I’ve noticed that some bindings seem to be doing some kind of behind the scene transformation on item value that is causing me problems because actual items states seem to be different from rendered item state. Seems to be related to state description, but i haven’t found solution in the documentation.
I’m having this problem for example with charging states of Dacia binding or Operation mode of Onecta (beta) binding.
My problem is that when I try writing rules based on states of these items, based on what i see displayed in the interface it does not work. Same issus trying to set dynamic visibility in sitemaps.
How can i find what is the actual states of these item in order to use it in my rules and sitemaps ?
Is it related to the unit of measurement changes of v4.0? Lots of topics about it if so:
One example:
To see the values coming in you can check the logs. Though I’ll be honest, i cheat and use node red for that because it’s more practical.
It would actually be nice to have a log window in each item, filtered for that item alone, to see the values coming in and out… but regardless, check the logs
Thanks Pedro, i’ll look for the log.
May be related to this unit issue, but in my case, it is a text state that is transformed into a different text. For example, on the Onecta binding, air conditionning operation mode is displayed as “Cooling” in the interface, but value I need to use for comparison in rules & dynamics sitemaps is “COLD”.
The state is not actually being converted really. Some bindings automatically apply state descriptions to items linked to their channels so that the Display state is different than the actual item state. Many of the items specific pages in the UI use that display state instead of the actual state. To see the difference you can use the Developer Side Bar and go to the expression tester. Then type in
=items.Name_Of_Your_Item
And the result will be an object that shows you the state of the items and, if it exists and is different than the state, the display state.
You can also always see the actual state in the items list page itself.
That’s why I use node red. It’s a nifty automation application where you can expose openHAB items (and a whooooooooole lot of other stuff). And you can easily check one specific item.
There are lots of ways to see the “raw” state of an individual Item. In no particular order:
grepping through events.log as shown above
querying for the Item in Developer Tools REST API
Developer Sidebar
a. expression tester as demonstrated above
b. watch the event stream with a filter on just the one Item
c. Scratchpad Script and log the Item’s state to openhab.log
the raw state of the Item is shown on the Settings → Items page (as shown above)
if using VS Code to configure text file configs, you can hover over the name of an Item to see it’s current state
override the binding provided state description pattern with %s which will show the untransformed state of the Item everywhere and not just in the places listed above
