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

Lol, If everything works fine for you with mihome, so why are you writing on this thread? Are you troll or something? I didnt touch vacuum code in my fork so i didnt break any currently working functionality.
I didnt post my version only for you @Nico111, the thread is subscribed by few people and also there are many “lurkes” who may want to test it out.

I don’t understand your concern right now. It has been working but since OH Update 2.2 -> 2.3 it isn’t anymore.

Any Updates?
I’ve messaged the wrong Contributor of Xioami Binding, he couldnt help.

Nope, i’ve been able to connect by serial port to gateway, but xiaomi disabled in latest update downgrade function (flashing custom firmware). I’ve been in contact with Dennis Giese, he knows a lot about xiaomi devices and how to “mod” them. Maybe he will be able to help us.

In attachment UART schema connection:

1 Like

Good job, why do you want to flash the FW?

…because it’s high possibility that it will restore compatibility with openhab mihome addon and i won’t be forced to re implement all functionality in miio addon.

What is he saying about packages not arraiving openHAB?

Hi guys, I have the model lumi.gateway.v3 and fw version 1.4.1_159.
I’m using the latest snapshot of mihome binding and 2.4.0 M4 openhab version.
I don’t have any connection problems at all.

Do you all have monkeycom installed? can you try at least not running monkeycom so that it doesn’t block the port 9898? As the tutorial states this is the main port for the binding to communicate with the gateway.

No, i didn’t install monkeycom. My port 9898/udp is opened by openhab2, when i disable (or change) port definition in *.things file it is closed.

Actually it was a pretty simple solution, but hard to detect.
First of all, this was my solution:
sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev wlan0
UDP multicast messages (ip 224.xxx.xxx.xxx) can use a port even tho it’s already in use of another service.
So the data arrives, but it arrives on the eth1 (ethernet) interface of the Raspberry Pi.
OH is processing the Xiaomi data on the wlan0 interface.
simple and easy, one command and it’s working again

Glad to hear that, but still i can’t capture any udp packages… so i assume i’ve different problem.

same, I just celebrated to early.
I don’t quite get it, every time I change something astrodata (temperature, humidity, pressure) updates for once but then stops working.
It’s so weird

Got it working again, my Access Point was blocking multicast traffic.
Simple as that …

Hi Nico111 and wojciech.fred,

Reading through this thread is a little confusing. Can someone please advise what the current status is on the v2 Gateway? The two messages I’m getting are:

  1. They’ve disabled the old protocol and will need the newer protocol implemented to work with openhab, or
  2. You may need to play with your multicast settings to get the messages working correctly; but the current openhab binding should work.

I’m wondering if someone could clear up; which of these is the case now?

The reason I’m asking is I’ve just recently bought a v2 Gateway (DGNWG02LM). As far as I know it is running the latest firmware (as of yesterday) as I (potentially foolishly) updated the firmware as soon as I got it. I’m not having any luck getting it to work, but I do have a reasonably complicated network configuration, so it is possible that I’ll need to setup multicast udp packets properly.

I’m not really sure, nico11 had problems with multicasting. If you want to check if multicasting works in your network, you can check it with https://github.com/home-assistant/home-assistant/issues/16407#issuecomment-418576405 (third sub-point). If you had done all the checkpoints from the post above, and you still can’t connect, you probably have “my problem” and you have two choices:

  1. wait for implementation of new protocol (i’m busy so i’ve abandoned programming addon, on github there is only proof of concept)
  2. try to buy another gateway and pray for working one

I don’t know how to distinguish “working” with “not working” units. My first shot has firmware version, but my friend have same unit with same firmware version and he had no problems.

Thanks for the reply wojciech.fred. Much appreciated.

I’ve tried the steps you linked to. My understanding is that the Mi Gateway should be broadcasting to 224.0.0.50 periodically (heartbeat) plus whenever anything happens (switch pressed etc).

Unfortunately I didn’t have much luck. I have confirmed multicasting is working on my network by performing the following:

  • On my Linux machine (running Openhab) I ran iperf -s -u -B 224.0.0.50 -i 1 -p 9898
  • On my PC (on the same network with the Gateway) I downloaded and ran a windows program packetsender.
  • I sent a UDP packet to 224.0.0.50:9898. It confirmed I joined the multicast group (saw it appear in the Linux console) and then subsequently I could see the packets being sent.
  • In addition, I ran ‘tcpdump -i eth0 -s0 -vv net 224.0.0.0/4’ on my server and could see the packets I was generating, but no packets from the Mi Gateway.

I tried re-initialising the gateway a number of times, but had the same results each time.

I’m still not 100% convinced I’m not doing something wrong; it seems weird that some people are having issues and some aren’t (despite having both updated their firmware).

If it does come down to it I can probably look at developing something. I’m a software developer with experience in Java and OSGi, so it is possible I could get up to speed fairly quickly…

Spent a bit of time over the weekend exhaustively proving that there are no broadcast packets being sent from the gateway (only packets back to the cloud). I’m now considering looking into developing a solution for the Miio interface. I want to be sure that is required before committing time to it. Does anyone know if the working devices will also work with this Miio interface? Can someone try and see if they have port 54321 open on a device working with the current binding?

Hi,

Are you completely sure that you have latest upgrades? Are you connected to region Mainland China?

I got my Xiaomi bridge from Gearbest last week I was able to set everything up on latest snapshot version of OH. The only problem I have right now is that all of sudden it went offline and that battery on temperature sensors drops like 2% every 6h. Other than that everything seems to be working.

Plugin version in MI App 2.65.9

The main difference I see is fw version 1.4.1_159 vs 1.4.1_157

This is my config from about section in application:

Version code:207
网关ID:98935959
Zigbee通道:11
网关信息:
{"life":435381,"cfg_time":0,"token":"##-mytoken-##","mac":"##MAC##","fw_ver":"1.4.1_159","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":-70,"ssid":"##mywifi##","bssid":"##MAC##"},"netif":{"localIp":"IP","mask":"255.255.255.0","gw":"IP","gw_mac":"###MAC###"},"mmfree":171992,"ot":"otu","otu_stat":[255,202,16,3,13,1533],"ott_stat":[52,24,108,2702]}

Hi Dominik_Jeziorski,

Thanks for the message.

First thing I did was select Mainland China and run the update (as suggested in the how to guide). I’m running 1.4.1_161.0143.

Here is my configuration:

    Version code:207
    网关ID:98942057
    Zigbee通道:25
    网关信息:
    {"life":119,"cfg_time":0,"token":"CURRENT-TOKEN","mac":"MI-MAC","fw_ver":"1.4.1_161","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":-64,"ssid":"SSID","bssid":"MAC"},"netif":{"localIp":"IP","mask":"255.255.255.0","gw":"GATEWAY","gw_mac":"MAC"},"mmfree":181424,"ot":"ott","otu_stat":[0,0,0,0,0,100],"ott_stat":[1,0,41,332]}

From what I can see it looks pretty similar to yours. Will get them side by side in a sec and check.

Quick question; did you turn on developer mode before or after you updated the firmware on your gateway?

Just a quick followup; the only main difference I see is that my “ot” is set to “ott” and your “ot” is set to “otu”. The subsequent ott and otu data fields are also different.

I’m not sure what “ot” is…