Hi @chris,
I’ve been trying to understand well the process of going from schedules and loads to programs, mostly using JSON libraries.
I think i’ve found a bug in this process.
I define a series of schedules, some of them using the WeeklySchedule component and some the ConstantSchedule.
I managed to save the definitions as a JSON file that i can retrieve with the LoadObjects component but not with the SearchSchs.
Wanted to use those retrieved schedules for program definitions. And here is the problem. The schedules defined with Constant values are not retrieved.
Thanks for letting me know , @AbrahamYezioro . I will investigate once I am back at my computer and let you know what I find.
FYI, when you serialize a ProgramType to JSON, it embeds the detailed schedule definitions within the JSON (unless you use the abridged_ option on the Dump Objects component in which case it’s expected that you put the schedules separately in your schedules standards folder). This is all just to say that you can create a ProgramType and store all of the data about it in a single JSON file.
So nice!!!
As a matter of working costume way of work, do you thing it is better to have all in one JSON or let the definitions be split? Maybe for debugging is better to have many pieces.
Give it an hour or two for the change to percolate through all of our integration tests and then you should be able to get it on your end with the versioner component.
For the question about whether to use detailed objects in your standards library (eg. schedules embedded in the program definition) or use abridged objects (eg. schedules referenced by identifier in the schedules folder), it really depends on how extensive of a standards collection you are trying to build and how/if you want to distribute it.
If you just want to create a few programs that are easy to share individually with other people, you might as well embed everything in the program JSON so that there’s only one file to share and there’s no risk of people missing a referenced file. This is why this is the default.
However, if you are trying to build a whole collection of standards and you plan to re-use the same schedule across several programs, you might want to just define it once in your schedules folder and have all of the other programs reference it by identifier (using abridged programs). This makes it easier to change that one schedule later and have all of the referenced programs updated. One thing to be aware of along these lines is that, when schedules are embedded under a program, they become specific to that program. So schedules that are embedded like this will not show up as their own element within the schedule library (they only exist within the ProgramType object in the programs library and, if you want to grab that individual schedule and use it elsewhere, you have to deconstruct that ProgramType). So this may be another reason why you want to use abridged programs. But just bear in mind that abridged objects can make it difficult to share your standards so, if you want to share or distribute standards in an abridged format, you should probably zip your whole standards folder.
Regarding the explanation of having everything under one roof or not, i understand and i was thinking about the same issues. There are pros/cons for both.
Another question: The JSON files have to be under the correspondent hierarchy of directories as what they contain? I mean a schedule JSON has to be on ladybug_tools\resources\standards\honeybee_standards\schedules directory?
Hey @AbrahamYezioro ,
Yes, the JSON files in the standards library have to be under the folder of the object they represent. So a ProgramType should go under the honeybee_standards\programtypes directory (even when it has schedules embedded in it) but a schedule on its own needs to go into the honeybee_standards\schedules folder.
Hi @chris, I have a further question about working with the unique numerical identifiers created with custom programs and schedules in v1.1:
Each time you make a change in a custom schedule, the numerical identifier following the name changes rather than overwriting itself (which makes sense). However, this means that to reference a schedule in my custom programs without it breaking with each number change I have needed to create a ‘Find and Replace’ workaround for listing the Occupancy schedules and Cooling/Heating setpoints schedules that feed into each Custom Program.
See attached for an example of how I’ve set up one of these custom programs along with the custom schedules it is referencing. The boxes in red show the workaround for naming.
Is there a better way to go about this process, or a way to make it more streamlined? The use of the numerical identifiers makes it more tedious to work with custom objects compared to simply naming them and having them overwrite with changes. I will be creating a few dozen custom programs, and at least a dozen custom schedules as part of a firm-wide resource library which can be pulled into individual Honeybee workflows as a .json. Being able to write to .json is an incredibly helpful functionality for this!
We realized that the UUIDs were becoming annoying and so we removed them from the schedules, programs, etc. in the development version of the plugin whenever you plug in a _name_. So you can run the “LB Versioner” component to get a version of the plugin where you don’t have to worry about this.
Alternatively, the last stable release on Food4Rhino has a component called “HB Set Identifier” which you can use to overwrite the identifier of any object to be whatever you want. So you can use that to ensure the ID of any object is exactly the same every time your Grasshopper script is run.
