Is anybody interested in having a WG to stub out the tags for indoor air quality? Seems like RESET is gaining a lot of traction, with the required air sensors: PM2.5, TVOC, CO2, CO, Temperature, and Humidity.

Would be willing to champion this group if there is interest. I don't think it would be a ton of work.

Hey all,

Is there a process for this? How do we present to Haystack community? Provide back thoughts / comments? Thanks.

Initial Concept, formatted to align with Brian Frank new Type System (only included the diffs, not everything from the AirPoint.phd file):

//
// Copyright (c) 2011, Project-Haystack
// Licensed under the Academic Free License version 3.0
//
// History:
//   22 Feb 2011  Brian Frank  Creation
//   14 Jul 2018  Brian Frank  Rework for new def design
//   14 Nov 2018  Test for RESET params

/*************************************************************************
** AirPointQuantity
*************************************************************************/

// Quantity or apparatus of air measured or controlled
def AirPointQuantity : Choice
{
  // Particulate Matter 2.5.  This is an atmospheric pollutant of fine particles with
  // an aerodynamic diameter of 2.5 micrometers or less
  def pm25 : Marker
    pointUnits: ["µg/m³", "ppb"]

  // Particulate Matter 10.  This is an atmospheric pollutant of fine particles with
  // an aerodynamic diameter of 10 micrometers or less
  def pm10 : Marker
    pointUnits: ["µg/m³", "ppb"]
  
  // Carbon dioxide level
  def co2 : Marker
    pointUnits: ["ppm"]

  // Total volatile organic compound (TVOC).  This is a general term applied to the
  // overall total volatile organic compouns (VOCs) detected.  TVOC detection is
  // used to simplify reporting when VOCs are present.
  def tvoc : Marker
    pointUnits: ["µg/m³", "ppb"]
}

TODO:

• RESET certifies to three grades, do we want to capture grades A, B, and C somehow...Enum called resetCertGrade: ["A", "B", "C"]?
• Do we want to specify as a zone point? May get confusing...
• How to associate with RESET certified params...? Thinking some type of Marker like resetParam

Cory: I will add those into the 551 prototype for now. But would really be better to have a few more people in this working group to weight in on the terms and definitions.

Will throw my two bits worth into the air quality tags:

Most of the low cost particle sensors these days are based on a laser which counts the number of particles going past a detector, they report their results as the number of particles in a given volume.

The more scientific method which a meteorology station would use is to run a known volume of air through a filter and measure the weight before & after the test. This will yield a result in ug/m3 but its a much more expensive sensor.

You can convert from #particles / volume to ug/m3 but this involves assuming a certain shape of particle and estimating the pollutant density.

To properly reflect what's going on inside these low cost laser based particle sensors I'll suggest an option to report the units as #particles/volume.

Hi,

I'd also like to see these formalized into haystack and agree with above posts. These multi parameter IAQ sensors are becoming more common. I've used the same point tags as Cory outlined above on past projects which lends to their validity to me.

We also made an equip tag of airQuality which i'd like to propose be added. Many or our indoor air quality projects are just these multi-parameter sensors and aren't connected to the building automation system, so don't have an ahu or vav to associate with. Also the sensors generally "cover" an area or zone that spans many terminal units.

I like the idea of resetCertGrade also. In my experience we have only used B.

Cory for the parameters are you referring to the sensor thresholds? ie. co2 above 1,000 ppm. For these we made some simple threshold rules.

This is a great idea to add RESET into Haystack.

The one issue that I see with your definitions is that some points are allowed to be ["µg/m³", "ppb"]. The issue with this definition is that µg/m³ and ppb are not equivalently derived units.

µg/m³ is a weight per volume and is easily convertible from the SI standard for mass concentration kg/m3.

ppb is a dimensionless unit. It is very similar to %. Where % is effectively saying 1/100, ppb is very similar to saying 1/1000000000.

To convert from ppb to µg/m³, it has to be multiplied by molecular mass/molar volume. (We should avoid incongruities like this.)

Both µg/m³ and ppb can be useful measures of concentration and each have their advantages/disadvantages. But are both used with these measurements?

PM2.5 and PM 10 are definitely measured in µg/m³, but are there cases where they are measured in ppb?

TVOC is definitely measured in µg/m³. I think it is also measured in ppb, but I’m having an issue finding a reliable source for this. Does anyone have a good source showing TVOC measured in ppb? Since these would technically be providing different measurements, do we consider this two different types of points requiring different tags?

I am inviting an expert on this topic. Let's see if she can help us with this.

Yeah, it wouldn't be ppb, it would be particles / volume. My usual sensor module from Korea reports in this way.

However, I just checked through a few data sheets of other modules and some are reporting their results in ug/m3, they may be making assumptions about the density of the pollutant. I had Sensiron in my office the other day and meant to ask, will check and report back.

OK, so Sensirion is not divulging much about what's going on inside their sensor but we can read both ug/m3 and also a bin count for the number of particles per volume of air for each size category. So both engineering units will be useful: ug/m3 for the gravimetric type sensors as they're called and # particles/m3 for laser based particle counters.

Hey all,

Link to the Kaiterra API

Link to the Tongdy MSD Cutsheet

It seems like they are just doing:

• Particulate matter as a density (ug/m3, mg/m3)
• TVOC as a density or concentration (mg/m3 or ppb)
• CO2 as a concentration (ppm)

These are the two sensor models I am familiar with. Anybody have any others...?

To run off of Ben's point, we are also seeing increasingly more multi-sensors, not necessarily connected to the BMS, but maybe as installed with a lighting control system or as a standalone data collection system. Is anybody in favor of identifying a multiSensor to qualify an equip? This could then be nested to another equip (VAV, AHU, etc.). This has an obvious issue of not being able to disassociate an occupancy point and an ambient light point, that are both part of a single multi-sensor to two different equip for logical control association.

We have, however, seen the use case where we are using multi-sensors as data gathering points as opposed to only control points. Not sure if this should be tackled as part of the scope of this working group, but just trying to think of an elegant way to handle this.

I feel like we will be getting to a point soon where a single sensor will be providing the input to multiple different control systems, and wondering how best to attack that. As this seemed a relevant working example of it, I thought I would bring it up here. Thoughts...?

Any additional thoughts from the rest of the group? Would like to see this get finalized.

Hey Brian,

As no additional comments have come in, I think we can go ahead and close? I think these updates to just get rolled into the 4.0 prototype?

Is there an official process for concluding working group?

Cory, we are able to compile phSandstar now. I am interested in getting these tackled for a project that we are actively working on. Lets schedule a meeting over it.

The WG process is described in WG 404

Yes I mapped this proposal into 4.0 ontology. If you guys have reviewed and everyone is happy, we can close it out.

For now lets mark it In Review

I think this can be closed out at this point, unless anybody else has other objections.