I am running OH 2.5.6 in a docker container on my NAS. It is the debian x86_64 version …
Since I upgraded from OH 2.5.3 to OH 2.5.6 I get an warning only for one of my Shelly Plug-S devices and in the Basic UI it shows ‘Err’ for the power usage instead of a value!
All other Shelly Device - Plug-S and Shelly 1 PM - show correct values.
It might be necessary to say that the Shell Plug-S that throws this message has no power at boot time of OpenHAB. It gets powered on with a physical switch during the day to activate all power in the garden shed … This plug then is used to turn the water pump on and off.
But everything worked fine in OH 2.5.3. The problem started occuring after the upgrade:
Here is the excerpt from the log:
17:15:21.642 [WARN ] [.ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value '0.0' of item ShPlS1_GHPumpPow with format '%.2f %unit%': Conversion = 'u'
17:25:48.259 [WARN ] [.ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value '0.0' of item ShPlS1_GHPumpPow with format '%.2f %unit%': Conversion = 'u'
17:25:59.005 [WARN ] [.ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value '0.0' of item ShPlS1_GHPumpPow with format '%.2f %unit%': Conversion = 'u'
You are right! At least it is not documented that the shelly binding supports quantity types with units. The funny thing is that it works for another device of the same type. My feeling is that the problem lies in the fact that the device with the issues is not active at boot time and hence maybe the binding runs some communication to the devices that are not responded by this one device. And hence the other device that is always activated is able to communicate to the binding at boot time … The bad thing is that I did not see the issue with 2.5.3 and it appeared with 2.5.6 …
Ok, I found out that the currentWatts channel gets not initialized when the binding starts at boot time and the device is not connected to a power outlet. And then the binding has some orphan old value …
I have now defined in my “set_defaults.rule” file that at boot time of OpenHAB a dummy value of “17.09 W” gets set. This prevents the conversion warning …
When I turn on the plug device I can turn it on and off as this channel is bidirectional and gets therefore activated afterwards. But the currentWatts channel is only sending data to OpenHAB and therefore gets not initialized afterwards.
When I restart the binding the channel gets updated and the current Watts value are send in the format “###.## W” and hence correctly displayed.
I will have to ask the binding owner how a device gets initialized which is powered on after the initialization at boot time …
Ok, sorry. This is because I have unintentionally mixed up things here:
there have been two overlapping problems:
The conversion warning causing because of a wrong value in the item also causing the ‘Err’ display in Basic UI.
=> I have solved this by setting a dummy value at boot time
When the shelly device is not powered on at boot time (when the binding starts) it does somehow not initialize the channels for this device correctly. Because when I turn on the power and switch the relay the device sends its power usage to the channel but OpenHAB does not receive any updates as the karaf log show not updates to the appropriate item:
The ‘fix’ for your units issue is just a workaround really, because you are linking a number only channel to a Number:power type Item. It sorta works, sorta doesn’t, because it’s an unsupported linkage.
It’s your openHAB and you can do what you like with it, of course.
On the channel initialization thing, there’s no reason the binding should update any given channel unless the target device has told it something new about that data element.
So the question might be better asked as -
Does the device report this property at startup?
If it doesn’t, that is usually the end of that so far as openHAB is concerned.
If it does, perhaps the binding needs enhancement to capture data appearing in a different message context or such like.
It is arguable if a general wakeup message omitting the data might update the channel to UNDEF, to indicate unknown at present.
It certainly shouldn"t make up values, not even zero.
Regarding my fix … I have a second Shelly plug which is constantly connected and this one works absolutely correctly including the unit. The item from the powered off plug had an orphan value without unit (don’t know why this happens because - again - the other plug works with unit) which caused the problem and hence I decided to set a valid value as there is none set by the binding.
So there has something changed in the behaviour form 2.5.3 to 2.5.6 as before it worked and maybe there was a change to the binding causing a wrong initialization or OpenHab has became more accurate in checking item types and states …
However I can live with that respectively I hope this problem disappears when I find a way that the channel gets correctly initiated when it powers on.
Please help me understand.
If I have a thing defined for a device and corresponding items to the thing’s channel and the device is not available at startup: Will the channels be correctly initialized?
Or the other way round - considering the binding intializes all channels correctly no matter if the device is available or not - when I now turn on the device: Is there a frequent/automated/device initiated discovery process so that the powered on device gets configured correctly even when being turned off later?
I am wondering why the data being send to the channel will not be recognized by OpenHAB automatically. Because when I restart the binding then the channel accepts the energy consumption data sent by the device …
If you have defined Thing, but no device is physically present/communicating at start up … what is that you expect the channel to do, exactly?
It may help here to understand that a channel only passes events, really. The Item holds the persistent state.
Then, you seem to have a different problem. If you turn on the device later, it is not seen by the binding, not updating channels? That would be a deficiency IF the device is actually sending information.