I would like to discuss this weather definition and how haystack uses the air tag to differentiate between air temperatures. It seems that that dry bulb temperature points get the air tag, but wetBulb, apparent, and dew temp points do not.

In the definition of the air tag, it states that it denotes a point that is "associated with the measurement or control of air." I think that wet bulb and apparent and dew temp points definitely fall into this category by defining the characteristics of the air, in the same way that we use the air tag along with humidity or pressure or flow on AHU points. However, if air was added to these other temperatures, then we are faced with dry bulb temp tagging being non-unique. A query for "air and temp" would then return all temps, be them wet bulb, dry bulb, or dew.

I propose that a dryBulb tag is added to dry bulb air temperatures in order to be specific, and that the air tag is used on any points that measure the air in the weather section, including wetBulb, dew, humidity, enthalpy, pressure, and wind.

I understand the convenience of not having to specify dry bulb when querying. However, while slightly less convenient, including a dryBulb tag improves the consistency of the haystack tagging scheme, and is much more intuitive for the usage of the air tag.

I second that. We use drybulb internally for that very reason

I agree. Good suggestion.

For us as well, there have been several cases where air vs. dew and wetBulb was a point of confusion for us, but we've been able to work around it in most cases. I would support use of air to tag any air temperature (dry bulb assumed if no qualifier given), with dryBulb, wetBulb, and dew as optional qualifiers.

If it's ok, I'd like to limit the scope of this proposal to weather points for the time being. It will help to keep the discussion focused.

As I understand it, the proposal is this:

1. Add new tag dryBulb: used to identify weather point for "standard" outside air temperature (previously tagged as just weatherPoint air temp)
2. Outside air temperature points would now be tagged weatherPoint dryBulb air temp
3. Add the air tag to existing weatherPoints:
   1. weatherPoint wetBulb air temp
   2. weatherPoint air apparent temp
   3. weatherPoint air dew temp
   4. weatherPoint air humidity (*)
   5. weatherPoint air barometric pressure (**)
   6. weatherPoint air wind direction (***)
   7. weatherPoint air wind speed (***)

I have purposely excluded enthalpy because it is not a weatherPoint.

I am open to this proposal but would like to get further input on the following ideas:

I'm not sure it makes sense to add air to any of the points I starred in that list. Here is my reasoning

1. If we go this route, I think I would prefer to limit using the air tag on weatherPoints to those that specifically measure temperature
2. The context of this discussion is specifically weather points, and I'm not sure adding air to the starred tags really clarifies anything.
3. I'm not sure it makes sense at all for humidity which is a ratio; a measure of air-water mixture
4. For the other starred tags, if we really want to use air, I would like feedback on changing the points to this instead. But I think I'd much rather leave them as-is as they are using standard "weather terminology"
   1. weatherPoint air pressure (remove barometric)
   2. weatherPoint air speed (remove wind)
   3. weatherPoint air direction (remove wind)

One of the problems with adding air to all the weather points, is that it actually makes it harder to determine the dryBulb temp. Suppose someone tags all those points with air and temp, but does not use dryBulb on the OAT (because it is assumed). When I do a haystack filter for weatherPoint and air and temp I will now get back up seven (7) points; or I have to explicitly filter out the ones I don't want:

weatherPoint and air and temp and not (wetBulb or apparent or dew or wind or pressure or humidity)

That's a pretty brittle approach if we ever add another weather point that also uses air and temp.

Finally, (sorry for the long post), I would like feedback on the idea of completely removing the use of the air on weatherPoints. I know this is kind of the opposite of Jay's proposal, but wanted to explore this too. I feel that air doesn't really add any value in the context of weather points. So the various temperatures would become:

1. weatherPoint dryBulb temp
2. weatherPoint wetBulb temp
3. weatherPoint apparent temp
4. weatherPoint dew temp

This doesn't solve the problem of assuming dryBulb if the other tags are missing. But it does make the weather point tag model potentially more concise while not sacrificing the meaning of the points.

