Same here just with the Aquara one button switch (86sw1) no reaction when pressing.
(OpenHab 2.1 with official mihome binding from paper ui)
I confirm 
Is the new square aqara temp/humidity/pressure sensor working now with latest snapshot version of this binding?
I´m on openhab 2.2 snapshot and made apt-get update/upgrade today to build 2.2.0 #1023 but still no automatic discovery of new devices. I can see the new sensors in the myhome app but not in paper ui.
can’t get the Smart Plug (ZigBee Version) to work.
only get an error
any idea or the same problem?
2017-08-24 21:35:41.076 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occurred while calling handler: java.lang.NullPointerException
java.util.concurrent.ExecutionException: java.lang.NullPointerException
at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly(SafeMethodCaller.java:220)[98:org.eclipse.smarthome.core:0.9.0.b5]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:189)[98:org.eclipse.smarthome.core:0.9.0.b5]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:83)[98:org.eclipse.smarthome.core:0.9.0.b5]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:67)[98:org.eclipse.smarthome.core:0.9.0.b5]
at org.eclipse.smarthome.core.thing.internal.ThingManager.receiveCommand(ThingManager.java:374)[105:org.eclipse.smarthome.core.thing:0.9.0.b5]
at org.eclipse.smarthome.core.items.events.AbstractItemEventSubscriber.receive(AbstractItemEventSubscriber.java:47)[98:org.eclipse.smarthome.core:0.9.0.b5]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:192)[98:org.eclipse.smarthome.core:0.9.0.b5]
at org.eclipse.smarthome.core.internal.events.OSGiEventManager$1.call(OSGiEventManager.java:1)[98:org.eclipse.smarthome.core:0.9.0.b5]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:181)[98:org.eclipse.smarthome.core:0.9.0.b5]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]
Caused by: java.lang.NullPointerException
at org.openhab.binding.mihome.handler.XiaomiBridgeHandler.toJsonValue(XiaomiBridgeHandler.java:319)[181:org.openhab.binding.mihome:2.1.0]
at org.openhab.binding.mihome.handler.XiaomiBridgeHandler.sendCommandToBridge(XiaomiBridgeHandler.java:257)[181:org.openhab.binding.mihome:2.1.0]
at org.openhab.binding.mihome.handler.XiaomiBridgeHandler.sendCommandToBridge(XiaomiBridgeHandler.java:239)[181:org.openhab.binding.mihome:2.1.0]
at org.openhab.binding.mihome.handler.XiaomiBridgeHandler.writeToDevice(XiaomiBridgeHandler.java:266)[181:org.openhab.binding.mihome:2.1.0]
at org.openhab.binding.mihome.handler.XiaomiActorPlugHandler.execute(XiaomiActorPlugHandler.java:42)[181:org.openhab.binding.mihome:2.1.0]
at org.openhab.binding.mihome.handler.XiaomiDeviceBaseHandler.handleCommand(XiaomiDeviceBaseHandler.java:97)[181:org.openhab.binding.mihome:2.1.0]
at org.eclipse.smarthome.core.thing.internal.ThingManager$4.call(ThingManager.java:377)[105:org.eclipse.smarthome.core.thing:0.9.0.b5]
at org.eclipse.smarthome.core.thing.internal.ThingManager$4.call(ThingManager.java:1)[105:org.eclipse.smarthome.core.thing:0.9.0.b5]
at org.eclipse.smarthome.core.common.SafeMethodCaller.executeDirectly(SafeMethodCaller.java:218)[98:org.eclipse.smarthome.core:0.9.0.b5]
... 12 moreI am still waiting for it, but is anybody running that Xiaomi Wifi Power Strip with six outputs (https://www.gearbest.com/electronics-gadgets/pp_310701.html ) in openhab?
I did not find it in any binding or thread. Probably a waste of money? Should have looked before - these gearbest-flash sales… 
Thank you in advance.
Edit: Found a thread with very few comments: Binding for Xiaomi wifi plug and power strips - Xiaomi Mi IO Binding ; guess it was a waste of money.
Edit 2: The Xiaomi Robot Vacuum Binding should help: Xiaomi Robot Vacuum Binding ; just to inform anybody who reads this 
I think you need to download the jar manually from
https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.mihome/2.2.0-SNAPSHOT/
I have 4 of them working
1 Like
Not working with this too.
I uninstalled the old binding manually, then changed the addons.cfg and after that copied the jar to the addons-folder and made a complete server reboot.
No new devices…
i have made a mihome.things file - could this be the error? Or can i have a mixed setup? Some devices configured with mihome.things and some with paper ui?
Don´t know how i can get the device-id of the new temp sensors without paper ui auto discovery?’
Now it works. I had to wait some time…
But another question:
I get pressure in kPa (maybe 99.2 kPa).
In germany pressure is measured in mbar.
Do i have to change this with a rule or is there a simpler way?
Thank you so much!!! This makes the Smart Plug (ZigBee) to work perfectly!!!
The same here in Denmark, it is only a factor 10 difference, but having a rule setting multiplying with 10 for a virtual item would be overdoing it, I think
I also had my smart plugs stop working after an update. I found the problem was that the channel naming had changed from my old version. So you can try removing and adding one unit to see if the channels are different.
I got my gateway, couple buttons, and a few door and motion sensors today. Everything works well through the app.
I can’t get OH to connect to the gateway. I’ve tried both the 2.1 and marketplace bindings, manually adding the gateway, upgraded to 2.2 snapshot (from 2.1). At one point I was getting some debug info when doing a discovery or adding the gateway manually. Since 2.2 I don’t even seem to get that.
Developer mode is enabled. I’ve tried disabling and reenabling just to make sure it wasn’t stuck somewhere.
It doesn’t seem like anyone else has run into this problem.
Hey, I have the exact same kind of issue with 2.1 or 2.2 binding versions but both displays nothing on logs.
I’m able to ping the gateway and triple checked that dev mode and network functions are enable in “Mi Home” app.
I tried to manually add a “Xiaomi Bridge” with infos given in the app and then “Xiaomi Gateway” but the 1st one is blocked in “initializing” state, the other one wait for the 1st to finish as they gateway seems to depend of a bridge.
I’m out of idea now
I tried the same and get the same initializing. Took me a bit to figure out I needed to add the bridge instead of the gateway.
When setting the log level, is the correct name org.openhab.binding.xiaomi? I thought that’s what I had done before, but I’m not getting anything now. I even went so far as to do a complete removal of OH2 and reinstall. I’ve had that clear up odd issues in the past but no luck this time.
I talked with another user which implemented Xiaomi smart home stuff last week and he didn’t had issues like us. Weird.
I retried the procedure with 2.1 revision and have still the same issue. I also regenerated developper key multiple time (and clicked on confirm) but nothing to do, still in “Initializing” state.
Here are my logs :
20:29:42.527 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'mihome:bridge:110cc149' has been added.
20:29:42.547 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'mihome:bridge:110cc149' changed from UNINITIALIZED to INITIALIZING
20:30:20.197 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - HttpChannelOverHttp@773dfe56{r=2,c=false,a=IDLE,uri=/rest/thing-types/mihome:bridge} messageComplete
20:30:20.197 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - HttpChannelOverHttp@773dfe56{r=2,c=false,a=IDLE,uri=/rest/thing-types/mihome:bridge} handle enter
20:30:20.197 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - HttpChannelOverHttp@773dfe56{r=2,c=false,a=DISPATCHED,uri=/rest/thing-types/mihome:bridge} action REQUEST_DISPATCH
20:30:20.197 [DEBUG] [org.eclipse.jetty.server.Server ] - REQUEST GET /rest/thing-types/mihome:bridge on HttpChannelOverHttp@773dfe56{r=2,c=false,a=DISPATCHED,uri=/rest/thing-types/mihome:bridge}
20:30:20.197 [DEBUG] [ax.web.service.spi.model.ServerModel] - Matching [/rest/thing-types/mihome:bridge]...
20:30:20.197 [DEBUG] [ax.web.service.spi.model.ServerModel] - Path [/rest/thing-types/mihome:bridge] matched to {pattern=/rest/.*,model=ServletModel{id=org.ops4j.pax.web.service.spi.model.ServletModel-11,name=org.ops4j.pax.web.service.spi.model.ServletModel-11,urlPatterns=[/rest/*],alias=/rest,servlet=com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge@59afbac1,initParams={},context=ContextModel{id=org.ops4j.pax.web.service.spi.model.ContextModel-10,name=,httpContext=DefaultHttpContext [bundle=com.eclipsesource.jaxrs.publisher_5.3.1.201602281253 [9], contextID=default],contextParams={},virtualHosts={},connectors={}}}}
20:30:20.197 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=com.eclipsesource.jaxrs.publisher_5.3.1.201602281253 [9], contextID=default]}
20:30:20.197 [DEBUG] [.jetty.server.handler.ContextHandler] - context=||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=com.eclipsesource.jaxrs.publisher_5.3.1.201602281253 [9], contextID=default]}
20:30:20.198 [DEBUG] [eclipse.jetty.servlet.ServletHandler] - servlet |/rest|/thing-types/mihome:bridge -> org.ops4j.pax.web.service.spi.model.ServletModel-11@b9f03e58==com.eclipsesource.jaxrs.publisher.internal.ServletContainerBridge,-1,true
20:30:20.198 [DEBUG] [ce.jetty.internal.HttpServiceContext] - Handling request for [/rest/thing-types/mihome:bridge] using http context [DefaultHttpContext [bundle=com.eclipsesource.jaxrs.publisher_5.3.1.201602281253 [9], contextID=default]]
20:30:20.199 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ o.e.j.s.h.ContextHandler@4be33c31{/static,null,AVAILABLE}
20:30:20.199 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=org.jupnp.transport.impl.osgi.DisableAuthenticationHttpContext@692a1af2}
20:30:20.199 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=org.openhab.core_2.1.0 [166], contextID=default]}
20:30:20.199 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=org.openhab.ui.dashboard_2.1.0 [170], contextID=default]}
20:30:20.199 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=org.eclipse.smarthome.core.audio_0.9.0.b5 [99], contextID=default]}
20:30:20.199 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=org.eclipse.smarthome.ui_0.9.0.b5 [136], contextID=default]}
20:30:20.199 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=org.eclipse.smarthome.ui.icon_0.9.0.b5 [137], contextID=default]}
20:30:20.199 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=org.eclipse.smarthome.ui.basic_0.9.0.b5 [176], contextID=default]}
20:30:20.199 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=org.eclipse.smarthome.ui.paper_0.9.0.b5 [177], contextID=default]}
20:30:20.199 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=org.openhab.ui.habmin_2.1.0 [197], contextID=default]}
20:30:20.199 [DEBUG] [.jetty.server.handler.ContextHandler] - scope null||/rest/thing-types/mihome:bridge @ HttpServiceContext{httpContext=DefaultHttpContext [bundle=org.openhab.ui.habpanel_2.1.0 [179], contextID=default]}
20:30:20.199 [DEBUG] [org.eclipse.jetty.server.Server ] - RESPONSE /rest/thing-types/mihome:bridge 200 handled=true
@pboos May you please help us to debug it ?
EDIT : @PointandClick is your server wired to your LAN ? It’s my case and during my researches I’ve found that about Xiaomi Gateway and Domoticz :
If you experience problems and are connecting your Domoticz server through a LAN cable, try connecting Domoticz through WiFi instead.
Don’t know if it could be the reason of our issue but there is nothing else to test actually
I have OH running on an Ubuntu Server VM, so yes a wired connection.
It seems some have had issues with certain models of wireless routers. I have a Unifi AP, which someone over on the Home Assistant community says works for them. None the less, I tried connecting my gateway to an old WRT54g running dd-wrt and got the same result. I’ve also seen it mentioned that the wireless security might cause issues I tried wpa2-tkip, wpa2-aes, and wpa2-tkip+aes with no change.
I have an install of Home Assistant that I was testing some time ago. I fired it up and added the xiaomi component and got nothing but an “invalid config” which makes me think it’s a problem with the gateway. Or, I guess, me and HA’s screwy yaml config file.
I’ve trouble to configure my wifi adapter on my server, I have to swtich to network-manager 'cause wpa_supplicant is messing with me but I’m too pissed off to try now.
I’ll first try to reset once more the gateway 
Did you tried to reach your gateway with python script or something else ? I’m trying to reach my gateway without using openhab binding, the aim is to point and understand where is the problem but I have limited knowledge in Python dev / socket / networking.
I’m studying how to use this kind of project https://github.com/jon1012/mihome
Ok, so it seems to have an issue with some kind of Xiaomi Gateway where the “local area network communication protocol” switch do nothing.
See this : https://community.home-assistant.io/t/xiaomi-gateway-not-discovered/25030/62
It’s for HA but we all have the same problem. A way to test is the port is opened is to do :
# nmap -sU -p 9898 192.168.0.22
Starting Nmap 7.01 ( https://nmap.org ) at 2017-08-29 14:18 CEST
Nmap scan report for 192.168.0.22
Host is up (0.0050s latency).
PORT STATE SERVICE
9898/udp closed unknown
MAC Address: 34:CE:00:FA:5A:CF (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 0.53 seconds
In my case, as you can see, it’s not working.