Xiaomi Robot Vacuum Binding

Add-ons Bindings
, ,
1141

@Olymp the inbox behaviour indeed I expect will happen with any autodiscovery device.
Every few minutes the binding searching for services.
I think OH does not add them when they exact thinguid is already existing, but otherwise it’s adding it to the inbox including the INFO message along with it.

Wrt to the other message, it is indeed informational. It will help a lot when trying to identify issues.
If you don’t want it, set the level for the miio binding to WARN. (See first topic on how to set the level)

Anyway, it is indeed not a warning, but informational that the necessary configuration is completed for the binding to operate your thing.

1142

That is odd… Suggest to set debug level for the logging.

1st check if you see the commands being queued. If not, this may be a channel configuration issue.
2nd if the command is properly queued see what response you get, or if they are ever send.

1143

I tried debug while triggering the item from console since Paper UI is generating overwhelming number of logs on the console. Here’s what I got but I’m not sure I’m able to make sense of it (RoborockS5_Actions_ControlVacuum is my item linked to the control channel of the Roborock thing):

18:51:39.565 [DEBUG] [le.osgi.LoggingCommandSessionListener] - Executing command: 'smarthome:update RoborockS5_Actions_ControlVacuum vacuum'
18:51:39.582 [DEBUG] [le.osgi.LoggingCommandSessionListener] - Command: 'smarthome:update RoborockS5_Actions_ControlVacuum vacuum' returned 'null'
18:51:39.585 [INFO ] [smarthome.event.ItemStateChangedEvent] - RoborockS5_Actions_ControlVacuum changed from dock to vacuum
18:51:39.588 [DEBUG] [org.eclipse.jetty.server.HttpChannel ] - sendResponse info=null content=DirectByteBuffer@11e3e80[p=0,l=168,c=32768,r=168]={<<<event: message\nda...mStateEvent"}\n\n>>>ateTime\\",\\"oldVa...rmap:forecasted} complete=false committing=false callback=Blocker@134ce1f{null}
18:51:39.597 [DEBUG] [g.eclipse.jetty.server.HttpConnection] - org.eclipse.jetty.server.HttpConnection$SendCallback@213c42[PROCESSING][i=null,cb=org.eclipse.jetty.server.HttpChannel$ContentCallback@1c9b50f] generate: FLUSH (null,[p=0,l=168,c=32768,r=168],false)@COMMITTED
18:51:39.608 [DEBUG] [org.eclipse.jetty.io.ChannelEndPoint ] - flushed 168 SocketChannelEndPoint@17104fc{/127.0.0.1:47852<->/127.0.0.1:8080,OPEN,fill=-,flush=W,to=1487/30000}{io=0/0,kio=0,kro=1}->HttpConnection@1fbd921[p=HttpParser{s=END,0 of -1},g=HttpGenerator@c8a5f7{s=COMMITTED}]=>HttpChannelOverHttp@18c4a80{r=1,c=true,a=ASYNC_WAIT,uri=//localhost:8080/rest/events?topics=smarthome/items,age=6607803}
18:51:39.619 [DEBUG] [org.eclipse.jetty.io.WriteFlusher    ] - Flushed=true written=168 remaining=0 WriteFlusher@b1226f{WRITING}->null
18:51:39.625 [DEBUG] [g.eclipse.jetty.server.HttpConnection] - org.eclipse.jetty.server.HttpConnection$SendCallback@213c42[PROCESSING][i=null,cb=org.eclipse.jetty.server.HttpChannel$ContentCallback@1c9b50f] generate: DONE (null,[p=168,l=168,c=32768,r=0],false)@COMMITTED
18:51:39.635 [DEBUG] [org.eclipse.jetty.server.HttpChannel ] - sendResponse info=null content=DirectByteBuffer@11e3e80[p=0,l=227,c=32768,r=227]={<<<event: message\nda...hangedEvent"}\n\n>>>type":"ItemStateC...rmap:forecasted} complete=false committing=false callback=Blocker@134ce1f{null}
18:51:39.642 [DEBUG] [g.eclipse.jetty.server.HttpConnection] - org.eclipse.jetty.server.HttpConnection$SendCallback@213c42[PROCESSING][i=null,cb=org.eclipse.jetty.server.HttpChannel$ContentCallback@13a15ba] generate: FLUSH (null,[p=0,l=227,c=32768,r=227],false)@COMMITTED
18:51:39.650 [DEBUG] [org.eclipse.jetty.io.ChannelEndPoint ] - flushed 227 SocketChannelEndPoint@17104fc{/127.0.0.1:47852<->/127.0.0.1:8080,OPEN,fill=-,flush=W,to=30/30000}{io=0/0,kio=0,kro=1}->HttpConnection@1fbd921[p=HttpParser{s=END,0 of -1},g=HttpGenerator@c8a5f7{s=COMMITTED}]=>HttpChannelOverHttp@18c4a80{r=1,c=true,a=ASYNC_WAIT,uri=//localhost:8080/rest/events?topics=smarthome/items,age=6607846}
18:51:39.655 [DEBUG] [org.eclipse.jetty.io.WriteFlusher    ] - Flushed=true written=227 remaining=0 WriteFlusher@b1226f{WRITING}->null
18:51:39.662 [DEBUG] [g.eclipse.jetty.server.HttpConnection] - org.eclipse.jetty.server.HttpConnection$SendCallback@213c42[PROCESSING][i=null,cb=org.eclipse.jetty.server.HttpChannel$ContentCallback@13a15ba] generate: DONE (null,[p=227,l=227,c=32768,r=0],false)@COMMITTED
1144

Thanks! As I understand it, everything is configured correctly for me, reassured me :slight_smile:
Understood the level of the magazine, I’ll do it!

1145

@mikosoft sorry, I should have been more explicit.
I mean set the miio binding logging to debug (see first topic on how-to)
This seems to be the jetty log.

1146

Ah, I see. Well, as mentioned in my first post (it’s okay if you didn’t notice, there’s a lot going on here), I already did that and I didn’t see anything when I issued any command through the control channel.
The weirdest thing is, it just happened all of a sudden. I had the thing and items configured, tested a and everything worked. Then I dabbed with automation through node-red, still worked. Then two hours later without me touching anything it just stopped working.

1147

I had a while now with openhab so here goes (debug warn for miio bundle), here I sent the “vacuum” comand from paper UI

20:59:06.325 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'RoborockS5_Actions_ControlVacuum' received command vacuum
20:59:06.342 [INFO ] [arthome.event.ItemStatePredictedEvent] - RoborockS5_Actions_ControlVacuum predicted to become vacuum
20:59:06.355 [INFO ] [smarthome.event.ItemStateChangedEvent] - RoborockS5_Actions_ControlVacuum changed from dock to vacuum

skip some lines here

20:59:14.880 [DEBUG] [inding.miio.handler.MiIoVacuumHandler] - Periodic update for 'miio:vacuum:0F9B030E' (miio:vacuum)
20:59:14.885 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":137,"method":"get_dnd_timer","params":[]} -> 192.168.0.70 (Device: 0F9B030E token: redacted Queue: 1)
20:59:14.891 [DEBUG] [rnal.transport.MiIoAsyncCommunication] - Sending Ping 0F9B030E (192.168.0.70)
20:59:14.898 [TRACE] [rnal.transport.MiIoAsyncCommunication] - Connection 192.168.0.70:39634
20:59:14.908 [TRACE] [rnal.transport.MiIoAsyncCommunication] - Connection 192.168.0.70:39634

more cut lines for brevity, pretty much just comm between binding and roborock. I can supply those if needed but it’s quite a lot of text and I don’t think they add much, if anything

20:59:15.102 [TRACE] [rnal.transport.MiIoAsyncCommunication] - Received response from 192.168.0.70: {"result":[{"msg_ver":2,"msg_seq":4205,"state":8,"battery":100,"clean_time":2065,"clean_area":30882500,"error_code":0,"map_present":1,"in_cleaning":0,"in_returning":0,"in_fresh_state":1,"lab_status":1,"fan_power":60,"dnd_enabled":0}],"id":139}
20:59:15.106 [TRACE] [rnal.transport.MiIoAsyncCommunication] - Received  JSON message {"result":[{"msg_ver":2,"msg_seq":4205,"state":8,"battery":100,"clean_time":2065,"clean_area":30882500,"error_code":0,"map_present":1,"in_cleaning":0,"in_returning":0,"in_fresh_state":1,"lab_status":1,"fan_power":60,"dnd_enabled":0}],"id":139}
20:59:15.110 [TRACE] [rnal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@84c75c, data org.openhab.binding.miio.internal.MiIoSendCommand@95758d from org.openhab.binding.miio.internal.MiIoSendCommand@95758d
20:59:15.113 [DEBUG] [ding.miio.handler.MiIoAbstractHandler] - Received response for 0F9B030E type: GET_STATUS, result: [{"msg_ver":2,"msg_seq":4205,"state":8,"battery":100,"clean_time":2065,"clean_area":30882500,"error_code":0,"map_present":1,"in_cleaning":0,"in_returning":0,"in_fresh_state":1,"lab_status":1,"fan_power":60,"dnd_enabled":0}], fullresponse: {"result":[{"msg_ver":2,"msg_seq":4205,"state":8,"battery":100,"clean_time":2065,"clean_area":30882500,"error_code":0,"map_present":1,"in_cleaning":0,"in_returning":0,"in_fresh_state":1,"lab_status":1,"fan_power":60,"dnd_enabled":0}],"id":139}
20:59:15.131 [TRACE] [rnal.transport.MiIoAsyncCommunication] - Connection 192.168.0.70:39634
20:59:15.138 [INFO ] [smarthome.event.ItemStateChangedEvent] - RoborockS5_Actions_ControlVacuum changed from vacuum to dock

and here it apparently resets the control item do “dock” based on received status.

And the command seemed to never even be sent to binding. As mentioned above, I tried to pretty much delete everything, items, thing, even uninstalled the binding, redid all again and it’s the same.

1148

Now it will seem like spamming, sorry for that. I rebooted my whole Openhab system and now it’s working. I’ll keep an eye on it and let you know how it goes.

1 Like
1149

Hi!
I have two types of lamps, YLDP01YL(yeelink.light.mono1) and YLDP02YL(yeelink.light.color1).
The first lamp does not know how to change the color temperature, it is fixed at 4000K.
But in PAPERUI, I see a Color Temperature channel:
image
image
And in the log file:

2019-12-03 16:09:16.120 [TRACE] [nal.transport.MiIoAsyncCommunication] - Received response from 192.168.215.51: {"result":["on","63","0","","2"],"id":93}
2019-12-03 16:09:16.121 [TRACE] [nal.transport.MiIoAsyncCommunication] - Received  JSON message {"result":["on","63","0","","2"],"id":93}
2019-12-03 16:09:16.123 [TRACE] [nal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.internal.handler.MiIoBasicHandler@59cda6, data org.openhab.binding.miio.internal.MiIoSendCommand@e717301 from org.openhab.binding.miio.internal.MiIoSendCommand@e717301
2019-12-03 16:09:16.124 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for white1 type: GET_PROPERTY, result: ["on","63","0","","2"], fullresponse: {"result":["on","63","0","","2"],"id":93}
2019-12-03 16:09:16.130 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Error updating miio:basic:white1 property colorTemperature with '' : null
2019-12-03 16:09:16.131 [TRACE] [io.internal.handler.MiIoBasicHandler] - Property update error detail:
java.lang.NumberFormatException: null
	at java.math.BigDecimal.<init>(BigDecimal.java:596) ~[?:1.8.0_191]
	at java.math.BigDecimal.<init>(BigDecimal.java:383) ~[?:1.8.0_191]
	at java.math.BigDecimal.<init>(BigDecimal.java:806) ~[?:1.8.0_191]
	at com.google.gson.JsonPrimitive.getAsBigDecimal(JsonPrimitive.java:208) ~[bundleFile:?]
	at org.openhab.binding.miio.internal.handler.MiIoBasicHandler.updateProperties(MiIoBasicHandler.java:411) [bundleFile:?]
	at org.openhab.binding.miio.internal.handler.MiIoBasicHandler.onMessageReceived(MiIoBasicHandler.java:450) [bundleFile:?]
	at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication$MessageSenderThread.run(MiIoAsyncCommunication.java:226) [bundleFile:?]
2019-12-03 16:09:16.136 [TRACE] [nal.transport.MiIoAsyncCommunication] - Connection 192.168.215.51:39119
2019-12-03 16:09:16.141 [TRACE] [nal.transport.MiIoAsyncCommunication] - Message Details:Message:

Did I configure something wrong? Or should it be ignored?
There are also two channels:
image
image
Can they be used somehow?
When switching the first, no information (TRACE) about the change event of this channel is displayed in the log.
Thanks!

1150

With the channel - Name, figured out:

YeeC_01_cmd.sendCommand("set_name [\"Color-01\"]")
1151

@Olymp there are many yeelight, with slightly different commands. It can be that your’s is not supporting the property.

GET_PROPERTY, result: ["on","63","0","","2"], the parsing error can be handled more gracefully by the binding. Maybe you can add it to the github as issue. It is not a config error on your side. The lamp is responding with a “” and I think the binding is expecting a number there.

I think this specific color parameter is working for a white light, but only on specific modes. The binding is not switching on/off the color channels based on the selected mode, hence in the other modes you would still see this channel regardless that it does not do anything.

1152

Yep, so rebooted in the evening, it stopped working during the night. So I rebooted it again today around 9:30, worked. I tested node-red automation, it worked as well. Then at 12 it stopped again, this time not only control but also updates (I have persistence on status and battery level and while the vacuum was charging I saw in Grafana that battery level stopped at 88% exactly at 12:00). I had debug logs running on miio binding, so here goes:
First, around 12:01 the updates are going on:

2019-12-03 12:01:20.010 [DEBUG] [nding.miio.handler.MiIoVacuumHandler] - Periodic update for 'miio:vacuum:0F9B030E' (miio:vacuum)
2019-12-03 12:01:20.010 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 0F9B030E type: STOP_VACUUM, result: ["ok"], fullresponse: {"result":["ok"],"id":687}
2019-12-03 12:01:20.011 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":690,"method":"get_dnd_timer","params":[]} -> 192.168.0.70 (Device: 0F9B030E token: redacted Queue: 3)
2019-12-03 12:01:20.011 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0F9B030E (192.168.0.70) success
2019-12-03 12:01:20.013 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0F9B030E (192.168.0.70)
2019-12-03 12:01:20.013 [TRACE] [nal.transport.MiIoAsyncCommunication] - Connection 192.168.0.70:56556
2019-12-03 12:01:20.013 [TRACE] [nal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@898ef5, data ONLINE from NONE
2019-12-03 12:01:20.025 [TRACE] [nal.transport.MiIoAsyncCommunication] - Connection 192.168.0.70:56556
2019-12-03 12:01:20.026 [TRACE] [nal.transport.MiIoAsyncCommunication] - Message Details:Message: (truncated for brevity)
2019-12-03 12:01:20.028 [TRACE] [nal.transport.MiIoAsyncCommunication] - Received response from 192.168.0.70: {"result":["ok"],"id":688}
2019-12-03 12:01:20.030 [TRACE] [nal.transport.MiIoAsyncCommunication] - Received  JSON message {"result":["ok"],"id":688}
2019-12-03 12:01:20.031 [TRACE] [nal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@898ef5, data org.openhab.binding.miio.internal.MiIoSendCommand@1a8cf35 from org.openhab.binding.miio.internal.MiIoSendCommand@1a8cf35
2019-12-03 12:01:20.031 [TRACE] [nal.transport.MiIoAsyncCommunication] - Message Details:Message:  (truncated for brevity)
2019-12-03 12:01:20.032 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 0F9B030E type: CHARGE, result: ["ok"], fullresponse: {"result":["ok"],"id":688}
2019-12-03 12:01:20.032 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0F9B030E (192.168.0.70) success
2019-12-03 12:01:20.033 [TRACE] [nal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@898ef5, data ONLINE from NONE
2019-12-03 12:01:20.034 [TRACE] [nal.transport.MiIoAsyncCommunication] - Connection 192.168.0.70:56556
2019-12-03 12:01:20.036 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":691,"method":"get_clean_summary","params":[]} -> 192.168.0.70 (Device: 0F9B030E token: redacted Queue: 2)
2019-12-03 12:01:20.038 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 0F9B030E (192.168.0.70)
2019-12-03 12:01:20.043 [TRACE] [nal.transport.MiIoAsyncCommunication] - Connection 192.168.0.70:56556
2019-12-03 12:01:20.044 [TRACE] [nal.transport.MiIoAsyncCommunication] - Message Details:Message:  (truncated for brevity)
2019-12-03 12:01:20.046 [TRACE] [nal.transport.MiIoAsyncCommunication] - Received response from 192.168.0.70: {"result":[{"msg_ver":2,"msg_seq":1117,"state":8,"battery":88,"clean_time":1701,"clean_area":26787500,"error_code":0,"map_present":1,"in_cleaning":0,"in_returning":0,"in_fresh_state":1,"lab_status":1,"fan_power":60,"dnd_enabled":0}],"id":689}
2019-12-03 12:01:20.047 [TRACE] [nal.transport.MiIoAsyncCommunication] - Received  JSON message {"result":[{"msg_ver":2,"msg_seq":1117,"state":8,"battery":88,"clean_time":1701,"clean_area":26787500,"error_code":0,"map_present":1,"in_cleaning":0,"in_returning":0,"in_fresh_state":1,"lab_status":1,"fan_power":60,"dnd_enabled":0}],"id":689}
2019-12-03 12:01:20.049 [TRACE] [nal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@898ef5, data org.openhab.binding.miio.internal.MiIoSendCommand@88120d from org.openhab.binding.miio.internal.MiIoSendCommand@88120d
2019-12-03 12:01:20.050 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 0F9B030E type: GET_STATUS, result: [{"msg_ver":2,"msg_seq":1117,"state":8,"battery":88,"clean_time":1701,"clean_area":26787500,"error_code":0,"map_present":1,"in_cleaning":0,"in_returning":0,"in_fresh_state":1,"lab_status":1,"fan_power":60,"dnd_enabled":0}], fullresponse: {"result":[{"msg_ver":2,"msg_seq":1117,"state":8,"battery":88,"clean_time":1701,"clean_area":26787500,"error_code":0,"map_present":1,"in_cleaning":0,"in_returning":0,"in_fresh_state":1,"lab_status":1,"fan_power":60,"dnd_enabled":0}],"id":689}
2019-12-03 12:01:20.051 [TRACE] [nal.transport.MiIoAsyncCommunication] - Message Details:Message:  (truncated for brevity)
2019-12-03 12:01:20.053 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 0F9B030E (192.168.0.70) success
2019-12-03 12:01:20.054 [TRACE] [nal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@898ef5, data ONLINE from NONE

Then suddenly there is a 4 minute gap (refresh interval is set to 15 seconds with 15 seconds timeout) and then this:

2019-12-03 12:05:48.935 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Receiver thread received SocketException: Socket closed
2019-12-03 12:05:48.935 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Getting new socket for discovery
2019-12-03 12:05:48.937 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Receiver thread ended
2019-12-03 12:05:48.938 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Starting discovery receiver thread for socket on port 54788
2019-12-03 12:05:48.938 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery sending ping to 192.168.0.255 from 0.0.0.0/0.0.0.0:54788
2019-12-03 12:05:48.945 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Thread Thread[Thread-210,5,main] waiting for data on port 54788
2019-12-03 12:05:48.947 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery sending ping to 224.0.0.50 from 0.0.0.0/0.0.0.0:54788
2019-12-03 12:05:48.950 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery sending ping to 224.0.0.1 from 0.0.0.0/0.0.0.0:54788
2019-12-03 12:05:49.001 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Received 32 bytes response from 192.168.0.70:54321 on Port 54788
2019-12-03 12:05:49.005 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery response received from 192.168.0.70 DeviceID: 0F9B030E (truncated for brevity)
2019-12-03 12:05:49.007 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery responses from : 192.168.0.70:21 31 00 20 00 00 00 00 0F 9B 03 0E 5D E6 41 8C FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
2019-12-03 12:05:49.014 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Thread Thread[Thread-210,5,main] waiting for data on port 54788
2019-12-03 12:05:49.016 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Received 32 bytes response from 192.168.0.70:54321 on Port 54788
2019-12-03 12:05:49.019 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Discovered Mi Device 0F9B030E (261817102) at 192.168.0.70 as miio:generic:0F9B030E
2019-12-03 12:05:49.019 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Discovery response received from 192.168.0.70 DeviceID: 0F9B030E (truncated for brevity)
2019-12-03 12:05:49.021 [TRACE] [iio.internal.discovery.MiIoDiscovery] - Thread Thread[Thread-210,5,main] waiting for data on port 54788
2019-12-03 12:05:49.021 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - No token discovered for device 0F9B030E. For options how to get the token, check the binding readme.

And this exact same discovery sequence keeps repeating every 10 minutes indefinitely without any other activity at all.

There is nothing else in the log. Log severity was set to debug as you requested.

So, any ideas?

1153

Suggest to put your refresh rate way slower. e.g. 1/minute.
Many devices will not sustain a high refresh rate, I have some yeelights that will freeze on such refresh rate. For the rest, indeed this log appears healthy.

eg. your 2nd line
2019-12-03 12:01:20.010 [DEBUG] [ing.miio.handler.MiIoAbstractHandler] - Received response for 0F9B030E type: STOP_VACUUM, result: ["ok"], fullresponse: {"result":["ok"],"id":687}

the vacuum appears to give a normal response that it accepted the command.

the discovery is indeed scheduled to run every 10 minutes. This scans for any new devices on the network. It is part of the regular auto discovery. Your device responds in the expected way to that.

Do you see any errors when the commands are not well processed? I was expecting e.g. timeouts, or not send at all, or not seen by the binding, garbage responses etc.

Here the device responds to every request it seems

1154

Suggest to put your refresh rate way slower. e.g. 1/minute.
Many devices will not sustain a high refresh rate, I have some yeelights that will freeze on such refresh rate.

I can try that. Default was 30 minutes, I just thought that was a little too slow for the automation but I’ll test with minute to see how it goes. But the vacuum didn’t freeze, it works, it’s just there is no communication.

Also, after that last line around 12:01 mark:
2019-12-03 12:01:20.054 [TRACE] [nal.transport.MiIoAsyncCommunication] - inform listener org.openhab.binding.miio.handler.MiIoVacuumHandler@898ef5, data ONLINE from NONE

The binding went silent until 12:05. There is no log between the last 12:01 log and the first 12:05 log. There’s not even the status request that should have ran every 15 seconds. That’s what bothers me, it’s as if something broke.

Anyway, I’ll try rebooting openhab again, setting the refresh to 60 seconds and see what happens.

1155

Again short question regarding Zone Cleanup…coordinates etc…

I know from a user that IOBroker / FHEM and HA use “set clean_segment”

They use the created and named rooms from XiHomeApp do do the cleaning. They dont need coordinates etc. - so they do room cleaning by name from Xiaomi APP

ref links here:

Just for my understanding - is that also like this implemented in OpenHab or could this be implemented ? @marcel_verpaalen

1156

it is not implemented that way in OH.
Your workaround would be to use the command channel and send app_segment_clean[your room nr] to it. To get your rooms you would use get_room_mapping[]
I don’t see right away how the real room names could be retrieved though.

1 Like
1157

Thank you for your very fast answer ! Ok but i could test it with every number from 1-XX and see/watch where the robot goes to ?

So if that will work - that would be the easyiest way to do seperate room cleaning - why nobody do this ? Whats the disadvantage ?

1158

ok i tried it and it really works great - my first test was

rule "test_sauger"
    when
    Item test_sauger received command
    then
    if (receivedCommand==ON){
    sendCommand(Xia_action_Command,"app_segment_clean[16]" )
    }
end

and it goes stright to my livingroom

3 Likes
1159

Hi, me again. So after two days of running fine the binding again stopped sending commands and requesting updates. There is just nothing in the log again apart from periodical discovery. I guess setting the period to absurdly long time would resolve the issue but kinda defeats the purpose, right? :slight_smile:
Any ideas?
Edit: after restarting openhab binding works again. Restarting just the binding didn’t do anything. I can have a cron job restart openhab every day but it’s not exactly ideal :confused:

1160

what did you have to install to make the command sendCommand(Xia_action_Command,“app_segment_clean[16]” ) work?
Is it python-miio? How is it installed in OH?