Actually it would be worth to find the root-cause of such long time needed to update state in MQTT.
Currently I don’t know if most time is spent on wifi connection or sending data to mqtt plays the role.
Still various users reports time between 2 and 8 secs, but without info about where DW reports its state to (mqtt, integration, shelly cloud etc).
I try to check it without mqtt. But I would be surprised if it is HA/mqtt connection which takes most.
BTW I bought door sensors sold by Lidl which are very cheap zigbee ones. They report its state instantly: way under half a sec (z2m, Conbee2). Unfortunately those, as most of zigbee sensors, have no tilt sensing which is useful for tilted windows.
I assume that so.
But then, why it takes me 8 secs to connect? Even when sensor is located 50cm from AP? Fixed IP obviously etc.
There is no answer why it varies between 2 and 8 secs from user to user.
I suspect those 2 sec responses were when the device had not gone to sleep / dropped the connection.
This is because when plugged in it does not go to sleep and drop the connection.
When on battery it has to go to sleep or the battery would only last a day. Wifi is power hungry.
Distance / signal strength isn’t going to have any effect until you are well past -70dBm, and that is only going to make it slower than the fastest it can connect from sleep (8 sec) due to errors and required retransmissions.
8 sec is how long it takes to negotiate for a connection and prove authentication with the access point. You can’t make it any faster. Maybe slightly dependable on the quality of the AP and firmware optimisation of the TCP/IP stack and wake routines in the wireless device. But not 6 seconds worth.
I know all of this.
But it’s stange that people claim to get event notifications in 2-3 sec and I can’t get better than 8sec when the device is in sleep mode, or sometimes up to 15 seconds with the Shelly button.
I have a decent wifi network, 3 Unifi AP, correctly configured, different non overlapping channels and so on, no interference on the 2.4Ghz band, …
Last thing I will try is with the native Shelly integration instead of MQTT. That would not make any logic if I get better results but…
I have very good coverage using Unifi APs and can’t get better than 10 seconds on my Shelly window sensors.
It’s simple. Their device is not asleep when they see this reaction time. When it is asleep it takes much longer but they don’t report this as they like to brag, or simply don’t notice.
Device is going asleep immediately after sending data. IMO it would be very hard to trigger new event exactly after communicating most recent event and before going asleep again. I can imagine weaving a window continuously, but then how to correlate particular reed-switch changes to HA entity changes
It could be true in “laboratory env” being promoted by Shelly staff only. But too many users report that.
Not saying you are not right about this 8secs. But why people report 2-3 is still not clear to me.
Regardless that, I’m happy that my H&T sensors still report 100% of battery after 10monts of operation (still measuring temp and hum )
I did it quite often when I was testing after initial installation. It took a few seconds to go to sleep. Mind you I have not updated my firmware for over a year so it is an old version.
I took some WeMos D1 minis (esp8266) using the ESPNOW protocol, I made some door/window sensors using normally open reed switches, that way the D1 is only switched on when the door is open. The wake up time to communicate to my Pi webserver/HA is about 500ms. If the door stays open for a while, the D1 goes into deep sleep until it is powered off by door closure. So you have a fast response and low battery usage. I did this because Wyze sensors are pieces of shyte. I thought I’d try shelly, but I like the idea of the battery being off 99.9% of the time. Here is picture of the D1, the button is the same as a NO reed switch. The resistor is used to report the battery voltage every time a door is opened, so you can alert on when it is time to recharge these small lipos I used. REEDBUTTON|598x461
On the D&W2s i recently purchased, i had the same issues with reporting times being around 8-10 seconds. What lowered the reporting times to 2 seconds consistently was using the feature “Reconnect to the Strongest AP” which basically tells the device to reconnect to the closest AP instead of the one where it was initially set up. Always verify that the device is indeed connected to the closest AP, as on a couple of them i had to retry the operation once or twice. I have all 6 D&W2 on the latest firmware and using static IPs.
Reporting times or connecting times. Those are two different things. Someone correctly pointed to the fact that it’s impossible to connect wifi in 2 secs.
I’ve tested DW and HT shelly sensors and it takes about 7-8 secs everytime even when connecting to 1 meter away AP.
By reporting time i meant the time it took from the moment the door was opened to the moment Home Assistant registered a status update (Door/Window open/closed). The sensors are in deep sleep and have static IPs. These readings are from sensors installed on doors and windows that haven’t been open since a few hours.
I’m only sharing my findings with the community. If you don’t believe me, then try it yourself.
Here’s the link to the article: How to improve work of battery operated Shelly devices - Official Shelly Support Forum (shelly-support.eu)
Shelly just released (yep on Sunday) FW1.11.1 for battery powered devices which should shorten WIFI negotiation time.
Reaction time is improved significantly. After first power on device will store AP BSSID and credentials and next time will connect for less than 1 second. Static IP address is mandatory to achieve these results. If you move the devices far away from stored AP, first wake-up can take 4-5 seconds to store new AP data.
Door Window 1/2 - fake vibration alarms are fixed
Battery time is increased at least 30%.
I’ve updated one spare DW2 sensor and unfortunately found as follows.
The device stays connected (is responding to pings) for a minute after woken up. Unaware of that person might think that subsequent state changes indeed take a second.
Unfortunately it’s the result of fact that device remains online.
After getting asleep, device still needs about 8 secs to report.
To be sure, I’ve checked another device, this time DW1 with FW1.9.0 and it gets asleep about 3 secs after waking up (3 pings get reposponse).
Note it seems that not all users are affected by such behavior. I have been ensured by CEO that they contact me next week in order to find the root-cause and fix the issue. I believe they do 100% to resolve that.
I will inform you about results.
I decided to share this information to help you in case you end up with the same situation which may result in very short battery life.
I’m not really getting anywhere here and I’m about to throw this thing out the window.
I own a DW2 - tested with current firmware V10.2 and V11.1.
Enabled is MQTT on a home assistant MQTT Addon so I can operate it nicely with Home Assistant.
The status, whether it is open / closed is not written back via MQTT at all or only very rarely (see screenshots).
The web interface tells me - CLOSED also ip/status tells me Closed.
MQTT tells me via MQTT Explorer OPEN.
The Home Assistant integration have the same issue that i did not get the right status back.
My other Shelly 1 and 2.5 did not have this problem they are working fine.
How can this be ?
Has anyone had this before ?
A factory reset did not help
My MQTT Configuration in the addon:
logins: []
customize:
active: false
folder: mosquitto
certfile: fullchain.pem
keyfile: privkey.pem
require_certificate: false
anonymous: false
From what you are saying, it seems like communication issue between DW and mqtt. Likely WiFi related.
Difference between Shelly 1/2.5 and DW2 could be manifesting due of wifi coverage and the fact that DW supposingly have weaker antennas.
Anyway, at first I would confirm that mentioned web GUI reacts properly on DW2 state changes. Meaning it always shows correct state. Especially after wakeup.
Then there is a question of QOS. I would set it at least to 1. 0 means that a device sends notification but never waits for confirmation from mqtt. It might cause information loss.
Saying that I have no problems with mqtt +shelly (and never had). If wifi coverage is satisfying, if device works (in case od DWs positioning of magnet is crucial), mqtt always reflect state of device.
act reason says that the last stored change in mqtt has been triggered by power_on (wake up forced by pressing reset switch)
So other values haven’t been stored as a result of open/close sensor change.
are those values in mqtt ever change, ie if you enable dw with reset switch?
It would be strange that it can report all other sensor changes but open/close. never heard about such case
yes, for me its also totaly weird and i can not understand it.
All values are change in mqtt except of state.
Sometimes when i do it often then also the change in mqtt change but only by open/close DW2 5-10 Times. There is no logic behind, like “random”.
All other values are totally fine.
The JSON is also totally fine.
If i use mqtt or the Home Assistant Integration its every time the problem the “state”.
The magnetic reed switch could be broken. They do break. To test this remove the battery and check the continuity of the reed switch with the magnet in place and away from the DW.
I am getting same weird issue as @ unglazedswansea
I noticed one of my door sensors stopped working. The battery seems to died 2 days ago. Changed it, and while viewing the sensor via my local ip address, the state changes, but MQTT remains unchange for the state.
I was on v10.2 prior to changing the battery. After I replaced the battery, I updated to v11.1. I am trying to go back to v10.2 to via OTA, but when I issue this url to my broswer, it does nothing.
Update:
I said above that trying to OTA back to v10.2 failed. It didn’t failed. I can see from mqtt explorer that I am back on v10.2, but the issue still remains.
Update, Update:
Here is a little more update. Since reverting back to v10.2, initially the states still would not change. After messing around with settings and closing and opening the door several times, it started to work as it should. I really don’t know what I did and why 11.1 behaved differently. I am staying at 10.2 for the time being.
