This error doesn’t have quite as much to do with the change in LBT version but rather the IronPython that Rhino is using. I think some people might have gotten this issue as a result of Revit’s IronPython interfering with the one that Rhino uses.
Did you install Revit on your machine (or anything else using IronPython)? If not, what version of Rhino are you using and are you on Windows or Mac?
Thanks @chris for getting back to me on this. Here what I can say:
I’ve never installed Revit, but I am not sure if anything else uses IronPhyton. But I can say I am literally using no other plugins than those of yours (this time installed via your one-click installer).
Rhino 7.27.23032.13002, 2023-02-01
This happened on my Mac, but my student with a PC had the same issue with HB Thermal Load Balance component (but as I remember not with HB End Use Intensity).
Please let me know if I can provide any more detail on the problem.
I am really sorry that I should have done a better test when you first reported the issue. You are right that it is a bug that was introduced 2 years ago in this PR. The bug only affects people using Mac, which might explain why we have not seen it until now. It looks like there was just a missing import statement for OrderedDict. I just added this in via this PR:
Long story short, if you update by using the LB Versioner, you should get the fixed component on your end.
The issue that your student experienced with the HB Thermal Load Balance component must have been with a very old version of the LBT plugin since I can’t see any way that the error would have happened with LBT 1.6 and the code used by that component.
Thanks @chris for chasing this.
But I just checked HB Thermal Load Balance from LBT 1.6.51 on a Mac and still connecting solar gain to the balance crashes the component. Anything I can do to help you diagnose the bug on Mac?
Ah, sorry that I missed seeing that you were trying to report two separate bugs in a single topic. In the future, it’s likely better to open two separate topics when this happens.
In any event, I opened your original file and I could see that the solar data could not be matched whenever you connected individual Honeybee Rooms to the _rooms_model input of the HB Thermal Load Balance component. It looks like this happened because EnergyPlus introduced a concept of Spaces as distinct from Zones in their last release. You can get around it if you connect the whole Honeybee Model to the _rooms_model input. The fact that it works for the whole Model is probably why we have not noticed the issue until now because it’s usually recommended that you connect the whole Model unless you’re trying to understand the load balance of a particular subset of Rooms.
I have a fix ready for the case that you connect individual Rooms:
But, for now, just connect the Honeybee Model object instead of the Room object and it will work.
I wondered if deploying it via the published fix on GitHub (instead of the LB Versioner) might work for some reason, but I’m not sure what to do with the Source code.zip folder once it’s unzipped. I’m sure that’s just ignorance on my end, but any help/guidance you can offer would be greatly appreciated. Thanks for all of your hard work on this fantastic tool.
The component with the fix will have a version number of 1.6.1 (or greater).
After running the LB Versioner, you will have to drag/drop a new component with this version onto your canvas since the 1.6.0 component is not updated automatically in your older Grasshopper definition. Or you can use the LB Sync Grasshopper File component to automatically sync all of the components on your Grasshopper canvas with the version installed in your toolbar.