As an aside, I'm not sure I'm a fan of "assumed" or "default" tags for points. It adds complexity to applications that want to query against these points. You basically have to always assume the worst case and do a bunch of explicit filtering, which, in my opinion, kind of defeats the purpose of having a semantic model. It's supposed to be easy to find the points you want. Right?

So I'd rather say that if we add dryBulb we make it required. If applications want to support old tagging model, that is a burden applications can choose to take on. But it shouldn't be official tagging model for the points as far as Haystack is concerned.

Look forward to additional feedback.

Great points Matthew. Thanks for the discussion everyone.

Matthew, your understanding of the proposal is correct. Fundamentally, my proposal aims to implement the air tag according to its definition across all systems. That is, apply the air tag to all points that measure a characteristic of the air. This causes problems with the weatherPoint temperature points because no dry bulb tag is currently defined, so the proposed dryBulb tag was seeking to fill this hole.

To respond to your list:

1. I disagree. There are many more things that can be measured in the air than temperature. For example, humidity, CO2 concentration, pressure, etc. This is indicated in the tagging of ahu points.
2. I don't think it necessarily clarifies anything, but it improves the consistency of the tagging model. If I query for air points, I would expect to see all points that relate to air measurements, regardless of whether they are on an ahu a vav or a weatherPoint.
3. I definitely think including air with humidity because relative humidity is as much an air characteristic as dry bulb temperature or dew temperature. You cannot measure the relative humidity in something that is not a gas. Furthermore, we include air on humidity points on AHUs.
4. I don't feel too strongly about these. They still are measurements of the air, but do seem a bit redundant. However, I prefer redundancy if it means we can use air consistently.

Internally, we also include outside on all these points, for consistency with the outside definition here. If we are already changing things, maybe it makes sense to include adding outside to all these points within this proposal.

I absolutely understand the convenience of simply querying for "air and temp" rather than "air and dryBulb and temp". However, I don't believe that this conciseness should be preferenced above the consistency and intuitive nature of the tagging model.

Again, thanks for the discussion everyone. I look forward to hearing your interpretations.

I agree that drybulb should be added as a tag if we use wetbulb or dew with temp. I also agree with Jay that these points should really have an outside tag. Here is my train of thought:

As I understand it the basic Haystack tag set for a sensor tells you: the "location", the "medium" and "what" was measured. So...

• [where][fluid type][measurement]
• discharge air temp
• return water temp
• zone air co2

There can be additional tags for these ( chilled, sensor, point, etc), but this is the basic formation.

What we are talking about measuing are values that is being read from the outside air. Shouldn't they be:

• outside air temp
• outside air humidity
• outside air pressure
• outside air direction
• outside air speed

Theoretically, other tags should be added to help improve the definition of a specific point ( drybulb, wetbulb, dew, barometric, wind)... Unless we stop trying to use wetbulb or dew with temp

I think part of our problem is that drybulb is a simple temperature measurement where dew and wetbulb take into account humidity and are not the same type of measurement (yes, wetbulb can be measured by the same instrument if it is slightly altered and yes, they are recorded on the same scale and yes, they are related to each other (with humidity), but they are not the same). So, shouldn't the tag sets really be:

• outside air temp
• outside air wetbulb
• outside air dew
• outside air humidity
• outside air pressure
• outside air direction
• outside air speed

If someone asks you for the air temp, you aren't going to tell them the dew point. By itself, temperature has a meaning... adding wet bulb or dew point to it changes that meaning, slightly.

Regardless of the direction we go, there are going to be problems.

(If we are going to use apparent with a temperature value, its definition needs to be changed, but that should probably be a separate discussion)

I agree with the tag set as suggested by Keith. While wetbulb is measured in the same units as drybulb, that is about the only thing they have in common.. as Keith pointed out. So, tagging wetbulb also as a temp is not really accurate or meaningful, IMHO.

As Matt says, we want to avoid having to use a bunch of filtering with " and not.. and not.. " to get to the single point we want. This is probably something we should be discussing and evaluating over the entire model, and certainly with any new tagging models proposed.

