Sorry, I forgot to mention that this build requires OH 5.3-SNAPSHOT. We are currently discussing how to handle 5.2 (regular DEV build still runs on 5.2).
Ah ok.. Thx for information.
perhaps update your post, so nobody else is trying with 5.1. or 5.2 release.
Hi Markus, just wanted to report back, i completed some testing. Creating the channels manually solved the problem completely. I am not storing the door state value with persistence service, so cannot comment how it effects the original issue (sensor channels not created dinamically), but here is what happens without persistence.
- When openHAB restarts with BLU Gateway and BLU Door Window sensors defined in things file properly BUT WITHOUT sensor channels, DW things are in âpending configurationâ state and only 2 device channels (alarm and wifiSignal) exist
1.1 If you push the button or open/close the door before the automatic status report sent by the device (every 7th hour), all good, 4 sensor channels, 3 device channels, 2 battery channels and 3 relay channels are dynamically created, beside the already existing 2 device channels.
1.1.1 After this, opening/closing the door is properly updating the state, lux ans tilt channels, and the binding updates the lastUpdate value also.
1.2 If the first message is the automatic status message from the BLU DW sensor which openHAB receives, only 1 sensor channel is created (instead of 4), the lastUpdate channel, with the 3 device, 2 battery and 3 relay channels, beside the already existing 2 device channels.
1.2.1 After this, opening the door wont trigger the dynamic creation of state, lux and tilt channels anymore, i think this is a small bug. - When openHAB restarts with BLU Gateway and BLU Door Window sensors defined in things file properly WITH sensor channels, DW things are in âpending configurationâ state, it has already the 4 defined sensor channels, and 2 device channels which is autocreated upon loading the thing definition i assume.
2.1 On the first update coming from the BLU device to openHAB, the missing 3 device, 2 battery and 3 relay channels are dynamically created, all channels updates correctly (including all sensor channels).
If i may suggest, potential - and better - solution could be to create the 4 sensor channels when the DW thing is loaded from the things file, together with the 2 device channels. Or if that is not good for any reason, the binding could add all 4 sensors with NULL value when - and if - the status update (which donât have any state, lux or tilt information) arrives first, without state, lux and tilt information.
If you want - and makes sense - i can test further, dont know if i let openHAB to discover the DW things, maybe it behaves differently. Just let me know. And thanks again for your immediate reply on my post, my config is already working perfectly, i am just thinking of the those who will start using DW sensors in the future with text file based config. Which is still my preference, because i can use VSCode to program my rules.
Hi, I have some Shelly devices that show âError:COMâ in red for some days now (Shelly Plug S Gen3, Shelly 1 Gen 4) after working okay for months. Some other Shelly devices are okay (Shelly plus 2PM).
The Status is
Status:
OFFLINE
COMMUNICATION_ERROR
Es trat ein unerwartetes Problem beim API-Zugriff auf. ĂberprĂŒfen Sie die Logdatei fĂŒr genauere Informationen.
But in the OpenHAB Log, there are no Shelly entries.
All âOfflineâ devices are reachable via IP address and can be switched on/off from there.
Any idea on how to solve this?
did you upgrade to firmware 2.0.0? If yes, try to install the latest beta version and share your findings here.
Yes, upgraded to 2.0.0. Today, I upgraded to 2.0.1 and after that, the devices were online again - but only very short time. Now all 3 are offline again.
@michel53
have you switched to this dev build?
https://github.com/markus7017/myfiles/blob/master/shelly/org.openhab.binding.shelly-5.3.0-SNAPSHOT.jar
All my devices with firmware v2.0.1 work flawless with it
Run OH 5.2.1 Release Build and binding version 5.3.0.202609201332. Have Shelly FW 2.0.1 on all devices which allow to install it.
Can confirm that everything runs 100% perfect.
Upgraded now to OH 5.3.0.M1 and can confirm that it still works out perfectly with binding version 5.3.0.202609201332 and firmware 2.0.1.
I am running openHAB 5.2.1 with Shelly Binding 5.3.0.202609191558 and just tested some devices, after using the beta firmware, with stable firmware 2.0.1. It is looking pretty good so far. Didnât see any issues at the moment.
It seems as if binding version 5.3.0.202609201332 has to be installed in addition to the official Shelly binding!? Without the official Shelly binding, all devices show a âmissing handlerâ error and are offline in OH.
With both bindings installed, I still have 2 devices with âERROR:COMâ.
The org.openhab.binding.shelly-5.3.0-SNAPSHOT.jar was copied to usr/share/openhab/addons/
I have restarted OH, no difference.
Very strangeâŠ
The Shelly binding needs the californium library. marketplace bindings or jars cannot load them by themselves.
If you install the old binding than it is doing this job. But thatâs definitely not the way to go as itâs unclear which binding takes over.
Either you put the missing libraries into the addon-folder (described above in this thread) or (my recommendation) install the tradfri-binding which loads the libraries too.
Ah, thanks, with the tradfri binding and the shelly binding version 5.3.0.202609201332, the Shellies that worked before are online again.
Still, one of the 2 plug S Gen 3 is offline and the Shelly 1 Gen4 is offline, too, still having a âCOMMUNICATION ERRORâ.
You can install Californium using the Karaf console and the following command:
feature:install openhab-transport-coap
This does the missing job.
Okay, thanks, this is an alternative to the tradfri binding.
But the 2 devices are still in âCOMMUNICATION ERRORâ.
Are they running firmware version > 1.7?
Thatâs not possible. If the binding works with Shelly devices that there have to be entries in the Log. For more details enable DEBUG log on the OH console.
No, the opposite. The release binding needs to be removed before installing the DEV builds.
Check READMEbeta and follow the instructions to get a clean base
Check openhab.log and include relevant information here. You canât expect a solution by the community just including 2 facts, but no details.
Yes, this occurs since updating the devices to 2.0 and then updating to 2.0.1.