Following my previous post about Shelly powered devices which stays awake unnecessarily for 1 minute I’ve got answer from Shelly’s CEO, that they know what causes such behavior, but it lays in the fact that the device waits for answer from MQTT then timeouts after a minute. And this is problem on my-end with my network.
I did several tests confirming that this is likely Shelly fw issue introduced in v1.10. Below I’m reposting my answer to Mr Dimitrov (on FB):
I’ve tested again several versions. Version v1.9.4 is the last where DW/DW2 goes deep sleep immediately after logging state change to MQTT. Starting with version 1.10, DW2 stays connected for 1 min after storing data to MQTT. Regardless QoS set.
It seems the same for HT devices, since recently a few of them which I upgraded to 1.10.x drained batteries in a 3 months (while with fw 1.7 they survived more than a year)
BTW It seems DWs and HTs don’t disconnect from MQTT properly. At least Mosquito server logs following entries:
Client shellydw2-xxxxxxxxx has exceeded timeout, disconnecting.
It’s valid for all firmwares I’ve tested (1.9.x, 1.10.x, 1.11.x). If it’s for saving a battery then OK. But seems unrelated to the issue I’m reporting since it appears also for v1.9 which behaves as expected
Not saying it cannot be on my end. But definitively it’s not network issue. Maybe there are differences in MQTT servers which respond differently (I’m using Mosquito 1.6.12)
Anyway, it’s pretty obvious that the behavior of Shelly battery powered devices has changed in fw v.1.10 potentially causing pretty big damage to batteries.
if you need more information which could help finding the issue, feel free to contact me.
BTW how can I tail the log shown in HA’s Mosquitto add-on GUI? Even after enabling debug for homeassistant.components.mqtt messages I can see in the GUI don’t appear in HA home-assistant.log.
Today I received a development version of DW2 firmware.
It fixes 1min stall of DW2 in awake mode. Also looks like errors reported by mqtt about improper disconnection are fixed too.
However, my testing DW2 still takes 9.3 sec to report sensor state to mqtt. Because they claim it should take about a secs (hey I know it’s hard to believe) and asked me to test it with some other AP than unifi I started to think how can I debug things prior to experimenting with other AP. Not much I can do in this area (nor have time/skill) but I ssh’ed onto my APs (Unifi APACLR), with idea of pinging DW2 from there. In theory, direct ping from AP should be most responsive comparing to other places in the network.
Unfortunately ping appear 9 secs after expected sensor state change.
Then I’ve checked logs of AP. It’s interesting. Logs confirms that time period between the first logged record (Sead AUTH) and disconnection (EVENT_STA_LEAVE) is about 2 secs (logs has 1 sec resolution). Question is what takes so long before? wake-up from deep sleep? Or maybe some handhaking with AP not logged in the log.
I passed the logs to them. Hope it will help them/us
it seems, with the most recent FW 1.11.4 RC3 Shelly finally improved connection time to WIFI.
Instead of initial 9 secs I’m measuring 4 secs (confirmed by APACLR logs).
Final version of the firmware should be released next week. But RC is available for everyone (see web GUI)
I assume the led is meant to expose device activity incl wifi one.
Cannot confirm “fully sleepness” as I have no visibility to what the device is doing internally.
But if I limit the test to monitoring its availability in network then yes. It’s not available outside observed time span.
BTW MQTT is updated with new state after ~3 secs (measured with stopwatch)
One more experiment. Instead of mqtt, I used DDD, toggling Shelly1 which controls ceiling lamp.
Below there is video showing reaction as well as log from AP.
Look at time period between auth and sta_leave. it’s withing 1 sec.
After that I did multiple tests with mqtt, and state change appears always after about 3 sec (measured from visuals either in MQTT explorer or HA Lovelace). Interesting what may be responsible for this.
Edit: I did tests of mqtt using mosquito_pub.exe command, and reaction is immediate. So for sure it’s not a problem with mqtt server.
Sun Sep 5 00:48:23 2021 daemon.info hostapd: ath0: STA e0:63:da:yy:yy:yy DRIVER: Sead AUTH addr=e8:db:84:xx:xx:xx status_code=0
Sun Sep 5 00:48:23 2021 user.info : wevent[1251]: wevent.ubnt_custom_event(): EVENT_STA_LEAVE ath0: e8:db:84:xx:xx:xx / 19
Sun Sep 5 00:48:23 2021 user.info : wevent[1251]: wevent.ubnt_custom_event(): EVENT_STA_JOIN ath0: e8:db:84:xx:xx:xx / 19
Sun Sep 5 00:48:23 2021 daemon.info hostapd: ath0: STA e8:db:84:xx:xx:xx IEEE 802.11: associated
Sun Sep 5 00:48:23 2021 kern.warn kernel: [2346825.444325] ieee80211_update_node_ecm_flags: node with aid 19 and mac e8:db:84:xx:xx:xx has been tagged [ fast-path ]
Sun Sep 5 00:48:23 2021 daemon.info hostapd: ath0: STA e8:db:84:xx:xx:xx WPA: pairwise key handshake completed (RSN)
Sun Sep 5 00:48:23 2021 user.info : wevent[1251]: wevent.ubnt_custom_event(): EVENT_STA_IP ath0: e8:db:84:xx:xx:xx / 192.168.0.68
Sun Sep 5 00:48:23 2021 user.info : stahtd[1252]: [STA-TRACKER].stahtd_dump_event(): {"event_type":"sta_leave","message_type":"STA_ASSOC_TRACKER","mac":"e8:db:84:xx:xx:xx","vap":"ath0","assoc_status":"0","event_id":"5"}
Sun Sep 5 00:48:33 2021 daemon.info hostapd: ath0: STA e8:db:84:xx:xx:xx RADIUS: starting accounting session A19CB4C9zzzzzzz
Sun Sep 5 00:48:33 2021 user.info : stahtd[1252]: [STA-TRACKER].stahtd_dump_event(): {"auth_ts":"2346825.469521","auth_delta":"0","event_type":"soft failure","message_type":"STA_ASSOC_TRACKER","mac":"e8:db:84:xx:xx:xx","wpa_auth_delta":"50000","vap":"ath0","assoc_status":"0","ip_assign_type":"roamed","dns_resp_seen":"yes","assoc_delta":"10000","event_id":"6"}
Today, Shelly released firmware v1.11.5 for battery operated devices.
I’m just trying it with DW1 and it seems they improved time to 2 up to 2.5 sec (measured time between sensor change and icon change on HA dashboard)
BTW I have some DW sensors for which I recorded more than 1300 state changes. And still reporting 100% of battery
BTW I have some DW sensors for which I recorded more than 1300 state changes. And still reporting 100% of battery
I don’t trust the battery level. Mine never goes down 90% and it seems to stay at 100% all the time. I had a few DW2 sensor batteries died with the battery indicated at 100% and the last battery change was less then a year. This time I have noted a date of when a fresh battery was replaced. This will tell me how long the battery last.
Don’t remember how DW batteries are reported but HT reports decreasing batteries. it might depend on battery type though(discharge curve).
The mentioned by me DW lasts about year so far. It’s also worth to note that battery age depends on features enabled in dw. I use main and tilt sensors only with mqtt (no cloud). Every other feature adds to battery drain. Especially those features measuring light. DW2 can measure temp too - I don’t use it since windows are exposed to more rapid/frequent temp changes thus more frequent reporting and more battery usage
Especially those features measuring light. DW2 can measure temp too
I didn’t know we can disable those features. I don’t use them, but I noticed readings from it. Will see to disable both. I only use the sensor for open/close and battery readings
those are reported always with other sensor changes. However might wake up device based on light intensity changes only - this feature might be disabled
I’m in the market for some door/window sensors and I’ve been scrolling through this thread.
What’s the consensus now, are the Shelly sensors any good, or should I go for Aqara or zooz sensors?
The Shellies seem to have gone from uther crap to quite good?
I don’t have a zigbee network at the moment, except Hue lights (those are Zigbee, right?).
I have lot of shellies and few zigbee Lidl sensors, as I expanded my rig with zigbee not long ago.
I have to admit, reporting of zigbee sensor state to HA is instant. If I start today, likely I would go for Zigbee Smartthings multipurpose sensor (as only one zigbee which reports tilt) instead of DW/DW2.
But today Shellies are very strong. Seems all firmware problems have been resolved. This device still needs about 2.5 secs to report data to HA. But for a lot of use-cases it might good enough. Battery should lasts really long. some of my devices reported 2000 state changes during a year, and still report 100% of battery
Note, DW2 features sensing of temperature, light intensity and vibrations (in addition to open/close and tilt). For sure those additional features shorten battery life. This is why I disabled them.
Big advantage of Shelly devices over any zigbee is built-in web GUI allowing to configure or debug device. For example if something doesn’t work, you can check it in the network, connect, open GUI, confirm it works without HA.
Battery should lasts really long. some of my devices reported 2000 state changes during a year, and still report 100% of battery
I am not sure if I will purchase Shelly Door V2 for additional add-on. Yes, it takes about 2 seconds to report the state change, but it is faster than the switchbot door sensor. I recently bought an Aqara door sensor for a different project and it instantly report of change state. Though it is zigbee network.
The battery status isn’t accurate for me. It never drops below 90%. Always at 100%. I had 2 of the sensors giving me false battery readings. The sensor no longer works, but the battery shows at 100%. Replaced the battery and all is fine again. I jotted down a date of when a fresh battery is replaced and it looks like the battery last 1 year and a few days before it goes completely dead.
