[SOLVED] Openhab2 - Xiaomi Mi Gateway - does not respond

openhab2
gateway
xiaomibinding
Tags: #<Tag:0x00007f01520c5eb8> #<Tag:0x00007f01520c5418> #<Tag:0x00007f01520c4dd8>

(Wojciech F) #41

Be advised: it will be hard to acquire full functionality of gateway using miio protocol. Thanks to miio protocol you can manipulate synchronously gateway (turn light, arm alarm, set color of light, choose radio station) and read some (but not all) sensors. If you want to handle events such as “door opened” or “motion detected” you won’t be able because gateway send this data only to cloud (if you ask for them synchronously by yourself, you can miss (for example) state where door was open (because someone could close them fast)).
If I haven’t discouraged you yet, here are some links I found on the web:

These are pretty good presentation about Xiaomi Ecosystem (it's rather low level): 
  https://recon.cx/2018/brussels/resources/slides/RECON-BRX-2018-Reversing-IoT-Xiaomi-ecosystem.pdf (start at page 14- )
  https://dgiese.scripts.mit.edu/talks/Recon-BRX2018/recon_brx_2018-final-split.pdf (start at page 94- )

and also github repo with all the staff author mentions: 
  https://github.com/dgiese

Must-have util for testing miio protocol: 
  https://github.com/aholstenson/miio

Chinese development documentation for miio?
  https://github.com/MiEcosystem/miio_open

More chinese documentation for miio (might be more useful because includes some field names for miio procotol)
  https://github.com/louisZL/aiot-open-2b/blob/master/resource_definition.md

Here is documentation for lumi protocol (which doesn't work for some of us, udp protocol):
  https://aqara.gitbooks.io/lumi-gateway-lan-communication-api/content/

Yes, I’m sure that I’m using Mainland China. Probably it’s only option to use xiaomi gateway. You can’t connect “mi home” to xiaomi gateway if you set your location to EU or US. Currently I’m using version _159, I didn’t update post after latest upgrade. Now I’m pretty certain that I’ve got “broken” device and it’s not connected to firmware version.

Yeah, but my “ot” is set to otu, and udp protocol doesn’t work for me.

If both of you could share first two bytes of your xiaomi mac addresses, maybe we could figure pattern and warn others?


(Aaron) #42

Already started looking into this. That was going to be my first question; I can send data, but I’d have to poll the interface to detect changes. Then I’d end up with problems as you have highlighted.

From what I’ve found there is a third option: I could implement a dust cloud which effectively emulates the Xiaomi cloud behavior (or parts of it) and can capture enough information to discern when events have occurred. Not sure I want to go to these lengths though.

I’m still not convinced that somehow the non cooperative units can’t be ‘fixed’ (with software or a command). It feels like maybe they’ve entered a locked down state. I was wondering if it has something to do with upgrading the firmware. I upgraded my FW before enabling developer mode (as per the instructions in the howto), but I’m wondering if I had of enabled developer mode first if that would have made a difference (perhaps grabbed a different FW for example, or stored a flag somewhere). This may explain why people getting their second gatway (after no luck with the first) seem to have more luck (they switch developer mode on first)? Just a theory…


(Aaron) #43

I don’t think I mind if you have my whole MAC address. In fact; lets keep a record here:

ps: WPPU = Wireless Protocol (enabled) Prior to Update
ST = square text (old) and RT = round text (new)

	user		MAC					FW			RT/ST	WPPU	Working
	aus.aaron	7C:49:EB:B1:AA:4B	1.4.1_161	?		N		N
	aaron(2)	7C:49:EB:??:??:??	1.4.1_161	RT		Y		Y
	Jensen		7C:49:EB:1C:D5:72	1.4.1_157	?		?		N?
	Dominik		7C:49:EB:??:??:??	1.4.1_159	?		?		Y
	wojciech	78:11:??:??:??:??	1.4.1_159	?		?		N
	dimalo		28:6C:07:??:??:??	1.4.1_161	?		?		Y
	jebo		78:11:DC:??:??:??	1.4.1_161	?		?		Y
	bartsnijder	7C:49:EB:??:??:??	1.4.1_159	?		?		Y (reports there are no updates available)
	Olymp		28:6C:07:??:??:??	1.4.1_159	?		?		Y 
	rsx2007		7C:49:EB:??:??:??	1.4.1_161	RT		N		N (reported not working on _157 and _159 also)
	Josep		28:6C:07:??:??:??	1.4.1_161	ST		?		Y
	Alex44		78:11:DC:??:??:??	1.4.1_161	RT		Y		N
	Sergey		??					??			RT		?		N

Very keen to get to the bottom of this.


(Wojciech F) #44

Check dgiese github repository. He already done (it’s called dustcloud) what you want, but… if you want to fake xiaomi cloud you need another key (because gateway use separate encryption keys for local and cloud communication (for more info check the pdf i’ve linked above)) and to acquire cloud key you need some basic soldering skills and jtag (hardware) to extract proper memory segment from device.


Connection to Xiaomi Bridge not working
(Aaron) #45

From an alternate thread, user Jensen is reporting similar problems (not confirmed it isn’t network related, but sounds suspiciously similar). He posted his settings:

Version code:201
网关ID:87635039
Zigbee通道:25
网关信息:
{“life”:294415,“cfg_time”:0,“token”:“59db7b81jksghfzrfueuehgz70c51ebd”,“mac”:“7C:49:EB:1C:D5:72”,“fw_ver”:“1.4.1_157”,“hw_ver”:“MW300”,“model”:“lumi.gateway.v3”,“mcu_fw_ver”:“0143”,“wifi_fw_ver”:“SD878x-14.76.36.p84-702.1.0-WM”,“ap”:{“rssi”:-41,“ssid”:“con1”,“bssid”:“78:8A:20:2A:AA:1A”},“netif”:{“localIp”:“192.168.178.54”,“mask”:“255.255.255.0”,“gw”:“192.168.178.1”,“gw_mac”:“E0:28:6D:AD:A5:E5”},“mmfree”:159808,“ot”:“ott”,“otu_stat”:[0,0,1,1,0,752],“ott_stat”:[25,1,624,974]}

子设备信息:
[{“model”:“lumi.weather.v1”,“did”:“lumi.158d0002325d11”,“name”:“Temperature and Humidity Sensor”}]

(Dimalo) #46

Hi guys, maybe you have got a buggy device as reported here?


(Aaron) #47

Hi dimalo,

Good question. I feel I have some authority to contribute an answer to this question; I design electronics and write software for a living (Electrical Engineer) so I have some background / knowledge about how these things work. I can’t for the life of me figure out how a hardware fault could cause this to happen; therefore I’d have to assume it is a software bug (or feature?). Especially given:

  1. My device generally works (works with the app, talks via zigbee to a sensor).
  2. My device is more than capable of sending unicast UDP packets; including DNS requests and messages to the Xiaomi cloud.
  3. Can’t confirm right now (but can in future if it is important), but I’m pretty sure I’ve seen my device occasionally send a multicast message to 244.0.0.251.
  4. I can use the miio interface (port 54321 UDP) to query the device and set the light on etc.

Given these points I can only imagine that software is limiting the behavior of the device. The only questions really are why? and can it be fixed? It doesn’t seem right to just buy more gateways until you get a ‘working’ one.


(Dimalo) #48

I agree, the gateway shouldn’t have that behaviour. If eveything works except the local communication, maybe it’s not able to activate it. Most likely it’s software related. Perhaps some IC was changed and now some method fails, hence the whole local communications service is not able to start as soon as you flip the switch.

My opinion is also, that just buying hardware until the problem resolves is a poor option. On the other hand if there is no support to contact, nobody to help and no possibility to hack yourself into the software, maybe just buying a working one is a viable option. Depends on if you want to tinker or to have it working… I guess anybody having a gateway already invested in sensors to do something productive with them. And for that price I doubt it’s worth big efforts, although throwing away (basically) working gear is just a waste…

With Xiaomi now being present in Spain, one of my friends had one of his Yeelights replaced (because it came broken) and was happy with the service. He contacted the seller (I think it was Gearbest) and was advised to send the broken light to Spain, then got a new one dispatched from China. Perhaps there is a chance of getting support for the gateway as well then… But I’m sure they’ll throw it away too.


(Aaron) #49

Yeah; I have to agree. I’m better off ponying up the $40AU for a new gateway and get on with it. Unfortunately I can’t help but think about the few people that may run into this problem (with less skills and experience) and it just turns them away from the whole home automation / tinkering path. I think that is a real shame and if there is something I can do to prevent that happening I’d like to contribute.

At the very least I thought we should compile a list of the FW version, order which dev mode was turned on (before or after FW updates), MAC address and any other relevant info for both working and non-working devices. Perhaps we could determine if there is a pattern…

It’s unfortunate that the developers are not contactable, because I bet they could probably clear it up in a few minutes.

In the mean time I think I’ll try to find somewhere to buy a ‘working’ device, but I’m still keen to get to the bottom of this problem. Is Gearbest my best bet?


(Dimalo) #50

Actually you can try to contact Aqara directly and raise the question. https://www.aqara.com/en/home.html

My MAC is 28:6C:07:xx:xx:xx - hope this helps.

I got mine from Gearbest at least, don’t know if it’s really dealer dependant though, as we don’t know if it’s a bad batch.


(Aaron) #51

Thanks @dimalo :grinning: I’ll update my table above. I’d say there is a good chance that batches will have similar MAC addresses, so that is why I’m keeping some record of that to see if there is a correlation. I’ll try Gearbest and cross my fingers :crossed_fingers:

PS: Will also try contacting Aqara, but I wont hold my breath!


(Dominik Jeziorski) #52

My MAC is “7C:49:EB:XX:XX:XX”


(Jesper Borglund) #53

Hi,
I’m on home assistant and experiencing the same problem. My GW has been working fine for 1,5 year until I updated to fw 1.4.1_161.0143 when it suddenly stopped working. From my point of view it has to be fw related.

Any updates would be much appreciated and though I’m no developer I’m happy to help if there are any thing I can do to bring this issue forward.


(Aaron) #54

Thanks! I’ll update the table above. Looks like a similar batch to mine.

Interesting @Jebo… will be keeping an eye on other people with working devices to see if they have any problems when (if) they get this update. I updated to this version out of the box and never saw my device working, so I can’t confirm if it would have ever worked unfortunately.

Not sure if anyone else with a working setup wants to try upgrading to 1.4.1_161 to see if that’s the issue? (probably not if it means risking a working device).


(Jesper Borglund) #55

If it is fw I guess we will soon be getting more reports.
Adding my mac too: 78:11:DC:xx:xx:xx


(Aaron) #56

Indeed we will @Jebo. Interestingly you seem to be in the same batch as @wojciech.fred who has problems with his from the start (based on MAC at least). Thanks for the info and watch this space…


(Bart Snijder) #57

My MAC is =: 7C:49:EB:xx:xx:xx and I have a functional gateway. Interestingly, it does not say anything about a FW update being available (currently I’m @ 1.4.1_159)


(Sergey M) #58

mac 28:6c:07:ff:ff:ff
fw 1.4.1_159.0143
check for updates: latest software installed


(Jesper Borglund) #59

Strange that you don’t get promoted to update. I had a second HUB in a drawer that I tried with, it’s on 141 and does not allow me to add any devices without updating to 161 - which I have not done this far.


(Aaron) #60

Hi @Olymp,

Can I assume your gateway is working OK?

Also thanks to @bartsnijder for the info. Updating the table accordingly.