@marcel_verpaalen I have a xiaomi smart fan, would you be looking into integrating that? I dont mind to help if you need me to.
Hey! I have a problem with the Binding…
On the PaperUI the Stats of my Vacuum are read out correctly, but on the BasicUI Sitemap i dont get any status of the vacuum.
Here some lines of the debug Log
2018-02-20 20:31:32.766 [DEBUG] [org.openhab.binding.miio ] - BundleEvent [unknown:512] - org.openhab.binding.miio
2018-02-20 20:31:32.776 [DEBUG] [org.openhab.binding.miio ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.core.thing.binding.ThingHandlerFactory}={component.name=org.openhab.binding.miio.internal.MiIoHandlerFactory, component.id=20, service.id=121, service.bundleid=227, service.scope=bundle} - org.openhab.binding.miio
2018-02-20 20:31:32.777 [DEBUG] [org.openhab.binding.miio ] - BundleEvent STARTING - org.openhab.binding.miio
2018-02-20 20:31:32.778 [DEBUG] [org.openhab.binding.miio ] - BundleEvent STARTED - org.openhab.binding.miio
2018-02-20 20:31:32.780 [DEBUG] [org.openhab.binding.miio ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.io.transport.mdns.discovery.MDNSDiscoveryParticipant}={component.name=org.openhab.binding.miio.internal.discovery, component.id=21, service.id=122, service.bundleid=227, service.scope=bundle} - org.openhab.binding.miio
2018-02-20 20:31:32.783 [DEBUG] [org.openhab.binding.miio ] - ServiceEvent REGISTERED - {org.eclipse.smarthome.config.discovery.DiscoveryService}={component.name=org.openhab.binding.miio.internal.discovery.MiIoDiscovery, component.id=22, service.id=123, service.bundleid=227, service.scope=bundle} - org.openhab.binding.miio
2018-02-20 20:31:32.787 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Start Xiaomi Mi IO background discovery
2018-02-20 20:31:32.813 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Getting new socket for discovery
2018-02-20 20:31:32.823 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Starting discovery receiver thread for socket on port 37554
2018-02-20 20:31:33.299 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Error submitting discovered Mi Io device at 192.168.0.5
java.lang.NullPointerException: null
at org.openhab.binding.miio.internal.discovery.MiIoDiscovery.discovered(MiIoDiscovery.java:129) ~[?:?]
at org.openhab.binding.miio.internal.discovery.MiIoDiscovery.access$1(MiIoDiscovery.java:118) ~[?:?]
at org.openhab.binding.miio.internal.discovery.MiIoDiscovery$ReceiverThread.lambda$0(MiIoDiscovery.java:283) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:?]
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-20 20:33:33.359 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 034DD7F3 (192.168.0.5)
2018-02-20 20:33:34.654 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 034DD7F3 type: DND_GET, result: [{"start_hour":22,"start_minute":0,"end_hour":8,"end_minute":0,"enabled":0}], fullresponse: {"result":[{"start_hour":22,"start_minute":0,"end_hour":8,"end_minute":0,"enabled":0}],"id":19}
2018-02-20 20:33:34.657 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 034DD7F3 (192.168.0.5) success
2018-02-20 20:33:34.657 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":21,"method":"get_status","params":[]} -> 192.168.0.5 (Device: 034DD7F3 token: 7356583668517A494346493547737858 Queue: 2)
2018-02-20 20:33:34.657 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 034DD7F3 (192.168.0.5)
2018-02-20 20:33:34.666 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 034DD7F3 (192.168.0.5) success
2018-02-20 20:33:34.666 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":22,"method":"get_consumable","params":[]} -> 192.168.0.5 (Device: 034DD7F3 token: 7356583668517A494346493547737858 Queue: 3)
2018-02-20 20:33:34.667 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 034DD7F3 (192.168.0.5)
2018-02-20 20:33:34.670 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 034DD7F3 (192.168.0.5) success
2018-02-20 20:33:34.700 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 034DD7F3 type: CLEAN_SUMMARY_GET, result: [309308,4957462500,138,[1519023600,1518764400,1518591600,1518418800,1518159600,1517986800,1517814000]], fullresponse: {"result":[309308,4957462500,138,[1519023600,1518764400,1518591600,1518418800,1518159600,1517986800,1517814000]],"id":20}
2018-02-20 20:33:34.733 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 034DD7F3 type: GET_STATUS, result: [{"msg_ver":6,"msg_seq":2004,"state":8,"battery":100,"clean_time":2839,"clean_area":48287500,"error_code":0,"map_present":0,"in_cleaning":0,"fan_power":77,"dnd_enabled":0}], fullresponse: {"result":[{"msg_ver":6,"msg_seq":2004,"state":8,"battery":100,"clean_time":2839,"clean_area":48287500,"error_code":0,"map_present":0,"in_cleaning":0,"fan_power":77,"dnd_enabled":0}],"id":21}
2018-02-20 20:33:34.794 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 034DD7F3 type: CONSUMABLES_GET, result: [{"main_brush_work_time":314068,"side_brush_work_time":314068,"filter_work_time":314068,"sensor_dirty_time":71372}], fullresponse: {"result":[{"main_brush_work_time":314068,"side_brush_work_time":314068,"filter_work_time":314068,"sensor_dirty_time":71372}],"id":22}
–EDIT–
Problem solved
@Brain0verflow, yes that is the intention.
However the binding needs to be approved which is bit of a lenghty process.
Another challenge is that ine of the things to be included is proper documentation which is bit of a challenge due to the number of devices that it is supporting
@fandy
Can you reseach what properties it supports and what are the commands to update the settings.
In the end supporting a device means mainly adding a database entry for the device.
e.g. see here an example of such file.
I think you should define one point in time where you do not integrate more devices, so
However the binding needs to be approved which is bit of a lenghty process.
this process can be started.
proper documentation which is bit of a challenge due to the number of devices that it is supporting
The less devices, the smaller the binding, the quicker the review+merge 
You are free to make smaller follow-up PRs for new devices, which are then easier to review.
I have followed this thread since a while and I only see you adding one device after the other. While it’s nice for the users to have support for that, it makes it even a longer way to be integrated into an official release.
I really would like to see this binding in OH2 and would also volunteer to make a first review. But before doing that you need to specify a “feature complete” state where you do not add further devices and provide the proper README documentation with .things, .items and .sitemap files. 6000 lines of code is quite a huge amount, so before starting to do a review I would like to see a feature freeze and only follow-up commits that address review comments instead of adding new features.
WDYT?
2 Likes
Hi
@marcel_verpaalen
I have also a ceiling lamp and the problem with setting the color temperature not working. I hope I haven’t overseen some comment, but as far as I can see, the problem is just the number of parameters used:
2018-02-23 14:26:36.190 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":1145,"method":"set_ct_abx","params":[3500]} -> 192.168.178.54 (Device: 049E20FF token: *** Queue: 1)
2018-02-23 14:26:36.249 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 049E20FF type: UNKNOWN, result: null, fullresponse: {"error":{"code":-5000,"message":"general error"},"id":1145}
2018-02-23 14:26:36.252 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Error received: {"code":-5000,"message":"general error"}
From Specification
Request Example: {"id":1,"method":"set_ct_abx","params":[3500, "smooth", 500]}
Response Example: {"id":1, "result":["ok"]}
Using the command channel with 3 parameters is working. Thanks @OliM for the workaround. I’m now able to set the color temperature.
2018-02-23 19:47:57.539 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":2535,"method":"set_ct_abx","params":[3500,"smooth",500]} -> 192.168.178.54 (Device: 049E20FF token: *** Queue: 1)
2018-02-23 19:47:57.555 [DEBUG] [inding.miio.handler.MiIoBasicHandler] - Locating action for channel actions#commands:set_ct_abx[3500, "smooth", 500]
2018-02-23 19:47:57.611 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 049E20FF type: UNKNOWN, result: ["ok"], fullresponse: {"result":["ok"],"id":2535}
I hope this is a bit helpful.
Do I have to use Xiaomi cloud or does it also work when cleaner is offline (only local WLAN connection to OH; but no internet access)?
I am from Germany, so I have some doubts using cloud services 
I have mine setup in an isolated VLAN. I had all sorts of problems with the robot only being accessible for a few secs every 5 mins, and finally tracked it down to my firewall which was dropping outgoing requests, and therefore the robot was continually timing out when trying to phone-home. When timing out on these requests the robot was blocking any other incoming requests so I was unable to monitor or control it.
After changing my firewall to reject these outgoing packages, the robot was able to fail quickly when trying to phone-home and I no longer have any issues connecting to it.
2 Likes
Hi,
How can i get the Jar for the latest release?
Hi Marcel
I don’t know if this is in the scope this binding, but I found a github site saying that you can change the radio channel of the mihome gateway, I don’t know if you will block the ressource but if possible I would very much like this possibility:
@marcel_verpaalen and @Anthrax Where do I get the version of the binding with the JIAOYUE 650 ?
I tried the binding from the market but it only finds this:
lumi-gateway-v3_miio78335590
Xiaomi Unsupported Mi IO device
miio:unsupported:04AB4E66
and this:
lumi-gateway-v3_miio78452509
Xiaomi Unsupported Mi IO device
miio:unsupported:04AD171D
and further more this: Discovered Xiaomi Mi IO Device
which i think is my ceiling light but it says it is offline because a token is missing, what do i need to do now ?
You need to add the token (see all around this thread wrt how to get the token…)
Once you’ve added a valid token the binding can communicate with the device and can read the actual type from it (your JIAOYUE 650 ) and it can use it.
2 Likes
@eileen-g yes, I know the yeelights prefer the additional params as well.
unfortunatly that is not yet supported by the binding / database, hence is why yeelights I still consider experimental. Some of the types accept the commands with single param, other types don’t (may even be firmware version related)
I’m doing some re-arrangements to fix this.
I would expect all of the homegateway stuff to be integrated via the mihome binding, as they developed communication with that device.
Anyway, Looking at the code you may experiment by sending custom commands via the miio binding:
get_prop_fm[]
get_props[ "current_status"]
play_specify_fm [ {"type": 0, "id": 0, "url": //here the url// } ]
play_fm ["on"]
play_fm["off"]
1 Like
This means, i need mihome binding (for mihome bridge) and your mihome vacuum cleaner (wlan) binding to change the radio station?
Maybe it would be a great idea to include this into the other mihome binding (which can control the zigbee devices like temp-sensors and so on) rather than into this wlan mihom binding?
I agree, but untill then I hope this solution works
Does anyone else have the issue where the Vacuum keeps returning to the inbox? I have two Vacuums, and every morning I have one or two of them in the inbox again. They work just fine. I have tried to ignore the inbox items, but that does no matter at all?
Some more good… looked at the brightness issues (blue color when using the brightness slider from the color widget) and was able to fix it. Likewise fixed the colortemperature not updating (due to the missing additional parameters) .
As well as and some smaller issue fixes (ao. powerstrip v1) and some new devices (philips zyceeling, waterpurifier)
SHello,
I got that working, now I am working on beeing able to dim the YIAOUYE Ceiling light via an homematic actor.
I found out that when the lamp is in night mode, the brightness value is not displayed correctly
The yeelight support forum said to get the current brightess value of night light the command ‘get_prop[“nl_br”]’ needs to be used.
The ID for night mode is 5 :
// switch lamp to night mode
{“id”:1,“method”:“set_power”,“params”:[“on”,“smooth”,500,5]}
The ID for normal mode is 1 :
// switch lamp to normal mode
{“id”:1,“method”:“set_power”,“params”:[“on”,“smooth”,500,1]}
How can I add this to the binding so i can use the brightness value in a dimming rule.