using standardized tags for column names

[christopherDT]

Hi @bbartling -- great work so far on this project! Work has really been speeding along! I've been testing it out and am really impressed with it.

I was wondering if there were plans to use names from a standardized schema/tagging library (like Brick or Haystack), particularly for column names in the data being fed into the program. For example, "economizer_sig" in some of the fault conditions is a bit ambiguous, and it took me some digging to realize it was apparently looking for outside air damper position, rather than a binary on/off economizer signal. Using standardized names would help with this ambiguity.

[bbartling]

Hi great suggestion....would you have any advice to implement haystack or brick? The basics for an AHU is that about 8 points are needed which then need to be translated into a string Python understands to make a Pandas dataframe column, so yeah that's an awesome idea. Am also experimenting with this in near real time in a VOLTTRON agent near real time FDD, so these are the required inputs for all AHU faults: https://github.com/bbartling/volttron-g36-fdd/blob/develop/G36FddAgentAhu/config Hopefully that link works let me know if you have any recommendations for a better point naming convention am more than happy to implement it.

…

On Tue, Feb 28, 2023, 2:37 PM Christopher Dudas-Thomas < ***@***.***> wrote: Hi @bbartling <https://github.com/bbartling> -- great work so far on this project! Work has really been speeding along! I've been testing it out and am really impressed with it. I was wondering if there were plans to use names from a standardized schema/tagging library (like Brick or Haystack), particularly for column names in the data being fed into the program. For example, "economizer_sig" in some of the fault conditions is a bit ambiguous, and it took me some digging to realize it was apparently looking for outside air damper position, rather than a binary on/off economizer signal. Using standardized names would help with this ambiguity. — Reply to this email directly, view it on GitHub <#6>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHC4BHJV353VNWZJRKKLET3WZZOZ7ANCNFSM6AAAAAAVLGNSG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[bbartling]

@christopherDT would have any advice for renaming these to a haystack or brick ontology?

                  "duct_static_setpoint"
                  "duct_static"
                  "vfd_speed"
                  "cooling_valve"
                  "heating_valve"
                  "mixing_dampers"
                  "supply_air_volume"
                  "supply_air_pressure"
                  "supply_air_pressure_setpoint"
                  "supply_air_temp"
                  "supply_air_temp_setpoint"
                  "mixing_air_temp"
                  "outdoor_air_temp"

[christopherDT]

I've been thinking a bit about this. In reality, I suppose the column names could stay as-is, and you could instead simply document how your names map on to one or both of these schemas, and that would equally reduce ambiguity.

Either way, how you label each depends on what system you want to use. To use just the point type, you can find the relevant standardized point type names for each schema online (e.g., for vfd_speed you could use Brick's Motor_Speed_Sensor , whereas for Haystack you could use vfd_speed_sensor (which is almost like yours, but in the Haystack system it is explicitly differentiated from vfd_speed_cmd, the fan speed command point).

Given the detail needed for your column names, however, I would think it could be useful to specify even further than just point type, and it looks like Haystack has a nice system you could implement. It looks like their system concatenates different vocabulary terms from their semantic model to create different points. In this case, you can add on where in the duct section the point falls. So since your vfd_speed is a supply fan speed sensor, you could use discharge_fan_vfd_speed_sensor. Likewise, supply_air_pressure_setpoint would become discharge_air_pressure_sp. Also, your mixing_air_temp could become mixed_air_temp_sensor, outdoor_air_temp would become outside_air_temp_sensor, and so on. So that helps differentiate some of these points, while using a standard system.

I think from that info, most of the names should be obvious. I'm not sure without looking through the docs what, for example, duct_static would translate to. I'm also talking with a colleague tomorrow to get more information, as he's more familiar with these schemas, I'll let you know if I get any other useful information.

[christopherDT]

Looks like Brick offers a lot of similar unambiguous options for sensor names as well, e.g. https://brickschema.org/ontology/1.3/classes/Outside_Air_Temperature_Sensor/, https://brickschema.org/ontology/1.3/classes/Mixed_Air_Temperature_Sensor, and so on. I'm compiling a csv with your column names above translated to both Brick and Haystack, I'll submit a pull request once it's finished.

[bbartling]

sounds great!

[acedrew]

A standardized way of defining an ontology-to-input mapping is part of what I think is in scope for the work I'm documenting here:
https://github.com/ACE-IoT-Solutions/open-building-analytics-wg
As I think you concluded above @christopherDT the rules themselves should be agnostic to how the data is sourced, and the 'engine' implementing the standardized interface will be able to translate as necessary for the platform it's running in or against.