every time you do a new inclusion (change wifi network), the token is changing.
I don’t know if changing the IP/VLAN makes any difference wrt to the token.
As far as I remember, the mihome app will switch to cloud communications if they are not on the same subnet as the device. (You can check it in the app by looking at the network tab). Hence don’t know if the device indeeds blocks any traffic from outside the subnet. (note this behavior can be different per device)
The MiHome app works very unrealiable for me… Now it is showing remote connection to every device, even the ones which are connected to the same network. Yesterday, even the air purifier (which is on a different network) showed “Network connection”.
The vacuum works between subnets and the only difference is that it is rooted (Valetudo), but for openHAB communication, still the miio protocol (this binding) is used.
I’m out of ideas why it is not working. I will try to move another device and see if that one works…
If the app is working unreliable, this is mostly a sign the connectivity between the devices and the network is not good. You can expect to have similar issues in openhab. (lots of timeouts, re-connections, slow/no updates etc)… been there/done it/…
To understand if this is really the issue, suggest to move your device to a direct line of sight of your accespoint. (many devices have pretty weak reception anyway) to see if that improves the reliability.
Well I don’t think so. I might rephrase this. Only the app (from a functional perspective) seems bad, connection to the devices are always working, though for example I can’t understand why it is usually showing “Remote Connection” even if the devices are in local network.
Removing the device and initiating a discovery brings up the device immediately so it “sees” it. Though adding again, now I get “Handler Configuration Pending”.
It seems that it won’t fill the token automatically. I have added them manually to the newly created thing, still goes into offline. It is possible that discovery works and then it can’t connect to the device?!
It will only have the token if the description of the item shows it. Also, if you just changed the token and right away do the discovery (I believe <1min) the new token may not yet been received and it will be configured with the old token (device goes off-line in OH). See in the picture, the first has token, the 2nd not)
The binding has 2 different discovery mechanisms and indeed I think there are scenario’s possible when you discover a device and not able to reach it (esp in case of VLANs, as mDNS might be propagate between the vlans, but actual traffic not).
well, that’s strange then. The log in debug mode shows the tokens for each device (with current IP as well so I might think this is correct), but I have never seen an Inbox entry like this.
Yes, I have an mDNS reflector setup, so that mDNS traffic is crossing through all the VLANs in my setup.
Though as I said, currently (until I migrate everything to my IoT VLAN) there is no limitation or whatsoever what can be accessed from the IoT network and also my main network (where openhab is right now). So they are indeed on a different network, but for both networks, everything is accessible.
(So for example if I’m on the main lan, I can access everything on the IoT VLAN and if I change to IoT VLAN I can access everything on the main). I don’t know what is wrong with this, maybe something is really blocked at a network level, though I don’t have any firewall rules for this.
Anyway openhab server will be moved to the IoT VLAN so this might not be a really big problem, just I can’t do this transition in one.
Next I will try to setup a test openhab server on the IoT VLAN and see if it works from there.
Hello Marcel,
thanks for the support. Yes, copied your “fixed version” into addon-folder. Unfortunately no map is downloaded, the miio-folder is empty.
Okay, thanks for testing. As this does not work, it means the normal way of continue after an error occurs does not work.
I’ll make a version which does not have the text feature at all, I expect that should avoid any missing font errors
Hello Marcel,
yes, I think this might help. Pls let me know where I could find this version. Everything else is working great, WAF is very high :-))
Hello everyone,
I am getting the following issue message for the map:
2020-06-28 16:46:55.893 [INFO ] [g.miio.internal.cloud.CloudConnector] - Getting vacuum map roboroommap%xx%2F0 from Xiaomi cloud server:
2020-06-28 16:47:05.906 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IllegalArgumentException: Invalid URI host: null (authority: null)
at org.eclipse.jetty.client.HttpClient.checkHost(HttpClient.java:510) ~[?:?]
at org.eclipse.jetty.client.HttpClient.newHttpRequest(HttpClient.java:495) ~[?:?]
at org.eclipse.jetty.client.HttpClient.newRequest(HttpClient.java:453) ~[?:?]
at org.eclipse.jetty.client.HttpClient.newRequest(HttpClient.java:442) ~[?:?]
at org.eclipse.smarthome.io.net.http.HttpUtil.executeUrlAndGetReponse(HttpUtil.java:212) ~[?:?]
at org.eclipse.smarthome.io.net.http.HttpUtil.downloadData(HttpUtil.java:438) ~[?:?]
at org.eclipse.smarthome.io.net.http.HttpUtil.downloadData(HttpUtil.java:417) ~[?:?]
at org.openhab.binding.miio.internal.cloud.CloudConnector.getMap(CloudConnector.java:141) ~[?:?]
at org.openhab.binding.miio.internal.handler.MiIoVacuumHandler.getMap(MiIoVacuumHandler.java:465) ~[?:?]
at org.openhab.binding.miio.internal.handler.MiIoVacuumHandler.lambda$5(MiIoVacuumHandler.java:449) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[?:1.8.0_252]
at java.util.concurrent.FutureTask.run(FutureTask.java:266) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_252]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_252]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_252]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_252]
Does somebody know this message or can give me a hint what it is related to? Since once week the map is not updating any longer, I did not change anything since then.
(the xx in the log file was a number I removed not knowing where it comes from)
thank you.
Due to a SD card error, I had to reinstall my OpenHAB installation. And yes, I had a backup file of my configuration.
My old installation was on 2.4.0 - my new on is 2.5.6 (Openhabian)
More or less, everything is back to work, but mit Xiaomi Vacuum is not working.
After installing the Xiaomi Mi IO Binding, the Vacuum was immediately in my Inbox.
But adding the thing using PaperUI ends with an error pop-up --> “Error 409 - Conflict”
The logfile shows:
2020-06-28 23:07:27.797 [WARN ] [g.discovery.internal.PersistentInbox] - Cannot create thing. No binding found that supports creating a thing of type miio:vacuum.
Any hint what the problem could be?
If you just installed the binding I would recommend restarting openhab. Seems like the binding was not known yet in the whole framework
It indicates the host is null, that means either the cloud gave a unexpected URL for your map
OR you don’t have a correct country server defined for your robot. ( e.g de for Europe)
Country code is blank at the moment. What is the V-cloud? Do you have an idea how to fix the URL issue?
Kindly
Will try that, too
Define the right country server,(from: cn,de,sg,tw,us,ru) for your vacuum. Otherwise the binding does not know from which server to pull the map and it will most likely go wrong.
I restarted OpenHAB more than once and I added my credentials and location.
Nothing changed - I still have this error when adding the vacuum from my Inbox 
2020-06-29 18:03:07.836 [WARN ] [g.discovery.internal.PersistentInbox] - Cannot create thing. No binding found that supports creating a thing of type miio:vacuum.
Any other things that I can do / check?
It is very strange.
Please log an issue in GitHub and add a debug log to understand better what is going on.
What you could try:
Add it manually as a miio:generic thing
Or remove the binding and add it once more
After another uninstall and install I could add the vacuum 
Whatever the reason was before …
Hi @marcel_verpaalen,
I got my Roborock S6 to work with openHAB, thanks for this great binding.
My only question for now: during cleaning phase I see this message in the log every 30 seconds:
2020-06-30 16:22:11.507 [INFO ] [g.miio.internal.cloud.CloudConnector] - Getting vacuum map tanos%2F321360xxx%2F<digit> from Xiaomi cloud server:
Is that normal?
By the way - for the binding I configured Xiaomi server country = de (Paper UI > Configuration > Binding) but is not shown in the log (after Xiaomi cloud server:). Nevertheless the map is shown in openHAB.
I run binding version 2.5.6.202006040359 on 2.5.0.M4.
Regards,
Andy