Global variable ShadeType_ not defined when using Honeybee 0.59

Hello HB+LB community,

I am following the Shading Benefit example on Hydra (…) for a project.

I was having compatibility issues so I decided to upgrade most of the components to Honeybee 0.59. However, now I get an error that states:

“1. Solution exception:global name ‘shadeType_’ is not defined”

I noticed that the version 0.58 has an input for the shadeType_ but it’s no longer available in 0.59 so I’m not sure how to get it functioning.

Thank you,

Justin (610 KB)

I discovered when the Shade Generator component was updated from v0.58 to v0.59 the shadingType_ input was not added to the component. I dropped in the v0.59 Shade Generator and the input is now available.

At the moment, plugging in the cooling loads of the building to the zoneData is freezing the simulation so I’ll see what I can do.

I now receive a new error that is more confusing:

“1. Solution exception:KeyError”

From the read me:


No shades schedule has been connected. It will be assumed that the shades are drawn when the setpoints are met.
Runtime error (KeyNotFoundException): KeyError
line 1015, in createEPBlindControl, “<string>”
line 1185, in main, “<string>”
line 1230, in script


Hi Justin,

Did you try to update the whole definition using update components and then recompute the definition? All the errors seems to be because of version discrepancies.


Hi Mostapha,

Thank you for the reply. I have now updated each component piece by piece with better success. However, following the Shading Benefit example on hydra with updated components to v0.59 freezes my Grasshopper. Running the EnergyPlus simulation is fine but when doing the shading benefit part the program freezes. Might there be something holding up the simulation?



I can see that there is a change between the hydra version and the updated version of the HB_EPWindowShades components. Specially with the last input items (data1, 2, 3), which in the new there is only data1.

I’ve tried adding the inputs in the component but the file works endlessly, so i assume some clarifications regarding those inputs will be welcomed.

Also in the HB_EnergyShadeBenefit inputs it is not clear now (for me) how the output of the Shads must be connected regarding the heating/cooling loads and beam gain inputs.



Glad that you were able to update the file.

Keep in mind that the shade benefit calculation usually takes a good 2-5 minutes to complete. It is projecting over 4000 sun rays from each of the 100+ test points on each of the windows so it’s fairly computationally intensive.

Just give it some time and you should get the result that you see on the Hydra example. I might also recommend running it for just one zone if you need faster feedback.


I experienced a similar problem as Abraham. When configuring the model to study benefits of shading the file runs endlessly. I let it run for 7+ hours and at the end did not receive any results.

Justin and Abraham,

Sorry for not looking deeper into this before. I didn’t realize how much the new capabilities that I had added to the zone shades component had damaged the shade benefit workflow. The big reason why the component was running endlessly was that when you add zoneData2_ and zoneData3_ inputs to the component, they were not being set to Tree access automatically (each item of the tree was being evaluated and this was causing the component to run 8760x4 times). The assigning of tree access now happens automatically. The attached file should work well without complications.

Also, I updated the Hydra example file:…

Let me know if you have any other questions and thank you for bringing this to my attention.

-Chris (590 KB)

Thanks Chris!!

All this time i was thinking that i’m missing something. Now it is clear again.