- Solution exception:Expected Room. Got <class ‘honeybee.model.Model’>.
is there a particular need to facilitate model rather than rooms input into annual loads component?
In the context above there is no shades, aps doors etc assigned to the model; there is the shades_ input in the annual loads component as well as you can assign shades at the room level instead of the model level.
1 Like
No, but Model to OSM requires Model input, and this component, rooms. Just a little bit weird and wonder why there they use different input, nothing more. 
1 Like
If I am not mistaken; I believe that room level input on the annual / peak loads components is to enable easier ‘chunk-by-chunk’ addressing of the thermal zones that comprise the overall model while in the process of tuning the overall singular model.
But I could be wrong!
best
-trevor
1 Like
In my case, this component was calculating individual rooms’ energy loads. For example, if this is something like a test box, then this component is pretty much proper. To calculate the whole building’s loads, you may try “Honeybee Model to OSM” component.
1 Like
I realize that it feels a little odd but there were a couple of reasons why I implemented it this way:
- There are a few capabilities (eg. The Airflow Network) that aren’t supported in the direct-to-IDF methods used under the hood by the Annual Loads component. These features are only assign-able at the model level and so having the Annual Loads component only accept Rooms conveniently prevents this type of invalid input.
- The legacy plugins for energy simulation had been organized with a “rooms” and “shades” input instead of a “model” input so I figured there’s a precedent for a component being formatted like this.
I am not totally wedded to this format, though. I’m happy to enable the _rooms input to accept a model if people don’t want to go through the extra step of deconstructing a model into Rooms and Shades.
2 Likes