Weather sensors: standardizing wind, rainfall, pressure

Plugins & Plugin Development General Plugin Discussion
1

The UPnP spec gives us standard service files for temperature and humidity, but it doesn’t specify other environmental properties that users might want to use for home automation purposes. Let’s fill that gap.

Wind sensors can tell us:

[ul][li]what direction the wind is coming from[/li]
[li]what the current (instantaneous) wind speed is[/li]
[li]a time-smoothed average of the wind speed over the last n minutes[/li]
[li]what the strongest wind gust speed was in the last n minutes, and when it was[/li][/ul]

Rainfall sensors can tell us:

[ul][li]how much rain fell in the last n minutes[/li][/ul]

Pressure sensors can tell us:

[ul][li]what the current barometric pressure is[/li]
[li]what the corrected-for-sea-level barometric pressure is[/li]
[li]whether the pressure has risen or fallen since n minutes ago[/li][/ul]

I want to create three UPnP-style S_*.xml service files that plugins can use to expose physical weather station data, and scraped-from-the-web weather data.

Some comments:

Not every sensor can detect every aspect of a property. For instance, not every wind sensor detects gusts or can do time-smoothing. Not every pressure sensor knows if the pressure is rising or falling.

Time spans (n minutes in the above lists) are dictated by the sensor, not the user. My weather station can report rain-since-midnight, but not for other intervals. Weather Underground reports rain-in-the-last-hour.

There are also derived values such as rain rate, computed from the reciprocal of the time between rain collector bucket tips. I’m not sure that these belong on the sensor service specifically, but I could be convinced otherwise.

All of these measurements have different units in different parts of the world. Much as I would like to follow the UPnP approach and store everything in metric*10, that’s not practical (and MCV didn’t follow it either because of Z-Wave devices not sticking to the spec). Probably every measurement will have to have an accompanying unit.

Also: I’m deliberately leaving forecasts out of this. That’s a different discussion.

2

Best option in my opinion is to mesure it in SI Units and then have a convertion table to other units

Sent from my WT19i using Tapatalk 2

3

I will check later what I have in the RFXtrx plugin but I believe that what you defined covers what provide devices supported by the RFXtrx (except missing forecast).

Why not defining D_.xml and D_.json too ?

4

Wanted to push this topic further and get this standard going. Would like to see this in future builds of the weather plugin. I just picked up a weather station and plan to have the data show in Vera. Would it be best to have the measurements in metric and have options to convert to the different formats for each device?

  • Garrett
5

Garrett

I think each device should be separately configurable for units. In the UK (perhaps because we’re in between the US and the rest of Europe) we tend to use degC for temperature but mph for wind speed. In other words, neither metric nor US units - so a universal ‘Metric/US’ switch wouldn’t work for me.

6

I meant have the metric as the main with code for the plugin to choose which measurement you want to use. So the wind will be in metric, but there will be an option to choose it in mph. If we can agree on a standard unit, it would than be pretty easy to add code to convert those values to the unit of the user’s choice.

  • Garrett
7

How could we go about getting this discussion to become more active to make these new devices become a reality?

  • Garrett
8

Right. I’m going to make some standard weather sensor service files, and submit them to plugin developers (e.g., Weather Underground) and access point developers (e.g., AutHomation). Anyone who is interested, NOW is the time to talk. If you don’t contribute then you don’t get a chance to include your pet feature.

Be specific. Say what you want and what you are going to use it for. Provide context; not everyone shares the same background about weather because not everyone lives in the same climate.

9

So a few quick items that I think need to be thrashed out:
a) serviceId to use
I’d like to use a standardized servivceId for each logical reading. I have no personal opinion on the specific serviceId string to use, but want to have a unique one per type of recording.
Eg one for UV, one for water levels, etc.

I’d also like to see it be possible for a single device to implement multiple of these (non overlapping) serviceIds and still get rendition. This will require the control points not to make assumptions about device types and such… Instead looking at the serviceIds.

Without this,things like the weather plugin will cause an explosion of child devices, or of config parameters.

b) units to use
Generally I’d prefer that unit conversion be left to control points, and that Standardized (metric) units be used for the data side of the house. Unfortunately, the horse may have already bolted on that one, so well need a metric and an imperial unit measure for everything.

c) a library/module for API access/conversions
When some choices have been made about units etc, it would pay to have a std module for the conversions etc. When the time comes I have no problems seeding this script. It could then contain any conveniences that data providers and consumers both need to ensure consistency of impl/use.

The most popular ones seem to be wind speed/direction (standardized direction info?), cloud conditions/coverage. In some cases,the providers have clauses indicating the data must be passed through unchanged… Which will make some stuff interesting.

10

Wind. A device for current wind conditions will need:

[ul][li]Measurement units. This will be a string from a small set of common windspeed unit names (kph, mph, mps, knot, others?). Required. Weather stations have a preferred unit that they measure in; that is what the implemetation writes here. This value is not displayed to the user.[/li]
[li]Display units. This will be a string from a small set of common windspeed unit names (km/h, mph, m/s, knot, others?). Required. This string is chosen by the user.[/li]
[li]Current instantaneous speed in measurement-units. This is a number >= 0. Optional. This value will be written by the implementation. This value comes straight from the weather station and is not unit-converted. This value is not displayed to the user.[/li]
[li]Current instantaneous speed in display-units. This is a number >= 0. Optional. This value is computed* from the measurement-unit variable above. This value is displayed to the user.[/li]
[li]Current gust speed in measurement-units. This is a number >= 0. Optional. This value will be written by the implementation. This value is not displayed to the user.[/li]
[li]Current gust speed in display-units. This is a number >= 0. Optional. This value is computed* from the measurement-unit variable above. This value is displayed to the user.[/li]
[li]Time-averaged speed in measurement-units. This is a number >= 0. Optional. This value will be written by the implementation. This value is not displayed to the user.[/li]
[li]Time-averaged speed in display-units. This is a number >= 0. Optional. This value is computed* from the measurement-unit variable above. This value is displayed to the user.[/li]
[li]Duration of time-averaged speed in seconds. This is a number > 0. Optional. This value will be written by the implementation. Some weather stations compute a time-averaged speed (say, over the last ten minutes). The duration (600 in the example) goes here.[/li]
[li]Direction language choice. This is a string, an ISO language code. Optional. This value is chosen by the user and controls in what language the wind direction is displayed to the user in (example: “en” produces strings “N”, “NNE”, “NE”, …). If unrecognized then the direction in degrees is used unchanged.[/li]
[li]Direction in degrees. This is a number 0 to 359. Optional. This value will be written by the implementation. Weather stations that measure to degree-accuracy will just write the bearing here. Weather stations with less precision will need to scale their reading to degrees.[/li]
[li]Direction as a human-readable string, based on the Direction Language Choice above. This value is generated* from the direction-in-degrees value and is displayed to the user.[/li][/ul]

Service Type: urn:schemas-micasaverde-com:service:WindSensor:1

Recommended Service ID for devices that use one of this service: urn:micasaverde-com:serviceId:WindSensor1

  • I’m imagining that this generation is done by an automated piece of Lua outside of the implemention. It watches the variables that the implementation changes, and then sets the human-readable values accordingly on the device. This saves implementations from having to duplicate unit-conversion code. Consult the existing kWh-integration code for prior art.
11

Language sensitivity will be a little tricky, and might be a slippery slope. If added, there will likely need to be variables/values that aren’t sensitive to Locale… Otherwise the JSON (and generalized scene scripting) get tricky for stuff with domain values like N,SW, etc. For the stringified values, it would pay to have a normalized value set for scripting also.

The slippery slope comes in when you consider there normal format-based Locale stuff.

Eg. 12,6C (somewhere like Germany where . and , are swapped)

Q: should language/locale be part of this, or kept separate?

I could well imagine having to set that preference on a plethora of child devices for weather, for example… I suspect a way to get it is needed, so that CPs know how to handle the data, but setting it might need to be impl dependent.

12

I don’t feel strongly about it, except that I have seen in my Day Job what happens when English has a privileged status in the code base. It’s the easy way out and it invariably leads to Problems.

I’m hoping that the direction-as-degrees is sufficient for scripting purposes. IMO, users who script based on display-only strings deserve what they get. If we provide conversion functions then users can test the internal unconverted variables and not be tempted to use the display-only strings.

Good point about the decimal separator character. Should be a global Luup preference that can be queried, just like the user’s temperature preference can.

13

Of course, I am concerned as I have created or used for the RFXtrx plugin several weather devices: wind, rain, UV, …
I will develop another day, I have other priorities today (Christmas preparation) ;D

14

I have run straight into this problem with writing a plugin for the Netatmo weather station. Any progress?

A possible, but possibly dangerous, approach to units, which could also be a ‘solution’ to the calibration problem would be to provide a gain and offset variable to be applied to each displayed (not recorded) measurement. I intend to add this approach to my next version unless convinced that this is a truly BAD IDEA.

If there’s consensus within at least the MCV community (we could die waiting for UPnP standards) and, more importantly someone actually writes those dreadful JSON files, then why not move forward?

15

I would like to see more movement on this.

  • Garrett
16

+1

17

Several months ago I ported over a set of weather metrics functions to a Lua module:

[url=https://github.com/watou/lua-weathermetrics]https://github.com/watou/lua-weathermetrics[/url]

These contain standard functions for converting between temperature units, relative humidity to and from dewpoint/temperature, heat index, etc. I would gladly open up that repository for others here to contribute new “universal” weather and environmental functions and data if anyone is interested.

I think this module would evolve separately from new code for Vera services, control points or other Vera-specific things.

I’m eager to contribute if there is going to be a project to fill in the blanks that futzle and others have identified.

watou

18

Could I suggest that to move this community forward in defining devices and services we fix on a service ID like this:

urn:forum-micasaverde-com:serviceId:XXXXXXXSensor1

Where XXXXXXX is replaced by ‘Noise’, ‘CO2’, ‘Pressure’, etc…

That way, it’s clear where the credit (and blame) lies.

19

I’m in agreement. But we also need to work out the service variables, units, etc.

  • Garrett
20

In terms of variables, I can’t imagine why we shouldn’t want to use “CurrentLevel”, for most scalar values. It’s always seemed an anomaly that temperature uses “CurrentTemperature”.

Units should best be accepted within the SI system(?). This does for CO[sub]2[/sub] (%), Noise (dB), Pressure (hPa) [this is equivalent to (mbar)], Windspeed (m/s), Direction (degrees), I suppose, but weather conditions fall outside of this formula, of course. It would be nice to have a units field, too, for the UI5 panel and for program interrogation.

Could I make a plea to disconnect the dynamic icon variable from the primary measurement variable? this gives freedom to make icons dynamic, using, say, an ‘IconState’ variable. If so, I’d make the case that the 0-100% range should be 0-4, giving five user-defined icon options. Of course you could go negative (as some have done) or more than 100%, but the fixed step-size is 25% (hence the proposed range).