Openhab-addons: [MiHome] Secondary Xiaomi gateway bridge not initialised
Expected Behavior
Being able to use 2 xiaomi gateways.
Current Behavior
After upgrading from 2.5.3 to 2.5.4 my second xiaomi gateway doens't work anymore.
I never had any problems before.
Downgrading mihome binding to 2.5.3 solves the problem
Log:
2020-04-19 20:57:10.516 [hingStatusInfoChangedEvent] - 'mihome:bridge:XXXXX' changed from UNINITIALIZED to INITIALIZING
==> /var/log/openhab2/openhab.log <==
2020-04-19 20:57:11.074 [ERROR] [nternal.DiscoveryServiceRegistryImpl] - Cannot trigger scan for thing types '[mihome:sensor_ht, mihome:86sw2, mihome:sensor_magnet_aq2, mihome:86sw1, mihome:basic, mihome:sensor_plug, mihome:ctrl_ln1, mihome:ctrl_ln2, mihome:sensor_magnet, mihome:gateway, mihome:curtain, mihome:smoke, mihome:sensor_motion_aq2, mihome:sensor_switch_aq2, mihome:sensor_weather_v1, mihome:sensor_wleak_aq1, mihome:sensor_switch, mihome:sensor_motion, mihome:sensor_vibration, mihome:sensor_cube, mihome:sensor_lock_aq1, mihome:natgas, mihome:ctrl_neutral1, mihome:ctrl_neutral2]' on 'XiaomiItemDiscoveryService'!
java.lang.NullPointerException: null
at org.openhab.binding.mihome.internal.socket.XiaomiSocket.sendMessage(XiaomiSocket.java:152) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.sendMessageToBridge(XiaomiBridgeHandler.java:272) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.sendCommandToBridge(XiaomiBridgeHandler.java:303) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.sendCommandToBridge(XiaomiBridgeHandler.java:276) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.readDeviceList(XiaomiBridgeHandler.java:145) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.discoverItems(XiaomiBridgeHandler.java:392) ~[?:?]
at org.openhab.binding.mihome.internal.discovery.XiaomiItemDiscoveryService.startScan(XiaomiItemDiscoveryService.java:68) ~[?:?]
at org.eclipse.smarthome.config.discovery.AbstractDiscoveryService.startScan(AbstractDiscoveryService.java:209) ~[bundleFile:?]
at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:382) [bundleFile:?]
at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScans(DiscoveryServiceRegistryImpl.java:358) [bundleFile:?]
at org.eclipse.smarthome.config.discovery.internal.DiscoveryServiceRegistryImpl.startScan(DiscoveryServiceRegistryImpl.java:216) [bundleFile:?]
at org.eclipse.smarthome.io.rest.core.internal.discovery.DiscoveryResource.scan(DiscoveryResource.java:97) [bundleFile:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_222]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_222]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_222]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_222]
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory$1.invoke(ResourceMethodInvocationHandlerFactory.java:81) [bundleFile:?]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher$1.run(AbstractJavaResourceMethodDispatcher.java:144) [bundleFile:?]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.invoke(AbstractJavaResourceMethodDispatcher.java:161) [bundleFile:?]
at org.glassfish.jersey.server.model.internal.JavaResourceMethodDispatcherProvider$ResponseOutInvoker.doDispatch(JavaResourceMethodDispatcherProvider.java:160) [bundleFile:?]
at org.glassfish.jersey.server.model.internal.AbstractJavaResourceMethodDispatcher.dispatch(AbstractJavaResourceMethodDispatcher.java:99) [bundleFile:?]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:389) [bundleFile:?]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:347) [bundleFile:?]
at org.glassfish.jersey.server.model.ResourceMethodInvoker.apply(ResourceMethodInvoker.java:102) [bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime$2.run(ServerRuntime.java:326) [bundleFile:?]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:271) [bundleFile:?]
at org.glassfish.jersey.internal.Errors$1.call(Errors.java:267) [bundleFile:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:315) [bundleFile:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:297) [bundleFile:?]
at org.glassfish.jersey.internal.Errors.process(Errors.java:267) [bundleFile:?]
at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:317) [bundleFile:?]
at org.glassfish.jersey.server.ServerRuntime.process(ServerRuntime.java:305) [bundleFile:?]
at org.glassfish.jersey.server.ApplicationHandler.handle(ApplicationHandler.java:1154) [bundleFile:?]
at org.glassfish.jersey.servlet.WebComponent.serviceImpl(WebComponent.java:473) [bundleFile:?]
at org.glassfish.jersey.servlet.WebComponent.service(WebComponent.java:427) [bundleFile:?]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:388) [bundleFile:?]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:341) [bundleFile:?]
at org.glassfish.jersey.servlet.ServletContainer.service(ServletContainer.java:228) [bundleFile:?]
at com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge.service(ServletContainerBridge.java:76) [bundleFile:?]
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:544) [bundleFile:9.4.20.v20190813]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307) [bundleFile:9.4.20.v20190813]
at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [bundleFile:?]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [bundleFile:9.4.20.v20190813]
at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [bundleFile:?]
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.Server.handle(Server.java:494) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:367) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
==> /var/log/openhab2/events.log <==
2020-04-19 20:57:11.246 [vent.ItemStateChangedEvent] - Gateway_woonkamer_Illumination changed from 348 to 346
==> /var/log/openhab2/openhab.log <==
2020-04-19 20:57:11.547 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.mihome.internal.socket.XiaomiSocket.sendMessage(XiaomiSocket.java:152) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.sendMessageToBridge(XiaomiBridgeHandler.java:272) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.sendCommandToBridge(XiaomiBridgeHandler.java:303) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.sendCommandToBridge(XiaomiBridgeHandler.java:276) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.readDeviceList(XiaomiBridgeHandler.java:145) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.lambda$0(XiaomiBridgeHandler.java:139) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_222]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_222]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_222]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_222]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_222]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
and after adding the developer key in the thing settings:
2020-04-19 20:59:11.670 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[]]
2020-04-19 20:59:11.675 [vent.ConfigStatusInfoEvent] - ConfigStatusInfo [configStatusMessages=[]]
Possible Solution
Downgrading mihome binding to 2.5.3 solves the problem.
Steps to Reproduce (for Bugs)
Add a seconday xiaomi gateway of type: lumi.gateway.v3
Context
I use a second gateway on the top floor of my house to extend the range of the zigbee network.
Sensors on the top floor become unstable/unreachable when i use only one gateway.
Your Environment
Raspberry Pi 3B+ with openhabian 2.5.4.
Bindings in use:
airquality, astro , hue , ntp , mihome , openweathermap , network , sonyaudio , dsmr , miio , http1, mqtt, gpstracker, mail, telegram, chromecast, hpprinter
nilsx
All 11 comments
I have the same problem as you, with the seconday gateway. The solution for my was also to downgrade the mihome binding.
Boxter83
on 20 Apr 2020
I have the same problem. When adding second bridge I get error:
2020-04-22 21:17:47.639 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.NullPointerException: null
at org.openhab.binding.mihome.internal.socket.XiaomiSocket.sendMessage(XiaomiSocket.java:152) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.sendMessageToBridge(XiaomiBridgeHandler.java:272) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.sendCommandToBridge(XiaomiBridgeHandler.java:303) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.sendCommandToBridge(XiaomiBridgeHandler.java:276) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.readDeviceList(XiaomiBridgeHandler.java:145) ~[?:?]
at org.openhab.binding.mihome.internal.handler.XiaomiBridgeHandler.lambda$0(XiaomiBridgeHandler.java:139) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_232]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_232]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_232]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_232]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_232]
On 2.5.3 and 2.4.0 it works perfectly.
majherek
on 22 Apr 2020
I have the same issue. I use four gateways. Only the first one installed in OpenHab is still working.
How can i downgrade the mihome binding? Thanks in advance.
bkemmler
on 23 Apr 2020
Same issue here ( but I am an new user and it was driving me crazy!)
Can disable the working one, and re-initialize one of the others and then that one works fine!
Also not sure how to downgrade too - Using latest Raspian OpenHAB SD image
Many thanks - and glad to know I am not along :)
### My Environment
Raspberry Pi 4 Model B Rev 1.2 with openhabian 2.5.4.
Bindings in use:
Xiaomi Mi Smart Home Binding
archie-99
on 23 Apr 2020
To Downgrade!
Then find the "org.openhab.binding.mihome-2.5.3.jar" file in the foloowing directory:
repository\org\openhab\addons\bundles\org.openhab.binding.mihome\2.5.3\
uninstall the mihome binding and place the new jar file in the openhab2-addons directory
nilsx
on 23 Apr 2020
Have also the same problem, I have 3 gateways and only 1 came up ONLINE.
The downgrade helps well as a workaround.
LordPacDemon
on 25 Apr 2020
Sorry! We might have broken it with some changes in https://github.com/openhab/openhab-addons/pull/7280. :disappointed:
I've made some more changes that hopefully fix it. Maybe some of you can test them with this org.openhab.binding.mihome-2.5.5-SNAPSHOT.jar ? If it works I'll create a PR.
After adding some annotations the compiler now guarantees there won't be any NPEs ever in this code. Hopefully those changes don't break any other functionality. :crossed_fingers:
wborn
on 25 Apr 2020
It's working now. But I'll check if others _things_ goes online after an hour...
openhab> bundle:list |grep mi
[cut]
284 │ Active │ 80 │ 2.5.5.202004251308 │ openHAB Add-ons :: Bundles :: Xiaomi Mi Smart Home Binding
openhab> smarthome:things list | grep "^mihome:bridge"
mihome:bridge:7811dcb9e127 (Type=Bridge, Status=ONLINE, Label=Xiaomi Gateway Gora, Bridge=null)
mihome:bridge:7811dcb7e00d (Type=Bridge, Status=ONLINE, Label=Xiaomi Gateway Dol, Bridge=null)
After 1h:
openhab> smarthome:things list | grep "mihome"|grep OFFLINE|wc -l
0
So that means it works properly now @majherek?
wborn
on 25 Apr 2020
Yes, I can confirm that everything works. I even restarted OH to check it.
majherek
on 25 Apr 2020
Great and thanks for testing!
There's #7474 now to fix it in which I also added some proper naming for the threads.
wborn
on 25 Apr 2020
Related issues
trailblazer2006
·
6Comments
doandzhi
·
6Comments
mjcumming
·
5Comments
kubawolanin
·
4Comments
smyrman
·
4Comments
Most helpful comment
It's working now. But I'll check if others _things_ goes online after an hour...
After 1h: