2.0 Discussion: Units, sensor types and protocol

John

You are probably way ahead of me in terms of formal color spaces

Not really, i'm no color expert, But did a lot with colors lately because i use this to influence our living environment

Ok got it, Hue with rainbow style is variable due to the amount of colors (real life circumstance like angel etc) on that page an almost perfect rainbow angle and lighting situation is used.

I agree with you, but that's user implementation on the hardware, and something mysensors can not control. You would still need the HSB parameters ;) The implementation of rainbow or spectrum should be done on the controller<->end device side and the end user should know about it (or at least the developer of that specific controller/hardware implementation), not protocol based, because the parameters are still the same.

epierre

@Hek globally I don't understand the min/max/average, are they managed by the sensor or the controller ? if it is the sensor in case of reboot it should get it back from the gateway/controller and should be resettable maybe to have a year/month/week/day min/max. For me that should be controller side to handle this logic...

Now for my favorite playground ;-) it needs the calibration value clearly first, then for the discussion some projects (AirPi) avoid the calibration pitfall by sending back the voltage... If we want to have a concentration value from the sensor that is ok.

 S_AIR_QUALITY - Air Quality Sensor
 V_LEVEL - ? We need to describe this better
 V_LEVEL_RESET - Reset max/min value

@hek 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   Hmm... V_Moisture, (relative) 0-255 / 0-100% / True | False

On both I agree, I have some imaginatronix and yes you need a margin of error... but when it rains it rains... this is where a calibration value will be usefull at least to have several sensors showing the same value at the same environment time... I you want a logic then the true false can be good but not enough... on my imagitronix I have an empty value of 20% and a watered value of 100%, sometimes after the rain it is 80%..., where would be the limit ?

