If the sensor is offline in MiHome - it’s not sending Information (battery empty or no connection to the gateway). I’m afraid the “online”-logic has a flaw.
Thanks Thomas for the answer. I wonder if the way I have configured persistency for the items in influxdb could be creating a problem : I have specified “restoreOnStartup” by default and I wonder if this could be getting in the way of the expiration mechanism that you mentioned earlier as a way to detect “offline”?
The online logic at the things level would probably still have a flow, but I could have prevented the expire mechanism from triggering offline?
Ok, the good thing is that I did not miss anything obvious:-) Thanks for confirming.
normally not - even if it’s “restoreOnStartup” - after that it should run into expire after 2h (or whatever you put in). Are you sure, the item never goes to UNDEF? what’s in events.log for that item?
I have looked at the events.log and there is a point in time (last night at 20:00) from when I have no signs of that item anymore. Neither for temp, nor for humidity nor pressure…
expire-binding is installed? At 22:00 the item should go into UNDEF, if you took the example I posted above. If still unclear, please post your item and have a look in paperUI, if expire binding is active
I connected gateway to wifi and move some devices to it.
Good to know, i am planning the same.
Coming back to a problem similar to what user fanavity had.
Originally I had the RPi and two gateways connected to a spare Fritzbox wifi router, and my OH definition & rules worked OK.
Now I moved to the intended network setup and nothing works anymore. From what I can tell it looks like an issue with the binding or OH:
I loaded the RPi3 with a fresh Openhabian image. The RPi is connected to my wired Ethernet and has internet access.
The Openhabian image was flashed today and I did only the modifications listed below.
I followed this guide to set up a hotspot (less IP forwarding):
Hotspot using Stretch
I switched off wifi power save mode, and configured DHCP to provide fixed IPs to the Xiaomi gateways.
Overall this is working well: I can connect to the RPi from my laptop using the RPi hotspot or using my wired Ethernet. The RPi has internet access, but devices connected to the hotspot are isolated from the internet (no IP forwarding). The Xiaomi gateways connect to the hotspot, and I can ping both successfully from the RPi.
Except the Xiaomi gateway discovery doesn’t work, and things / items are never updated.
I think its a binding / OH issue, and here is the reason why:
This is what happens when doing a Xiaomi discovery with Ethernet plugged in:
2018-02-12 20:03:58.313 [DEBUG] [nternal.socket.XiaomiDiscoverySocket] - Setup discovery socket
2018-02-12 20:03:58.319 [DEBUG] [nternal.socket.XiaomiDiscoverySocket] - Initialized socket to null:-1 on 0.0.0.0/0.0.0.0:37063
2018-02-12 20:03:58.327 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - There are 1 open sockets: {37063=java.net.DatagramSocket@189230f}
2018-02-12 20:03:58.334 [DEBUG] [scovery.XiaomiBridgeDiscoveryService] - Start scan for bridges
2018-02-12 20:04:08.316 [DEBUG] [scovery.XiaomiBridgeDiscoveryService] - Stop scan
2018-02-12 20:04:08.320 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - Interrupting Thread Thread[Thread-84,5,main]
2018-02-12 20:04:08.322 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - Closing socket java.net.DatagramSocket@189230f
2018-02-12 20:04:08.328 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - Receiver thread ended
No Xiaomi Gateway Bridge is discovered.
If I unplug the Ethernet cable and repeat the discovery I get an error in the log:
2018-02-12 21:19:37.447 [DEBUG] [scovery.XiaomiBridgeDiscoveryService] - Stop scan
2018-02-12 21:19:37.468 [DEBUG] [nternal.socket.XiaomiDiscoverySocket] - Setup discovery socket
2018-02-12 21:19:37.472 [DEBUG] [nternal.socket.XiaomiDiscoverySocket] - Initialized socket to null:-1 on 0.0.0.0/0.0.0.0:59893
2018-02-12 21:19:37.491 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - There are 1 open sockets: {59893=java.net.DatagramSocket@1cc699b}
2018-02-12 21:19:37.495 [DEBUG] [scovery.XiaomiBridgeDiscoveryService] - Start scan for bridges
2018-02-12 21:19:37.503 [ERROR] [.mihome.internal.socket.XiaomiSocket] - Sending error
java.io.IOException: Network is unreachable (sendto failed)
at java.net.PlainDatagramSocketImpl.send(Native Method) ~[?:?]
at java.net.DatagramSocket.send(DatagramSocket.java:693) [?:?]
at org.openhab.binding.mihome.internal.socket.XiaomiSocket.sendMessage(XiaomiSocket.java:146) [202:org.openhab.binding.mihome:2.2.0]
at org.openhab.binding.mihome.internal.socket.XiaomiDiscoverySocket.sendMessage(XiaomiDiscoverySocket.java:64) [202:org.openhab.binding.mihome:2.2.0]
at org.openhab.binding.mihome.internal.discovery.XiaomiBridgeDiscoveryService.discoverGateways(XiaomiBridgeDiscoveryService.java:99) [202:org.openhab.binding.mihome:2.2.0]
at org.openhab.binding.mihome.internal.discovery.XiaomiBridgeDiscoveryService.startScan(XiaomiBridgeDiscoveryService.java:64) [202:org.openhab.binding.mihome:2.2.0]
at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:222) [104:org.eclipse.smarthome.config.discovery:0.10.0.b1]
[snip]
So to me it seems like the binding just looks for the gateway on the wired interface. If its present, it can’t find anything (because the gateways are on the wireless interface). If the wired interface is offline, it gives an error.
Now if I add the gateway thing manually to the Inbox the binding successfully identifies the gateway, and populates the Inbox with things for all sub-devices that are assigned to it. If I approve any sub-device thing in the inbox it shows up as “online” in the configuration section. But things and items receive no updates afterwards.
Here is the log for adding a gateway manually with wired Ethernet connected:
2018-02-12 20:05:51.819 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Having 1 Item Discovery listeners
2018-02-12 20:05:51.832 [DEBUG] [org.openhab.binding.mihome ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=311, service.bundleid=202, service.scope=singleton} - org.openhab.binding.mihome
2018-02-12 20:05:51.850 [DEBUG] [org.openhab.binding.mihome ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=312, service.bundleid=202, service.scope=singleton} - org.openhab.binding.mihome
2018-02-12 20:05:51.876 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Init socket on Port: 9898
2018-02-12 20:05:51.881 [DEBUG] [e.internal.socket.XiaomiBridgeSocket] - Setup socket
2018-02-12 20:05:51.884 [DEBUG] [e.internal.socket.XiaomiBridgeSocket] - Initialized socket to null:-1 on 0.0.0.0/0.0.0.0:9898
2018-02-12 20:05:51.889 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - There are 1 open sockets: {9898=java.net.MulticastSocket@1e364cf}
2018-02-12 20:05:52.895 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Triggered discovery
2018-02-12 20:05:52.899 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "get_id_list"}
2018-02-12 20:05:52.909 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - Received Datagram from 192.168.188.21:9898 on Port 9898
2018-02-12 20:05:52.918 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read", "sid": "158d0001dbb7a0"}
2018-02-12 20:05:52.922 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read", "sid": "158d0001aad1ee"}
2018-02-12 20:05:52.925 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read", "sid": "158d000123df02"}
2018-02-12 20:05:52.928 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read", "sid": "158d0001b14454"}
2018-02-12 20:05:52.931 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read", "sid": "158d0001dbcc8c"}
2018-02-12 20:05:52.935 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read", "sid": "158d0001ab403e"}
2018-02-12 20:05:52.938 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read", "sid": "158d0001d6f8ab"}
2018-02-12 20:05:52.941 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read", "sid": "158d00016d8e28"}
2018-02-12 20:05:52.947 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read", "sid": "158d000123df47"}
2018-02-12 20:05:52.950 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read", "sid": "158d0001e46332"}
2018-02-12 20:05:52.954 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read", "sid": "158d0001de92cf"}
2018-02-12 20:05:52.964 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:74f76698: {"cmd": "read"}
2018-02-12 20:05:52.968 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - Received Datagram from 192.168.188.21:9898 on Port 9898
2018-02-12 20:05:52.978 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Device 158d0001dbb7a0 honored read request
2018-02-12 20:05:52.984 [DEBUG] [discovery.XiaomiItemDiscoveryService] - Detected Xiaomi smart device - sid: 158d0001dbb7a0 model: sensor_magnet.aq2
2018-02-12 20:05:52.991 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'mihome:sensor_magnet_aq2:158d0001dbb7a0' to inbox.
2018-02-12 20:05:52.994 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - Received Datagram from 192.168.188.21:9898 on Port 9898
2018-02-12 20:05:52.997 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Device 158d0001aad1ee honored read request
2018-02-12 20:05:53.004 [DEBUG] [discovery.XiaomiItemDiscoveryService] - Detected Xiaomi smart device - sid: 158d0001aad1ee model: sensor_magnet.aq2
2018-02-12 20:05:53.011 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'mihome:sensor_magnet_aq2:158d0001aad1ee' to inbox.
2018-02-12 20:05:53.024 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - Received Datagram from 192.168.188.21:9898 on Port 9898
Adding the gateway manually works the same way with Ethernet connected or disconnected. With the Ethernet unplugged it shows an error in the log, but works just the same.
Here is the same log for adding the gateway with the Ethernet disconnected. Note the “socket error”
2018-02-12 21:21:55.360 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Having 1 Item Discovery listeners
2018-02-12 21:21:55.365 [DEBUG] [org.openhab.binding.mihome ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={service.id=307, service.bundleid=202, service.scope=singleton} - org.openhab.binding.mihome
2018-02-12 21:21:55.379 [DEBUG] [org.openhab.binding.mihome ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.core.status.ConfigStatusProvider}={service.id=308, service.bundleid=202, service.scope=singleton} - org.openhab.binding.mihome
2018-02-12 21:21:55.411 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Init socket on Port: 9898
2018-02-12 21:21:55.415 [DEBUG] [e.internal.socket.XiaomiBridgeSocket] - Setup socket
2018-02-12 21:21:55.418 [ERROR] [e.internal.socket.XiaomiBridgeSocket] - Setup socket error
java.net.SocketException: No such device
at java.net.PlainDatagramSocketImpl.join(Native Method) ~[?:?]
at java.net.AbstractPlainDatagramSocketImpl.join(AbstractPlainDatagramSocketImpl.java:178) [?:?]
at java.net.MulticastSocket.joinGroup(MulticastSocket.java:323) [?:?]
at org.openhab.binding.mihome.internal.socket.XiaomiBridgeSocket.setupSocket(XiaomiBridgeSocket.java:47) [202:org.openhab.binding.mihome:2.2.0]
at org.openhab.binding.mihome.internal.socket.XiaomiSocket.intialize(XiaomiSocket.java:71) [202:org.openhab.binding.mihome:2.2.0]
at org.openhab.binding.mihome.handler.XiaomiBridgeHandler.initialize(XiaomiBridgeHandler.java:101) [202:org.openhab.binding.mihome:2.2.0]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
at org.eclipse.smarthome.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:153) [109:org.eclipse.smarthome.core:0.10.0.b1]
at org.eclipse.smarthome.core.internal.common.Invocation.call(Invocation.java:53) [109:org.eclipse.smarthome.core:0.10.0.b1]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
at java.lang.Thread.run(Thread.java:748) [?:?]
2018-02-12 21:21:55.422 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - There are 1 open sockets: {9898=java.net.MulticastSocket@1d5a774}
2018-02-12 21:21:56.430 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Triggered discovery
2018-02-12 21:21:56.436 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "get_id_list"}
2018-02-12 21:21:56.845 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - Received Datagram from 192.168.188.21:9898 on Port 9898
2018-02-12 21:21:56.857 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read", "sid": "158d0001dbb7a0"}
2018-02-12 21:21:56.864 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read", "sid": "158d0001aad1ee"}
2018-02-12 21:21:56.867 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read", "sid": "158d000123df02"}
2018-02-12 21:21:56.871 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read", "sid": "158d0001b14454"}
2018-02-12 21:21:56.875 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read", "sid": "158d0001dbcc8c"}
2018-02-12 21:21:56.879 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read", "sid": "158d0001ab403e"}
2018-02-12 21:21:56.882 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read", "sid": "158d0001d6f8ab"}
2018-02-12 21:21:56.886 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read", "sid": "158d00016d8e28"}
2018-02-12 21:21:56.889 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read", "sid": "158d000123df47"}
2018-02-12 21:21:56.893 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read", "sid": "158d0001e46332"}
2018-02-12 21:21:56.896 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read", "sid": "158d0001de92cf"}
2018-02-12 21:21:56.900 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Send to bridge mihome:bridge:f9d9e331: {"cmd": "read"}
2018-02-12 21:21:56.904 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - Received Datagram from 192.168.188.21:9898 on Port 9898
2018-02-12 21:21:56.909 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Device 158d0001dbb7a0 honored read request
2018-02-12 21:21:56.921 [DEBUG] [discovery.XiaomiItemDiscoveryService] - Detected Xiaomi smart device - sid: 158d0001dbb7a0 model: sensor_magnet.aq2
2018-02-12 21:21:56.970 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'mihome:sensor_magnet_aq2:158d0001dbb7a0' to inbox.
2018-02-12 21:21:56.978 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - Received Datagram from 192.168.188.21:9898 on Port 9898
2018-02-12 21:21:56.983 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Device 158d0001aad1ee honored read request
2018-02-12 21:21:56.987 [DEBUG] [discovery.XiaomiItemDiscoveryService] - Detected Xiaomi smart device - sid: 158d0001aad1ee model: sensor_magnet.aq2
2018-02-12 21:21:56.994 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'mihome:sensor_magnet_aq2:158d0001aad1ee' to inbox.
2018-02-12 21:21:56.999 [DEBUG] [.mihome.internal.socket.XiaomiSocket] - Received Datagram from 192.168.188.21:9898 on Port 9898
2018-02-12 21:21:57.001 [DEBUG] [g.mihome.handler.XiaomiBridgeHandler] - Device 158d000123df02 honored read request
This is followed by more similar lines for each device attached to this particular gateway.
But there are no further debug messages from the binding. Total silence, no interaction between the binding and the gateway, and no heartbeats.
With the previous setup (RPi and gateways connected to a router) the logs showed gateway heartbets coming in every ten seconds.
To confirm that the RPi actually receives the gateway heartbeats I checked with tcpdump. Tcpdump shows the 10s heartbeats of the two gateways (and additional traffic if I trigger a switch, cube or window contact):
20:15:53.761206 IP 192.168.188.22.54321 > 120.92.96.242.8053: UDP, length 32
20:15:54.292927 IP 192.168.188.21.4321 > 224.0.0.50.9898: UDP, length 137
20:15:54.293722 IP 192.168.188.22.9898 > 192.168.188.21.4321: UDP, length 79
20:15:54.983528 IP 192.168.188.22.4321 > 224.0.0.50.9898: UDP, length 137
20:15:54.983856 IP 192.168.188.21.9898 > 192.168.188.22.4321: UDP, length 79
20:15:55.757146 IP 192.168.188.22.54321 > 120.92.96.242.8053: UDP, length 32
20:15:57.753925 IP 192.168.188.22.54321 > 120.92.96.242.8053: UDP, length 32
20:15:59.753133 IP 192.168.188.22.49153 > 192.168.188.1.53: 0+ A? ott.io.mi.com. (31)
20:15:59.753612 IP 192.168.188.1.53 > 192.168.188.22.49153: 0 6/0/0 A 58.83.160.36, A 58.83.160.14, A 42.62.94.185, A 120.92.96.88, A 124.243.204.138, A 120.92.96.87 (127)
20:16:04.272325 IP 192.168.188.21.4321 > 224.0.0.50.9898: UDP, length 137
20:16:04.273887 IP 192.168.188.22.9898 > 192.168.188.21.4321: UDP, length 79
20:16:04.963219 IP 192.168.188.22.4321 > 224.0.0.50.9898: UDP, length 137
20:16:04.964161 IP 192.168.188.21.9898 > 192.168.188.22.4321: UDP, length 79
So RPi receives the heartbeats, but OH / binding doesn’t process them.
I am no network or linux expert, but to me it seems this is an issue with the binding or OH itself. Maybe its just missing a configuration to tell the binding which interface to use or so.
Any idea??
EDIT: I did another test: My laptop and both gateways connected to the RPi’s hotspot. OH running on the laptop can discover the gateways and receive heartbeats & data, but OH on RPi can’t.
Oh dude… I spent ages to track, understand and document this issue just to get an answer from you guys. And now while waiting for a solution from forum members I stumble over it:
sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev wlan0
This is an example from the manpages of the route command. It routes all UDP multicast traffic through wlan0.
So it looks like the Xiaomi binding talks to eth0 only, and the routing table modification redirects this traffic.
This modification may not be the best solution as it could have side effects (no multicast on eth0) but works for me.
openHAB itself needs a distinct network interface, which it connects to. Look in the logs directly after starting oh2, you’ll find which one it uses and which one it ignores. I had at one point wlan0 and eth0 also connected in my case oh2 chose wlan0 on every start.
I’m no expert either, but perhaps oh2 chose eth0 in your case - I digged no further, but there could be some way to tell oh2 which NIC to use?
Good idea. But it doesn’t seem to work this way.
I just restartet my RPi which undoes the change to the IP routing table. The log file :
2018-02-13 09:23:15.644 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.168.178.31
2018-02-13 09:23:15.674 [WARN ] [g.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.168.178.31
2018-02-13 09:23:15.776 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at http://192.168.188.1:8080
2018-02-13 09:23:15.780 [INFO ] [.dashboard.internal.DashboardService] - Started dashboard at https://192.168.188.1:8443
2018-02-13 09:23:35.366 [INFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
OH binds itself to the wlan0 (192.168.188.1) and ignores eth0 (192.168.178.31).
I can reach the OH dashboard from both networks eth0 and wlan0. The Xiaomi binding doesn’t work (discovery fails, manually added gateway shows online but is not functional, no heartbeat data).
After I execute the route command
sudo route add -net 224.0.0.0 netmask 240.0.0.0 dev wlan0
the Xiaomi gateway discovery works immediately and heartbeat data comes in for newly discovered gateways.
Already defined gateways don’t work right away, this requires a restart of OH. I guess the socket in use doesn’t pick up the routing table change on the fly.
I’m no expert in neither TCP/IP nor in openHAB2-core internals. But it seems to me:
- OH2-core prefers wlan0 over eth0 (exactly as I experienced)
- the UPD-traffic seem to avoid wlan0 on system Level
ad 1)
I guess, you have to distinguish OH2-core and OH2-interfaces (UI and API). So, the core (meaning including all bindings) only connects to one interface (wlan0 seems the preferred one), so you can only have that network for communication. In my case I had two completely different subnets for wlan0 and eth0 - openHAB2 naturally didn’t bridge them, but used the wlan0. Which after some thoughts makes sense as how would OH2 know, which interface/subnet to use for core and binding functionality (mainly for the eventbus I guess).
As in your case, I also could access the interfaces (UIs, API) via both networks - but the core only communicates with one (the not-ignored one)
ad 2)
I know nothing on UPD-packet control or whatever, but it seems, they would prefer (why? I don’t know) eth0 before wlan0? and for some reason (could be your router configuration? or the raspbian one?) they come over eth0 in default.
conclusion:
Why do you need two interfaces? I don’t know your iptables and router configuration for subnets, but the 178 and 188 seem to be also two discrete subnets? So, if you find a way to channel them before your oh2-raspi, that would solve the issue - otherwise I don’t see a reason, why your current setup won’t function as a “real” solution, as you reroute the UDP-traffic for your wlan0 interface?
My setup
I had two interfaces, because I had my guest Wifi (with some minor device running in there) and my normal network. But as I didn’t find a way for telling openHAB to use eth0 as it’s interface (and of course I didn’t get both network information into openHAB the same time (again: no bridging within openHAB - only on rasbpian/router side?) I ditched the idea and removed wlan0 again.
The rationale behind this setup:
- I don’t want to grant cheap chinese gadgets access to my primary network. A strong passphrase becomes worthless if stored in a chinese cloud, and any potentially compromised device inside my primary network is a concern. So I want a separate wifi for home automation things (cameras, gateways, actors, sensors), one that doesn’t bother me much if compromised somehow.
- Devices on the HA network should have no access to the internet or my main network. Only exception is for manual firmware updates, which requires temporary restricted internet access for individual devices.
- I don’t want to run a second router unlesss I have to. I know its only a matter of a few Euro per year but still
- I need to access the RPi from my main network and through VPN tunnel for administration and visualization
- The RPi is also used for media streaming on my main home network, which shows somewhat better performance if connected over wired ethernet
So for me the natural choice is to wire the RPi into my ethernet and use the RPi’s hotspot to create a separate wifi for the home automation things.
1 Like
sounds reasonable enough - so I’d stick with your solution, unless you bridge both secure and unsecure networks via hardware you do so (at least for UDP) in your Pi.
But from my experience, openHAB won’t have access (at least TCP/IP) from eth0 devices. I have a bunch of bindings, which weren’t accessible - so latest in that regard you have to find another solution, if you also have bindings reliant to eth0 traffic.
The IP route defintion looks like all multicast UDP goes into the wlan0 network, so this should not create an unwanted bridge. I’ll look into the bridging issue, but with ip forwarding off no traffic seems to roam between these two networks, also no UDP.
As long as the chinese gadgets don’t call home I’m OK.
I just tested the network binding with the IP routing change in place. The discovery shows me network devices from both networks.
I’ll do some more checks, but for now it seems to be OK for my usecase.
Hi,
I have connected Yeelights to my OH2 installation.
I have just received my Aqara Temp/Humidity/Pressure sensor and they were detected by OH.
I can then see them in Paper UI with correct temp and humidity. However, the value is never updated in the interface. I have to refresh the web page to get the new value.
Is this the normal behaviour ? I am also using the EventSource /rest/events and can’t see any events pushed regarding temp/humidity like the one I can see for my yeelights.
That’s a known issue with 2.2
please keep in mind: openHAB is a Backend, the UIs provided are completely different. So, if the items get updated via the eventbus (events.log is the place to look for), everything is fine - the Basic UI at present doesn’t autorefresh in that case.
I don’t know of JSR223 scripting (that’s what you use with EventSource, right?), but if the states get updated, there should be something here also.
Thanks @binderth for your quick reply
I am using EvenSource as I have created my own custom web interface for tablet using the rest API 
and it’s easy to get all the events on http://localhost:8080/rest/events
On the EventSource, I receive update for my Yeelights status but nothing regarding temp/humidity changes. Thus, I can’t update my dashboard 
As for the version, I am using the latest OH stable version downloaded 3 days ago with the last official Xiaomi Mi Smart Home Binding (I haven’t downloaded any jar or replaced anything from the default config). I don’t know which version they are nor how to check it.
EDIT: I noticed when I go to edit my sensor in Paper UI, the description says : "Sensor reports the temperature when there’s a difference around 0.5°C. If there is no significant temperature change, sensor reports temperature once a 50 minutes"
I have tried to warm the sensor but it still does not send any event 
What’s in events.log?