Capability Rain Sensor / Rain Measurement

Devices & Integrations Capability Type Suggestions
1

Please consider a new capability called Rain Sensor and possibly a Rain Measurement

Suggested attributes for Rain Sensor:
rain enum[detected, clear]

Suggested attributes for Rain Measurement:
rainFall/rainGauge/rainLevel decimal [number of inches of rain fall]

Please feel free to adapt/add things, I do not own such a device yet. Netatmo would be one of the first devices to benefit from this.

9 Likes
2

@JonPittman should be interested in this.

1 Like
3

Would love to see this. Would really help my custom device type. :grinning:

2 Likes
4

With Bloomsky’s Storm coming out this seems like a must.

2 Likes
5

Hi.

Do you know whether there was any movement on this capability?

6

@Jim Any plans to add this capability, maybe a capability for wind measurements also?

2 Likes
7

Is it worth supporting both absolute/cumulative and derivative figures? e.g.:

rainDepth (mm) - cumulative figure since last reset (analogous to an accumulated energy figure in electricity meters).
rainSpeed or rainFall (mm/hour, mm/day) - derivative figure (analogous to instantaneous power in electricity meters).

I think the Netatmo rain gauge reports both.

8

I think that for political correctness, rain should be called precipitation.

rainFall (or precipitationFall) is by nature cumulative (integral), as opposed to rainRate (precipitationRate) which would be the derivative of rainFall (precipitationFall)

Most rain gauges generally measure the precipitation in millimetres
equivalent to litres per square metre. The level of rainfall is
sometimes reported as inches or centimetres. Rain gauge amounts are read
either manually or by automatic weather station (AWS).

I would rename it into Precipitation Sensor

precipitation enum(clear, detected)
precipitationFall decimal (mm or inch, not sure which one is more popular in the US and/or UK)
precipitationRate decimal (mm/hour, inch/hour, etc.)

Also, 1 mm of rain fall is equivalent to 1 liter per square meter. The inch, not so much :slight_smile:

1 Like
9

I’d approve of the terms rainFall, and rainRate, as you’ve described above, however I’m not sure it’s necessary to widen the scope to precipitation as devices that measure other types of precipitation (e.g. snow) are typically distinct from rain gauges and operate in a different way. That being said, the output attributes would be the same i guess.

Note, capabilities/attributes don’t define units (only the quality), so there is no need to decide between mm/hour, or inches/hour etc. E.g. an Energy Meter is free to report energy in kWh, kVAh, BTU, Joules, etc.

Also, thinking about it, if a capability includes a cumulative attribute (rainFall or precipitationFall) then logically it should also have a corresponding resetRainFall() or resetPrecipitationFall() command too, and perhaps also another attribute to indicate the time at which it was last reset ( resetTimeRainFall or something…)

1 Like
10

Correct. And it should also define a unit for each of these values. Or multiple attributes for multiple units. But I think the unit is good…

11

No, that’s fundamentally wrong. Attributes support multiple units by their very nature! That’s why latestState() returns a map [name: …, value: …, unit: …]

def latestEnergyState = device.latestState("energy")
log.debug "latest energy state value: ${latestEnergyState.value}"
log.debug "latest energy state name: ${latestEnergyState.name}"
log.debug "latest energy state unit: ${latestEnergyState.unit}"

That’s why we don’t need the temperature Measurement capability to have a temperatureCentigrade attibute and a temperatureFahrenheit attribute.

It is the responsibility of whatever is reading a device attribute state (i.e. a SmartApp) to consider not only the value, but also the unit.

1 Like
12

I think you are incredibly correct…

But… I’ll bet that 90% of existing DTHs and SmartApps ignore the units parameter.

13

Good point!

I just did a quick audit of my devices, and out of around 40 devices, I can see one device type that doesn’t put units on its temperature and another that doesn’t put a unit on battery. Most are quite good though.

So for DTHs publishing attributes, I don’t think it’s quite that bad, although could be better.

But for SmartApps handling attributes, yes, I think you could be right!

1 Like
14

Great research!

Since a physical device is likely to only provide an Attribute in one particular units (except via a configuration change), it is easy for the DTH coder to just tack on the units argument.

SmartApps, however, have not been given supporting infrastructure for handling the infinite possible Units it may have to deal with! For example, if I prompt for Temperature Alarm Points, the prompt should indicate the Units, since my temperature sensors may provide the attribute value in F, C, K…

And now is it the responsibility of the DTH to do unit conversion?

This is an overlooked area in SmartThings :confounded:.

1 Like
15

I think SmartThings at least have thought about this somewhat. They’ve designed the attribute states to have names/values/units in the first place, which I think is a very good idea. Plus, when it comes to temperature scales (probably the most common attribute to have move than one common unit), we have the getTemperatureScale() function to get the user’s preferred unit for a location. What is supposed to happen is that DTHs and SmartApps should convert an attribute (say in C) from a device, and display in Fahrenheit for the user, if that is their chosen temperature scale.

Re supporting infrastructure, I think you’re right. It would very useful to have some kind of library function for unit conversion. e.g. getUnitConversionFactor("J","kWh"), that would save developers lots of time and encourage developers to think about units more.

[Perhaps relevant to the rainRate: getUnitConversionFactor("mm/hour","inch/day")]

2 Likes
16

Also, since we are talking about rain measurement… how about wind measurement?

4 Likes
17

Gentlemen, for future unit additions i’d reccommend picking the ones Z-Wave defined, this way at least the Z-Wave part of ST is fully covered. The public specs make them available here:
http://zwavepublic.com/sites/default/files/command_class_specs_2017A/sds13812-1_multilevel_sensor_command_class_list_of_assigned_multilevel_sensor_types_and_scales.pdf

Now if only ST would fully implement dynamic unit changing in the UI apps.

2 Likes