Hello,
I am using oh 3.1 m1 and make my first steps with blockly. I try to compare the item state (number item) with a number from the math block in an if statement, but I can not link the Number block to the inequality block (see first picture). A text block is no problem (2. picture) but doesn’t work. If I set a variable to the number value and than link the variable in the inequality block everything is running like I expect (3. Picture).
Can somebody help me to link the number block like it should…
When they are done. It’s all volunteer effort. there is no schedule. It might be tomorrow, it might be next week, it might be next year. In the next couple of weeks is the most likely.
From what I can tell, this has not yet been fixed.
What a strange bug. Isn’t such a comparison (i.e. between an item state and a number) quite a common thing?
I suppose the reason why I find it strange, is that I don’t understand something, but the only explanation I can come up with is that item states are usually strings so that comparing them to text was the most important thing to implement since even numbers (i.e. number-strings) can be compared to strings. So it only becomes a problem when the comparison involves mathematical operations. Does that makes sense or is there a different explanation?
Blocky support was hurried and released as a minimum viable product (to parrot an Agile development term). Wiring with numbers on OH is actually quite complicated because of Units of Measurement so it’s not simple to implement.
The hint with the variable is still up to date.
To make a simple temperature control, where the object to be cooled should be lowered a few degrees, must still be achieved with variables.
Example: Room temperature is set to 22°C, but the air conditioner should cool down to 21°C.
So
[Variable] = Item State
ItemTemperature < [Variable] - 1
And it’s not going to be possible due to limitations of JS. JS doesn’t allow operator overloading.
There’s also the issue about what units to use.
100 °C > 5
5 what? °C? °F? K?
So if you want to do math with units, all the operands need to be Quantity. And because JS doesn’t allow operator overloading, we have to use the methods on Quantity instead of the built in math operators.
Or you can strip off the units and do math with plain numbers, but there you have to use the built in math operators and not the Quantity methods.
That was my first idea. Use “get numeric state of item”, which should strip the unit and leave me with a pure number to do math with. You are correct that “quantity” isn’t the right way here.
@Tschetan comparing the numeric state of an item to a number doesn’t work, either. The only way I’ve got it working now is by doing the detour via a variable.
And since we’re on topic: is there any reason why (in pseudocode) “if state.of.item = (x or y)” doesn’t work? The way that works is: “if (state.of.item = x) or (state.of.item = y)”.
Hmm, now that you mention it, I was pretty sure it worked in the DSL rules, but I can’t seem to find an example in my old rules, so you are very likely correct.
But yes, when I had a bunch of conditions to compare I didn’t use the list but there is a logic block that is “AND/OR for any of the following”. That worked, too, I replaced my old switch/case rules with that.
I’m actually saying the opposite. If you have a Quantity, your code will be more self explanatory and robust if you stay working with Quantity. You just have to use different blocks to do the math under the “Units of Measurement” category.
yes: If you use quantities then you have to use the quantity operator (notice the “Qty” below) which your find under “units of measurement”.
If you don’t use quantities then the normal operator is sufficient. So both of these work:
Yup. But the 2nd example is very unfortunate. Numbers should never be used as a string when comparing. “10” is less than “2 W”
because: The comparison of two strings is done character-by-character (i.e., according to the value of charCodeAt) from left to right. The extended equality rules of the Unicode standard do not apply, and Unicode normalization does not take place.
