[miio] missing voltage readout on qmi.powerstrip.v1

[valpackett]

Expected Behavior

qmi.powerstrip.v1 should report voltage, e.g. python-miio supports the voltage property:

% miiocli powerstrip […credentials…] status
Power: on
Temperature: 50 °C
Voltage: 219.62 V
Current: 751 A
Load power: 148 W
Power factor: 899
Power price: None
Leakage current: 8 A
Mode: PowerMode.Normal
WiFi LED: None

Current Behavior

No voltage channel is available with the miio:basic binding:

Your Environment

• Version used: 3.1.0 release
• Environment name and version: OpenJDK 11
• Operating System and version: FreeBSD 12.1

[marcelrv]

Can you run python-miio in debug and see which commands/property is requested with missing properties. Looks like there is some conversion issues though (maybe it is milliamperes instead of ampere)

[marcelrv]

Note.. I consider this an enhancement request rather than bug .....

[valpackett]

DEBUG:miio.miioprotocol:192.168.1.15:54321 >>: {'id': 1, 'method': 'get_prop', 'params': ['power', 'temperature', 'current', 'mode', 'power_consume_rate', 'voltage', 'power_factor', 'elec_leakage']}
DEBUG:miio.miioprotocol:192.168.1.15:54321 (ts: 1970-01-08 04:04:22, id: 1) << {'result': ['on', 50, 647, 'normal', 126, 22168, 879, 8], 'id': 1}

so voltage is returned as an integer that's the float value * 100, i.e. 22168 means 221.68 V

[marcelrv]

qmi.powerstrip.v1.json.txt
please try attached json and feedback the results (are all the channels working?).
See binding readme on how to load local json files (remove the .txt from the filename)

[valpackett]

Does work, thanks!

[valpackett]

Though hours after adding the JSON file a thread leak issue has appeared (unable to create native thread: possibly out of memory or process/resource limits reached errors and corresponding hangs). Seems like miio has been implicated in this kind of thing before… Could it have been caused by the file?

[marcelrv]

Unlikely specific to this file. There is no java code in it, so unless it all of the sudden reveils an already existing issue it is not related to the file.

Maybe something generic to the binding, but then we need much more detail... I can't rule it out, but can't confirm it either.

As per the linked topic:

If indeed you have the issue, you may be able to run dev:dump-create in the kraf console which creates a zip file. Inside that zip there is a file threads.txt.
If you see there hundreds of threads related to miio than… Houston we have a problem

[valpackett]

Right, looks like same results without the file (unless it's already included in the latest 3.2.0 snapshot as of just a couple hours ago)

[marcelrv]

did you do the dev:dump, that should give a good hint
in case of issues you should see hundreds or thousants of waiting threads.
expected is to have 2 or 3 threads per miio thing and a few more for the http part (cloud) and 2 for the discovery