Blockly handles comparison differently when taken from state directly or from intermediate variable

[stefan-hoehn]

The problem

• when a state of type number (e.g a power item) is compared in blockly it is not treated as a number but a string instead
• when the item's state is assigned to a value and then the variable is compared it is treated as a number

See more details in thread https://community.openhab.org/t/solved-how-to-convert-state-string-to-number-in-blockly/113933/4

Expected behavior

It is expected that a state value of type number can be directly compared against a number without intermediate assignment to a variable which to me even though working rather looks like a hack 😄

Steps to reproduce

• Define a number item and then create the following rule in blockly

• in the above image the first comparison works against a number as it has been assigned to a variable before
• if the comparison is done line in the second if branch it only allows a string comparison (which does not make sense in this case)

Your environment

Openhab 3.0.0

generated javascript code from blockly:

var watt;

watt = itemRegistry.getItem('Shelly1Steckdose_Leistung').getState();
if (watt < 5) {
}
if (itemRegistry.getItem('Shelly1Steckdose_Leistung').getState() < '5') {
}

[stefan-hoehn]

I have researched the problem myself. Basically the reason is because it is converted to Javascript and comparison works well if

• the state does not contain a metric (and therefore only contains a number)
• one of both has the type of Number

In the case a String (containing a number) is compared with a Number then Javascript converts the String into a Number and the comparison works.

So the reason why it works above in the first case is actually not the reason that is assigned to a variable but because the comparison is done agains a number.

Also see discussion here: https://community.openhab.org/t/extending-blockly-with-new-openhab-commands/127169/202

[Oekel]

Nevertheless there is the mentioned workarround and a reasonable explanation it is not intuitive and should be fixed some day ;)

[stefan-hoehn]

I agree totally we just don't yet know what would be the best approach on how to fix it.

[stefan-hoehn]

@ghys What if we would add a block that would always return a number for a given state (stripping off any trailing metric string after a number).

We could

• add a separate block "get state value of item" similar like "get state of item" but returning a value instead the state string

• add an additional entry "state value" in the drop down of "get attribute of item" returning a value instead the state string

[stefan-hoehn]

@florian-h05 I would say that this will be fixed with openhab/openhab-js#201 , correct?

[florian-h05]

@stefan-hoehn As far as I have understand the issue correctly, the problem here is that the state is type of a Java object.
I am not sure when and how NashornJS is converting the type here, but GraalJS is more strict on types (which is correcter).

Anyway, the introduction of UoM support will solve problems with comparison.

So yes, this will be fixed.

[stefan-hoehn]

Can you add this to openhab/openhab-js#201 this here it will be automatically closed with 201?

[florian-h05]

I’ll add it to both Quantity PRs, not sure which one will get merged but I’d guess the second one 👍

[florian-h05]

@stefan-hoehn Can you please close this issue? openhab/openhab-js#206 has been merged, I guess that it did not close this issue because I have no write access to the webui repo.