2.0 Discussion: Units, sensor types and protocol

[Yveaux]

I would like a way to configure a sensor from the gateway, to e.g calibrate a sensor or store some ID. Maybe a V_CONFIG can be added, where childid indicates the actual variable written. Or define a few V_CONFIG0,V_CONFIG1 etc.
What do you think?

[hek]

@Yveaux said:

g/m3 if you standardize on SI
Same for distance BTW. Might be more...

I choose to scale the SI units to something relevant for thing getting measured. E.g. g/m3 would give a VERY small small value for dust.

Distance is mainly for the distance sensor now, which only has a small range.

Rain - measure in meters would also render very small numbers.

So, until we have a scaling factor in the protocol or something similar we'll have select a proper scaling at the source and agree on it between sensor and controller.

[hek]

@Yveaux said:

V_CONFIG0,V_CONFIG1

A few config-placeholders would be a nice.

[hek]

@gregl said:

V_PH_LEVEL

Added.

[hek]

@Yveaux said:

Why average/highest over last hour? My weather station reports wind speed every minute and I like to see the minute detail instead of averaging everything over an hour.

I'll change the definition to "over the last report period".

[a-lurker]

V_ANGLE sounds good. With a bit of (floating point) maths, all can be calculated.

[hek]

@ServiceXp said:

V_RELAY_STATUS 1=Active, 0=Deactive

Not sure what differs this form V_LIGHT_STATUS.
Maybe we need a better word than LIGHT that describes a thing-that-can-be-turned-on-or-off?

[Yveaux]

@hek said:

So, until we have a scaling factor in the protocol or something similar we'll have select a proper scaling at the source and agree on it between sensor and controller.

When values are sent as floats it doesn't matter. Scaling is implicitly store in the floating point value when sent as binary float. When transfered as ASCII you're right, but that isn't required with 1.4 anymore...

[Yveaux]

@hek said:

a thing-that-can-be-turned-on-or-of

Hmmmm.... Let me think.... a switch ? ;-)

[hek]

@a-lurker said:

Electrical impedance and resistance are not the same thing- suspect resistance is intended here?
V_IMPEDANCE --> V_RESISTANCE

I think the impedance-variable comes from the RFXTRX plugin. And it is related to body fat measurements for body scales.

http://code.mios.com/trac/mios_rfxtrx/browser/trunk/L_RFXtrx.lua

If I understand it correctly Impedace is used for AC and resistance for DC. Not sure what would be most useful in this setup.

[hek]

@Yveaux said:

When transfered as ASCII you're right, but that isn't required with 1.4 anymore.

Most users still use the serial protocol. Which means strings like "0.000003423" must be generated and transferred to the controller from gateway.

[hek]

@Yveaux said:

Hmmmm.... Let me think.... a switch ?

Haha.. yeah.. :+1:

[Damme]

@hek Moisture or Water detecded... Might be 2 different ?
Thinking different applications: Moisture in ground. (I.e. Water needed? Ground dry?) And Water level, hmm, if you have a fluid level meter to detect overfill. or leakage. Fluid flow

[Yveaux]

@hek said:

strings like "0.000003423" must be generated and transferred

Ok, but is this a problem? You could even pass it as 3.423e-6....
You don't want this string on air if you can transfer the same thing in 4 bytes, that's true.
I only want to state that if you transfer it purely in SI units, without scaling, you always know what the actual value is.

[Yveaux]

I'm still in doubt if we really need all these different value types...
In principle a (light) switch, water level sensor, burglar alarm, heater status <fill in your own binary switch> all just return or take 0 or 1. V_BINARY should suffice for all of them.
For other values you see the struggle between defining them as bare units (V_AMPS, V_VOLTS, V_CUBIC_MEASURE) and function (V_FLOW, V_WEIGHT, V_HUMIDITY).
Can't we just live with transfering values by specifying their units only and leave the interpretation of it to the controller (e.g. V_AMPS, V_BINARY, V_PERCENTAGE) ?
I'm not familiar with Vera, but e.g. the OpenHAB/MQTT combination doesn't care at all what type of value is exchanged. It's up to the configuration of OpenHAB how a value is interpreted.

[hek]

@Damme said:

Moisture or Water detecded... Might be 2 different ?

For water detected I would probably use V_TRIPPED.

