[miio] Fix Qingping Air Monitor (cgllc.airmonitor.s1) support

[mak-42]

[miio] Qingping Air Monitor (cgllc.airmonitor.s1) support is broken #13258

1. Custom refresh command for "battery" was defined . The device with "4.1.8_9999" firmware version does not allowed to obtain this information by this way which prevents to obtain other values. The solution should work for both old firmware (the battery information would be requested as before) and it does not prevent the device with new firmware from sending other values (I checked it).

fix #13258

[marcelrv]

I don't really understand how this is fixing the problem. The command send to the device should be the same.
Can you try lowering the maxPropertiesinstead, e.g. to 3 to see if the amount of properties has impact.
If that does not work, can you try with maxProperties 1 which I think should also work. (in that case however your PR may be a better solution though)

[mak-42]

I described the problem in the correspondent issue. The device with firmware "4.1.8_9999" stops recognizing parameter "battery" in "get_value" command and returns "result":"ok" in the response instead of values if the parameter exists. I split the request for values into two requests: the first one for all the parameters ("pm25","co2","tvoc","humidity","temperature") except "battery" and another one for "battery" parameter. It allows to obtain all values except "battery" from the device with firmware "4.1.8_9999" and obtain all the values from the device with old firmware versions.

[marcelrv]

Yes, I understood your description.
But there can be 2 causes of the issue:

1. the battery is not recognized anymore in the new FW
2. the amount of properties that can be requested in 1 request has changed in the new FW.

I would like to ensure the 2nd option is not the cause as in that case the lowering of maxProperties would do the trick as well in a better way.

[mak-42]

The device does not recognized request for battery value any more. I sent get_value["battery"] to device and received {"id":11974,"result":"ok","exe_time":32} from it. After that I sent get_value["temperature"] to device and received {"id":11987,"result":{"temperature":25.2},"exe_time":32} from it. Then I sent get_value["battery","temperature"] to the device and received {"id":12010,"result":"ok","exe_time":31} from it. At the end I sent get_value["somethingwrong","temperature"] to the device and received {"id":12026,"result":{"temperature":25.3},"exe_time":33} from it. I think it fully confirms my theory.

[marcelrv]

Agree.
Please add a "readmeComment": "some smart remark about only supported for firmware version below xx" in the json
So the readme will clarify this particular behaviour

[mak-42]

I'm totally agree with you. It might look like a riddle without the comment.

[mak-42]

Done

[nma-ro]

@marcelrv may i ask you to merge this pull request?

[marcelrv]

@ivo-pupkin I don't have rights to merge commits.
maybe @fwolter can merge these or propose someone

[ildar170975]

@mak-42
Does it mean that "battery_level" cannot be acquired anymore?
Strange that an official Mi Home mobile app still gets this data from a device.

[mak-42]

Strange that an official Mi Home mobile app still gets this data from a device.

The old way of getting this information locally was broken. I think the device still transfer battery level data to MI Home servers. It may be another way to obtain the battery level of the device, but someone should try to dig it up.

[ildar170975]

Thanks a lot for the reply.
Do you know any way to "sniffer" a traffic between a device & server?
With a possible decryption )))