In the end I’ve opted for the 3H, so there shouldn’t be any problems. I’ll let you know how it goes.
OH did recognise the 3H, but I’ve actually decided to return it, so I didn’t get as far as obtaining the token to be able to test it.
Hello.
I migrated to docker and OH 2.5.9 recently (not sure if this is relevant) and my purifier thing stopped working. I tried to solve the issue by reconnecting the device to wifi, using cloud user/password. The binding is able to discover new basic thing with token, but after adding it, fails connecting to it:
2020-10-18 12:09:43.667 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping xxxxxxxx (192.168.20.15)
2020-10-18 12:09:43.668 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Opening socket on port: 38897
2020-10-18 12:09:43.668 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Starting Mi IO MessageSenderThread
2020-10-18 12:09:58.683 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Communication error for Mi device at 192.168.20.15: Receive timed out
2020-10-18 12:09:58.683 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping xxxxxxxx (192.168.20.15)
2020-10-18 12:10:13.699 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Communication error for Mi device at 192.168.20.15: Receive timed out
2020-10-18 12:10:13.699 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping xxxxxxxx (192.168.20.15)
2020-10-18 12:10:28.718 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Communication error for Mi device at 192.168.20.15: Receive timed out
2020-10-18 12:10:28.718 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping xxxxxxxx (192.168.20.15) failed
2020-10-18 12:10:28.718 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Closing socket for port: 38897
I can ping this address from the container:
PING 192.168.20.15 (192.168.20.15) 56(84) bytes of data.
64 bytes from 192.168.20.15: icmp_seq=1 ttl=254 time=401 ms
64 bytes from 192.168.20.15: icmp_seq=2 ttl=254 time=2.07 ms
64 bytes from 192.168.20.15: icmp_seq=3 ttl=254 time=2.03 ms
64 bytes from 192.168.20.15: icmp_seq=4 ttl=254 time=1.99 ms
64 bytes from 192.168.20.15: icmp_seq=5 ttl=254 time=1.89 ms
64 bytes from 192.168.20.15: icmp_seq=6 ttl=254 time=1.87 ms
64 bytes from 192.168.20.15: icmp_seq=7 ttl=254 time=1.89 ms
64 bytes from 192.168.20.15: icmp_seq=8 ttl=254 time=1.93 ms
^C
--- 192.168.20.15 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 1.865/51.796/400.718/131.880 ms
Does anybody know what is wrong? What can I do to solve this issue?
The device is indeed on the address, you can see it as both manual ping as well as the ping from the binding works fine.
There are 3 possible issues that come to mind.
-
the token is wrong, is not very likely but still can happen.
This can happen e.g. if your device is defined on multiple country servers. The binding may pull the token from the wrong country server. If you define only the country that the device is on in the binding config page (where the cloud userid/pwd is enterd) this should pull the right token. -
you have the same device added multiple times.
The communication each time send a sequential number. If the device is twice defined, the numbers received by the device are no longer sequential and it will stop responding for some time. -
The connection is not too good, so you have timeouts etc.
Position your device closer to wifi / check in the mihome app if the wifi strength is good enough
I forgot to add, that I am able to control the device using Mi Home.
I can try all the servers, is there a list of all Mi Home servers?
This is very likely. I added it some time ago and removed Mi Home app after that. After I realized it has troubles to communicate with OH, I installed the app, logged in (but not sure if this was the same account) and there was no device on the list. So I added it once again, by pressing both buttons for 3 seconds. I thought it resets the device completely, but now I have doubts.
I don’t think so, I can control it from Mi Home without any problems.
You can leave the list empy… than It will try all known ones.
If you have defined the item on multiple servers, you can logon again on the server you don’t want and remove the device. Until it is defined only on a single server.
You can check the files in /userdata/miio folder, as there the responses of the various servers are stored
I have it empty already.
But it seems it is only on “de” server. What if the device is defined also on other account? Is this relevant?
It seems the device is on “de” server only:
-rw-r--r-- 1 openhab openhab 46 2020-10-18 15:22 miioTokens-cn.json
-rw-r--r-- 1 openhab openhab 716 2020-10-18 15:22 miioTokens-de.json
-rw-r--r-- 1 openhab openhab 46 2020-10-18 13:37 miioTokens-ru.json
-rw-r--r-- 1 openhab openhab 46 2020-10-18 15:22 miioTokens-sg.json
-rw-r--r-- 1 openhab openhab 46 2020-10-18 15:22 miioTokens-tw.json
-rw-r--r-- 1 openhab openhab 46 2020-10-18 15:22 miioTokens-us.json
I never tried, but I think it is relevant. I expect that if it is defined with a different userId, it also gets a new token. In that case, remove it from one of the accounts.
The cloud functionality is only used to get the token, so if you want it with a different account, simply logon with that account, let it find the right token and save it in your device config. Than logon with the old account. As long as the device is not also on the old account, the token won’t be overwritten.
Again. I think I have just one account. But it is possible that I had another account and registered this device on the other account before. But I am not using this account anymore, I don’t remember email, password, etc.
What I have done today:
- installed Mi Home app,
- used “Forgot password” for the email I was convinced is the right one,
- after I logged in to the app there was no devices on the list,
- I registered the device using 2 buttons which disconnected it from my wifi and connected it again,
- configured user name and password in the binding configuration.
- new thing has been discovered with token, but affter adding it, the thing is offline because of mentioned ping timeouts.
So I wasn’t able to remove the device from the app before I added it again, because device list was empty I after I logged in. Maybe I was using some other account, it is possible, but the one I am using now is not new, because it is not created today. I just forgot password.
Looks like you did all the right things to get it connected again.
I’m bit out of suggestions indeed.
I would do as last possible steps: check once more if the item is really not defined twice in OH.
If you defined with text file config, delete it, try to get it working with paperUI first.
Go in to the thing definition, delete the token
restart Openhab (to be 100% sure it pulls the latest & greatest token, and it is not coming from cache)
If that fails, maybe send in PM a larger portion of the binding debug log, including the start of the binding and at least a refresh, maybe I can see something odd… but as long as the device is not responding it is hard to find cause.
I did some test (thanks for the tips) and definitely this is a network issue as OH and Purifier device are in different subnets. It used to work some time ago, either changes to my network configuration I did caused the issues or something else has changed and makes troubles.
Anyway I need to solve this on my own. Thanks @marcel_verpaalen for all your help.
Continuing the discussion from Xiaomi Mi Air Purifier (Xiaomi Mi IO):
Hi All, I’ve come across a problem (OH 2.5.9) with Xiaomi binding and Mi Air Purifier 2S device.
The power command seems not to work properly for me. When it receives ON (through the paper or bacis GUI), it powers the device on, however almost immediately the status is changed to OFF (see below) - same happens with OFF command:
2020-10-21 12:22:37.944 [ome.event.ItemCommandEvent] - Item ‘power_1’ received command ON
2020-10-21 12:22:37.947 [nt.ItemStatePredictedEvent] - power_1 predicted to become ON
2020-10-21 12:22:37.960 [vent.ItemStateChangedEvent] - power_1 changed from OFF to ON
2020-10-21 12:22:38.112 [vent.ItemStateChangedEvent] - power_1 changed from ON to OFF
2020-10-21 12:22:44.792 [ome.event.ItemCommandEvent] - Item ‘power_1’ received command OFF
2020-10-21 12:22:44.796 [nt.ItemStatePredictedEvent] - power_1 predicted to become OFF
2020-10-21 12:22:44.814 [vent.ItemStateChangedEvent] - power_1 changed from ON to OFF
2020-10-21 12:22:44.867 [vent.ItemStateChangedEvent] - power_1 changed from OFF to ON
The thing is configured as generic (miio:generic:04CFXXXX:power) Any idea what I did wrong ? Thanks …
Can you share a debug log file. What is the exact model you see in the device properties?
Is the command working at all? (meaning does the device switch on/off or not at all) or it does nothing. If you change the on/off in the mihome app, does Openhab ‘follow’?
I can’t see any DEBUG messages in the log file (only INFO messages), despite the TRACE level is set.
The exact model I see is:
Xiaomi Mi Basic Device
|hardwareVersion|MW300|
|modelId|zhimi.airpurifier.mc1|
|Vendor|Xiaomi|
|wifiFirmware|SD878x-14.76.36.p84-702.1.0-WM|
The power command works - after sending ON, the devices turns ON, however the OH2 control values changes to OFF, despite the fact the device is still in ON status. Toggling to ON again (2nd or 3rd time) normally keeps the device ON and the OH2 control value is ON. Same to the other direction (when sending OFF).
Now, what I noticed - the device status is properly displayed in the Mio App and all control functions work very well from the App. However if the power state is changed from the App, it’s not propagated to OH2.
Some more logs:
11:46:53.107 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘power_2’ received command OFF
11:46:53.113 [INFO ] [arthome.event.ItemStatePredictedEvent] - power_2 predicted to become OFF
11:46:53.132 [INFO ] [smarthome.event.ItemStateChangedEvent] - power_2 changed from ON to OFF
11:46:53.286 [INFO ] [smarthome.event.ItemStateChangedEvent] - power_2 changed from OFF to ON
11:46:56.649 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘power_2’ received command OFF
11:46:56.654 [INFO ] [arthome.event.ItemStatePredictedEvent] - power_2 predicted to become OFF
11:46:56.695 [INFO ] [smarthome.event.ItemStateChangedEvent] - power_2 changed from ON to OFF
11:46:57.596 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘power_2’ received command ON
11:46:57.622 [INFO ] [arthome.event.ItemStatePredictedEvent] - power_2 predicted to become ON
11:46:57.646 [INFO ] [smarthome.event.ItemStateChangedEvent] - power_2 changed from OFF to ON
11:47:02.570 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘power_2’ received command OFF
11:47:02.575 [INFO ] [arthome.event.ItemStatePredictedEvent] - power_2 predicted to become OFF
11:47:02.593 [INFO ] [smarthome.event.ItemStateChangedEvent] - power_2 changed from ON to OFF
11:47:05.824 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘power_2’ received command ON
11:47:05.831 [INFO ] [arthome.event.ItemStatePredictedEvent] - power_2 predicted to become ON
11:47:05.850 [INFO ] [smarthome.event.ItemStateChangedEvent] - power_2 changed from OFF to ON
11:47:07.077 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘power_2’ received command OFF
11:47:07.083 [INFO ] [arthome.event.ItemStatePredictedEvent] - power_2 predicted to become OFF
11:47:07.147 [INFO ] [smarthome.event.ItemStateChangedEvent] - power_2 changed from ON to OFF
Item: Switch power_2 “Power AP” (G_airpurifier_2) {channel=“miio:generic:04CFC549:power”}
Thanks …
Same here
2020-10-22 14:34:04.730 [ome.event.ItemCommandEvent] - Item ‘MijaSmartHumidifier_Power’ received command ON
2020-10-22 14:34:04.737 [nt.ItemStatePredictedEvent] - MijaSmartHumidifier_Power predicted to become ON
2020-10-22 14:34:04.764 [vent.ItemStateChangedEvent] - MijaSmartHumidifier_Power changed from OFF to ON
2020-10-22 14:34:05.207 [vent.ItemStateChangedEvent] - MijaSmartHumidifier_Power changed from ON to OFF
Can you please share a debug log file. There is little I can analyse with just the info log.
you can enable it by typing log:set debug org.openhab.binding.miio
than log:tail org.openhab.binding.miio
Also, did this happen just after the update, did it work before? If so, from which version you were coming?
Hi,
I moved from RP (OH2.4.x) where it worked fine and did fresh OH2 installation, adding all things from scratch (to avoid issues).
Below some more logs:
==> /var/log/openhab2/events.log <==
2020-10-22 18:40:52.721 [ome.event.ItemCommandEvent] - Item ‘power_2’ received command ON
2020-10-22 18:40:52.726 [nt.ItemStatePredictedEvent] - power_2 predicted to become ON
==> /var/log/openhab2/openhab.log <==
2020-10-22 18:40:52.732 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Locating action for channel ‘power’: ‘ON’
==> /var/log/openhab2/events.log <==
2020-10-22 18:40:52.743 [vent.ItemStateChangedEvent] - power_2 changed from OFF to ON
==> /var/log/openhab2/openhab.log <==
2020-10-22 18:40:52.744 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Sending command set_power[“on”]
2020-10-22 18:40:52.750 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:834,“method”:“set_power”,“params”:[“on”]} -> 10.192.168.220 (Device: 04CFC549 token: 3F7AEC24XXXXXXXXXXXXXXXX15B61F1D Queue: 1)
2020-10-22 18:40:52.756 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Periodic update for ‘miio:generic:04CFC549’ (miio:basic)
2020-10-22 18:40:52.760 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:835,“method”:“get_prop”,“params”:[“power”,“mode”,“humidity”,“aqi”,“average_aqi”]} -> 10.192.168.220 (Device: 04CFC549 token: 3F7AEC24XXXXXXXXXXXXXXXX15B61F1D Queue: 2)
2020-10-22 18:40:52.767 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:836,“method”:“get_prop”,“params”:[“led”,“buzzer”,“f1_hour”,“f1_hour_used”,“use_time”]} -> 10.192.168.220 (Device: 04CFC549 token: 3F7AEC24XXXXXXXXXXXXXXXX15B61F1D Queue: 3)
2020-10-22 18:40:52.773 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:837,“method”:“get_prop”,“params”:[“motor1_speed”,“filter1_life”,“favorite_level”,“temp_dec”,“purify_volume”]} -> 10.192.168.220 (Device: 04CFC549 token: 3F7AEC24XXXXXXXXXXXXXXXX15B61F1D Queue: 4)
2020-10-22 18:40:52.776 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {“id”:838,“method”:“get_prop”,“params”:[“child_lock”]} -> 10.192.168.220 (Device: 04CFC549 token: 3F7AEC24XXXXXXXXXXXXXXXX15B61F1D Queue: 5)
2020-10-22 18:40:52.814 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 04CFC549 type: SET_POWER, result: [“ok”], fullresponse: {“result”:[“ok”],“id”:834}
2020-10-22 18:40:52.831 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 04CFC549 type: GET_PROPERTY, result: [“off”,“silent”,51,8,7], fullresponse: {“result”:[“off”,“silent”,51,8,7],“id”:835}
2020-10-22 18:40:52.849 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 04CFC549 type: GET_PROPERTY, result: [“on”,“on”,3500,2032,null], fullresponse: {“result”:[“on”,“on”,3500,2032,null],“id”:836}
2020-10-22 18:40:52.854 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Transformed with ‘SecondsToHours’: Filter Hours used 2032 -> 0
2020-10-22 18:40:52.857 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Property ‘use_time’ returned null (is it supported?).
2020-10-22 18:40:52.872 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 04CFC549 type: GET_PROPERTY, result: [0,41,14,224,null], fullresponse: {“result”:[0,41,14,224,null],“id”:837}
2020-10-22 18:40:52.875 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Transformed with ‘/10’: Temperature 224 -> 22.4
2020-10-22 18:40:52.881 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Property ‘purify_volume’ returned null (is it supported?).
==> /var/log/openhab2/events.log <==
2020-10-22 18:40:52.890 [vent.ItemStateChangedEvent] - power_2 changed from ON to OFF
==> /var/log/openhab2/openhab.log <==
2020-10-22 18:40:52.895 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 04CFC549 type: GET_PROPERTY, result: [“off”], fullresponse: {“result”:[“off”],“id”:838}
Maybe indeed the device is not fast enough… and needs a delay.
The cause is indeed clear: see these 2 responses:
It first responds with ok on the power ON command , BUT then the following line is the status request, there it responds that the power is OFF. (first property). This is causing the flipping back in the UI. Am I right to assume that within the following +/- 30 seconds it will flip once more?
Unfortunately not, the status remain unchanged, although the device is in the desired state.
Indeed, adding a delay to the status response might help - would you pls explain howto ? 