Hmm.. Soil Moisture.. I have no idea how to represent this. Help me! The ebay sensors we're using isn't super accurate and comes uncalibrated.

[Damme]

@hek I know, ist more 'need moisture' or not :) Hmm... V_Moisture, (relative) 0-255 / 0-100% / True | False

[Yveaux]

@hek Can we also pass battery level as just a sensor value? There's no real need to pass this as an internal message, is it?

[Zeph]

First off, this is a very positive step forward!

Now some details
@hek said:
> I think the impedance-variable comes from the RFXTRX plugin. And it is related to body fat measurements for body scales.

I think that we need to be clear about the core concept of what we intend to measure.

Resistance or impedance generally don't make much sense, as they are usually not the conceptual thing being measured but an intermediate value used in calculating it.

This is also true of Volts and Amps, except that sometimes we really do want volts and amps (for power monitoring).

But consider a Light Dependent Resistor in a bridge circuit.
We could report the value as ADC readings 0..1023.
Or we could convert that to volts 0..3.3 or 0..5.0 or whatever.
Or we could convert that to LDR resistance (knowing the other resistor value) in ohms.
Or we could do some calcs and try to report the result in Lux.

Since the conceptual thing we are trying to measure is light intensity, the best option would be to report it in Lux if possible. Not as ohms, volts, or ADC readings.

So any time we see something reporting as resistance or impedance, we should ask if that's the core concept we need to report, or an incompletely processed proxy that will be hard for the server to understand.

Likewise with volts or amps - are we really trying to report temperature or humidty or what? If we are monitoring a battery or the AC mains, then maybe volts it exactly right, but we need to think it out first.

So who in a home automation context cares about resistance or impedance as the core thing being measured?

[Zeph]

@hek said:

V_TEMPERATURE - Degrees celsius <int or float>
V_HUMIDITY - Humidity percentage 0-100% <int or float>

Can any of the values be int or float? Or just these two?

V_DIMMER - Percentage 0-100% (used for lights, blinds and curtains)

The core concept here is V_PERCENT. In one home automation system there might be only one included concept, the Dimmer, and you'd have to use that for blinds as well as dimmers. In another home automation system there might be separate UI widgets for blinds and light dimmers. The sensactuator node's code should not need to change either way. Mapping a given V_PERCENT variable to UI concepts of blinds or dimmers is conceptually part of the configuration for a given (version of a) home automation system.

V_FORECAST Whether forecast. One of "stable", "sunny", "cloudy", "unstable", "thunderstorm" or "unknown"

Difficult one. That is very definitely not the controlled vocabulary used by all forecasting sources, and mapping into this list is going to be difficult. "Scattered showers" and "partly cloudy" and "light rain" and "foggy" are not going to be easily represented. What about stable/sunny versus stable/rainy? Are stable/unstable mutually exclusive choices with the others, or optional additional attributes for any of the other choices?

Maybe this has to be an open vocabulary with a text string? What text they will get depends on their source.

V_RAIN - mm
V_WIND - m/s (average wind speed during last report period)
V_GUST - m/s (highest wind speed during since last report)
V_WATT - Watt <int>
V_KWH - kWh <int or float>

What is the report period and what resets it? Last minute, last hour, last 24 hours, since midnight, since the reset button was pushed, or using automatic episode detection (I was just looking at a rain sensor which uses 8 hours of no rain to separate rain accumulation events). Without some knowledge of the reporting period these values cannot be meaningfully interpreted.

V_RAIN could be a forever incrementing total if the host wants to do its own deltas and define it's own report periods (maybe several of them).

V_WIND is a bit more difficult. If we had guaranteed delivery, we could just average since the last report from the node. Of course, some weather stations may do their own averaging, or the node could average many readings. But how does the host know?

From my perspective these "time period sum or average" values would ideally involve:

• an OTA format which loses no useful information available from the sensors or peripherals
• a flexible gateway (or adapter) which reformulates into time units meaningful to the HA controller software
  Let me make up an example. Suppose the sensor reported wind speed averages over 5 minute periods and the HA controller wanted to report it over one hour periods. The gateway could average 12 reports - for either the last 60 minutes, or for on-the-hour, as needed. Or "new rainfall" could be reported in 10 minute increments, but accumulated since midnight by the gateway, if that's what the controller prefers. Different controllers might use different accumulation periods; and what is sent to a controller could vary from what was uploaded to a cloud service. The node should not be adapting to the controller, it should send all available and useful info and the gateway or adapter should adjust - sort of like degrees F but more complicated because it might involve keeping running totals for averaging.