This has been really good discussion; thanks to all who have chimed in so far.

I wanted to take a step back and ask, "What problem are we really trying to solve?"

Currently, all the weather points - when properly tagged - are uniquely identifiable (proper tagging includes not add superfluous tags like outside and air to all the points). The intention for these points is to specifically model the kinds of weather readings you get from a weather service or weather station. So I kind of feel like having the tag weatherPoint implies many of the suggestions that are being made. One could consider it a "meta" tag of sorts; it encapsulates many of the tags that people are proposing.

I think there is a balance that needs to be made between what is consistent, and what is pragmatic. The model has been around for years now, and I think it is working well. We need to consider the impact of any proposed changes. The ideas being proposed are actually breaking changes. See my earlier post about the impact to querying: any application that was querying for weatherPoint and air and temp and expecting to get back one point will now be broken. We should not underestimate the impact these changes would have: it's going to become harder to query for weather points correctly.

We use a similar framework to Keith when logically constructing a point name and its respective dictionary: [where][fluid type][measurement]

I don' think there is right or wrong here, but the general perspective we take at our organization which has allowed us to develop a robust tagging library and manageable database follows these basic principles:

We try to keep the tags as literal to what we are actually describing as possible, even if this means needing to update our library from time to time. wetbulb, drybulb, dewpoint, are all measuring temperature, but in different ways, so they should all get a temp tag if that is what they are measuring. Additionally they would need the following descriptors (wetbulb, drybulb, dewpoint) respectively to differentiate. We have found that following this approach makes these decisions simpler and less subjective. Likewise, if it measururing "outside air", those tags should also be applied. Often we also measure supply or return air dewpoint/humidity/drybulb, etc. as well.

While breaking changes are not ideal, I think being able to accurately describe our databases in a logically consistent manner, that can be universally applied across the databases is in the long term, more valuable. This does mean that libraries will need to continually evolve. If for example, thermodynamically it was disocvered by the community that there are actually multiple kinds of dewpoint temperature measurements (which there are not as far as I know), then we would need to add an additional tag to differentiate between the types and the code would have to be updated accordingly. Methods can be used to routinely scrub your database records and code so that you can programmatically cast necessary changes.

I'm not saying this THE right way, but it is functional and manageable for us, and more intuitive for users.

I've been following this discussion closely, as we use dry bulb, wet bulb, and dew point measurements quite a bit, and not just for weather stations. I would like to see a solution that generalizes to any relevant air temperature measurements, or commands for that matter. I agree with Adam that there's probably not a "right" solution, but I also agree with Matthew that's probably best to avoid breaking changes without a good reason.

Still, I think we can agree that in the long run it doesn't make a whole lot of sense for air to mean/imply dryBulb when it comes to air temperatures, and replace air with wetBulb if you mean something other than the dry bulb temp. It works but it strikes me as something that has evolved from not making breaking changes in the past.

In my opinion, an ideal update would meet these two goals:

1. Minimize code refactoring (i.e. minimizing breaking things)
2. Correct inconsistencies in modeling, so that the logic is intuitive.

There are clearly multiple ways to make changes. E.G.

• Is outside really needed for tagging weather points?
• Is it really necessary to always include air, if an air temperature is implied?
• Should temp be used in conjunction with the wetBulb and dew tags (i.e. wetBulb and dew as qualifiers) or should wetBulb and dew stand alone (i.e. as different types of measurements)?
• If dryBulb is defined, then should an air temp be required to have one of dryBulb, wetBulb, or dew, or is dry bulb temperature implied if wetBulb and dew aren't present?

Opinions in this thread clearly differ on these points. In light of the above two goals, what do people think about the above bullets?

Also, kind of as a process aside: if we want to give folks like to make app changes, maybe it would be good to start collecting a number of proposals like these that make significant changes and wrapping them into scheduled Haystack updates that folks know ahead of time are coming out. That would let app developers sync app releases that are compatible with tagging changes to when the changes go into effect, so to speak.

Great discussion guys.

