[mihome] UDP Socket problem

[shabbab]

I use latest Openhabian & Xiaomi binding on a RPi3. Wired ethernet eth0 is connected to my main router.
I have an access oint etup using this guide. This AP is used by the Xiaomi gateways. The gateways connect and I can ping them from the RPi.

Problem is the Xiaomi gateways are not discovered. If manually added they show up as online, and all assigned sensors are also discovered and show online. But no sensor ever receives an update.

No gateway heartbeat messages are received by the binding. It appears that the binding uses the eth0 interface for discovery and updates.

All details in this post:
https://community.openhab.org/t/mi-xiaomi-smart-home-bindings/4711/658?u=shabbab

There is a workaround, which is to add the following route to redirect all multicast to wlan0:
route add -net 224.0.0.0 netmask 240.0.0.0 dev wlan0

I think the binding requires an update to handle this situation. I currently cannot make a PR, as I don't even have a dev environment setup and not enough spare time to do so.

[dimalo]

hi @shabbab,
you want to have the choice of a specific network interface for the binding to listen on.
do I understand you right?

Please try out this test build. It's modified so that a socket is set up on each network interface. But not for discovery, only for gateway communication.
It is quick and dirty, not a proper solution.
org.openhab.binding.mihome-2.3.0-SNAPSHOT.jar.zip

Edit:
after thinking a while about having the user choose, I think it's easier to just open redundant sockets. this means sending something to the gateway results in sending it on every network, but ensures simplicity.

[dimalo]

@shabbab any progress on this one?
cheers!

[shabbab]

I thought I had already provided feedback, but it seems I just forgot. Sorry, I have been completly busy :-(

I removed the UDP route, uninstalled & deleted the 2.2.0 version and installed the version you posted. The binding identifies itself as 2.3.0.201803111757 in the karaf console.

However this version does not work without the UDP route. No heartbeats are shown in the log files.
If I add the UDP route again and restart OH everything works.

So no improvement

[schaze]

Hi,
I think I have the same issue in a docker environment. My openhab container uses a "macvlan" network which basically exposes it with a proper IP in my network. (this is to not have any hassle with forwarding udp traffic and so on...)

In addition however there are other networks connected in the container (default stack network and a bridge network for use with a traefik proxy)

--> long story short, I have basically 4 network interfaces in the container:

• localhost,
• macvlan, (this should be used for communication)
• stack,
• proxy-net

Discovery of Mi Home Bridge is not working. If add the Bridge manually in a things file, the thing is shown as online and connected devices are discovered - however I do not get any event inputs from these devices (testing with a 2 button switch and a motion sensor)

If I remove all networks except the macvlan one everything works like a charm. As soon as I add any other network (no matter wich kind or how many) it does not work any more.

I have read many different forum posts from people with similar issues, so this does seem to be a more common problem.

I have tried your version from March 11 but unfortunately the result is the same.

I am willing to help in any way possible (short of writing actual code) and can respond promptly to get this resolved :)

FYI: I am also using the miio binding (for a xiaomi vacuum -- see https://marketplace.eclipse.org/content/xiaomi-mi-io-binding), this binding can discover also the bridge, however as it does not support these devices I only see them as generic miio devices. But discovery does work for them // Discovery is done here: https://github.com/marcelrv/openhab2/blob/xiaomi-miio/addons/binding/org.openhab.binding.miio/src/main/java/org/openhab/binding/miio/internal/discovery/MiIoDiscovery.java

Regarding making the network used user configurable, there is also the option to use the Primary Network address which can be set in the system settings: https://community.openhab.org/t/multiple-network-adapters/33887/6
But I guess simply taking all interfaces will probably work for all of the usecases.

[andreasBihlmaier]

Having the same issue here. Did you find a proper solution?

I found the following workaround: Set the default gateway route with the best metric to the interface that is connected to the Mi Home Bridge.

For example Raspberry Pi connected to LAN (misc) and WLAN (Mi Home Bridge):

$ ip route
default via IP.OF.LAN.ROUTER dev eth0 src THE.LAN.IP.ADDR metric 202 
default via IP.OF.WLAN.ROUTER dev wlan0 src THE.WLAN.IP.ADDR metric 303 
THE.LAN.NET.WORK/MASK dev eth0 proto kernel scope link src THE.LAN.IP.ADDR metric 202 
THE.LAN.NET.WORK/MASK dev wlan0 proto kernel scope link src THE.WLAN.IP.ADDR metric 303 
...

Workaround, decrease metric of LAN route:

sudo ip route delete default via IP.OF.LAN.ROUTER; sudo ip route add default via IP.OF.LAN.ROUTER dev eth0 metric 404

default via IP.OF.WLAN.ROUTER dev wlan0 src THE.WLAN.IP.ADDR metric 303
default via IP.OF.LAN.ROUTER dev eth0 src THE.LAN.IP.ADDR metric 404
THE.LAN.NET.WORK/MASK dev eth0 proto kernel scope link src THE.LAN.IP.ADDR metric 202 
THE.LAN.NET.WORK/MASK dev wlan0 proto kernel scope link src THE.WLAN.IP.ADDR metric 303
... 

Note that dhcpcd might reset to previous non-working state after requesting a new release ...

To make this permanent, add the following lines to /etc/dhcpcd.conf:

interface eth0
metric 404

[shabbab]

The workaround that i mentioned inn the initial post has been working ok for me ever since.
So i haven't followed up to get at the root cause.

[mrbig]

Hello all,

after two days of struggle with the above topic I've finally read through the linux multicast howto.

The "official" solution is here: https://www.tldp.org/HOWTO/Multicast-HOWTO-3.html

So if you have more then one nic you have to tell the kernel which one should be default handle multicast.

So the solution in the first comment seems to be the best way how to handle this situation. When using the 'ip' tool the same can be achieved using:

ip route add multicast 224.0.0.50/32 dev eth0.998

One more note: the multicast group 224.0.0.50 is defined as link-local and no well behaving router should forward it between subnets. So if your openhab box and mi gateway are on different subnets then you're out of luck.

[marcelrv]

@mrbig that method is applied in to miio binding.

https://github.com/openhab/openhab2-addons/blob/d53b0890585f0b4500d61ff974c6d5ef3e5995ca/addons/binding/org.openhab.binding.miio/src/main/java/org/openhab/binding/miio/internal/discovery/MiIoDiscovery.java#L106

[mrbig]

@marcelrv as far as I understand that only tells where to send packets. But if you have multiple subnets connected then it won't tell wichone to use. Your linux box will chose on as default, but wont use all of them. I guess the reason is that this is multicast wich should have a specific downstream route.

Maybe binding the socket on creaton to the right interface could help, I did not try that.

[hmerk]

closed as related PR was merged