I’m actually experiencing a strange variation of this issue.
After a fresh restart of Hassio everything will work fine, then usually after around 24 hours or so all communications with the Hub will stop and I will get the {“error”:“Invalid key”} issue… This is then resolved
again by restarting Hassio.
Has anyone experienced this, or offer any insights?
I’m experiencing a strange variation of this issue too.
I just made a new installation of HomeAssistant on my retired RedMi 3S smartphone (with Linux Deploy) and configured to access XiaoMi devices, all are with the latest versions.
I have single XiaomMi gateway.
On the Web GUI of HomeAssistant, I can turn on/off the wall_switch (ZigBee) successfully, but failed for gateway_light — received “Invalid key” in the Log when doing it.
INFO:homeassistant.core:Bus:Handling <Event call_service[L]: domain=homeassistant, service=turn_on, service_call_id=4127306160-28, service_data=entity_id=light.gateway_light_7811dcb1f997>
INFO:homeassistant.core:Bus:Handling <Event call_service[L]: domain=light, service=turn_on, service_call_id=4127306160-29, service_data=entity_id=['light.gateway_light_7811dcb1f997']>
ERROR:xiaomi_gateway:Got error element in data {"error":"Invalid key"}
INFO:homeassistant.core:Bus:Handling <Event system_log_event[L]: message=Got error element in data {"error":"Invalid key"}, source=components/light/xiaomi_aqara.py, timestamp=1519585983.445348, level=ERROR, exception=>
ERROR:xiaomi_gateway:Got error element in data {"error":"Invalid key"}
INFO:homeassistant.core:Bus:Handling <Event system_log_event[L]: message=Got error element in data {"error":"Invalid key"}, source=components/light/xiaomi_aqara.py, timestamp=1519585983.4641218, level=ERROR, exception=>
INFO:homeassistant.core:Bus:Handling <Event service_executed[L]: service_call_id=4127306160-29>
INFO:homeassistant.core:Bus:Handling <Event service_executed[L]: service_call_id=4127306160-28>
INFO:homeassistant.core:Bus:Handling <Event call_service[L]: domain=homeassistant, service=turn_off, service_call_id=4127306160-30, service_data=entity_id=switch.wall_switch_158d00016c5e82>
INFO:homeassistant.core:Bus:Handling <Event call_service[L]: domain=switch, service=turn_off, service_call_id=4127306160-31, service_data=entity_id=['switch.wall_switch_158d00016c5e82']>
INFO:homeassistant.core:Bus:Handling <Event state_changed[L]: new_state=<state switch.wall_switch_158d00016c5e82=off; icon=mdi:power-socket, battery_level=100.0, friendly_name=Wall Switch_158d00016c5e82 @ 2018-02-26T03:13:13.252149+08:00>, old_state=<state switch.wall_switch_158d00016c5e82=on; icon=mdi:power-socket, battery_level=100.0, friendly_name=Wall Switch_158d00016c5e82 @ 2018-02-26T03:06:41.163205+08:00>, entity_id=switch.wall_switch_158d00016c5e82>
INFO:homeassistant.core:Bus:Handling <Event service_executed[L]: service_call_id=4127306160-31>
INFO:homeassistant.core:Bus:Handling <Event service_executed[L]: service_call_id=4127306160-30>Here is the packet dump.
You can see the key value was not changed even got the new token via get_id_list.
mapgps@localhost:~$ sudo ngrep -d wlan0 port 9898
interface: wlan0 (192.168.31.0/255.255.255.0)
filter: (ip or ip6) and ( port 9898 )
#
U 192.168.31.163:46402 -> 192.168.31.90:9898
{"data": {"rgb": 3036676095, "key": "2773a459cc26b9d514864c1f821949b7"}, "sid": "7811dcb1f997", "cmd": "write"}
#
U 192.168.31.90:9898 -> 192.168.31.163:46402
{"cmd":"write_ack","sid":"7811dcb1f997","data":"{\"error\":\"Invalid key\"}"}
#
U 192.168.31.163:46402 -> 192.168.31.90:9898
{"cmd" : "get_id_list"}
#
U 192.168.31.90:9898 -> 192.168.31.163:46402
{"cmd":"get_id_list_ack","sid":"7811dcb1f997","token":"F0QCDuCX6Sq5pxWj","data":"[\"158d00015f3351\",\"158d0002284991\",\"158d00016c5e82\"]"}
#
U 192.168.31.163:46402 -> 192.168.31.90:9898
{"data": {"rgb": 3036676095, "key": "2773a459cc26b9d514864c1f821949b7"}, "sid": "7811dcb1f997", "cmd": "write"}
#
U 192.168.31.90:9898 -> 192.168.31.163:46402
{"cmd":"write_ack","sid":"7811dcb1f997","data":"{\"error\":\"Invalid key\"}"}Hello!
any update on this topic? I have the same issue with invalid key when turning on the gw light. In homeassistant web page they say the same as on this thread but nothing works for me. My router supports multicast (ZTE F680), and I’m using Android device and official xiaomi mihome app to generate the key, but still the same. Using last homeassistant version and xiaomi gw v2. My packet dump (ngrep) also shows key changing from time to time.
I don’t know how to continue troubleshooting this, could you give me some light? Has anybody with same problem solved it?
Thanks in advance!
Regards.
I have 3 gateways, and they seem to work correctly. But I’m seeing the invalid key error in the log. How can I know which gateway is causing this message? It was working correctly for several months, I don’t know the these error messages started appearing…
Thank you, I didn’t know this issue. So, it’s due to packet loss, but there will be a workaround to avoid it, right?
There is a small workaround which tries to retry a failed command. Your task is to avoid packet loss as much as you can. If your network is lossy you will miss state changes (f.e. of the motion sensor which is published just once).
My network should not lose packets, I’m using Ubiquiti UniFi access points which are very reliable. But I’ll test it.
Also, do you know how can I know which is the gateway that is failing? The log entry does not specify it.
Please enable the debug output of the component & underlying library by:
# configuration.yaml
logger:
default: warn
logs:
xiaomi_gateway: debug
homeassistant.components.xiaomi_aqara: debug
The home-assistant.log will contain all communication now including the “sid” (MAC address) of the gateway.
Thank you. I enabled debug, but I haven’t received the error again yet.
Let me paste my debug:
root@raspberrypi:~# tail -28 /home/homeassistant/.homeassistant/home-assistant.log | grep xiaomi_gateway
2019-01-09 22:47:21 DEBUG (Thread-6) [xiaomi_gateway] _send_cmd >> b’{“sid”: “7811dcf9aab4”, “data”: {“rgb”: 1694498815, “key”: “a1ad44a401b80633340da4e57528335e”}, “cmd”: “write”}’
2019-01-09 22:47:21 DEBUG (Thread-6) [xiaomi_gateway] _send_cmd resp << {‘sid’: ‘7811dcf9aab4’, ‘data’: ‘{“error”:“Invalid key”}’, ‘cmd’: ‘write_ack’}
2019-01-09 22:47:21 DEBUG (Thread-6) [xiaomi_gateway] write_ack << {‘sid’: ‘7811dcf9aab4’, ‘data’: ‘{“error”:“Invalid key”}’, ‘cmd’: ‘write_ack’}
2019-01-09 22:47:21 ERROR (Thread-6) [xiaomi_gateway] Got error element in data {“error”:“Invalid key”}
2019-01-09 22:47:21 DEBUG (Thread-6) [xiaomi_gateway] _send_cmd >> b’{“cmd” : “get_id_list”}’
2019-01-09 22:47:21 DEBUG (Thread-6) [xiaomi_gateway] _send_cmd resp << {‘sid’: ‘7811dcf9aab4’, ‘token’: ‘kckhdefSraHCZTwE’, ‘data’: ‘[“158d0002494a60”,“158d00024c2600”,“158d000204c017”,“158d00023d0ab5”,“158d00024da145”,“158d00020f84bf”]’, ‘cmd’: ‘get_id_list_ack’}
2019-01-09 22:47:21 DEBUG (Thread-6) [xiaomi_gateway] get_id_list << {‘sid’: ‘7811dcf9aab4’, ‘token’: ‘kckhdefSraHCZTwE’, ‘data’: ‘[“158d0002494a60”,“158d00024c2600”,“158d000204c017”,“158d00023d0ab5”,“158d00024da145”,“158d00020f84bf”]’, ‘cmd’: ‘get_id_list_ack’}
2019-01-09 22:47:21 DEBUG (Thread-6) [xiaomi_gateway] _send_cmd >> b’{“sid”: “7811dcf9aab4”, “data”: {“rgb”: 1694498815, “key”: “6632cd859373b905c89c9b285c3018db”}, “cmd”: “write”}’
2019-01-09 22:47:21 DEBUG (Thread-6) [xiaomi_gateway] _send_cmd resp << {‘short_id’: 0, ‘sid’: ‘7811dcf9aab4’, ‘data’: ‘{“rgb”:1694498815,“illumination”:452,“proto_version”:“1.1.2”}’, ‘model’: ‘gateway’, ‘cmd’: ‘write_ack’}
2019-01-09 22:47:21 DEBUG (Thread-6) [xiaomi_gateway] write_ack << {‘short_id’: 0, ‘sid’: ‘7811dcf9aab4’, ‘data’: ‘{“rgb”:1694498815,“illumination”:452,“proto_version”:“1.1.2”}’, ‘model’: ‘gateway’, ‘cmd’: ‘write_ack’}
2019-01-09 22:49:30 DEBUG (Thread-20) [xiaomi_gateway] _send_cmd >> b’{“sid”: “7811dcf9aab4”, “data”: {“rgb”: 1694498815, “key”: “6632cd859373b905c89c9b285c3018db”}, “cmd”: “write”}’
As I understand from the log, key is changing continously, but look at the first two lines, at the command response I get the first invalid key (that’s when I switch off the light through HA webpage).
Any idea of how to troubleshoot deeper?
Thanks in advance.
You can see the recovery mechanism here:
-> write rgb # turn on the light (the value of the "key" parameter is encrypted with an old or invalid token used)
<- error: "Invalid key" # Indiciates the "token" is outdated
-> get_id_list # Retrieves a device list. Will include a new and valid token
<- get_id_list_ack # Acknowledge device ("kckhdefSraHCZTwE" is a the new and valid token)
<- write rgb # Turn on the light again with key=6632cd859373b905c89c9b285c3018db. This value is encrypted by the new and valid token now.
-> write_ack # Positive response
You could try to capture some network traffic now. It looks like you are missing some heartbeat multicast messages which replaces an outdated token with a new and valid one.
Thanks syssi. Yes, it could be related with multicast. I’ve ordered a new router (Xiaomi 3G) to have together with my current one (ZTE F680). It seems that ZTE is able to handle multicast traffic as it has three options for that (disabled / snooping / proxy). I’ve tried snooping and proxy but same behavior on both (with latest firmware from my telco company), so the idea is to use the Xiaomi one only for this to try to avoid the ZTE. If that works, it would be a problem on the ZTE handling multicast traffic. The thing here is that other people with the same router don’t have this problem, but it could be firmware related. Let’s see, I will post an update once I get the Xiaomi router working or not.
Ok, so if memory serves, I had this issue when trying to run Hassio on my Synology NAS within Docker my IOT VLAN. I never got to the bottom of the issue, but my best guess was that it was a combination of the way Synology was handling layer 3 traffic combined and/or the way my switch was dealing with multicast traffic to/from the NAS.
My solution was to give up on running HA on the NAS 
…
I’m seeing something similar in mine, but I’m getting an invalid key response instead of the write_ack. e.g:
U 192.168.1.15:41844 -> 192.168.1.146:9898
{"cmd": "write", "sid": "158d0001e182af", "data": {"status": "off", "key": "0e45d098e4e34e76b627cea8f8a35101"}}
#
U 192.168.1.146:9898 -> 192.168.1.15:41844
{"cmd":"write_ack","sid":"158d0001e182af","data":"{\"error\":\"Invalid key\"}"}
#
U 192.168.1.15:48346 -> 192.168.1.146:9898
{"cmd" : "get_id_list"}
#
U 192.168.1.146:9898 -> 192.168.1.15:48346
{"cmd":"get_id_list_ack","sid":"34ce0091da9c","token":"26dWblaOPYRbyHdc","data":"[\"158d0001e182af\",\"158d0001b156ed\",\"158d0001a9a31a\",\"158d0001aaadad\",\"158d0001ab31bb\",\"158d0001e525c7\
",\"158d0002253c19\",\"158d0001e543f7\"]"}
#
U 192.168.1.15:42147 -> 192.168.1.146:9898
{"cmd": "write", "sid": "158d0001e182af", "data": {"status": "off", "key": "2d4f393969e4b29cd3b077be13bbea3e"}}
#
U 192.168.1.146:9898 -> 192.168.1.15:42147
{"cmd":"write_ack","sid":"158d0001e182af","data":"{\"error\":\"Invalid key\"}"}
#
I’ve rotated the key, and am still seeing this issue
Hi Team,
Mi problem was using the router ZTE F680. I used an old router as a switch, connecting it to one switch port of the F680 and disabling the DHCP on the old router. The raspberry with HA conencted by cable and the Xiaomi connected to a new SSID on the old ruoter (now I have 2 SSIDs but for the same L2 network). The ZTE is still assigning IP addresses. It works like a charm!
Cheers!
I have the same issue. do you have any solutions?
Hi Artur, after a lot of frustration the solution was to give up trying to run HA on my NAS and run HASSIO (on docker) within a VM on proxmox…