Sonoff ZBMINI switch toggles to previous state after being pressed on HA dashboard.
Sonoff ZBMINI switch toggles to previous state after bring pressed on HA dashboard.
e.g.
- Initial state of ZB Switch is ON.
- Switch OFF from Dashboard (actual switch turns OFF, ewelink app changed from ON to OFF).
- After about one second, turns ON on HA DASHBOARD, however actual switch is still OFF (ewelink app also still OFF) Outcome: Dashboard state out-of-sync with actual switch
The same but inverse applies if initial state if OFF. Disabled all automations to make sure nothing is messing up. When toggling the switch from ewelink app, the state is updated correctly in HA.
UPDATE:
The following three lines are logged when turning the switch ON.
[custom_components.sonoff.core.ewelink.local] <zbbridge_id> => Local4 | 192.168.1.10:8081 | {'switch': 'on', 'subDevId': '<zbswitch_id>'} <= {'sequence': '1698038403002', 'seq': 2, 'error': 400, 'encrypt': True}
[custom_components.sonoff.core.ewelink.cloud] <zbswitch_id> => Cloud4 | {'switch': 'on'} | 1698038403002
[custom_components.sonoff.core.ewelink.cloud] <zbswitch_id> => Cloud4 | 1698038403003
No extra lines are logged when the switch toggles back to OFF.
UPDATE 2:
After some debugging, I can confirm that XSwitch methods set_state, async_turn_on and async_turn_off are NOT being called in Step 3 above.
configuration.yaml:
# Loads default set of integrations. Do not remove.
default_config:
# Load frontend themes from the themes folder
frontend:
themes: !include_dir_merge_named themes
# Text to speech
tts:
- platform: google_translate
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
recorder:
db_url: mysql://hass-user:[email protected]:3306/hass-db?charset=utf8mb4
purge_keep_days: 365
sonoff:
username: !secret sonoff_user
password: !secret sonoff_cloud_password
force_update: [temperature, humidity, power]
scan_interval: '00:05:00' # (optional) default 5 minutes
sensors: [temperature, humidity, power]
mode: cloud
reload: always # update device list every time HA starts
http:
ssl_certificate: dehydrated/certs/XXXXXXXX.duckdns.org/fullchain.pem
ssl_key: dehydrated/certs/XXXXXXXX.duckdns.org/privkey.pem
DIAGNOSTICS:
{
"home_assistant": {
"installation_type": "Home Assistant Container",
"version": "2023.9.2",
"dev": false,
"hassio": false,
"virtualenv": false,
"python_version": "3.11.5",
"docker": true,
"arch": "x86_64",
"timezone": "Asia/Nicosia",
"os_name": "Linux",
"os_version": "6.2.0-33-generic",
"run_as_root": true
},
"custom_components": {
"hacs": {
"version": "1.32.1",
"requirements": [
"aiogithubapi>=22.10.1"
]
},
"sonoff": {
"version": "3.5.2",
"requirements": [
"pycryptodome>=3.6.6"
]
}
},
"integration_manifest": {
"domain": "sonoff",
"name": "Sonoff",
"config_flow": true,
"documentation": "https://github.com/AlexxIT/SonoffLAN",
"issue_tracker": "/api/sonoff/d328d459-5335-4bfa-bf84-9a3959fb1773",
"codeowners": [
"@AlexxIT"
],
"dependencies": [
"http",
"zeroconf"
],
"requirements": [
"pycryptodome>=3.6.6"
],
"version": "3.5.2",
"iot_class": "local_push",
"is_built_in": false
},
"data": {
"version": "2ad1cd7",
"cloud_auth": true,
"config": {
"username": "***",
"password": "***",
"force_update": [
"temperature",
"humidity",
"power"
],
"scan_interval": "00:05:00",
"mode": "cloud",
"reload": "always"
},
"options": {
"mode": "auto",
"debug": true
},
"errors": [],
"device": {
"uiid": 1156,
"params": {
"bindInfos": "***",
"subDevId": "1e96fafeff8d79e01156",
"parentid": "10017ae72c",
"switch": "off"
},
"model": "ZCL_HA_DEVICEID_ON_OFF_LIGHT",
"online": true,
"local": null,
"localtype": null,
"host": null,
"deviceid": "a480066637"
}
}
}
Looks like cloud not response with new device state. Can't do anything about it
Looks like cloud not response with new device state. Can't do anything about it
So does the code revert the switch back to previous state if there is no response? Can you point me to the part of the code where it does this? Thanks.
Not a code. It's a Hass mechanics. You should get response from device with new state to know if command executed OK
I had the same problem. I was able to fix It locally by adding the following line in the ewelink/init.py:class XRegistry:async def send method, under the 'elif can_cloud:' condition: self.dispatcher_send(device["deviceid"], params) I'm note sure if this is a proper fix or something else is breaking. Hint was given by the TODO: keyword right below.
I had the same problem. I was able to fix It locally by adding the following line in the ewelink/init.py:class XRegistry:async def send method, under the 'elif can_cloud:' condition: self.dispatcher_send(device["deviceid"], params) I'm note sure if this is a proper fix or something else is breaking. Hint was given by the TODO: keyword right below.
Thanks @alfon-fito, I confirm that adding that line of code to the send() method resolves the issue i.e. switch does not toggle back to previous state.
@AlexxIT does this info help?
This is not a fix. You are changing device state manually. You believe that device executed the command. But device may not receive this command. Or even be offline.
This is not a fix. You are changing device state manually. You believe that device executed the command. But device may not receive this command. Or even be offline.
Thanks for clarifying.
I've added the following lines at the end of the send() method right after the IF ... ELIF... ELSE statement.
# ZBMINI - Toggle workaround
my_zbminis = ['a480066c1a', 'a480066917', 'a480068715', 'a480069112']
if device["deviceid"] in my_zbminis:
self.dispatcher_send(device["deviceid"], params)
Using this workaround, the zbminis do not toggle back, and unless they are offline when switching they usually end up being in the right state. Without this workaround they are usually in the wrong state.
I think it's better to use normal local Zigbee integration with this switch.
Not a code. It's a Hass mechanics. You should get response from device with new state to know if command executed OK
Another question: Is SonoffLAN not able to poll the cloud for the state of the zigbee devices if no response is received?
How logs looks like? I saw two lines of logs in first message. Is there nothing else?
You can manually pull device state. Check docs. Try it out works for this device
How can you pull device's state? That was my first option, but didn't find how to do it. A link to the documentation would also help.
Link to docs https://github.com/AlexxIT/SonoffLAN
How logs looks like? I saw two lines of logs in first message. Is there nothing else?
From the switch only those two lines. There is also one line from the bridge to local (added to original message) which has a 400 error. But bridge doesn't have a LAN mode so I guess that's why?
Bridge doesn't support LAN mode. But anyway it should return new device state.
You can manually pull device state. Check docs. Try it out works for this device
Do you mean with homeassistant.update_entity service in HA Developer Tools?
Yes
@AlexxIT
I get this error:
2023-10-23 15:24:02.805 ERROR (MainThread) [homeassistant.helpers.entity] Update for light.sonoff_<zbdevice_id> fails
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 732, in async_update_ha_state
await self.async_device_update()
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 991, in async_device_update
await self.async_update()
File "/config/custom_components/sonoff/core/entity.py", line 131, in async_update
await self.ewelink.send(self.device)
File "/config/custom_components/sonoff/core/ewelink/__init__.py", line 106, in send
params_lan = params.copy()
^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'copy'
Input:
service: homeassistant.update_entity
data: {}
target:
entity_id: light.sonoff_<zbdevice_id>
Hi Javot, I'm having the same issue as you. I would like to know if you were able to resolve it and if so, how did you do it? I can't find the file mentioned in the comments to edit it. Could you help me?
This is not a fix. You are changing device state manually. You believe that device executed the command. But device may not receive this command. Or even be offline.
hi alexxit,
I'm having the same problem as Javot, the exact same thing is happening to me, is there any solution? What do you recommend . Thanks!
Hi Javot, I'm having the same issue as you. I would like to know if you were able to resolve it and if so, how did you do it? I can't find the file mentioned in the comments to edit it. Could you help me?
Hi, The workaround I use is not a fix but the end-result is much better than the default.
File is in:
home-assistant/custom_components/sonoff/core/ewelink
Hi, I found exactly the same bug behaviour for another Sonoff zigbee switch SNZB01. It's really annoying because it prevents to create any kind of automation because the switch state is not correctly updated in the developer-> state tab.
Let me know if you need also other details for this device to help solve the issue
@AlexxIT If you don't own any sonoff zigbee device/switch I can help you with testing new code.
This is wrong code. I won't add it as is. Maybe it should be some option for unhappy owners of Sonoff Zigbee bridge.
This is wrong code. I won't add it as is. Maybe it should be some option for unhappy owners of Sonoff Zigbee bridge.
@AlexxIT I don't mean the code above. I'm saying if you want to try out some new code and you don't have the zigbee devices to test I can do it for you OR if you want me to output parameters to understand how the bridge is working with specific zb devices
I have a lot of Zigbee devices. I just don't have a lot of time to experiments.
I have a lot of Zigbee devices. I just don't have a lot of time to experiments.
Same applies to me. I'm a Java developer so I will understand the code if I spend some time going through the source files but I just don't have the time at the moment.
Hi, I found exactly the same bug behaviour for another Sonoff zigbee switch SNZB01. It's really annoying because it prevents to create any kind of automation because the switch state is not correctly updated in the developer-> state tab.
Let me know if you need also other details for this device to help solve the issue
Sorry for the confusion. The problem I found again was on the ZBMINI (which is a SONOFF Zigbee wireless switch) too instead of the SNZB01 (which is a Zigbee wireless button)
@alfon-fito @Joacostepa @makksi are you using the sonoff zigbee bridge pro coordinator with your zbminis?