With a focus on the two goals Steven outlined, my proposal contains the following parts. Each part seems to be fairly self-contained.

1. Add outside to all weather points: This is not a breaking change. While it may not be necessary, it does improve the consistency of the outside tag.
2. Add air to all temp, humidity, pressure, and wind weather points and add dryBulb to outside air temp: This is a breaking change, but improves consistency of the air tag to match its definition and the usage of air in the AHU docs. Addding dryBulb simply makes the outside air temp point unique after the air tag is addded to the other temps.
3. Keep temp tags on wetBulb, dew, and apparent points: This is because wetBulb, dew, and apparent points meet the definition of the temp tag as it is currently defined.

The resultant weatherPoint points would look like:

• weatherPoint outside air dryBulb temp
• weatherPoint outside air wetBulb temp
• weatherPoint outside air apparent temp
• weatherPoint outside air dew temp
• weatherPoint outside air humidity
• weatherPoint outside air barometric pressure
• weatherPoint outside air wind direction
• weatherPoint outside air wind speed

I think we should defer discussion of whether wind or barometric should be kept alongside the air tag to a separate proposal.

Please let me know what you think!

I am a big fan of consistency within the standard and multi-use of simple tags rather than a lot of specialty tags; however I also think every tag should provide value.

In my opinion by requiring drybulb with temp makes the temp tag essentially useless. Each tag should be able to group a number of items together in a useful way, but in that scenario querying temp would provide a list that the only thing those points would have in common would be the unit, which could have been found with the unit tag.

If we consider temperature measurements of things other than air (water, surface, etc.) it is typically referring to a measurement which does not consider other factors such as moisture levels or evaporation rates, making it the same as the dry bulb temperature is for air. Any measurement which considers other factors is really something different. I feel temp should only be used on dry bulb and anything else should have a different tag, even if that tag needs to be more clearly defined such as wetbulbTemp or apparentTemp.

Hi Leroy, thanks for contributing.

I definitely see your point. Although, I think querying via units can be difficult if different units are used for the same "measurement" (like some sensors using Celsius and some Fahrenheit). That said, I see value in your argument that dryBulb and wetBulb temperatures are different enough that the traditional interpretation of temp is not correct.

If I'm understanding correctly, you are suggesting a change to the temp tag definition to specify that when alongside air it is a dry-bulb temp. Is this correct?

That is a perfect way of putting it Jay!

That makes sense. Air temps should be considered as dryBulb unless tagged otherwise.

Just to be clear, @Leroy and @Jay are suggesting that the tag temp should not be used in conjunction with wetBulb or dew so we don't have to do something like the following:

read(air and temp and not wetBulb and not dew)

.. just to get the air's dry bulb temperature.

Right?

Hi Eric. Yes, both solutions would avoid having to query "and not x and not x" to get dry-bulb temperature.

To summarize the conversation so far, it sounds like there is good consensus on the following item:

• Add outside and air to all temp, humidity, pressure, and wind weather points to match the definitions of outside and air.

However, there is disagreement on how to make dry bulb temperature unique, specifically to avoid the "and not x and not x" when querying. This problem arises because air used to be how we differentiated between dry-bulb and other temperatures. The two proposed solutions are:

1. Define a dryBulb tag to be applied to dry bulb air temperatures. All non-dryBulb air temperature points keep the temp tag, including wetBulb, dew, and apparent. The resultant weather points would look like:

   weatherPoint outside air dryBulb temp
   weatherPoint outside air wetBulb temp
   weatherPoint outside air apparent temp
   weatherPoint outside air dew temp
   weatherPoint outside air humidity
   weatherPoint outside air barometric pressure
   weatherPoint outside air wind direction
   weatherPoint outside air wind speed

2. Redefine temp to specify that it represents a dry bulb temperature in air. Remove temp from all non-dryBulb air temperature points, including wetBulb, dew, and apparent. A modification for the apparent tag will likely be required. The resultant weather points would look like:

   weatherPoint outside air temp
   weatherPoint outside air wetBulb
   weatherPoint outside air apparent
   weatherPoint outside air dew
   weatherPoint outside air humidity
   weatherPoint outside air barometric pressure
   weatherPoint outside air wind direction
   weatherPoint outside air wind speed

