If I recall right, currently indeed the support for the rice cookers is not there.
So to start, it would need a json file for yor device. You can create some base version of that by using the switch item that creates experimental support.
As the properties are not much like the other devices prob only very few channels are created.
Can you try separately the individual properties by testing the reponse to commands for the properties like this: get_prop["func"] and get_prop["menu"] etc…
If they respond, the created json db file can be extended to pull those properies.
But i was investigating and i see the implementation in python someone made, here the link:
as i can see they get the properties with get_prop[“all”] and get the array like appear in openhab with the response.
There is too all the calls for the functions available for the rice cooker (“set_menu”, “set_start”, “set_func”, “get_temp_history”)
I tried to start a cooking program with success sending:
With the profiles for my model of rice cooker (MODEL_NORMAL_GROUP2) works perfectly, and i can stop the process with set_func[“end”]
Now the problem is, how we can get this array of the response get_prop[“all”] and update channels or items with this information, I’m not sure if the Xiaomi Mi IO Binding allows to get this JSON Array and use this information or maybe is necessary to create a new binding for this specific devices.
I hope this information can help anyone to integrate the Xiaomi Rice Cookers in Openhab.
Interesting, so it responds always with all properties… that is not directly supported by the miio binding … but there is maybe a way to cheat… we create a json db file with all of these properties for your device, set the max_properties to 12
So the binding will do a request for all of these properties in 1 go, as it will get the response with all the properties.Hence I expect it will properly map them to the appropriate field.
I don’t know if all of the codes can be mapped with OH transformations to proper values, otherwise indeed on the binding side something needs to be programed to decipher the code (esp the last one) to something meaninfull.
(in the miio binding speak, we need to create custom transformations for them)
So with the json db files we can create an action menu to send those start & stop commands easilly
see example like that here:
the matchvalue would be what you want to see in the dropdown.
e.g. the end command action would look something like this:
The maxProperties dosen’t work, i still see the “Unexpected size different. Request size 1, response size 12.” i tried too with max_properties but looks like has any effect, i have to say im using openHAB 2.5.9 Release Build not the latest OH3. I’m not sure if this parameter works for my version.
For the channels i created (RiceCooker_stop, RiceCooker_start) works well sending the String with a transforms and a small rule, i can live with it but still important to receive the updates from de device.
So you need for every property a channel, so it has all of them, in the right sequence as you get the response.
btw, in the channels no need for the maxproperties entry. The first one is fine as you have it
All these channels need refresh true, except for the one with the end cooking.
I would suggest actually to make some sort of action channel, which would be able to deal with start, end etc. what the condition matchvalue does is only execute that action if the value is matched, so for every type of command you would like to have executed through that channel, you add an action.
Now there are a lot of work for beautify this data and know what does mean (i have to look the result data when is running).
I created some stateDescription but indeed im not on OH3 and i don’t see any difference, i have to solve some incompatibilities i have with the OH3 and try.
Is a good idea to make a customRefreshCommand and see in a graph how is going the cooking process but the data format is quite complex, in this link is explained the format:
Colud be interesting to set some settings in the device too, but i think is necesary to make some rules for create the necessary octets for the device can understand or made a specific binding for make as cleaner and transparent as possible for the users.
Anyway thanks very much for the help, I will try to improve the JSON when i understand better the data and upgrade to the new OH3
With OH3 indeed the mappings will help a lot to make it more readable
If you can figure out how OH likes the data so it is usable in the graph we can create a transformation for it. Maybe some of the other channels also need a custom transformation to slice the right data from the response.