V_ANGLE - radians <float or int>

Here's one of those "generic vs specific" ones. Like V_PERCENT suggested above, V_ANGLE has no implications for what is being measured, only the units. It could be wind direction, it could be the plantation shutter position, it could be the solar panel tilt. How does the host know?

(This is the kind of thing that prompted my suggestions on another thread to separate the concept of units from what is being measured.)

An int for radians doesn't make much sense (unless we have a scaling factor).
I think degrees is a reasonable compromise - it's more precise than any sensor we're going to afford (or than the noise in the data itself would make moot), so it loses no meaningful accuracy. And virtually no sensor is going to report in radians. Some report in degrees. If it reports in 16 compass points or such, that can be easily converted to degrees, without even using floating point.

V_WEIGHT - kg <int, float>
V_DISTANCE - Cm <int, float>
V_IMPEDANCE - Ohm

See other message about intermediate calculations and the true conceptual thing being measured, (with impedance as an example). What does a distance of 240cm mean?

V_ARMED - Armed status of a security sensor. 1=Armed, 0=Bypassed
V_TRIPPED - Tripped status of a security sensor. 1=Tripped, 0=Untripped

Here the underlying concept is "V_BINARY", with a variety of associated labels for 1 and 0 based on what is being reported or controlled. On/Off, Open/Closed, Armed/Unarmed, Tripped/Untripped, Locked/Unlocked, Enabled/Disabled, etc. Do we create an ever expanding set of binary options as different variable types? Or is it functionally one variable type (or a small number with definably different dynamics from each other) with additional attributes (like the labels used for 1 and 0)?

V_SCENE_ON - Scene number <int>
V_SCENE_OFF - Scene number <int>

Now we are conflating events or commands with statuses or values. We turn on a light by setting it to 1 (or 100%) and we turn it off by setting it to 0 (or 0%). This leverages the same "set value to" underlaying functionality, and allows a simple and consistent query concept (what is the current value of the light?) What is the advantage of treating a Scene differently?

Scenes are a bit confusing, because they may or may not be mutually exclusive. They are neither obviously "checkboxes" or "radio buttons".

V_HEATER_MODE - Heater mode. One of "Off", "HeatOn", "CoolOn", or "AutoChangeOver"

How do we set the themostat? What about Fan?

V_HEATER_STATUS - 1=On, 0=Off. Heater power switch

What about CoolOn mode? If it's cooling, is V_HEATER_STATUS on or off?
.

V_LIGHT_LEVEL - 0-100% <int>

Is this a sensor (alternative to V_Lux) or an actuator (different than V_DIMMER/V_PERCENT above)?

V_UP - command which modes blinds ful up. Use DIMMER to specify percentage
V_DOWN - command which moved blinds to full down. Use DIMMER to specify percentage

Use V_DIMMER (or V_PERCENT) instead of or in addition to this? Why not just set to 100% instead of having a "V_UP" command?

V_STOP - stop blinds in the middle of motion.

This is a bit tricky too - it's time dependent and latency becomes important, if you want to set a given position manually. So maybe it's just about canceling any previous command whereever the blinds are, eg: for safety. I'm not really sure how this is used in a script.

V_LOCK_STATUS - 1=Locker, 0 = Unlocked

Again, is this different than other binary set/query dynamics, or just different labels?

V_DUST_LEVEL - ug/m3

One of the issues I mentioned in the other thread is uncalibrated values. That comes up with some sensors. For example, the sensor's values may not be convertable to ug/m3, it might measure particle count without mass, or size without density to compute mass, or only particles within a given range. (Light is like this too, by the way, as a sensor's true output is not lux, but lux-within-a-given-wavelength-range-with_weighting, but we skip past that).

V_VOLTS - Volt <int or float>
V_AMPS - Ampere <int or float>

Discussed in another message. OK if the thing we are really measuring IS voltage or current.

Anyway, this is moving forward despite my questions, and it's meeting my desire to have each of these defined more meaningfully. Thanks!