You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are putting together some tagging conventions and came across the following. This is an aggregate issue to document multiple things.
Proposed concepts / entities:
multiSensor: subclasses from equip - generic grouping of sensor points being captured by a single physical sensor (like an IoT sensor capturing occupancy, light, temperature, etc.). It seems different than a pointGroup as we want to indicate the physical thing that is capturing all the sensed points. Obviously, things like elec-meter are a multi-sensor in a way, except that we have a good term of art for them, whereas these more generic sensors I feel like we don't. usage: {multiSensor equip}
elec-circuit: subclasses from equip - represents an electrical circuit. could also potentially just be circuit (as these are typically understood to be electrical), although elec-circuit is more explicit. usage: {elec circuit equip}
`elec
alarm: many people use an alarm marker already to indicate a point as an alarm
dehumidifier-equip: subclasses from equip. usage: {dehumidifier equip}
energyRecovery. Not sure exactly how to propose. We use this internally at the equipment level of an ahu with the enumerated values limited to: [heatPipe, heatWheel, runaroundLoop, flatPlate]
smoke: likely used with an alarm, something like {smoke, alarm, point}
preHeat, preCool: used on a point or a coil to indicate it is associated with conditioning the fluid before the primary conditioning occurs.
modulating vs. twoPosition: used on an actuator to indicate whether it can be fully modulated (0-100%) vs. just open / close. usage: {modulating valve equip} or {twoPosition damper equip}
status: Historically, {run sensor} has been used to indicate status. It seems like such a common use case that we should just have a status marker tag. A {run sensor}, especially on something like a valve, doesn't make too much sense. Status plays nicer IMO. usage: {status point equipRef->@valve}.
compressor: I think a compressor is a specific type of motor, similar to a fan-motor or pump-motor. This could subtype from motor. Usage: {compressor motor equip}. Raised by 874
suction: used on a compressor wrt the suction pressure, i.e. {suction refrig pressure sensor point}. Also raised by 874
runTime: Support for something like {runTime sensor point}, i.e. on a compressor / fan / etc. typically measured in a temporal unit (minutes, hours, etc.)
Questions:
I was wanting to propose some sort of loop. I see there is plantLoop, but it is not a marker as I would have expected. Can somebody describe how that would be used? I was thinking there would be a {chilled, water, plantLoop} or a {plantLoop, systemRef->@chwsys}, something like that. Same goes for condenser and hot water loops.
The text was updated successfully, but these errors were encountered:
Hey Haystack Community,
We are putting together some tagging conventions and came across the following. This is an aggregate issue to document multiple things.
Proposed concepts / entities:
multiSensor
: subclasses from equip - generic grouping of sensor points being captured by a single physical sensor (like an IoT sensor capturing occupancy, light, temperature, etc.). It seems different than apointGroup
as we want to indicate the physical thing that is capturing all the sensed points. Obviously, things likeelec-meter
are a multi-sensor in a way, except that we have a good term of art for them, whereas these more generic sensors I feel like we don't. usage:{multiSensor equip}
elec-circuit
: subclasses from equip - represents an electrical circuit. could also potentially just becircuit
(as these are typically understood to be electrical), althoughelec-circuit
is more explicit. usage:{elec circuit equip}
alarm
: many people use analarm
marker already to indicate a point as an alarmdehumidifier-equip
: subclasses from equip. usage:{dehumidifier equip}
energyRecovery
. Not sure exactly how to propose. We use this internally at the equipment level of anahu
with the enumerated values limited to: [heatPipe, heatWheel, runaroundLoop, flatPlate]smoke
: likely used with an alarm, something like{smoke, alarm, point}
preHeat
,preCool
: used on a point or a coil to indicate it is associated with conditioning the fluid before the primary conditioning occurs.modulating
vs.twoPosition
: used on an actuator to indicate whether it can be fully modulated (0-100%) vs. just open / close. usage:{modulating valve equip}
or{twoPosition damper equip}
status
: Historically,{run sensor}
has been used to indicate status. It seems like such a common use case that we should just have astatus
marker tag. A{run sensor}
, especially on something like a valve, doesn't make too much sense. Status plays nicer IMO. usage:{status point equipRef->@valve}
.compressor
: I think a compressor is a specific type of motor, similar to afan-motor
orpump-motor
. This could subtype from motor. Usage:{compressor motor equip}
. Raised by 874suction
: used on a compressor wrt the suction pressure, i.e.{suction refrig pressure sensor point}
. Also raised by 874runTime
: Support for something like{runTime sensor point}
, i.e. on a compressor / fan / etc. typically measured in a temporal unit (minutes, hours, etc.)Questions:
loop
. I see there isplantLoop
, but it is not a marker as I would have expected. Can somebody describe how that would be used? I was thinking there would be a{chilled, water, plantLoop}
or a{plantLoop, systemRef->@chwsys}
, something like that. Same goes for condenser and hot water loops.The text was updated successfully, but these errors were encountered: