I try to use decimal variables (which track the level and temp of a virtual lamp used for circadian lighting) in the level and temp of some lights and find I canāt select these hub variables. Why? Iām assuming because the system is looking only for number variables rather than decimals (based on the fact it does allow selection of other variables I have of that type). Sigh. Really? And because variables canāt be edited now I have to unpick them from other rules and redefine them I suppose as number hub variables even though it seems to me very reasonable to use decimal variables to control brightness and temp. For example if the values were calculated they would of course be decimals.
Please can you open up the selection of variables to accommodate decimals in this use case or provide a way for us to edit variable type (and by the way, name).
Decimal values are valid for temperatures (as in degrees), but not for level or colorTemperature of a bulb. Those values are integers. This has nothing really to do with variables, but with the device capability definitions. You can convert a decimal variable to a number variable by simply setting a number variable from the decimal variable. But setLevel doesn't allow a decimal value, nor does setColorTemperature. Allowing decimal variables in this context doesn't really make much sense. What would we do with 22.9? Should that be 22 or 23? That's up to you to decide, and you can decide by how you set a number variable from the decimal. If we did it for you, you'd complain that we did it wrong.
No I wouldnāt because Iām used to Perl and JavaScript where flexibility rules rather than having to code this type of variable type explicitly. I also donāt believe that lights must change their temp and brightness in arbitrary increments of 1. I prefer the system to have a brain as well as me lol. But never mind Iāll move this rule over to Node Red too. Cheers.
I assume this has to be in jest. On the odd chance it isn't, can you point me toward any RGBW bulb or LED driver that accepts RGB/HSL/HSV values as anything other than integers?
Guys, you are missing the point (which yes, was made partly in jest). Iād prefer the system to be resilient enough that itās not necessary to define variables as number or decimal for such a use case. Multiple reasons why. One example is a circadian lighting calculation that results in a decimal. To have to then convert that to an integer for use in a rule seemed unnecessary to me so I set them up as decimals and used them elsewhere. So now itās frustrating to have to redo it all.
I understand the purists amongst us. So you may not agree with the above. In which case Iād still like a way to edit variables having clearly set them up incorrectly.
Some drivers handle decimal to integer conversion. Some don't, and throw an error. I will investigate the possibility of allowing decimal variables in number contexts such as this, possibly for the next release. What would happen is a truncation of the decimal value to integer, so 22.9 would be 22.
Thinking more about this discussion, then looking at the capability of my devices. For my system I can't think of an instance where anything beyond the decimal point is used / needed / required. This is with the possible exception of internal calculations which I cannot comment on.
BTW my temperatures are in Ā°F because apparently we are not smart enough to understand the metric system
This is certainly true in general. However, that isn't really the point that @Angus_M is raising. His point has more to do with how strong the type checking is/should be for variables in these contexts. Nobody is looking to set a color temperature to 2753.5 vs 2753, but he wants the freedom to use a decimal variable without RM standing in the way.
It turns out that this is not a big deal, and in most contexts RM was already converting such values to integer. It's easy enough to always convert such values to integer before calling the drivers.
So, @Angus_M, this will be the case in 2.3.1 for sure. Quite possibly not in 2.3.0, as there may not be another 2.3.0 release after 2.3.0.124, which was just released.
I was running into issues with decimal values for hue and saturation with the Zooz RGBW Driver when used in a scene. The driver was reporting decimal values which were always off by a small amount from the integer value saved in the scene--so the scene would never become "set/on" (80.03 (driver) <> 80 (scene)).
That was back in 2.2.9--haven't paid too much attention to it lately. But, I'm mentioning it because it points out the complexity of tossing decimal numbers into the mix when some things use them and others use integers--you can easily get odd situations where "essentially equal" values aren't "equal enough".
This is not what is being discussed in this thread. We aren't "tossing decimal numbers into the mix". What the request was for is to allow decimal variables to be selected in bulb/dimmer contexts. The values used will always be converted to integers.
No, we're just smart enough to know that F is a much better scale for indoor temperatures than C... C is way too wide of a unit to control indoor temp, causing you have HAVE TO use decimals.
Good try Yes for home temperature control we would need decimals, but all in all the metric system works much better, and the rest of the world plus certain industries are still on the imperial system.
Now the much sadder thing is.... our congress who should be the visionaries are too busy bickering to get anything more than the minimum to keep the country running.
I understand, but in the end every system of measurement can work.
Are some more intuitive than others? Sure.
But do imperial units work just fine? Yup.
And it is becoming even less of an issue now that computers do the majority of scaling and conversion anyway. Not near the issue it was when doing it by hand.
In other words it really isn't a "problem" that needs fixing. More of a nice to have.
C is way too wide of a unit to control indoor temp, causing you have HAVE TO use decimals.
Yes for home temperature control we would need decimals, but all in all the metric system works much better, and the rest of the world plus certain industries are still on the imperial system.
