2.0 Discussion: Units, sensor types and protocol

John

@hek
Ahhh... understood :)... Splitting those up will not be an option then because it could then create a numerous amount of options....

A S_HSB would be nice though, even if it would only be ints....:
V_STATUS - 1 - turn on, 0 = turn off
V_H_DEGREE - Degree (0-360)<int>
V_S_PERCENTAGE - Saturation % <int>
V_B_PERCENTAGE/V_V_PERCENTAGE - Brightness/Value % <int>
V_WATT - Watt <int>
V_WATT_MAX - Max watt value
V_WATT_MIN - Min watt value
V_WATT_AVERAGE - Min watt value
V_WATT_RESET - Reset max/min value

I must say it is a personal request :$....

[Edit]

But switching to LEVEL and using 0-255 would be ok (if we need it :wink:).

It would create space to add the HSB/HSV option ;)

Zeph

What's wrong with setting lights at 1.475% Is percentage limited to integer?

Let's be very explicit about that. Is the idea that all values accept only integers unless they say they have the option of using floats? If so that should be made clear in the list.

Another thing that needs to be more clear is how to handle multiple V codes for the same sensacturator (like the RGB or HSV lights).

Is a sensor expected to report all of them?
Is an actuator expected to respond to all of them?
How do both sides stay in sync about subsetting?

By the way, there is a distinction to be made between RGB lights (three blendable primaries able to synthesize many colors in a predictable and fairly standard way) and multichannel control of N lights of arbitrary colors. RGBW is another thing entirely. The W could be cool or warm white. For that matter the fourth color could be yellow or violet. It's not a color space.

If the RGB channels blend I'd implement it as an RGB light plus a monochrome light, because there is no RGBW color space. If they don't blend I'd implement it as 4 monochrome channels, the same way I'd implement a Yellow and Green pair that didn't blend.

John

@Zeph

What's wrong with setting lights at 1.475% Is percentage limited to integer?

It just not represents any absolute bit value for a specific color, it is an approximate. If for example you have a fixture which does 255 steps and you want to set it at step 40. you will need to send 15.682.....%. But what if you would send 15.770... ? Due to the nature of floats it could be rounded down or up to 40 or 41 and especially in the lower steps of a color the difference would be seen if this is a mix of on of the RGB values, and even more as all the RGB values are send in percentages. A percentage would only be usable (But even then it's still an approximate) with 32 bit or analogue blend RGB fixtures. There ain't a lot of these.

@zeph said:

If the RGB channels blend I'd implement it as an RGB light plus a monochrome light, because there is no RGBW color space. If they don't blend I'd implement it as 4 monochrome channels, the same way I'd implement a Yellow and Green pair that didn't blend.

I do agree with you, and you're totally right, but:

@john said:

Splitting those up will not be an option then because it could then create a numerous amount of options....

In other words it could eat up the possible S_TYPE's

@hek
Please disregard this one, it wouldn't :"it would create space to add the HSB/HSV option".
But, couldn't it be an option to add the HSB/HSV variables to the S_RGBW? because if the presentation stays you would only have to send the vars that are supported, and the type S_RGBW could be renamed to something like S_LIGHT_COLOR?

hek

The question is where the actual calculation is done between RGB and HSB/HSV. Should it be done on the Arduino side or controller? Nothing stops you from making a fancy HSB/HSV GUI on your controller but the actual values send to the actuator is RGB. But my knowledge of color scales is a bit limited and I'm probably missing something?

John

@hek

It depends, if the HSB scale is purely in integers you will have about 3.600.000 options (including brightness steps) which is much less then 16 bit 0,0,0 - 255,255,255 scale. But this scale ain't specific in int's it is an implementation chosen scale. If choosing for ints, yeah keep the RGB, if going to floats, add it next to the RGB.

probably missing something?

The main difference is that with pure 16 bit you will have whole bit numbers and with degrees there is more then just go from 359 to 360/0. you could use 359,00 to 359,99 which gives an extra 990.000 extra red combinations (including saturation and brightness) with absolute 16 bit you stick with whole ints/bytes limiting the possible fixtures light high "resolution" capabilities.

Also because of the nature of HSB with higher color resolution possibilities you will always have the possibility to find the closest 16 bit neighbor or even the exact bit value because of higher to lower "spectrum" resolution.

With the above if you would leave out the brightness you would have a higher color resolution 255,254,255 is one step lower green form maximum, you can't go to 254.9 right? in degrees i think green is 120, you could go to 119.99999. because the degrees are not fixed to a whole as a byte is.

Because of more steps calibrating un-calibrated fixtures/leds (for example with the green mentioned earlier) can be more precise. Also HSB is more human perspective then fixed bits.

Maybe the above shines a light on the difference?

RGB is just a brightness setting of a specific color, HSB is pure color selection, intensity setting, and the brightness of these.

Personally:
HSB is nice to have, but from personal needs i have enough convertion functions (hsb->rgb and vice, hsb -> kelvin, etc...) to convert.

Should it be done on the Arduino side or controller?

I would let the controller do the actual conversions and let the device spec it's capabilities.

Zeph

@hek said:

S_RGBW - RGBW Light
V_STATUS - 1 - turn on, 0 = turn off
V_R_PERCENTAGE - Red component % <int>
V_G_PERCENTAGE - Green component % <int>
V_B_PERCENTAGE - Blue component % <int>
V_W_PERCENTAGE - White component % <int>
V_WATT - Watt <int>
V_WATT_MAX - Max watt value
V_WATT_MIN - Min watt value
V_WATT_AVERAGE - Min watt value
V_WATT_RESET - Reset max/min values

One of the areas where the spec is very unclear is when a variable is writable and where it's only reportable (read only).

For example, can I set the watts to 20 above (or for S_DIMMABLE) in order to tell the light how much power I want it to use? Seems like a valuable option. How am I supposed to know?

What if we made the write/report/trigger function explicit:

S_RGBW - RGBW Light

W_STATUS - 1 - turn on (100%), 0 = turn off (0%)
W_R_PERCENTAGE - Red component % <int>
W_G_PERCENTAGE - Green component % <int>
W_B_PERCENTAGE - Blue component % <int>
W_W_PERCENTAGE - White component % <int>
R_WATT - Watt <int> - current instantaneous or short term average value
R_WATT_MAX - Max watt value since last reset
R_WATT_MIN - Min watt value since last reset
R_WATT_AVERAGE - Min watt value since last reset
T_WATT_RESET - Reset max/min/avg value

W variables can be written to; the current value can also be queried
R variables can only be reported (automatically or by query)
T variables are triggers, writing to them triggers some action

This gives guidance to both the sketch writer for the node, as well the controller adapter writer in knowing what they can do with each variable a node presents.

The actual numeric values for R, W and T codes could be interspersed or non-overlapping ranges could be reserved for each (eg: 1-100 for R, 101-200 for W and 201-255 for T)

Damme

@Zeph it all depends on how skilled programmer and how nerdy you are. if you want to set a lamp power with V_WATT great, thats nerdy! but in not, just dont read any thing from v_watt. .. there is no such thing as a read only variable, all depends on if you listen to incoming messages of that type or not.... I think you over-think this a bit. The atmega328 is a rather small mcu and wont be able to magically do tons of stuff. how to know what is what, well every home automation system should have a manual :) Write it down.

Zeph

@John

I can see a case for making HSB the norm.

Think of light types like a class heirarchy, with added functionality

S_BINARY

V_STATUS (1=100%, 0 =0%)

S_DIMMABLE

V_STATUS (1=100%, 0 =0%)
V_PERCENTAGE (0.0% - 100.0%)

S_HSB

V_STATUS (1=100%, 0 =0%)
V_PERCENTAGE (0.0% - 100.0%)
V_HUE (0.0 - 360.0)
V_SATURATION (0.0% - 100.0%)

If you set V_STATUS to 0, or V_PERCENTAGE to 0%, any of these lights turn fully off.
If you set V_PERCENTAGE to 100%, S_DIMMABLE will go to 100% (V_STATUS=1)
and S_HSV will go to 100%, in the current hue and saturation
If you set V_PERCENTAGE to 50%, likewise.

I think one could make the case that it's more human compatible to go to "yellow, 25%" than to figure out what the RGB values would be. (The user interface could translate yellow to a hue number)

One aspect HSB is that there are a couple of ways of associating colors with angles, so we would need to specify which is our standard, so 40 degrees is the same hue for all nodes. I like the rainbow style.

@hek
I do also get the point that HSB -> RGB conversions could be done on the controller, passing the lower level RGB values to the node. There is an attraction to that as well.

This cannot be fully resolved without also considering the question of light curves or gamma factors, which has been raised. The controller needs to know whether or not the node implements light curves for RGB channels, so it can avoid doing that twice; and also it in the changes how the controller should convert HSB to RGB (the stock conversions assume RGB are linear).

Zeph

@Damme said:

Write it down

That's what I'm trying to do.

We could CLEARLY write down that V_WATT is intended only to report values and cannot be set, while V_RESET is a trigger, and V_R_PERCENTAGE is settable - so different implementors don't make different and incompatible guesses about what these mean.

We do not want the situation where one sketch writer interprets V_WATT to be a way to control how much power the lamp will use and another sketch write interprets it as reporting only. And then controller interface writers also guess differently about what it means. That's chaos.

One step in that direction would be naming them according to the intention - writable, reportable, or trigger.

I've done a LOT of implementing from specifications, as many others have. Having a clear specification that avoids huge ambiguities (is this something you set or something that reports is huge) is not over-thinking - it pays off big time.

Yveaux

@hek said:

Crazy

You didn't dare posting a red version, did you? :dancer:

John

@Zeph

I can see a case for making HSB the norm.

I'm not ;). it is just a possible addition of possible value types to the S_RGBW type and if not possible like you stated a S_HSB and to keep clarity V_PERCENTAGE should then be V_BRIGHTNESS. Or both percentages (not possible) or both naming as it is.

One aspect HSB is that there are a couple of ways of associating colors with angles

Off topic, which ones? i only know one, are you sure your not mixing HSB with HSL?

On topic:
I'm fine with only sending RGB if HSB ain't possible to be combined with S_RGBW or added with S_HSB/S_HSV if it is thought of as a logical addition.

Zeph

@John
You are probably way ahead of me in terms of formal color spaces. I'm just a color user.

I like using a modified Hue, such the the "rainbow" described here:

https://github.com/FastLED/FastLED/wiki/FastLED-HSV-Colors

John

@zeph said

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.

2.0 Discussion: Units, sensor types and protocol

17

11.7k

11.2k

113.0k