Please read a bit further up, you are not the only one with that issue
1 Like
@Kardiii
The basic PR is coming to an end, then I need to 2nd one to finalize synchronization
You should wait until âfix duplicate idâ and mDNS refactor is merged, see above
3 Likes
Sorry if this has been asked before but I realized that the battery#batteryLevel channel of the shellybludw does not provide a UoM but only a Nnumber. Could that be changed to a Number Dimensionless with a PercentageType?
please create an issue anf Iâll look into that
We habe 3 PRs read, but got stuck in review due to limited maintainrr avalanility
Let me create a build, which includes those changed
The first PR has been merged now 
Anybody is using 1.7.4 or the new beta 1.7.5? I have some new BLU Devices and it seems that for example time sync is only working with 1.7.4 and newer. So anybody tested this versions with the latest DEV Build of the binding?
Whatâs the link between binding and time sync? The binding does not provide an time syncing.
general update: PR 1 of 4 is merged, working on #2
@markus7017, is there some kind of âtest programâ that could be run to test a Shelly with a newer firmware version? Something that tests all possible aspects of the binding, and logs what goes wrong and what goes right?
there is no direct link to the binding. I have some of these new BLU H&T Displays, and they need to sync the time via Bluetooth. At the moment with 1.7.2 on my BLU GW Shellies the time is completely out of sync and I need to sync it via shelly app on my phone manually. With 1.7.4 some new Features, perhaps also the BLU Time Sync was implemented in the BLU Gateway feature of the shelly relais. At the moment all my devices are running very stable with your DEV Build 5.2.0.202601101913 so I just wanted to know if someone has tested the new firmware versions. I can live with the out of sync Displays, if all other Shelly stuff is running that stable, as it is right now.
Will there be a new DEV Build with all the new stuff you are working on at the moment, or will it first be implemented in the new 5.2 openHAB release? Canât wait to test the new connection methods you are developing at the moment. Keep on the great work @markus7017 
Iâll update the DEV buiöd toda with versions for 5.2,5,1 and 4,3 (if it works)
1 Like
(post deleted by author)
Updated DEV builds are available
- Improved multi thread safety and refactoring in the RPC socket layer - adresses WebSocket errors, improved logging
- RPC socket is no longer initialized for discovery
- Only one WebSocket client rather one per thing - saves resources
- Each http rpc request is now send with a unique request, but also unique src id - fixes âduplicate idâ messages in the device log, but also kreeps device internal processing clean (it could be that 1.7.4 introduced some protection against this and just drops WS connection). From my pov requirering a unique sec per request is wrong, the src should be the same, the id should update, but it is what it is.
The 2nd PR is not fully reviewed, once merged Iâll add keep alibe for the WS connecrion (to avoid closing when the device is not sending updates for a long time) and serializing mDNS processing will also improve thread synchronization and reduces resources.
One remark: Those changes are significant and may cause side effects or issues on edge cases. Therefore: Please
- backup old jar, update
- run yours tests, watch for issues, check OH log and event log for errors or exceptions
- give feedback
I need your support to harden the build and take it from there. Kudos also to @Nadahar who is supporting a lot and bringing good design to the codeâ
5 Likes
DEV build installed!
I am Running the new binding since about 4 hours now. Looks stable for me, no new errors / warning in the openhab log. The duplicate id warning didnât appear. I think itâs fixed, because I saw it many times with older binding version within 1 hour in the logs. I have also some devices with firmware 1.7.4, looks also stable.
I can see this Warning in my syslog server coming from most of my shelly relays, perhaps from all.
shelly_notification:116 ch type=WS_in info=192.168.50.20:50868 has no DST
Perhaps is this warning related to all the new connection stuff. If you think so, I can provide more informations. But perhaps it is also a misconfiguration on my side.
Thanks a lot, to you both, @Nadahar and @markus7017 ! I followed most of your conversations on these changes on GitHub 
1 Like
DST = Daylight Saving Time, so itâs complaining that it canât know if itâs daylight saving or not. Thatâs probably because the timezone is missing or wrong. I donât know if the binding handles this or if you have to set it some other way, but I understand it as if each Shelly is supposed to be configured with a proper timezone so that it can set the clock right.
interesting! DST is daylight saving time, though it is for destination. Also interesting is, then, that 192.168.50.20, which is my openHAB IP does not have the DST, or am I wrong? Timezone is set correctly in openHAB and also in the openHAB docker container. I also checked my Shellies, timezone is set up correctly. Checked the current device time, too, also correct.
I donât know the exact reason behind this, it could be that WebSocket messages all have timestamps, and that these donât specify a timezone for example. If so, it would be âthe fault of the bindingâ or Jetty. The best thing to do would probably be to log all the traffic for a short while, and study timestamps and see if something âlooks wrongâ.
I think itâs referring to the dst field in the message header and itâs not filled by the binding;
I checked the API doc and it says that this is only valid in the response message (= src of the corresponding requests). I donât understand why itâs complaining on an inbound request.
Do you see this messages frequently?
Thatâs true, it can be short for DeSTination as well. I donât know the protocol very much, but it says in the documentation that it is required for notification frames. Those arenât requests, but notifications that something has subscribed to I suppose. The DST field is there for âlocal routingâ within the device (to route the notification to whatever asked for/subscribed to it). I canât quite see why the binding would send notifications to the devices, I would think it was the other way around - but perhaps there are situations where the binding notifies the device? It does say shelly_notification in the log entry, so thatâs likely the reason itâs required.
If the binding doesnât send notifications, the only explanation I can think of is that the binding has described to notifications from the device, but not given the âsourceâ information for the subscription, so that the device donât know what to put in the DST field.