Shelly Binding

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)

Today is the Alterco press conference at IFA in Berlin
https://shelly.cloud/ifa-live/ at 14:05 CEST
The will present new devices and introduce a features.

Stay tuned :slight_smile:

Hello @Huaba and @markus7017 ,

i have the same problem with my DW2.
In the shelly app and browser the states/values workes fine and fast.
Only the binding doesn’t make any changes (in sleep mode).

I’m on binding 2.5.8 and the DW2 on 1.8.2.

Would this be fixed in 2.5.9 ?

Greets Stephan

DEV build is updated, please give it a try

Please try the latest DEV build with firmware 1.8.3


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

You need to delete 2.5.8 before switching to 2.5.9

perfect. It works correct. Thanks for you work.

Hello

i have tryed to change the AutoOff time from OH side it looks good but the Shelly has not change the Autoofftime

2020-09-07 23:24:41.401 [TRACE] [y.internal.handler.ShellyBaseHandler] - shelly25-relay-c45e73: Updating status
2020-09-07 23:24:41.403 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - shelly25-relay-c45e73: HTTP GET for http://192.168.177.18/status
2020-09-07 23:24:41.592 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - shelly25-relay-c45e73: HTTP Response 200: {"wifi_sta":{"connected":true,"ssid":"MosHome","ip":"192.168.177.18","rssi":-68},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"23:24","unixtime":1599521081,"serial":81,"has_update":false,"mac":"ECFABCC45E73","cfg_changed_cnt":8,"actions_stats":{"skipped":0},"relays":[{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"overtemperature":false,"is_valid":true,"source":"timer"},{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"overtemperature":false,"is_valid":true,"source":"input"}],"meters":[{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1599521081,"counters":[0.000, 0.000, 0.000],"total":44},{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1599521081,"counters":[0.000, 0.000, 0.000],"total":0}],"inputs":[{"input":0,"event":"","event_cnt":0},{"input":0,"event":"","event_cnt":0}],"temperature":53.56,"overtemperature":false,"tmp":{"tC":53.56,"tF":128.41, "is_valid":true},"update":{"status":"idle","has_update":false,"new_version":"20200827-065456/v1.8.3@4a8bc427","old_version":"20200827-065456/v1.8.3@4a8bc427"},"ram_total":49504,"ram_free":36204,"fs_size":233681,"fs_free":147086,"voltage":231.65,"uptime":3682}
2020-09-07 23:24:41.596 [TRACE] [.internal.handler.ShellyRelayHandler] - shelly25-relay-c45e73: Updating 2 relay(s)
2020-09-07 23:24:41.599 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - shelly25-relay-c45e73: HTTP GET for http://192.168.177.18/status/relay/0
2020-09-07 23:24:41.781 [TRACE] [ng.shelly.internal.api.ShellyHttpApi] - shelly25-relay-c45e73: HTTP Response 200: {"wifi_sta":{"connected":true,"ssid":"MosHome","ip":"192.168.177.18","rssi":-68},"cloud":{"enabled":false,"connected":false},"mqtt":{"connected":false},"time":"23:24","unixtime":1599521081,"serial":81,"has_update":false,"mac":"ECFABCC45E73","cfg_changed_cnt":8,"actions_stats":{"skipped":0},"relays":[{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"overtemperature":false,"is_valid":true,"source":"timer"},{"ison":false,"has_timer":false,"timer_started":0,"timer_duration":0,"timer_remaining":0,"overpower":false,"overtemperature":false,"is_valid":true,"source":"input"}],"meters":[{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1599521081,"counters":[0.000, 0.000, 0.000],"total":44},{"power":0.00,"overpower":0.00,"is_valid":true,"timestamp":1599521081,"counters":[0.000, 0.000, 0.000],"total":0}],"inputs":[{"input":0,"event":"","event_cnt":0},{"input":0,"event":"","event_cnt":0}],"temperature":53.56,"overtemperature":false,"tmp":{"tC":53.56,"tF":128.41, "is_valid":true},"update":{"status":"idle","has_update":false,"new_version":"20200827-065456/v1.8.3@4a8bc427","old_version":"20200827-065456/v1.8.3@4a8bc427"},"ram_total":49504,"ram_free":36212,"fs_size":233681,"fs_free":147086,"voltage":231.54,"uptime":3682}
2020-09-07 23:24:41.791 [TRACE] [y.internal.handler.ShellyBaseHandler] - shelly25-relay-c45e73: Updating 2 standard meter(s)
2020-09-07 23:24:45.058 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73: CoIoT Message from /192.168.177.18:5683 (MID=59491): {"G":[[0,9103,8],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,44],[0,6102,0],[0,4201,0.00],[0,4203,0],[0,6202,0],[0,3104,53.56],[0,6101,0],[0,9101,"relay"]]}
2020-09-07 23:24:45.062 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73: Serial 20736 was already processed, ignore update
2020-09-07 23:25:00.044 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73: CoIoT Message from /192.168.177.18:5683 (MID=59492): {"G":[[0,9103,8],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,44],[0,6102,0],[0,4201,0.00],[0,4203,0],[0,6202,0],[0,3104,53.56],[0,6101,0],[0,9101,"relay"]]}
2020-09-07 23:25:00.048 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73: CoIoT Sensor data {"G":[[0,9103,8],[0,1101,0],[0,1201,0],[0,2101,0],[0,2102,""],[0,2103,0],[0,2201,0],[0,2202,""],[0,2203,0],[0,4101,0.00],[0,4103,44],[0,6102,0],[0,4201,0.00],[0,4203,0],[0,6202,0],[0,3104,53.56],[0,6101,0],[0,9101,"relay"]]} (serial=20992)
2020-09-07 23:25:00.050 [DEBUG] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73: 18 CoAP sensor updates received
2020-09-07 23:25:00.053 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[0]: id=9103, Value=8.0 (cfgChanged, Type=EVC, Range=U16, Link=4: device)
2020-09-07 23:25:00.055 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[1]: id=1101, Value=0.0 (output, Type=S, Range=0/1, Link=1: relay_0)
2020-09-07 23:25:00.057 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[2]: id=1201, Value=0.0 (output, Type=S, Range=0/1, Link=2: relay_1)
2020-09-07 23:25:00.059 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[3]: id=2101, Value=0.0 (input, Type=S, Range=0/1, Link=1: relay_0)
2020-09-07 23:25:00.061 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[4]: id=2102, Value=-1.0 (inputEvent, Type=EV, Range=S/L;, Link=1: relay_0)
2020-09-07 23:25:00.063 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[5]: id=2103, Value=0.0 (inputEventCnt, Type=EVC, Range=U16, Link=1: relay_0)
2020-09-07 23:25:00.066 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[6]: id=2201, Value=0.0 (input, Type=S, Range=0/1, Link=2: relay_1)
2020-09-07 23:25:00.068 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[7]: id=2202, Value=-1.0 (inputEvent, Type=EV, Range=S/L;, Link=2: relay_1)
2020-09-07 23:25:00.070 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[8]: id=2203, Value=0.0 (inputEventCnt, Type=EVC, Range=U16, Link=2: relay_1)
2020-09-07 23:25:00.072 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[9]: id=4101, Value=0.0 (power, Type=P, Range=0/2300;-1, Link=1: relay_0)
2020-09-07 23:25:00.075 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[10]: id=4103, Value=44.0 (energy, Type=E, Range=U32;-1, Link=1: relay_0)
2020-09-07 23:25:00.078 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[11]: id=6102, Value=0.0 (overpower, Type=A, Range=0/1;-1, Link=1: relay_0)
2020-09-07 23:25:00.080 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[12]: id=4201, Value=0.0 (power, Type=P, Range=0/2300;-1, Link=2: relay_1)
2020-09-07 23:25:00.082 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[13]: id=4203, Value=0.0 (energy, Type=E, Range=U32;-1, Link=2: relay_1)
2020-09-07 23:25:00.085 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[14]: id=6202, Value=0.0 (overpower, Type=A, Range=0/1;-1, Link=2: relay_1)
2020-09-07 23:25:00.087 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[15]: id=3104, Value=53.56 (deviceTemp, Type=T, Range=-40/300;999, Link=4: device)
2020-09-07 23:25:00.090 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[16]: id=6101, Value=0.0 (overtemp, Type=A, Range=0/1;-1, Link=4: device)
2020-09-07 23:25:00.092 [TRACE] [elly.internal.coap.ShellyCoapHandler] - shelly25-relay-c45e73:  Sensor value[17]: id=9101, Value=relay (mode, Type=S, Range=relay/roller, Link=4: device)

the log starts before when sending the command to the channel, which then results in HTTP GET to modify the timer

Hello Markus7017.

Since the update to 2.5.8-1 an the attched SHelly binding, I have th eissue, that under the Android UI, an d other UI’s my shelly1’s which have the feature Auto Off for the Relais e.g. als openener fo the door, keeps the visible switch in the UI’s always on. In passed the UI was showing me 5sec the “On” and the after the 5sec it was shoiung me off. The shelly1 runs with 1.8.3, and the OH with 2.5.8-1.

With clean the cache an a reboot i coul dnot solve the issue.
Any idea?

BR
Jochen

PS: From the shelly forum, a other user “funkenwerner” is also reporting the issue.