Damn, sorry marcel, my error.
I hadn’t check the channel names for the mb3 model, and I see they now use upper case. I have’t checked everything yet but that appears to be the problem.
yes, the 3H works perfectly with the zhimi.airpurifier.mb3 model.
Apologies to have bothered you marcel. Thanks again for your help.
I recently just upgrade to 2.5 .6 from 2.5.0, I have set config files from miio:basic:xxxxxx to miio:basic:xxxxxx:light, everything is work as expect except one thing, I found brightness was changed from eg: 56 to 0.56 (1-100 to 0.01 -1), Is this change by purpose or mistake?
Hi Marcel, sorry to trouble you again, I have finally gotten around to trying what you recommended, it appears that the binding is still unable to find the file, i have done the chmod command recommended, as well as sudo chown openhab /etc/openhab2/misc/miio/deerma.humidifier.mjjsq.json
It is by design… Please note that the type also changed from a number to a dimmer.
This was as many folks experienced issues and wanted to use it as a dimmer together with like Alexa etc
thank you, as currently I use proxy brightness and update/command by rules to perform on/off when 0, does brightness now support power off when value as 0?
@emrys I don’t know how to further debug it. Looks like the location is right, but somehow the binding is not seeing it.
Your screenshot looks like the log without debugging info, enable that might give some more details
Indeed, that is also fixed with this new feature. You can send an Off to the channel and it will indeed power off
wow, that would be awesome, I will try it as soon as I get to home. thank you marcel
Dear @marcel_verpaalen
New changes is awesome, highly appreciated for the changes, the only thing still missing parts for lighting on binding is once detect “Power” is off, overide brightness value as 0,currently I think it will confuse user or even alexa that light is still on when check status.
Hey guys, I just noticed that the Purifier 2S disappeared from my Xiaomi App and I can only add it again if I change the country from China to e.g. Germany.
At the same time in OH the rules (switching on at 6:30, switching off when a window opens) work, but turning it on via switch or turning it off with the Expire binding, doesn’t. The purifier thing is shown online in Paper UI though.
Could there be an issue due to the CN setting in the binding in Paper UI and me not being able to add it to the app with the country set to CN?
no, the binding is in no way controlling to which server your device is connected.
This just means that it queries the selected servers for which devices are defined there. (hence you can even leave it blank as it will then query all known servers… it is just slightly less efficient as just querying the ones your devices are actually connected to)
On item level it also has the country, but it is only used for the vacuum devices (to know where to pull the map from)
I noticed that my token stays the same, even though I reset the wifi.
Checking the debug log I see that I get that padding error again…
2020-08-09 14:37:00.966 [DEBUG] [l.discovery.MiIoDiscoveryParticipant] - mDNS zhimi-airpurifier-mc1 identified as thingtype miio:basic with did 07FC1DF2 (133963250)
2020-08-09 14:37:01.274 [hingStatusInfoChangedEvent] - 'miio:generic:07FC1DF2' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to INITIALIZING
2020-08-09 14:37:01.348 [DEBUG] [internal.handler.MiIoAbstractHandler] - Initializing Mi IO device handler 'miio:generic:07FC1DF2' with thingType miio:generic
2020-08-09 14:37:01.358 [DEBUG] [internal.handler.MiIoAbstractHandler] - Polling job scheduled to run every 30 sec. for 'miio:generic:07FC1DF2'
2020-08-09 14:37:01.365 [hingStatusInfoChangedEvent] - 'miio:generic:07FC1DF2' changed from INITIALIZING to OFFLINE
2020-08-09 14:37:01.364 [DEBUG] [.internal.handler.MiIoGenericHandler] - Refreshing miio:generic:07FC1DF2:actions#power
2020-08-09 14:37:01.368 [DEBUG] [internal.handler.MiIoAbstractHandler] - Ping Mi device 07FC1DF2 at 192.168.178.21
2020-08-09 14:37:01.371 [DEBUG] [.internal.handler.MiIoGenericHandler] - Refreshing miio:generic:07FC1DF2:actions#testcommands
2020-08-09 14:37:01.376 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 07FC1DF2 (192.168.178.21)
2020-08-09 14:37:01.391 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 07FC1DF2 (192.168.178.21) success
2020-08-09 14:37:01.395 [DEBUG] [internal.handler.MiIoAbstractHandler] - Ping response from device 07FC1DF2 at 192.168.178.21. Time stamp: 1970-01-01T01:22:32, OH time 2020-08-09T14:37:01.395, delta -1596975269
2020-08-09 14:37:01.398 [DEBUG] [internal.handler.MiIoAbstractHandler] - Skipping periodic update for 'miio:generic:07FC1DF2'. No Connection
2020-08-09 14:37:01.402 [DEBUG] [.internal.handler.MiIoGenericHandler] - Periodic update for 'miio:generic:07FC1DF2' (miio:generic)
2020-08-09 14:37:01.406 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":1,"method":"miIO.info","params":[]} -> 192.168.178.21 (Device: 07FC1DF2 token: 192FFD06XXXXXXXXXXXXXXXX37B93AD5 Queue: 1)
2020-08-09 14:37:01.409 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 07FC1DF2 (192.168.178.21)
2020-08-09 14:37:01.426 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 07FC1DF2 (192.168.178.21) success
2020-08-09 14:37:01.443 [hingStatusInfoChangedEvent] - 'miio:generic:07FC1DF2' changed from OFFLINE to ONLINE
2020-08-09 14:37:01.497 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Send command '{"id":1,"method":"miIO.info","params":[]}' -> 192.168.178.21 (Device: 07FC1DF2) gave error Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
2020-08-09 14:37:01.500 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 07FC1DF2 type: MIIO_INFO, result: {}, fullresponse: {"error":"Given final block not properly padded. Such issues can arise if a bad key is used during decryption."}
2020-08-09 14:37:02.718 [DEBUG] [internal.handler.MiIoAbstractHandler] - Ping Mi device 07FC1DF2 at 192.168.178.21
2020-08-09 14:37:02.722 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 07FC1DF2 (192.168.178.21)
2020-08-09 14:37:02.744 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 07FC1DF2 (192.168.178.21) success
2020-08-09 14:37:02.747 [DEBUG] [internal.handler.MiIoAbstractHandler] - Ping response from device 07FC1DF2 at 192.168.178.21. Time stamp: 1970-01-01T01:22:33, OH time 2020-08-09T14:37:02.747, delta -1596975269
2020-08-09 14:37:05.596 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Discovered Mi Device 07FC1DF2 (133963250) at 192.168.178.21 as miio:generic:07FC1DF2
2020-08-09 14:37:05.599 [DEBUG] [iio.internal.discovery.MiIoDiscovery] - Discovered token for device 07FC1DF2: 192ffd06188afb0317ad6e9537b93ad5
2020-08-09 14:37:11.358 [DEBUG] [.internal.handler.MiIoGenericHandler] - Periodic update for 'miio:generic:07FC1DF2' (miio:generic)
2020-08-09 14:37:11.377 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Command added to Queue {"id":2,"method":"miIO.info","params":[]} -> 192.168.178.21 (Device: 07FC1DF2 token: 192FFD06XXXXXXXXXXXXXXXX37B93AD5 Queue: 1)
2020-08-09 14:37:11.380 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Sending Ping 07FC1DF2 (192.168.178.21)
2020-08-09 14:37:11.388 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Ping 07FC1DF2 (192.168.178.21) success
2020-08-09 14:37:11.439 [DEBUG] [nal.transport.MiIoAsyncCommunication] - Send command '{"id":2,"method":"miIO.info","params":[]}' -> 192.168.178.21 (Device: 07FC1DF2) gave error Given final block not properly padded. Such issues can arise if a bad key is used during decryption.
2020-08-09 14:37:11.441 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 07FC1DF2 type: MIIO_INFO, result: {}, fullresponse: {"error":"Given final block not properly padded. Such issues can arise if a bad key is used during decryption."}
I also tried reading out the token using this guide -> http://sns.wifi-town.com/topic/2/obtain-mi-home-device-token, which gives me a different one, but that still doesn’t work and the binding keeps showing the old token (192…).
Do you have any idea what could be the issue here?
2 thoughts…
- The binding is caching the token… if I remember well about 10min … so, just after resetting it may still provide the old one
- did you connect it to a new server… without deleting it from the first, than the binding may still select the token from the old server.
Suggest to delete the token from the config and restart the binding to ensure it pulls the latest token.
So for some strange reason my Air Purifier could only be found by the app when selecting Germany as country. All my other Xiaomi stuff used Mainland China and therefore I also used server=CN in the binding.
Once I changed that to DE I got a new token and could actually use it in OH.
That does mean though that I needed to switch the vaccum robot over to DE and get a new token, but thats alright.
Thanks for pointing me in the right direction.
Some devices are region locked, hence you cannot add them to all country servers.
You can define multiple servers in OH, e.g. de,cn in your case. separate them with comma.
No need to add all devices to the same county server. (it might not even be possible depending on the mix of Xiaomi devices)
1 Like
Hi everyone,
I read through the thread and it seems that the 3H model is supported, but I didn’t see a mention of the 2H model. Is that currently supported? (I’m currently mulling over whether to buy one).
Thanks.
to see if that one is supported you best google what is the modelId for that model. Than you can see in the binding readme if it is supported.
Unfortunately the commercial names and the technical model are not aligned. Having said that, there is little differences between the models, hence in most cases even if the mode is not supported the majority of channels will work
Thanks Marcel.
On Amazon it says the model is AC-M4-AA. It also calls it 2s rather than 2H. 2s is mentioned in the miio readme, so it looks like it’s supported. Thanks!
I have a 2H and it is working and should have been added as far as I understand
1 Like