PyXiaomiGateway Problem: {"error":"Invalid key"}

Third party integrations
102

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>
103

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\"}"}
104

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.

105

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…

106

Do you know this issue? https://github.com/Danielhiversen/PyXiaomiGateway/issues/26

1 Like
107

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?

108

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).

109

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.

110

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.

111

Thank you. I enabled debug, but I haven’t received the error again yet.

112

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.

113

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.

114

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.

2 Likes
115

did you solved your problem? @bBoorty i have the same problem

116

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 :frowning:…

117

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

118

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!

119

I have the same issue. do you have any solutions?

120

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…

121

Usually this issue is brought by complexity of your network. Does your network support multicast and doesn’t suffer on packet loss?