Xiaomi Mi Air Purifier (Xiaomi Mi IO)

You could see in the (debug) log if the device actually returns something.
Is this somewhere visible in the mihome app? Otherwise the more likely scenario is that the published spec is just wrong and the device does not really support it.

Hi Marcel, yes the value is available in the Xiaomi App.

Found the following in the debug log:

2021-06-14 23:44:53.925 [DEBUG] [internal.handler.MiIoAbstractHandler] - Received response for 1570C1D1 type: GET_PROPERTIES, result: [{"did":"temperature","siid":3,"piid":8,"code":0,"value":23.700001}], fullresponse: {"id":8808,"result":[{"did":"temperature","siid":3,"piid":8,"code":0,"value":23.700001}],"exe_time":244}
2021-06-14 23:44:53.925 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Unit 'celsius' used by 'miio:generic:1570C1D1' channel 'temperature' is not found in conversion table... Trying anyway to submit as the update.
2021-06-14 23:44:53.926 [DEBUG] [io.internal.handler.MiIoBasicHandler] - Error updating miio:generic:1570C1D1 property temperature with '23.700001' : java.lang.IllegalArgumentException: Invalid Quantity value: 23.700001 celsius

Item definition is as following:

Number:Temperature       Sf_ap_temperature                  "sleeping room [%.1f °C]"                           <temperature>     (gSf_airpurifier,gHeatAct)     {channel="miio:generic:1570C1D1:temperature"}

Thanks. The issue is clear to me now

1 Like

Hi @marcel_verpaalen,
I am getting a lot of WARN messages lately for one of my air purifiers:


Before I delete the thing and re-add, were there any other changes or will re-add fix it?
I am on 3.1 RC
Thanks!

I see such a message occasionally, but I never saw it persisting

Probably the easiest way to get rid of it is restarting the binding or openhab.

You can restart the binding by e.g
bundle:list | grep miio

Followed by a bundle:restart 234
Replace the 234 with the number identified with the first command.

If after restarting the message is persisting it requires bit deeper digging what is causing the issue.

Thanks, a bundle restart did not help. Will try a full OH restart tomorrow and report back.

Hi marcel,
thanks for keep updating the binding for us,
I recently try OH3 and I found below log pop out every few seconds in console,
is it possible that Error while polling/sending message turns to
Error while polling/sending message on deviceId=“12345678” or “Yeelight#1” and won’t show the lines start form java.lang, as I really have no idea which device cause these log, all things show online

22:12:14.247 [WARN ] [rnal.transport.MiIoAsyncCommunication] - Error while polling/sending message
java.lang.StringIndexOutOfBoundsException: index 9,length 9
        at java.lang.String.checkIndex(String.java:3278) ~[?:?]
        at java.lang.StringUTF16.checkIndex(StringUTF16.java:1470) ~[?:?]
        at java.lang.StringUTF16.charAt(StringUTF16.java:1267) ~[?:?]
        at java.lang.String.charAt(String.java:695) ~[?:?]
        at org.openhab.binding.miio.internal.Utils.hexStringToByteArray(Utils.java:59) ~[bundleFile:?]
        at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication.sendCommand(MiIoAsyncCommunication.java:309) ~[bundleFile:?]
        at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication.sendMiIoSendCommand(MiIoAsyncCommunication.java:177) ~[bundleFile:?]
        at org.openhab.binding.miio.internal.transport.MiIoAsyncCommunication$MessageSenderThread.run(MiIoAsyncCommunication.java:279) [bundleFile:?]

Did you ‘downgrade’ from a more recent version (3.2) to an older version perhaps (early version of 3.2 or 3.1)?

The deviceId changed in the latest version, if you would go back I expect this error. (would be solvable by removing the deviceId and let the binding auto fill it again)

no, I am at 3.1 from starting, I didn’t try 3.2 yet as stable version only at 3.1, I know the device id have changed again from hex to decimal, I made changes in xm.thing, do you mean in 3.2, there won’t be error message when poll fail?

I think that change is only needed in 3.2 , 3.1 is still the ‘the old one’. When you chane over to 3.2 the binding will make the change for you (or warns you in case of text config to make the change manual)

you are right, I think it was due to I installed a 3.2 miio binding for gateway v3 test purpose,
I try reinstall fresh oh3 and all warn log gone.

