Smarthome: Units of Measurement: Follow up issues for the new QuantityType

[htreu]

These are some known issues after the Units of Measurement support in ESH landed (#4818):

• When the measurement system gets switched (or locale gets updated, which would result in another measurement system) there is no refresh on any item. So until bindings post a new state update or a REFRESH command is issued to the corresponding items the user gets the impression nothing changed.
• Analyse Automation JavaScript support
• The precision in state descriptions is currently static regardless of the chosen measurement system
• Right now only measurement systems SI (metric) and Imperial are supported. There are countries which use mixed systems.

[wborn]

The documentation of the refactored bindings also needs to be updated:

• Yahoo Weather Binding README.md
• Weather Underground Binding README.md

[lolodomo]

Yes please, an updated documentation would be helpful to understand in particular how to define the items now (item label).

[wborn]

@lolodomo The demo contains some item definition examples:

https://github.com/eclipse/smarthome/blob/b22b2337f323704810ec79b242103271393099eb/distribution/smarthome/conf/items/demo.items#L17-L19

[lolodomo]

Good question: are all persistence services compatible with the new type ?
Someone reported it is not. That would be a major problem...

[kaikreuzer]

@lolodomo That's a very valid question! I had actually thought about this, but in the end forgot to adapt the compatibility layer (through which all persistence in openHAB is still handled) accordingly.
Just created https://github.com/openhab/openhab-core/pull/319 for it and will make sure to have it available in the distro asap.

[htreu]

I left a comment on the PR Kai did which shows a structural issue with persistence and UoM: https://github.com/openhab/openhab-core/pull/319#pullrequestreview-104861978

[J-N-K]

Please see openhab/openhab-core#325. The question is, is it right to strip the unit-subtype there or is it better stripped in the ItemProvider in ESH?

[kaikreuzer]

@J-N-K Clearly to be fixed in the compat layer, not in ESH.

[cweitkamp]

I found another issue related to the new QuatityType. In sitemaps rendered with Basic UI the highlight features like labelcolor and valuecolor are not working like expected. The color isn't applied anymore. Probably because of not matching comparisons for the item type. If you need an example you are welcome to ask.

// EDIT: For clarification: The highlight works fine on Number items without a specified unit.

[lolodomo]

The sitemap syntax should let you mention the unit for the visibility and color attributes.

[cweitkamp]

How does it work? I didn't find an example. What has to be changed in the following line?

Text item=fritzWashingMachineDECT200Temperature label="FRITZ!DECT 200 (Waschmaschine) [%.1f %unit%]" valuecolor=[<15="blue", <=18="green", <=21="orange", >21="red"]

// EDIT: Item type is Number:Temperature.

[lolodomo]

Sorry, I mean you should be able but unfortunately you probably can't ... until this is enhanced.

[lolodomo]

@htreu : can you please remind us what is the new syntax including the unit in rules and in console commands ?

[lolodomo]

Looking at the code for the console commands, I have the feeling this was not updated, meaning you can't mention the unit ?

[htreu]

@lolodomo in the console you are able to provide the value & unit in one string:

smarthome update Weather_Pressure 1000hPa

Unfortunately in the IDE console you get parsing errors when using the ° character. This is a limitation of the Eclipse console implementation.

[htreu]

As for the syntax in rules it is missing in the docs right now. But I did a blog post here. The syntax is described in the "Scripts & Rules" section.

[lolodomo]

So for sitemap, should we update the syntax the same way as for rules or should we consider the same syntax as in console commands ?
Console syntax with one unique string would mean no change of syntax in fact, just a fix in the code parsing the values. I would vote for this option and I can even try to fix it (but I have a limited free time for that at this moment).

[htreu]

For sitemaps the syntax follows the item state description syntax: label="my Label [%.2f °F]" will convert and render the given temperature value in degree Fahrenheit.

[htreu]

Console syntax with one unique string would mean no change of syntax in fact, just a fix in the code parsing the values.

The QuantityType is actually able to parse Strings like 20°C but the console implementation of the eclipse IDE has encoding issues. So the problem can not be fixed in the scope of ESH.

[lolodomo]

As @cweitkamp explained, the problem is not the label attribute but would be the labelcolor /valuecolor / visibility attributes.

[lolodomo]

Netatmo binding is handling Co2 and noise data, respectively in ppm and decibel units.
Are these units available in ESH ?

[J-N-K]

@lolodomo, I have created #5385 for dB and ppm.

[lolodomo]

@htreu : regarding your first point (refresh when the unit system is updated), I imagine that setUnitProvider will be called for the thing handler factory of any binding referencing it when the the unit system is updated by the user ?
If I am right, then the handler factory could then notify each thing handler of this change so that a refresh can be handled by these handlers.
WDYT ?

[htreu]

I imagine that setUnitProvider will be called for the thing handler factory of any binding referencing it when the the unit system is updated by the user ?

Unfortunately this is not the case. The framework provides one instance of the UnitProvider and changes are not propagated to referencing services. The service setter setUnitProvider is annotated as 1..1, STATIC which means the instance will not get overwritten once set.
Otherwise the whole HandlerFactory would be shut down and created from the ground up.

For the refresh to work we need some registration mechanism where bindings register for UnitProvider updates. The framework can then call all registered listeners and notify about the update.
Bindings could then issue the REFRESH command or simply update the state from their caches with the value and unit converted.

[lolodomo]

As discussed in another PR (netatmo binding), it looks like the min/max/step attributes of a channel type are not correctly handled when the channel type uses UoM. It should be possible to set the unit with the value of these attributes, something like min="4.5°C".

[J-N-K]

As mentioned here, it is not possible to check for the correct type of an item's state without generating log messages.

[J-N-K]

Comparison in rules for % is not possible:

.items

Number:Dimensionless    Bad_hum     "Bad [%.0f %%]"             <humidity>

.rules

rule "bad test"
when
    Item Bad_hum changed
then
    logInfo("lueftung", "orig: {}, comparison: {}, {}", Bad_hum.state, Bad_hum.state>55, Bad_hum.state>0.55)
end

openhab.log

18:58:22.572 [INFO ] [lipse.smarthome.model.script.lueftung] - orig: 55.4185 %, comparison: false, false

If I change to Bad_hum.state>55% the log is

18:59:31.943 [WARN ] [del.core.internal.ModelRepositoryImpl] - Configuration model 'bad.rules' has errors, therefore ignoring it: [95,86]: no viable alternative at input ','

[cweitkamp]

If I change to Bad_hum.state>55%

Did you try to put the % between square brackets like this Bad_hum.state > 55 [%]?

[J-N-K]

@cweitkamp, that works. It‘s even in the blog post @htreu mentioned above. Maybe it‘s me, but I didn‘t notice the necessity of the brackets.

[watou]

In a rule under OH 2.3.0, I receive this log error:

'toUnit' is not a member of 'org.eclipse.smarthome.core.library.types.QuantityType'

in reaction to the expression MyItemName.state.toUnit('mph') for a Number:Speed item. Also, an attempt to import tec.uom.se.AbstractUnit at the top of the rule does not result in resolving AbstractUnit when the rule tries to use the parse static method.

[kaikreuzer]

I have seen the same error and wondered why it happened. We might need some implicit imports in Xbase for it - @watou I would say that this is worth a separate issue (as I consider it a bug). Would you be so kind and create one?

[watou]

Looking for a working way to use UoM to create a QuantityType in a rule from a variable, not a constant scalar value. The following under OH 2.3.0:

import org.eclipse.smarthome.core.library.unit.SIUnits
...
val double dewptc = (some computation)
val double dewptf = new QuantityType(dewptc, SIUnits::CELSIUS).toUnit('°F').doubleValue

produces the log messages:

2018-06-20 11:16:38.869 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'meteostick.rules', using it anyway:
The constructor QuantityType(Number, Object) refers to the missing type Object
2018-06-20 11:16:38.935 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'my.rules'
2018-06-20 11:17:22.958 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 'PWS': The name 'SIUnits' cannot be resolved to an item or type; line ...

[htreu]

@watou I created a separate issue #5759 for the missing unit constants. PR is also on the way.

[watou]

Using 2.4.0-SNAPSHOT build # 1378, when using CELSIUS in a rule, the following is logged

2018-10-03 11:27:41.578 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'meteostick.rules', using it anyway:
The field SIUnits.CELSIUS refers to the missing type Object
2018-10-03 11:27:41.589 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'meteostick.rules'
2018-10-03 11:27:53.997 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'meteostick.rules', using it anyway:
The field SIUnits.CELSIUS refers to the missing type Object
2018-10-03 11:27:54.074 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'meteostick.rules'

The only expression in the rule referencing CELSIUS is

val double dewptf = new QuantityType(dewptc, CELSIUS).toUnit('°F').doubleValue

There is no reference to SIUnits in the rule file. The rule appears to work as intended despite these log messages.