Shelly Binding

There might be changes in the internal Thing structure and/or channel behaviour, that‘s the reason.
When merged to the release, those changes will be announced as breaking changes.
So nothing to be curious about.

if the channel definitions, translation etc are updated it’s the safe way to delete the things re-discover them. OH keeps Thing/Item linkage separate. This gets restored when the thing is re-discovered, so usually nothing gets lets.
You could keep your things, but maybe don’t get all new channels and maybe this causes side effects, so it’s not a must.

As mentioned before there is a breaking change. I removed channels

  • lastPower2, lastPower3 for meters
  • and lastDirectiin for rollers
    Those channels don’t get updated anymore if they exist. The reason: Those don’t get updated by Coap, even not in version 2

ok, will include that in the next release
Feel free to suggest other translation stuff

Hi all,
i have a problem with the shelly bindng and the Shelly 3EM with “device_accumulatedWTotal”.
Sometimes the binding give me the Total without “meter1_totalKWH”.
shelly_shellyem3_device_accumulatedWTotal = 37.86
shelly_shellyem3_meter1_totalKWH = 12.055
shelly_shellyem3_meter2_totalKWH = 6.325
shelly_shellyem3_meter3_totalKWH = 31.535

In the graph you can see that this problem comes at different times approx over 30 times a day.

Can’t find where you calc that in the binding.

Best wishes
and stay healthy
Uli

i see the same problem…

i have a trace log for you:
openhab.log (19.2 KB)

you see the lines:
Channel device#accumulatedWTotal updated with 189.695 kWh

Channel device#accumulatedWTotal updated with 227.669 kWh

…the second value is the correct one…

good news: the PR has been merged so Addon Package 2.5.9 will include support for all Shelly devices


Latest DEV build 2.5.9 - README - Installation - Firmware Index - Firmware Archive - API Doc

1 Like

Are you in the DEV build or regular release?

I’ve updated to the DEV binding and rediscovered all things. Now all works fine, excepting the tilt state of my 6 DW2. The tilt is calibrated and shows correct values in the webinterface. This value only updates via CoIP if the DW2 is online with the pressed button and LED is flashing. No update on state changes in standard operation.

Anyone else?

1 Like

i’m on 2.5.7-1 regular release

but i am on DEV release from 26.8.2020 and i see the same…

I’ve found a new issue (Openhab 2.5.8, DEV-Binnding):
When I install a new Binding, Openhab reinitializing the items. After that it resend the last event:

2020-09-02 21:05:06.118 [hingStatusInfoChangedEvent] - 'shelly:shellyix3:68c63afa940a' changed from ONLINE to UNINITIALIZED
2020-09-02 21:05:06.138 [hingStatusInfoChangedEvent] - 'shelly:shellyix3:68c63afa940a' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2020-09-02 21:05:22.254 [hingStatusInfoChangedEvent] - 'shelly:shellyix3:68c63afa940a' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
2020-09-02 21:05:28.887 [hingStatusInfoChangedEvent] - 'shelly:shellyix3:68c63afa940a' changed from INITIALIZING to UNKNOWN
2020-09-02 21:05:29.231 [me.event.ThingUpdatedEvent] - Thing 'shelly:shellyix3:68c63afa940a' has been updated.
2020-09-02 21:05:29.240 [hingStatusInfoChangedEvent] - 'shelly:shellyix3:68c63afa940a' changed from UNKNOWN to ONLINE
2020-09-02 21:05:29.263 [vent.ChannelTriggeredEvent] - shelly:shellyix3:68c63afa940a:status1#button triggered LONG_PRESSED
2020-09-02 21:05:29.267 [vent.ChannelTriggeredEvent] - shelly:shellyix3:68c63afa940a:status2#button triggered LONG_PRESSED

At this time, nobody has made a click bit it send the event and do the action behind.

Same here, also with the DEV-binding.

hi all,

do I understand this correctly that I have to delete and re-add all my shelly things if I switch to the dev binding? Is this a high effort? And will this still be required if 2.5.9 has been released? I run more than 30 shellies :-/

Stefan

Hello markus7017:

I would be nice, if you could short explain, what will be the impact when the next release from OH with 2.5.9 will be go live for all our shelly things.

It would be also not nice to delete 20-30 Things and the attched items. This would be more or less a fresh setup for some of us.

Thanks in advanced.

BR
Jochen

I raised the question on whether it is necessary to go through the deletion / recreation of things here: Shelly Binding From the answers I have seen, it looks like an action recommended to work around issues with changed Thing metadata. It is highlighted in bold - which makes it look mandatory - but I’m still not convinced it is really necessary. A sample never proves anything, but for me it worked to replace the release version by the developer version without the deletion / recreation. :wink: But i’m open to be convinced I’m wrong. :slight_smile:

This is correct and I see no way to avoid it. The problem is that the device doesn’t report a “real event”, but the last state. The binding remembers the last state and event counter and uses this to map the data into an event. When you restart the binding this data is not there and the binding triggers an event. Let me check if I could work around this

No worries, it doesn’t hurt :slight_smile:

As always

  • Once you add a thing from the Inbox openHAB copies the thing definition from the resources in the binding bundle
  • This means if you update the bundle the thing definition for existing things stays the same even the bundle (jar) may contain updated defintions
  • Running an updated binding on top of “old” thing definitions works in general, but might cause side effects

Deletion and re-discovery of the thing is a recommendation. Mostly it works without fine, but sometimes… It’s up to you and you could try first without deletion & re-discovery and see if it works.

In general this process is nothing special. openHAB keeps the linkage between channels and items even you delete a thing. When you re-discover the thing OH restores that linkage automatically and you don’t need to recreate the link. This works unless the thing id changes, which usually doesn’t happen. This is not specific to the Shelly binding, it’s the same feature for all bindings.

So, @HarryS1 is right, it’s recommended, but not mandantory. You could go the 2-step approach: First just switch to the DEV build, see if everything works and only delete & re-discover if you encounter problem

I recommand

  • crerate a backup of the OH configuration (at least the JSONDB folder)
  • delete all Shelly Things
  • switch to the DEV build (incl. restart)
  • re-discover all Shellys and add them back
  • if something breaks: restore your backup

believe me, I did this already more than once :slight_smile:

fyi: The PR has been merged, so support for new Shelly devices will be part of the upcoming 2.5.9 release (in 2-3 weeks). You could find the latest official 2.5.9 SNAPSHOT release here (make sure to delete 2.5.8 before installing 2.5.9 SNAPSHOT).

I’m working on another PR and hope to get it in also. This will add

  • new channel device#deviceName and
  • new channel relay#channelName
  • and maybe the fix on event triggers as mentioned above

to get the symbolic names you have configured in the Shelly App (new feature with firmware 1.8). This helps to keep an overview with a bigger number of Shellys and you could also use it in the UI.

Hello markus7017,

  • This means, when we upgrade the OH 2.5.8-1 to the OH 2.5.9, we will get the new shelly binding,
    and all shelly will work as before?
  • With the new binding, we are able to add e.g. new shelly type like my button1?
  • If we delete and add the shelly as things, we get new shelly features, which we can use?

Is this more or less the summery?

BR
Jochen

yes, this is my expectation
In fact the binding will add some new channels (like LED control or device/channel name) also to existing things. On the other side: Updated thing labels, fixed typos or missing translations will not be updated. As I said: your choice

Breaking change: The following channels have been removed and will no longer updated: lastPower2, lastPower3, voltage, lastDirection (for roller)