i have Mi Air Purifier 3C and OH 3.2.0 But don’t understand how to connect it. I find it inside inbox and add to OH “Thing menu” but when I open it settings channels it show me wrong channels.


It is because it appears as unsupported. You see the channels for unsupported devices.
Is the model the same when you expand the ‘things properties’.
Or did you update the device model string in your config? (the 3C models are notmally with mb rather ma)

In the latter case, you can try the 2 create experimental support channels. If you switch it the binding will try to make support for your device.
Be sure to share the files, so we can implement it in the regular release

Thx for reply

yes, the model that OH find is correct to model on the packege box (full model is Xiaomi Mi Air Purifier 3C BHR4518GL)

yes, I try many different “model strings” from Xiaomi Wifi devices (Mi IO) - Bindings | openHAB documentation. The default name in Mi home App/OH inbox is zhimi.airp.mb4a Maybe device is to new for OH? - on box manufactured in 13.08.2021

Is there more information? - I create these channels with “experimental support”, but what next?

Yes, your device is too new.
you can try this file. See readme on how to use/install.
Please confirm which channels work/not work and share a debug log with refresh

zhimi.airp.mb4a-miot.json (6.1 KB)

Where I can find readme (about placing your file). Also, I find this information from experimental channel file test-zhimi.airp.mb4a-20211201-100007.txt (32.3 KB) Is this the correct file for adding support? - I find it here openHAB-userdata\miio

Hi all,

Got a quick question. After doing some changes to my purifier (changed IP), I somehow get the following WARN log messages every 20 seconds even though the log level is set to INFO on the miio binding (and I did a bundle:restart org.openhab.binding.miio):

Any idea why this is happening?

EDIT: I do not see this behavior with my H Pro purifier neither with my Roborock. My config:

EDIT: Looks like a OH restart (or/and OH update to latest milestone solved it)

I’m having a question regarding the supported device “deerma.humidifier.jsq”.
This is a smart Sterilization Humidifier.
According to the Xiaomi App and python-miio this device (at least with firmware 2.0.7) has the following additional sensors:
TemperaturValue and waterstatus

How can I help to support these two sensor values in openhab?

This is the debug output from python-miio (some data replaced with [
]):

INFO:miio.cli:Debug mode active
DEBUG:miio.click_common:Unknown model, trying autodetection. None None
DEBUG:miio.miioprotocol:Got a response: Container: 
    data = Container: 
        data = b'' (total 0)
        value = b'' (total 0)
        offset1 = 32
        offset2 = 32
        length = 0
    header = Container: 
        data = b'!1\x00 \x00\x00\x00\x00\x0e\x9d\x97\xe2\x00&w\x14' (total 16)
        value = Container: 
            length = 32
            unknown = 0
            device_id = unhexlify('0e9d97e2')
            ts = 1970-01-30 04:14:12
        offset1 = 0
        offset2 = 16
        length = 16
    checksum = [...] (total 16)