Both of these solutions are breaking changes, but both avoid the "and not x and not x" situation.

We've heard a lot of good arguments in both directions. At this point, I think it might be valuable to have people vote for which solution (1 or 2) they prefer. My vote is for solution 1.

I am going to convert this thread to a Working Group. I think we are very close to settling on a solution but it might be best at this point to have a group phone call to hash out any further details. If you are interested in this topic, please join the working group. I will give a few days for people to join the group and then I will set up a web meeting where we can hopefully bring this proposal to a resolution.

Thanks!

Hello All,

Thanks Jay for summarizing.

In following this tread there is one thing that we might all consider. It is this. IMHO, wetBulb and dewPoint are not temperatures. They are both measurements of water content in air (along with pressure...but ignoring that..) and just happen to contain the unit of temperature, but are certainly not the air temperature (as denoted by the tags air and temp if we were to follow PROPOSAL 1).

If we stop trying to apply the temp tag to wetBulb and dew this issue pretty much goes away and is more logically consistent than applying the temp tag to points that are really measuring water content. The apparent tag is also a measurement of something other than temperature. It is wind mixed with water content (and solar gain?). So leaving off the temp tag would also apply here.

If we were to follow PROPOSAL 1 are we also now required to tag all other air temperature points such as the following to maintain consistency across the model?

Discharge Air Temp => "discharge air temp dryBulb sensor"

Similarly with zones:

Zone Temp => "zone air temp dryBulb sensor"
Zone Temp Setpoint => zone air temp dryBulb sp"

Perhaps we need to redefine the temp tag to be more than just a "measurement of temperature". In the wetBulb case the temperature being measured is the wet sock of a thermometer spun in air not the air itself. In the apparent temp, it is a calculated value given temperature units but is a conglomeration of wind and humidity readings. Similarly for dew. All three are humidity measurements of a sort.

Working Group Meeting 08/30/2017

The working group had a meeting on 08/30/2017 with all members present. The following summarizes the changes proposed by the group. This proposal will remain in review for a period of time to allow community feedback.

Proposal

Here are the proposed set of changes to existing weather points:

1. weatherPoint air temp
   1. No Change: implicitly means "dryBulb". We will not be adding dryBulb tag to the formal definition of this point.
2. weatherPoint air wetBulb
   1. Add "air" tag
   2. Remove "temp" tag
3. weatherPoint air feelsLike
   1. Change the name of "apparent" to "feelsLike"
   2. Add "air" tag
   3. Remove "temp" tag
4. weatherPoint air dewPoint
   1. Change the name from "dew" to "dewPoint"
   2. Add "air" tag
   3. Remove "temp" tag
5. weatherPoint air humidity
   1. Add "air" tag
6. weatherPoint air barometric pressure
   1. Add "air" tag

These changes meet a number of goals:

1. They are more consistent with the tags that are used on similar measurements in AHU equipment (primarily by adding the air tag)
2. They keep the points unambiguously defined (by removing temp tag where noted)
3. They clarify the meaning of the points (where a rename was made)

The temp tag's definition will be updated to indicate that when used in conjunction with the air tag then it refers to the drybulb temperature.

The outside tag will be considered optional for all weatherPoint points. A point can be both outside and weatherPoint if that accurately describes the point, but the use of outside is not a formal part of the definition for a weather point.

There are no proposed changes to any other weather points. In particular, there was discussion related to the wind measurements (wind speed and and wind direction), but there will be no change to these points.

Should this also include revising the definition of the temp tag as Jay suggested? Which would state that when used with the air tag it refers to the drybulb temperature?

I know that is outside of the weatherPoint scope, but I believe was one of the main takeaways from this discussion.

@Leroy - yes I will update the proposal post to add that action as well. Thanks.

This looks great to me, and it would be awesome to get it out of the review phase and into the standard. Does anyone from the wider Haystack community have questions/concerns?