Mi(Xiaomi) Smart home bindings?

Hi,

I tried to install the last version from your link : https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.mihome/2.1.0-SNAPSHOT/

But this time the binding doesn’t start. I tried to reinstall it, restart openhab with no luck. Is there an issue with this version (04/27) ?

Thanks.

looks good for me too.
which version of OH?
can you confirm it’s working on a former version?

@Origin8
binding is working and starting, not only for me. see the post above yours.
Please consult the logs and/or the karaf console (bundle:list) for more information.

The OH Version is 2.1.0~20170501124745-1 (Build #906).

Yes, I can confirm that the rule works before the update.

edit:
now, it works, with this simple Rule:

rule "da stimmt doch was nicht"
when
    Channel "mihome:sensor_switch:158d0001265de3:button" triggered CLICK
then
     sendBroadcastNotification("Klick")
end

But the next Problem :scream:
i´ve tried to add a second Gateway. In PaperUI the Thing for the Gateway works, but the Thing for the Bridge :triumph:
I also tried to add the Bridge manually, but it´s not possible to enter the IP and the Serial Number, only the polling Interval and the Developer Key can be edited.

Hi Dimalo,

Thanks for your reply. From the consol it seams that the bundle is active :

openhab> bundle:list | grep Xiaomi
227 | Active | 80 | 2.1.0.201704270648 | Xiaomi Mi Smart Home Binding

In the logs I don’t find any usefull information:

tail -100000 openhab.log | grep xiaomi
2017-05-01 14:32:47.102 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'xiaomi.items’
2017-05-01 14:32:47.320 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'xiaomi.items’
2017-05-01 14:45:28.914 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'xiaomi.items’
2017-05-01 14:52:12.503 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'xiaomi.items’
2017-05-01 14:56:15.750 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'xiaomi.items’
2017-05-01 15:12:50.150 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'xiaomi.items’
2017-05-01 15:31:12.644 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'xiaomi.items’
2017-05-01 15:52:12.423 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'xiaomi.items’
2017-05-01 16:12:34.389 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'xiaomi.items’
2017-05-01 16:49:15.926 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'xiaomi.items’
2017-05-01 18:32:15.433 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model ‘xiaomi.items’

Hi Dimalo,

Thanks for your reply. I reinstalled OH2 and the Smart Home addon. Now it seems working perfectly fine. I don’t know why.

Cheers

Does anyone else use the magnet door/window sensors? I am seeing some odd behaviour whereby if I open and close a door I see the expected open and close events being published from the gateway. And then I see periodic close events being repeated, which seem to be regular status updates. But then after a while they switch to open status updates.

I have 3 of these sensors and none of the doors they are on have been opened, but all three are now reporting open status updates every hour or so.

I got rgb led strip from xiami the other day and I am currently thinking about investing in a gateway, motion sensors and switches.

  1. Reading this thread both motion sensors and switches should be available by the Mi binding, which require the gateway right?
  2. The binding is not official and hence needs to be grabbed from github and can not be installed by the GUI? When will it be official? Will an sudo apt-get update grab updates?
  3. You do not have to pull the gateway for events(unlike HUE), but the gateway reports events to OH? This is a huge benefit if this is true, because you don’t want to call you motion sensor with 2hz to see its status(with hue motion sensor you need to do this and on rpi3 this slows down everything when you have 4+ motion sensors) but rather have the status update the OH item when motion occurs.

I discovert that I have a UNINITIALIZED status via console:

smarthome:things list
mihome:sensor_ht:158d0001299456 (Type=Thing, Status=UNINITIALIZED (HANDLER_MISSING_ERROR), Label=Temperature & Humidity Sensor, Bridge=mihome:bridge:f0b429cc5c8a)
mihome:gateway:f0b429cc5c8a (Type=Thing, Status=UNINITIALIZED (HANDLER_MISSING_ERROR), Label=Gateway, Bridge=mihome:bridge:f0b429cc5c8a)

@billygeen
you should raise an issue for the OH developers then. descibe the behaviour and the version after which the rule didn’t work, seems like a bug to me but I’m not developing OH. I actually would appreciate it, because I like the “one rule for all events” style :wink: heres the link
you’re the first one to have a second gateway I suppose. so there actually never was a development for that. please switch over to the PR discussion. then we can work out how to handle more than one gateway. what we need are some detailed logs on TRACE level, when you have two gateways connected to your network and trigger a discovery in paperUI. The binding should send a message containing {"cmd": "whois"}. when both gateways send some answer back the log gets interesting. we will help you out with this if you can provide some testing information.
The background here is, that at the moment the only known port for the gateway is 9898. I suppose the second one should then use another one, but perhaps it doesn’t - I have no idea really, never had this before :slight_smile:

@Origin8
please enable debug logging with log:set, then restart the binding and have a look into the logs again

@toxicbrain
cheers man have fun with them :tada:

@ben_jones12
this was the case for an old testing version of the binding and should be fixed now. consider installing the marketplace version, as this is mostly kept up to date…

@skatun

  1. yes
  2. use OH 2.1.0, for example the beta version - then install the IOT marketplace binding (mentioned earlier) - then the MiHome binding will be available, but as you already mentioned it’s still under development but working stable
  3. completely right, if something happens the sensor tells the gateway and the gateway tells OH - no polling. the gateway supports it, but there is no benefit in draining the batteries :wink:
1 Like

@dimalo
2. When will a official binding be released? If i do apt-get update, will the binding be updated?
3: Thats great news, that polling is not needed, this make it so much better the phillips hue motion sensors:)

you will need some more patience, the development is still in progress.
the marketplace version should be quite up to date, but I have no idea if already installed marketplace bindings get automatic updates. what I can say is, that apt won’t help you until the binding is official…

@billygeen @dimalo

I had this issue as well, not only with the Xiaomi binding, but the textual rules engine in general.
I’ve reported a bug in eclipse/smarthome:

Thanks @dimalo but I am not using the OH2 binding (as I am still on OH1.8). So I am using a simple python script (based on https://github.com/jon1012/mihome) which listens for the gateway broadcasts and publishes the messages on MQTT topics.

There is not logic in there, the python script just publishes whatever it receives so as far as I can tell the gateway is broadcasting these open events when the sensor is definitely closed, after a period of time with no sensor activity.

I am at a bit of a loss why this is happening but it doesn’t seem like anyone else is seeing this behaviour.

You can try this binding and see if it helps: https://github.com/octa22/org.openhab.binding.xiaomigateway
This is the original binding for 1.x

1 Like

Hi,

The only additionnal information I have is:

[DEBUG] [mpl.info.InfoBundleTrackerCustomizer] - Ignore incorrect info null provided by bundle org.openhab.binding.mihome

Finaly after loosing too much time trying to make it working, I istalled an older version of the binging (1.10) evrything is now working again :slight_smile:

This issue is known - the heartbeat messages seem to send mostly random values in their status apart from the battery voltage. The binding is ignoring the status in the heartbeat message and only takes report messages. this works stable, as the sensors send a report every time their status changes.
there are more devices which do not send values correctly. for example the plug, which still sends battery voltage, always set to 3600 - even if it doesn’t have a battery…

Ah I see, many thanks for that - I will adjust my python script to ignore these heatbeat messages.

Hi there, did anybody manage to ad these:
http://www.gearbest.com/alarm-systems/pp_610096.html?wid=21
and can you trigger the switch to switch on the ballast / light connected to it?

I have only the wireless version of the aqara switch. I´ve seen, there will be new aqara gadgets soon. Temp/humidity sensor, magnet door contact and another wireless switch. The sensors look like the same as the xiaomi sensors, only built into a more sqare housing.