Indeed that may be the solution.
Max properties 5… can than also be incorporated, though that to me is less relevant as all devices work with 5, it is just the case that some devices lock up or behave weird when too many properties are requested in one go. Similar as to some devices lock up when miio_info is requested too frequent… These are probably memory constraints / bugs in in some device firmwares
For example, Mi Home app sends 18 properties at time for MJXFJ-300-G1 while the binding will query it 4 times. So setting up max properties for a device might increase the performance.
I think there should be few xiaomi third party device have same issue, may be due to security ?
next air mon product from this company act like other xiaomi product, single value by get_prop is accept, weird part is update firmware won’t solve this issue
I think miio currently only have 3 category, basic, Vacuum and unsupport, for some of the product like light, I think should add to new category as most of the value can’t issue command alone, it has to be combine, also light need to set rules for on/off when brightness for 0,
I don’t know does other xiaomi product have combine command issue or not, but I think category for difference product is a good idea, Marcel set it from starting, just never extent.
Here’s a jar which uses get_value instead of get_prop: https://drive.google.com/file/d/141sFl8Zy1owstsRK-ncy9PJmXs7txRXN/view?usp=sharing
Works for my device.
Edit: updated link
There is (limited) possibilities for multiple parameters. It is used for some devices like the yeelights that indeed need more than 1 parameter set. e.g. look at yeelink.light.ceiling2.json
{
"command": "set_ct_abx",
"parameterType": "NUMBER",
"parameter1": "\"smooth\"",
"parameter2": "500"
}
The challenge is with openhab, it is difficult to set 2 or more parameters with single channel.
With the basic handler, I think you can handle most of the current challenges (using the additional parameters & transformations possibilities).
I have in the past toyed with the idea of having indeed the possibilities of setting multiple variables, but so far did not find a good (enough) use case for it that would also be well supported by OH.
There is though the need to create a new category/handler maybe for the latest devices that require to send the did, siid and piid in the parameters, or at least make an significant change in the basic handler.
As Xiaomi appears to be going for a database driven approach as well for newer devices (MioT-Spec), that may be the direction to go: somehow read their database file directly instead of creating one ourselves. But that will require a new handler as well.
Marcel, Thanks for the full explain, that makes me well understand the limit and why no further category for same type items.
by the way, there is a thought I wonder will it be a good choice, can miio binding read /etc/openhab2/services directory for json files eg:zhimi.airpurifier.v1.json so if file exist will be bypass the config file in jar, that would be easier for new device config setup and debug current config
I don’t have OH3 installed yet, I tested with OH2.5, I get binding online with basic category link to items as well, but looks like it’s not polling, all items keep null, I don’t see any warning/error from console, also with unknown reason, battery can’t be link to items, I set channel in items but paper UI shows no items linked.
Please re-download the jar. I’ve made some fixes which might help you. It works with OH2.5 for me.
do you mean the latest one https://drive.google.com/file/d/141sFl8Zy1owstsRK-ncy9PJmXs7txRXN/view?usp=sharing? I actually start with this
Re-uploaded: https://drive.google.com/file/d/1Y1XkBPVfnWHqp8IsjLjc-oinY2RVtaPs/view?usp=sharing
MD5 = 3efd0d2e31333777f68d1088736d3606
with new binding, it works, only battery still missing, paper ui shows it’s not linked to items with unknown reason
What’s in the logs?
I don’t see any error log, of cuz I didn’t set log:set debug
Yes, enable logging:
log:set debug org.openhab.binding.miio
That is an excellent idea… that allows to develop new database files and custom profiles much easier
I really don’t have much time for this now, my home is kind of mess around now, I am rebuilding my network with 3vLan, it drive me mad, also with new iot and net Cam migrate to openhab.
tomorrow I need to rebuild my floor as well, so it may take me few days to settle down
P.S. build HA mqtt server also drive me mad, so easy to run out of ram, really need to calc the scale
I’ve made a commit addressing this issue to my pull request, please review: https://github.com/openhab/openhab-addons/pull/6568
no worry:
great news, once my home settle, I would like to dig around with it.