Import JSON ConstrucitonSets?

Hi @chris,
This can be an obvious question but … how to import a set of constructions that i have as a JSON file?
For instance see attached example. It is located at C:\Users\XXXXX\ladybug_tools\resources\standards\honeybee_standards\constructionsets
Trying the SearchConstrSet i see there is a compulsory input (climate zone) and two more. I think i’m missing something but can’t get what is it.

MySets.json (17.9 KB) .

Hey @AbrahamYezioro ,

So, if you have dropped that construction set into your standards folder, it is in you library and you can assign it to Room objects in your Grasshopper definition using the identifier of the ConstructionSet (in your case IS_Set_5282_A_e32f10a1). It’s just a “display” issue that I haven’t made a component to show you all of the construction sets in your library at once. I have been debating whether it’s better to make a whole separate component for this or try to tweak the other “Search” components to be able to display all of the objects in the library. Let me know if you have any thoughts.

FYI, while I was putting together a sample to show you how to re-serialize your ConstructionSet from JSON, I discovered a bug in the “HB Load Objects” component. You can find a fixed component in this file: (10.5 KB)

And you can see that this provides another way to load up objects from JSONs, which does not rely on dropping them into your standards folder:

One more note: If you ever want to embed your custom ConstructionSet into a .gh file so that other users don’t need to have it in their standards library or re-serialize a JSON that you provide, you can internalize the JSON string in a Grasshopper Data parameter component and use the “HB String to Object” component like so:

Hi @chris,
It works as you explained. This is good, since i was worried that it is not possible. Which it isn’t under the existing search sets component.

Here i think that to be consistent with all other search components, the SearchConstrSet should allow to look for self-defined sets. Though i’m afraid this means changing a lot of it. I think also that as it is it is useful (very) to US user specially. But other places that might have own standards and requirements will not have a good use of it since it is no relevant.
Maybe the input filters can be implemented in another (new) component just dedicated to ASHRAE definitions and the existing component be more general.

Not sure if this makes sense for you. What do you think?
Thanks again,

Have another question (sorry),
I tried to stream with the ObjToStr component 2 (or more) construction sets. Pasted the panel into the JSON file, added a “,” between them to allow more than 1 in the file.
When i try to import using your method above the LoadObjects component complains about:

  1. Solution exception:Extra data: line 420 column 2 - line 840 column 2 (char 18636 - 37295)

I was expecting from it to give me a list of set names where i can pick one of them, as in the searchSets.

Obviously i’m doing something wrong. Can you help?


I managed with the file. It was a problem of curly parenthesis.
But when reading the file it only show one name instead of the list of set names.

Thank you, @AbrahamYezioro . I realize that this is a slight digression from the main issue we are discussing but I wanted to clarify that the construction templates are probably not as US-centric as you might think. Because they represent the guidelines of the International Energy Code Council (IECC), they are used as the basis for the energy codes that many countries adopt. Admittedly, each version of the IECC code is based off of a version of ASHRAE 90.1, which is why you see both a version of IECC and ASHRAE 90.1 for each option in the “HB Building Vintages” component (I realize that it was definitely US-centric of me to put the version of ASHRAE before the IECC one).

But, to make an analogy, saying that those ConstructionSet templates are US-centric would be a bit like saying the metric system is France-centric. Just because a standard happened to be first developed in a particular county doesn’t really make it centric to that country after the rest of the world adopts it as a basis for their standards.

With all of that said, what do you think about the following solution:

  1. For ConstructionSets, we will have two separate components. One that’s called “Search Construction Sets” (returning all construction sets filtered by keyword) and another called “Construction Set by Climate” (returning just one construction set according to climate zone).
  2. For ProgramTypes, we will still have the one component but, in the event that no building type is connected, all Programs in the library will be displayed and optionally filtered by keyword.

Does this sound like a good plan?

Re: the issue with writing multiple construction sets into one JSON file, I recommend that you use the “HB Dump Objects” component for this purpose. If you connect up a list of construction sets to the _hb_objs of this component, it will automatically format them correctly so that the multiple sets get written into one file. All of honeybee expects such “multiple objects” JSON files to be written as a dictionary (curly brackets) with the identifiers of the objects as the dictionary keys and the definitions of the objects themselves as the values (similar to what you see here in the honeybee-standards repo). But the Dump Objects component takes care of all this formatting for you.

Also note that you can use the indent_ input of this component to make the resulting JSONs more readable in a text editor.

Thnaks @chris,
Just before i get your response i figured it out. Works just fine and this is exactly what i wanted.
You all did a great job with all this [+], allow me to say!!

Hi @chris,
This sound excelent.
I’m sorry for the bad use of words i made regarding US/ASHRAE/etc. You are right. I think though that some explanations should be provided for this and probably other libraries. Users need to be educated a bit, or at least know what is behind those libraries. I’m sure that you’ll provide the link for that explanation that i just didn’t looked for … :upside_down_face: :wink:

You all did a great job with all this [+], allow me to say!!

