I have several Shelly Plus Smoke devices. They have been successfully added to the inbox of the shelly binding 4.2.2 and I could also integrate them to openHAB.
The problem is that after a day the thing status changes from ONLINE to COMMUNICATION_ERROR because the device is not responding and appears to be unavailable. Interestingly the channel “shelly:shellyplussmoke:SmokeName:device#heartBeat” is still be updated on all devices and one out of four devices stays online.
The Shelly Binding mentions that the device watchdog triggers for battery powered devices <sleepPeriod from device config> + 10min. Since devUpdatePeriod=86460 this would result in 87060 sec.
I did some research and found out that the updates are slightly off the expected 24 hour update period on three of four devices:
Value
Dev1
Dev2
Dev3
Dev3
Min
87721
83719
87533
87558
Avg
87752
83754
87560
87580
Max
87813
83779
87588
87605
Status
ERROR:COMM
ONLINE
ERROR:COMM
ERROR:COMM
Firmware upgrade from 1.2.2 to 1.3.4 did not solve the issue, the update rate kept the same. It seems to be a device dependant tolerance how often the updates are done.
Does anybody else experiences similar behaviour? Is the offset of 10 minute too less for the smoke devices and should be better set to +1 hour?
I have updated the shellies to version 1.4.4 because “Fix notifications to backend” was mentioned in the changelog. But unfortunately the behaviour is still the same. After a day the thing changes to offline because the shellies only sent their states about every 25 hours.
It is interesting that the device#heartBeat channel changes with each wakeup of the shelly while the sensors#lastUpdate channel keeps the same if the thing has changed to offline.
I thought I might have found a solution because I discovered that outbound websocket was not active on all Shellys. But unfortunately activating outbound websocket to ws://<openhabIP>:8080/shelly/wsevent on all devices and also using the latest firmware (1.4.4) did not solve the issue.
Is there really no one in this forum who can share their experience with the Shelly smoke detector and openHAB?
sorry i cannot help but i remember i had similar issues with my shelly smoke sensors. they where recognized by the binding but then it took up to 20 days until they went online. and always when i restarted openhab the game started from the beginning. i read that in this time (when not online) the binding will not be able to recieve a fire alarm so i decided to change the communication away from the binding to mqtt. since then it seems to work. still had no fire alarm but i receive every day a status update from each sensor and see the wlan strength and battery status.
Thanks a lot for your replies, I already thought about to use again MQTT since it ran quite stable. I expected it would be better to use the native binding because it also supports the Shelly Manager and also the BLU Devices.
As far as I can remember smoke alarms are not triggered any more if the thing is offline as you described (I will do some further tests). Just the heartbeat seems to be updated, anything else not. This would be an additional reason to use MQTT, at least in parallel.
I cannot reproduce the wait time (days) until the Shelly is displayed as online you had. If I enable the thing in openHAB, it immediately changes to “config pending”. If the the smoke detector wakes up or if I wake it up manually by its button it goes to “online” as expected.
Overall I think it would work, as it is also for my other battery powered Shellys, if the expected wake up period would be longer. I assume that the second controller that wakes up the smoke detector every day has no very accurate timing. If the devices have a large temporal variation this then would also explain why one device is staying online, others are not. I have created an issue on github. Probably the maintainer of the binding looks into it.
I think somewhere online is a modified script that pushed the bluetooth messages to MQTT, too.
As another option I’m using a dedicated wired ESP32 with openMQTT gateway to capture and decode the blu messages. It’s very cheap and very reliable - I get the shelly blu messages directly through MQTT.
My devices also stay on state “config pending”. Some change to online after 1 - 3 weeks but most of they time they are stuck in pending. With one or more manual button pushes they go online and stay online. So it’s definitely not an issue with the wakeup period, but rather how the binding initializes and discovers the device.
I’ve reported the issue over one and a half years ago but so far no change.
I think it’s also a conceptual flaw of the binding and there is no easy fix without openHAB core changes.
