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?
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…
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
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.
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”}]
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:
My device generally works (works with the app, talks via zigbee to a sensor).
My device is more than capable of sending unicast UDP packets; including DNS requests and messages to the Xiaomi cloud.
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.
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.
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.
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?
Thanks @dimalo 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
PS: Will also try contacting Aqara, but I wont hold my breath!
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.
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).
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…
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)
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.
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 