DEBUG:miio.miioprotocol:Discovered 0e9d97e2 with ts: 1970-01-30 04:14:12, token: [...]
DEBUG:miio.miioprotocol:192.168.2.29:54321 >>: {'id': 1, 'method': 'miIO.info', 'params': []}
DEBUG:miio.miioprotocol:192.168.2.29:54321 (ts: 1970-01-30 04:14:12, id: 1) << {'id': 1, 'result': {'life': 2520852, 'uid': 6437992445, 'model': 'deerma.humidifier.jsq', 'token': [...], 'ipflag': 1, 'fw_ver': '2.0.7', 'mcu_fw_ver': '0113', 'miio_ver': '0.0.8', 'hw_ver': 'esp8266', 'mmfree': 24668, 'mac': '[...]', 'wifi_fw_ver': '2709610', 'ap': {'ssid': '[...]', 'bssid': '[...]', 'rssi': -43, 'primary': 1}, 'netif': {'localIp': '192.168.2.29', 'mask': '255.255.255.0', 'gw': '192.168.2.1'}}, 'exe_time': 40}
DEBUG:miio.device:Detected model deerma.humidifier.jsq
DEBUG:miio.miioprotocol:192.168.2.29:54321 >>: {'id': 2, 'method': 'get_prop', 'params': ['OnOff_State']}
DEBUG:miio.miioprotocol:192.168.2.29:54321 (ts: 1970-01-30 04:14:13, id: 2) << {'id': 2, 'result': [0], 'exe_time': 360}
DEBUG:miio.miioprotocol:192.168.2.29:54321 >>: {'id': 3, 'method': 'get_prop', 'params': ['TemperatureValue']}
DEBUG:miio.miioprotocol:192.168.2.29:54321 (ts: 1970-01-30 04:14:13, id: 3) << {'id': 3, 'result': [27], 'exe_time': 530}
DEBUG:miio.miioprotocol:192.168.2.29:54321 >>: {'id': 4, 'method': 'get_prop', 'params': ['Humidity_Value']}
DEBUG:miio.miioprotocol:192.168.2.29:54321 (ts: 1970-01-30 04:14:14, id: 4) << {'id': 4, 'result': [37], 'exe_time': 520}
DEBUG:miio.miioprotocol:192.168.2.29:54321 >>: {'id': 5, 'method': 'get_prop', 'params': ['HumiSet_Value']}
DEBUG:miio.miioprotocol:192.168.2.29:54321 (ts: 1970-01-30 04:14:14, id: 5) << {'id': 5, 'result': [45], 'exe_time': 530}
DEBUG:miio.miioprotocol:192.168.2.29:54321 >>: {'id': 6, 'method': 'get_prop', 'params': ['Humidifier_Gear']}
DEBUG:miio.miioprotocol:192.168.2.29:54321 (ts: 1970-01-30 04:14:15, id: 6) << {'id': 6, 'result': [4], 'exe_time': 540}
DEBUG:miio.miioprotocol:192.168.2.29:54321 >>: {'id': 7, 'method': 'get_prop', 'params': ['Led_State']}
DEBUG:miio.miioprotocol:192.168.2.29:54321 (ts: 1970-01-30 04:14:16, id: 7) << {'id': 7, 'result': [1], 'exe_time': 540}
DEBUG:miio.miioprotocol:192.168.2.29:54321 >>: {'id': 8, 'method': 'get_prop', 'params': ['TipSound_State']}
DEBUG:miio.miioprotocol:192.168.2.29:54321 (ts: 1970-01-30 04:14:16, id: 8) << {'id': 8, 'result': [0], 'exe_time': 250}
DEBUG:miio.miioprotocol:192.168.2.29:54321 >>: {'id': 9, 'method': 'get_prop', 'params': ['waterstatus']}
DEBUG:miio.miioprotocol:192.168.2.29:54321 (ts: 1970-01-30 04:14:16, id: 9) << {'id': 9, 'result': [1], 'exe_time': 240}
DEBUG:miio.miioprotocol:192.168.2.29:54321 >>: {'id': 10, 'method': 'get_prop', 'params': ['watertankstatus']}
DEBUG:miio.miioprotocol:192.168.2.29:54321 (ts: 1970-01-30 04:14:16, id: 10) << {'id': 10, 'result': [1], 'exe_time': 250}
Power: off
Mode: OperationMode.Humidity
Temperature: 27 °C
Humidity: 37 %
LED: True
Buzzer: False
Target humidity: 45 %
No water: False
Water tank detached: False
Wet protection: None

As you can see, the result includes temperature and “No water” sensors.

I tried to override the model with another one which supports temperature and water status (
jsp5) with no success.
I also tried to understand the way to configure these two params in the database, but didn’t find a way.

Can I help to support these two sensors?

Many thanks,
Thomas.

You best download openhab-addons/bundles/org.openhab.binding.miio/src/main/resources/database/deerma.humidifier.mjjsq.json at main · openhab/openhab-addons · GitHub

and edit it by adding a section for both parameters e.g.

{
				"property": "waterstatus",
				"friendlyName": "water Status",
				"channel": "waterstatus",
				"type": "Number",
				"stateDescription": {
					"pattern": "%.0f",
					"readOnly": true
				},
				"refresh": true,
				"actions": []
			}

you can make it better by adding the mapping

"stateDescription": {
					"options": [
						{
							"value": "1",
							"label": "No Water"
						},
						{
							"value": "2",
							"label": "whatever this may be"
						}
					]
				},

than add db file in the misc/miio folder and restart the binding/openhab (see readme for bit more details)