Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Running List of Concepts to Add #6

Open
13 tasks
corymosiman12 opened this issue Feb 22, 2021 · 0 comments
Open
13 tasks

Running List of Concepts to Add #6

corymosiman12 opened this issue Feb 22, 2021 · 0 comments

Comments

@corymosiman12
Copy link

corymosiman12 commented Feb 22, 2021

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 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant