There is a lot more tightening up and polishing of the meta-model. This includes documentation updates for normalization, associations, and relationships.
Ontology
This version includes a port of almost everything from Haystack 3 in terms of tags and point types. At this point if you notice something modeled in Haystack 3 which is not found in Haystack 4 please let us know in case its an oversight.
I originally had a plan to try and model all points with a subject and quantity choice, but getting into the last 20% of points like heat wheels, faceBypass, etc that gets a little ugly. So I've kind of given up on that plan. But if you are interested and want to try to bring that consistency to the point ontology, let me know and we can work on it.
There is a lot of different ways to go with modeling the typical children points under equipment. What I've done to try and limit combo explosions is to pick an example for tags such as phase or stage (with tools then letting you select other options). An example of this technique the points under an ac-elec-meter.
ChangeLog
Version 3.9.7 (3 Oct 2019)
Cleanup relationship defs
Make containedBy, contains relationships, not associations
Add accumulate marker for normalization
Use produces instead of supplies for equip level functionality
Finish elec-meter points
Finish actuator points
Finish ahu points/tags: freezeStat, heatWheel, faceBypass
Brian Frank Thu 3 Oct 2019
We have upgraded the project-haystack.dev with a new version.
See previous version notes:
Docs
There is a lot more tightening up and polishing of the meta-model. This includes documentation updates for normalization, associations, and relationships.
Ontology
This version includes a port of almost everything from Haystack 3 in terms of tags and point types. At this point if you notice something modeled in Haystack 3 which is not found in Haystack 4 please let us know in case its an oversight.
I originally had a plan to try and model all points with a subject and quantity choice, but getting into the last 20% of points like heat wheels, faceBypass, etc that gets a little ugly. So I've kind of given up on that plan. But if you are interested and want to try to bring that consistency to the point ontology, let me know and we can work on it.
There is a lot of different ways to go with modeling the typical children points under equipment. What I've done to try and limit combo explosions is to pick an example for tags such as phase or stage (with tools then letting you select other options). An example of this technique the points under an ac-elec-meter.
ChangeLog
Version 3.9.7 (3 Oct 2019)
Madhushan Tennakoon Thu 3 Oct 2019
Hi Brian,
Thanks for the update. Does the elecMeterLoad def need to be included in the list of defs or is that under review (or maybe under a different name)?
Link to Haystack 3 documentation: elecMeterLoad
Thanks
Brian Frank Thu 3 Oct 2019
yeap the load tags are missing, thanks for posting
Cory Mosiman Wed 9 Oct 2019
Hey Brian,
Will there still be the concept of
enable cmd
,run cmd
, andrun sensor
? I am basing on the State of Utah Haystack Tagging Reference. For exampleHaystack 3 | Haystack 4
Has the equivalent of a
run sensor
been ported to Haystack 4? Is acmd
andstate point
equivalent in Haystack 4?Thanks for all the hard work!
Brian Frank Wed 9 Oct 2019
I have not ported the prose documentation, but the points are in the ontology. For example see children section of motor.
Note I added the
state
tag as part of my effort to try and model "control phenomenon".Also note that I am not expanding every combination of sensor/cmd. For example motor's points are listed as:
This implies the sensor/cmd/sp choice is made later (in tool or on your own). The alternative would be list points like this:
But I think it would add too much noise to the docs.