Handling OpenThings devices with unregistered productid

[whaleygeek]

By unknown device, I mean a device that does not have a device class for it in the Devices.py file.

This will happen if the Devices.py does not have the new product description in it (i.e. a device class that wraps a specific product_id code).

For the MiHome range (or anything that conforms to OpenThings), the devices are mostly self describing, in that the parameters that appear in the record payload are typed parameters from a well published parameter dictionary.

So, note to self, it would be possible to auto create a roughly functioning device class for an unknown product_id, based on the data in the record payload. For each received report parameter, you could auto generate a get_xxx method in the class. It would be a good first step to getting a new device integrated, without having to hand-write the class from scratch.

[whaleygeek]

Hmm, this might be quite simple by having a MiHomeDefault device in the DeviceFactory, that could wrap any product_id - if the discovery process finds a product_id that it can't match to any of the device classes in the factory, the factory could wrap a MiHomeDefault around it, look at the message (assuming it is a data message and not a join message), and auto generate methods.

However, restoring from the registry would be interesting, the get_config() method would have to return enough information in the returned config map such as the action and getter methods and what paramid they bind to, so that when restoring the registry later with a program restart, the same auto generation of an appropriately configured class could be done.

This sounds too complex to squeeze in as part of the device_classes branch, but the work done on device_classes enables this to be done. I'll leave it here with these notes about how it might be implemented, to pick up at a later date.

It's also related to something happening in setup_tool.py at the moment on the device_classes branch - it would be useful in the 'show device status' and also the 'switch device' menus, for a menu of available getter commands and action commands (respectively) to be introspected out from the device class, and offered to the user as a menu. That way, the menus will be self building, and adding new devices with new capabilities won't need custom menus to be written.

Parked for now, but with the ideas documented.

[whaleygeek]

Noted in #63

yet unmodelled devices still to be usable to some degree for MiHome devices, a proxy class generated dynamically based on received message parameters. e.g. if it reports a TEMPERATURE field, then there should be an automatic get_temperature() method generated.

[whaleygeek]

If the class device type in the registry was MiHomeDefault or MiHomeProxy, then the device could auto expand it's methods based on parameter id's on the next message that is received - i.e. it would be self describing, but not persistable.

This would mean that any program calling a method that does not (yet) exist such as turn_on() might fail, so there might need to be a getattr that returns a dummy for any getter/setter, that by default says 'not yet available', so that the failure semantics on startup are a bit softer.