Also, I am thinking of a leaf wetness (we had a lot here this year... and diseases that goes with it) that could be mapped to soil sensors [Article on values(http://www.decagon.com/education/do-you-measure-leaf-wetness/)

hek

@epierre said:

globally I don't understand the min/max/average, are they managed by the sensor or the controller ? if it is the sensor in case of reboot it should get it back from the gateway/controller and should be resettable maybe to have a year/month/week/day min/max. For me that should be controller side to handle this logic...

The MAX/MIN/AVERAGE are optional to use. My idea was that sensors would manage them. They can choose to store it in eeprom or throw away values when reboot occurs.
The idea originates from GUST for wind which really is a max value over a certain time. This is just a generalization.
Usecase: Sensor might not report every wind value to controller but just every 10 minute. But internally it can calculate average/max/min for every 10 seconds without pushing this.

Rasmus Eneman

Please leave HSV/HSL to the controller. Why complicate the node more that necessary?
Using LEVEL would be good, 8 bit per color is good, it's also super easy for the node to scale down if only supporting 7 or 6 bits and it's perfect for those digital LED strips.

Please have a pure RGB without W, most strips and RGB leds don't have a W diode so that would need to be simulated with different result in different nodes.

John

@Rasmus-Eneman

Please leave HSV/HSL to the controller. Why complicate the node more that necessary?

That's why i asked for an addition if it would over complicate stuff (and if there is room for it) ;). And well, yeah you're right, S_RGBW with HSB would be complicating things more mixing capabilities with the node naming. There is always S_CUSTOM with V_VAR_1,V_VAR_2,V_VAR_3 combination.

I agree with leaving out the W. But could be a nice addition for those non calibrated fixtures where you have to supply calibrated values in the node to get "proper" white levels.

epierre

@hek ok I agree. Can we have too an alert that could be sent back to the gateway, or like an armed mode for the air sensors ?

Today, one of my daughter broke a bottle of perfume, saturating the air and making the sensor go to its max. Even if the sensor is not calibrated, on some kind that (IMHO) must raise an alert for I cannot say infinite or over the maximum value...

Yveaux

@epierre In 1.4 a binary represetation of a float value can be exchanged with the library. This allows to report e.g. + or - infinite where normally floating point values are sent. Maybe this will serve your purpose?

Zeph

If you do have a strip with RGB and W LEDs (rare), this can be handled as an RGB light and a DIMMER.

A lot of our discussions really hinge on how much smarts to put where in the architecture. My overall philosophy would be to keep the node simple and move functionality to it only when the same thing cannot be easily done centrally. Reasons to move smarts into a node could include:

Uses local calibration that central doesn't have
Needs updating more often than reports go to central (eg: wind max)
Timing, eg: safety features that need to act fast
Reliability of data links, eg: safety features that should not depend on RF robustness
Providing some logically consistent interface available to all controllers
Providing some functionality which cannot be as easily implemented in a controller (eg: closed source)

The latter two would be one-off custom coding at this time, tho @hek has mentioned the idea of pushing some rules down to the node level in a more automated way someday.

This probably argues more for using RGB rather than HSV at the node level. What I liked about the HSB was the unification of on/off, dimmable, and HSB functionality as a nested set of expanding functionality. So a script or rule that sets the brightness could work on a DIMMABLE or a HSB light by setting the V_PERCENTAGE value (or V_BRIGHTNESS as someone suggested). But that could be done at the central level.

I've used the term "central" because I still have the vision that a "hub" or "gateway" could implement some features, rather than having the smarts only in the controller or in the sensactuator nodes. So for example, it could be possible for the gateway to convert HSB to RGB such that the controller doesn't have to implement it. I know that approach is not currently popular so you don't need to register general disapproval. This will either come to seem a worthwhile additional open in coming years or not.

Zeph

@epierre said:

Can we have too an alert that could be sent back to the gateway, or like an armed mode for the air sensors ?

Today, one of my daughter broke a bottle of perfume, saturating the air and making the sensor go to its max. Even if the sensor is not calibrated, on some kind that (IMHO) must raise an alert for I cannot say infinite or over the maximum value...

Let's not bring infinity into this...

How about just returning "the maximum reportable value" (finite). If the node is capable of detecting "above measurable" conditions, have it define the "maximum reportable" as 1 higher than it's internal "maximum measurable".

The idea is to keep a simple scale of results, where for example we can consistently compute "max/min over 24 hours", or set a trigger on "value >= threshold" without needing to deal with infinity math. Some controller software may not have any concept of infinity, so using it brings in unnecessary incompatibilities.

This allows the controller to define the alert as it wishes. For example, suppose a sensor reports uncalibrated values of 25 to 173, and the node uses 174 for a detected "over-range". The controller can implement a trigger or event at "value > 160" to test for high values (without having to test for infinite values too). Or it could test for "value >=174" if it specifically wants to test for overrange (which could be way over the max measured value or just barely above it).

hek

@epierre said:

Today, one of my daughter broke a bottle of perfume, saturating the air and making the sensor go to its max. Even if the sensor is not calibrated, on some kind that (IMHO) must raise an alert for I cannot say infinite or over the maximum value...

LOL

epierre

@Zeph I don't share the same view, since we allow logic in the sensor for min/max interval, why not doing it too for the gas level ? all the more that the limit of the sensor is not a "business logic" but an internal logic linked by the physical capacity of the sensor itself (and which varies with each sensor type...).

My point was more that if you monitor LPG NO2 / NO3 or smoke that could be really harmfull we should provide safeguards anyway... not a big deal, more a safety net...

hek

Ok,

I will change create two device-types S_RGB and S_RGBW and use a level instead of percentage for each color component (0-255).

epierre

For my sound sketch :

S_SOUND - Sound sensor

V_LEVEL - sound level in db
V_LEVEL_MAX - Max sound level
V_LEVEL_MIN - Min sound level
V_LEVEL_AVERAGE - Average sound level
V_LEVEL_RESET - Reset max/min value

epierre

For my vibration sketch :

S_VIBRATION -Vibration sensor

V_LEVEL - vibration level in Hertz
V_LEVEL_MAX - Max vibration level
V_LEVEL_MIN - Min vibration level
V_LEVEL_AVERAGE - Average vibration level
V_LEVEL_RESET - Reset max/min value

epierre

@zeph the smoke sensor is an Air Quality sensor in fact so we coud decribe it this way too.
@hek what about the V_GAS_TYPE proposed below ? that would limit extensing the S and V no ?

S_AIR_QUALITY - Air Quality Sensor

V_GAS_TYPE - gas type reported by the sensor
V_LEVEL - gas concentration in ppm/ppb
V_LEVEL_MAX - Max gas concentration level
V_LEVEL_MIN - Min gas concentration level
V_LEVEL_AVERAGE - Average gas concentration level
V_LEVEL_RESET - Reset max/min value
V_STATUS - Tripped status of a gas sensor. 1=Tripped, 0=Untripped
V_ARMED - Armed status of a security sensor. 1=Armed, 0=Bypassed

hek

@epierre said:

S_SOUND - Sound sensor

Wouldn't it be good to have a uncalibrated variable for S_SOUND also? Like proposed for S_LIGHT_SENSOR. Reported as:

V_PERCENTAGE - 0-100%

epierre

@hek hopefully all smartphone now have a calibrated microphone that could help calibrate this... what 'Ive not worked out enough is to know if the store sensor is suitable for this...

also I don't know what the semantic of "100% sound" would mean... max sensor capabilities ?

hek

@epierre said:

also I don't know what the semantic of "100% sound" would mean... max sensor capabilities ?

Yeah, something like (1023-analogRead(ANALOG_PIN))/10.23

epierre

@hek hmmm... what about if this is a 3.3V or a 5V arduino board too ? no ? ?

daulagari

Coming from the Can one child-sensor-id have multiple values thread I had a look at the initial post and I am wondering if this is what you can call "the latest proposal".

The rest of this thread seems to be more about which variables but what I am wondering is how all this would be implemented. Looking at the initial post I see:

New header would be:

ChildSensorId | ChildSensorType | ValueType | Payload

My assumption is that there is still a NodeID in the header, so actually:

NodeId | ChildSensorId | ChildSensorType | ValueType | Payload

If so, I think there is too much freedom/overhead in the first three fields.

My expectations as an user is that every sensor, or better "box" is one node and implements one type of sensor with one or more values. In this sense I do not see the use of the ChildSensorId field, so why not use:

NodeId | SensorType | ValueType | Payload

2.0 Discussion: Units, sensor types and protocol

13

11.7k

11.2k

113.0k