Thank you, Abraham. It’s really rewarding to hear that after a year and a half of full time work on this and also to see you understanding some of the same awesome powers that the JSON schema gives us. The development and refactoring of this schema was a lot of work but it’s really paying off now. Not only is it the reason why we can easily save and share different honeybee objects but it is also the reason why we are currently able to produce plugins for Revit and (standalone) Rhino without having to re-write 90% of the code (since all of these plugins write to the same, simplified JSON schema and we have one core Python library that handles all of the translation of this JSON to the various simulation engines). It’s an exciting new world and I’ll admit we didn’t even realize the size of it when we first started developing the schema.

In any case, glad that you agree with the plan for the construction set and program type components. I will try to implement this today and let you know when it’s ready for testing.

And those were definitely not bad words about US/ASHRAE. They reflect the view that I used to have before I understood how building energy codes are typically produced throughout the world and that governments (or organizations like the IECC) tend to start with other standards that are broad enough to cover a range of climates and they then “re-brand” the part that is applicable to their relevant climates as their own, possibly adding a few amendments or exceptions in the process. I can understand why all this “re-branding” happens but it has a downside where many of us don’t realize that all of our standards are actually not that different from one another. I definitely plan to make some more public posts about this and discuss it in video tutorials after we have the Food4Rhino release.

And, for lack of a more official reference right now for this explanation, this post about building envelopes in particular provides a good summary of the relationship between ASHRAE 90.1 and IECC.

@AbrahamYezioro ,

I just wanted to let you know that I merged in the changes to the “search” components. So feel free to update and let me know any thoughts.

And, maybe just to add a little more credibility to the statement I mentioned earlier about how energy codes are usually derived from other codes, I can say it happens a lot on the local/state level in the US. In the state I live (Massachusetts), there’s a “Massachusetts Stretch Code” that seems to have come from the ASHRAE Advanced Energy Design Guides (AEDG). And California famously has it’s state-wide Title 24 energy code but the current version of it is virtually equivalent to ASHRAE 90.1 2016 as you can see from this map here.

Hi @chris,
Trying to break it but couldn’t so far. Thanks!!
Seems to be working very well (as expected :wink:).

You have my whole credibility. The map you sent is a very good source. Thanks for that. I believe such type of sources can be added to the website. At least for a few of us that want to know beyond the capabilities of the tool and understand where things are coming from AND why, it will be nice.

Thanks again,

Thanks @AbrahamYezioro . Glad to hear that the components are working.

And thanks for the vote of trust, though you are right to point out the fact that including other sources is always helpful. I guess it’s just a little tougher to cite sources for this type of thing (the adoption and enforcement of standards) compared to the typical citing of scientific sources that we do. I get the sense that, while the people developing codes and standards use some of the same techniques as we do in the natural sciences (eg. building off of others’ work), there doesn’t seem to be as strong of a precedent in their community for citing their own sources. I don’t know if this is because there’s some general sense that codes and standards are a little subjective and therefore don’t need sources as much or if it’s because citing another’s work interferes with branding a new code as ones own or maybe in creates confusion for people enforcing the code to know that two standards are virtually equivalent to one another but differ in a few small respects. In any case, I often find myself having to use more informal sources to understand where certain standards came from.

Hi @chris,
Maybe is more a wish i have. I’ll be glad if more users are aware of the science (maybe just the sources) behind the topics LB covers. For them (us) will be much valuable, having that info, to understand better what are they are doing and not just relating to the task as a technical one with nice colors at the end. Sometimes i get frustrated on this.
Well … is a nice discussion to have.

I understand the frustration @AbrahamYezioro . I can at least say that we have been pumping the core libraries full of sources where we can, like you can see by checking any page of the ladybug-comfort or ladybug-core docs. And we will continue to try to write sources into the Grasshopper component descriptions. But is there something else that you had in mind other than these two things?

These pages are excelent @chris!!!
This is what i meant: You have the more technical part but you also have the back up for that. Very good!!
I admire the amount of work all of you have put in this. This is serious work.

Glad to hear that the SDK docs should satisfy your needs here. I think once we can assemble a central location that has links to all of the separate Python library documentation, it will be a really useful resource for a lot of people. Just to give you a sense of scale here, this is what the Ladybug Tools core SDK looks like right now:

Each one of those boxes is a separate repo/Python package and each repo has its own docs website. Each docs website has 5-50 different web pages depending on how many modules there are in the Python package. So there is a lot of detailed stuff there for you to reference, search through, and use to build your own components or Python scripts.

We “did open source right” this time around :smile:

Hey @chris and @AbrahamYezioro, allow me to continue your long and passionate conversation! US/ASHRAE construction standards are definitely useful and reuseable in our projects all over the world, just as the metric system outside France! (thank you for not using Btu / square feet / full moon in Ladybugtools by the way !! ;-)).
The new HB Search Materials and HB Search Constructions seems to be only useable for default libraries. It is planed to extend it to user libraries?
For the moment, I use the component Dump Objects and Load Objects for it, but retrieving the single objects with the Item Selector is not very convenient (the full json object is displayed)


See here the project user library : user_library.json (15.0 KB)

Thanks one more time for all your great achievement!

Hi @Romain. If you have created Json file and the file is dumped in standard under construction you can directly access that through honeybee search ep construction component.