Shelly binding - unit conversion warning and 'Err' shown in Basic UI after upgrade to 2.5.6

Hi there,

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'

The thing looks like:

Thing shelly:shellyplugs:###### "Shelly Plug S1 GH" [deviceIp="aaa.bbb.ccc.ddd", userId="", password="", eventsSwitch=true, eventsButton=true]

And the appropriate item looks like:

Number:Power ShPlS1_GHPow "Shelly S1 GH Energy [%.2f %unit%]" (gShelly)  {channel="shelly:shellyplugs:######:meter#currentWatts"}


    Frame label="Shelly Plug S1 GH" {
      Switch item=ShPlS1_GHRel icon="switch"
      Text item=ShPlS1_GHPow icon="energy"

The pump has different operation modes with different power consumptions and I use the power information to see in which mode the pump is running …

Any idea how to correct this would be appreciated.

Thank you!

To rephrase, while your Item has A NULL or UNDEF state, your Item’s [state description] format throws an error now, instead of calmly displaying the “-” hyphen we used to see?

The items state is “0.0”. It is neither NULL nor UNDEF

Even when I set the item state manually it is not able to convert and shows “Err”:

18:48:36.748 [WARN ] [.ui.internal.items.ItemUIRegistryImpl] - Exception while formatting value '17.0867' of item ShPlS1_GHPumpPow with format '%.2f %unit%': Conversion = 'u'

Reading the item’s state via the REST API UI gives “17.0867” but Basic UI shows “Err”

But the problem is actually: Why the conversion fails? Or am I wrong?

May we see this output? I would expect to see a unit like“17.0867 W”, your display asks for the unit after all.

According to the Shelly binding docs, only number channels are supported, not quantity types with units. But the docs may be out of date here.

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 …

Maybe this Thing attribute does the job eventsSensorReport=true

I have set it in my things file and I will check tomorrow if this works!

How can I identify the owner/maintainer of the binding to ask him how I cope with later acitvated device? Or should this be discussed in a dedicated topic?

I don’t really understand what you are asking.

By default, all openHAB Items are created with NULL state by default. That’s the way they stay until something else happens.

“Something else” could be an incoming update from a device via a binding. That could be seconds or days later.

Sometimes users prefer to set an Item to the last known good value, and they will generally use persistence service with restore-on-startup options.

I’m not sure which part of this cycle you are having trouble with?

Ok, sorry. This is because I have unintentionally mixed up things here:

there have been two overlapping problems:

  1. 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
ShPl_S1pow.postUpdate("17.0867 W")
  1. 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:
Number:Power ShPl_S1pow "Shelly S1 GH Pump Energy [%.2f %unit%]" (gShelly)  {channel="shelly:shellyplugs:######:meter#currentWatts"}

I see no updates for item ShPl_S1pow after I have turned the device on …

Hence my question is if and how the binding is recognizing devices that get turned on after boot time to enable their channels to receive the data they are sending?

Did I explain this in an understandable way?

And I guess I finally found the community topic of the shelly-binding creator and posted my question about the device handling there :slight_smile:

So this topic can be considered as solved … I will write the solution into a separate reply and mark it as the solution.

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. :slight_smile:

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.

Ok, thank you for the explanation!

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.

The current behaviour is:

  • OpenHAB starts
  • Device not present
  • Device gets started later during the day
  • Device starts sending data to the channel
  • OpenHAB is not receiving the data sent by the device to the channel
  • Submitting a bundle:restart ### => where ### is the bundle number
  • Restarting the binding enables that the channel receives the data from device

My wish/expectation would be that I do not need a restart of the binding when turning on the device later. And it worked like this in 2.5.3 and does not with 2.5.6

Okay, I suggest you gather your evidence - Thing channel, Item configurations, and your events log showing it not happening - and submit a “bug report” on Github for the binding.


Thanks for guiding me … will do so!