Sonoff Sensors do not update in home asisitant. #1509
Comments
|
Yes, it’s the same here. When I restart the integration, it starts working again but stops after a while. |
|
By the way, I have switched to the eWeLink (Original) Add-on instead of Sonoff for now, but I prefer to use the Sonoff integration. I will be following this issue up and switching back to Sonoff when the problem is solved. |
şu an çalışıyor mu sizin ki |
TR: Dediğim gibi, Sonoff yerine eWeLink Add-on kurarak çalıştırdım ama her restartta tüm sensörlerin state'leri değişiyor, eğer otomasyon kurduysanız hepsi tetikleniyor. Şimdilik işimi görüyor ama Sonoff kullanmayı tercih ederim. EN: As I said, I started using the eWeLink Add-on, and it works, but not well. All the sensors’ states are triggered after each restart, and the automations are run. I prefer to use the Sonoff integration. |
|
Now I changed the configuration to cloud. (It was at AUTO). Now everything is working |
I have the same issue. Setting it cloud didn't help.. reverts to stagnant state after sometime |
could you please tell us what to do? |
|
I've been experiencing the same issue for the past two days. Despite trying several solutions, including completely removing and reinstalling the integration, the problem persists. I even attempted the following YAML automation to force an update of the values, but without success. Here is my diagnostics: |
|
Same issue, haven't been able to figure out anything specific from the logs. Even with debugging mode. Also switching cloud/local only doesn't help! |
|
Same scenario. Cloud mode only fixes it for a short while. |
|
@basakmurat2005 @iridyum I don't see anything important in your info. You need to turn on the debug logs and examine them. |
|
@AlexxIT After disabling and re-enabling the integration, all sensors are updated. However, no further updates occur until the integration is restarted again. The eWeLink app itself works without any issues. The motion sensor functions for 2-3 minutes after each restart. I have enabled debugging, and here are the log entries containing the "sonoff" keyword: One thing I’ve noticed is that many people experiencing this particular issue are from Turkey, myself included. It might be related to eWeLink’s regional settings or server configurations. |
|
Let's collect the model identifiers that works and that don't works.
What about if you downgrade to v3.8.0? |
AlexxIT
added
bug
|
|
It's important to get feedback (about v3.8.0) from other users as well. Unfortunately, I only use simple WiFi relays from Sonoff. Can't test the problem myself. |
|
v3.8.0
Unfortunately, downgrading to v3.8.0 doesn't make any difference for me either. |
|
Looks like something has been changed in the cloud. |
|
I have some sonoff devices and they are not updating on HA. I'm restarting ever hour the sonoff integration to resolve this problem temporary |
Not true. From Singapore. Oh BTW, I am on v3.4.0 and it is the same so I think v3.8.0 will not work either. |
|
Here are sonoff debug logs for my devices. Seems like cloud is returning "None" state after some time. Do note that I even reloaded the add-on several times, which fixes the issue for a brief period. |
|
|
I am having the same problem with my sensors, especially with sonoff r5 scene controller. Although this is a workaround, I am sharing my configurations: Below is to reload the entity, put this in your The Below is my another automation to trigger the lights with sonoff r5 scene controller: |
|
I guess it's a problem on Sonoff's side, because I have the same issue with the official eWeLink add-on. |
|
Sorry for messing up with my messages here, @EboBH83 are you having problems particularly with the sonoff r5 scene controllers (I know that other sensors also problematic)? AFAIK, the scene r5 controller is not supported with the official eWeLink add-on. |
|
This is my code to temporary "reload" the devices. Easier this way because every entity will take too much to write out. And it is not just the temperature. It is the button state, the humidity, etc. This is working for me as a workaround. |
Oh, hey. I don't have the R5, sorry. |
I'm noticing that too, but I'll have to give it some time to be sure. |
|
Mine (dw2 wifi door sensor) started working properly again, too. |
|
I reached out to ewelink support this morning. It may be related. |
|
I also contacted ewelink support, in my case the status of the devices is having problems even in the app. If they provide me with any relevant answer I will share it. |
|
Hi friends, i am the one who opens this issue. Mine is working now too. I thank you all for the coopeartion. |
|
Mine is resolved automagically as well. Sonoff seems to have resolved the server issue, but I'm still approaching it cautiously and keeping an eye on things. |
|
Thanks AlexxIT and others for contacting ewelink. Looks like that did it. Working again in Australia. As I had a USB/TTL board on hand, finally bit the bullet to tasmotized my bridges (1 zbbridge 1 zbrouter) to localise the zigbee sensors. A bit of work, couple of small gotchas along the way but the ZHA integration is working well and should reduce downtime. |
Just the same, this problem pushed me to do it finally and tasmotized the zbbridge :D |
Yep, that Sonoff service was the weakest part in the whole HA setup for my install. I'm going to retire the couple of DW2s in the system and from then on it'll finally be all local with SonoffLAN and ZHA. |
|
Motion sensor has stopped functioning again. SNZB-02D temperature - humidity sensor looks OK for now. |
|
Temperature sensors stopped updateing in HA for me as well couple of days ago. I am in Europe, in Estonia. Ewelink app is working correctly, data is updating there. |
|
I think problem solved. Probably EU issues related to internet problems. |
|
I am also having issues with temperature sensors ceasing to update in HA, it seemed to magically start working again yesterday, but this morning it stuck again...furthermore the workaround I set up (basically forcing a restart to the service every 3 minutes) stopped working as well. I'm in the US. It may have been coincidental, but I did update the bridge FW and it hasn't been working reliably since. Did any of the rest of you with issues using a bridge update to 2.1.0? |
|
Everything is fine here since yesterday. Thank you guys! |
|
It's only updated for me if I have the ewelink app open on my phone. I'm in the U.S. |
Im in EU and this happens to me exactly. |
|
It's happening again to me. Fresh HA install, stopped working after a couple hours |
|
It's been fixed here for a while, and now there seems to be a delay in some updates. This is bad. It seems like there is a way to do this on the local network without relying on the cloud. I'll learn more about this. Thanks. |
|
Hi everyone, I'm following this thread with interest as I have similar problems. Introduction: After stabilizing my Zigbee network (far from Wifi frequencies), I'll tell you what happens to me. At 23.44.12 yesterday evening, one of the Motion Sensors (SNZB-03) correctly detected the movement but when I left the room the sensor remained in the "Detected" state all night. This apparently seems to be a problem with the SonoffLan/Home Assistant integration, but the same issue is reported in eWeLink app logs (and I'm sure that there was no one in the room as it was late at night). Then this morning, at 06:24:20, when I returned to the room, the motion sensor did not turn on the light via automation and this was because it was still in the "Detected" state. After 1 minute, however (with the room empty) it correctly returned to the "Not Detected" state. (because this morning the new Request made via API in the Cloud was successful) In the Home Assistant logs, by chance, I find some "Cloud Errors" at 23.40.09 (just before the sensor failed to update).
My opinion is that these sensors communicate their state to the Cloud but obviously not continuously but only when there is a change between "Detected"/"Not Detected" state and viceversa. The Sonoff SNZB-03 in particular, cannot change state before 60 seconds. So what happens if a sensor, when changing state, receives an error during the call to the Cloud? Simply the Cloud does not "accept" this change of state and the sensor remains in the same previous state until someone moves again in the room, forcing the sensor to change state and therefore communicate its new state to the Cloud. This is obviously a problem because for a timeout call or Apparently even the Zigbee Bridge that acts as an intermediary, in case of an error in the Cloud call, does not retry the call and therefore leaves the sensor permanently in that state. The problem here is architectural and that is to maintain the state only on a Cloud that is not 100% available. I hope I have given a contribution to this Thread; I also attach the various original logs to help with debugging. |
|
Sonoff api missing state changes can be expected to happen on occasion given the complexity of the arrangement. Best case: sensor -> zigbee -> wifi -> router -> internet -> sonoff server -> internet -> router -> home assistant. Sensors require real time signalling which reduces the likelihood of buffering/retries being implemented. What's observed can sometimes be expected in a best efforts system. Increasing local signalling integrity and capacity can improve performance but there are still all those parts that cannot be controlled. The recent problem was a bit different in that all sonoff wifi and zigbee sensors stopped updating, symptomatic of an api issue or change at sonoff. The 60 sec delayed state change is by design to reduce battery use. Missed signalling is just lost. Unfortunately, it is what it is. Localizing the sensors eliminates the uncontrollable elements in the chain. If you have sonoff gear then the only way ATM to do that is with Tasmota. After a week or so, my experience is one of improved zigbee networking with reliable and faster sensor updates. |
|
Thank You |
|
Also seeing this, device power stats don't update and remain on the previous value and break all automations. My decision to flash as many smart devices as possible with ESPHome has been vindicated. |
|
Did the same. (ESPHome) |
|
Hi All! I was experience this issue as well but in my case with the DUAL R3 power metering values that stopped reporting. But I think I found the issue. My setup for context: iHost from Sonoff running Hass docker install
Note: this build don't have the Supervisor menu available therefore I'm not using the "official" Sonoff integration. From my understanding this happens every time a new device is added to eWeLink account. After adding to eWeLink account, it is necessary to restart the eWeLink Smart Home service in iHost in order to be added/displayed in iHost. For some reason, and at the moment of this writing, this action makes that all devices stop reporting/update state as supposed. What I found is that the HAss needs to be completely restarted. Only reloading the integration does not help. After restarting HAss, all DUAL R3 started to report correctly. This routine got my stuff working again. |
|
Maybe every time a new unknown device appears in the account - there is some bug. |
|
Running this restart rotine is not an issue for me. |
|
I try to make the simplest solutions possible. What can be simpler than entering login/password in WebUI. |
|
AlexxIT, For me it is super simple! Couldn't be easier! |
|
Thank you @Stroumb, a restart of Home Assistant seems to have fixed the issue with stats not reporting. |
and others
Hello, for the last two days my SONOFF sensors have been staying in their last state after starting homeassistance. If they sensed something, it seemed like they continued to sense it. This situation improves after starting homeassistance, but it remains the same afterwards. But in the logbook it works great. but the automations are not working.
Log.pdf
The text was updated successfully, but these errors were encountered: