Use capabilities of devices to determine functionality

[aholstenson]

I've been moving miio to a capability based system where each device has a set of capabilities that indicate what it can do. API stability will be tied to these capabilities in the future, meaning that the capabilities of a device can change but the API of capability will remain stable.

There are two main capabilities I think are interesting in this library right now:

• switch uses the capability power-channels to support some of the Mi Home devices that can toggle the power for several sockets.
• The power capability is for devices that can be turned on or off such as air purifiers, humidifiers and so on.

There are a few other capabilities for sensor data right now which could also be implemented. These need the built-in property polling to be in place though.

I'm not familiar with Homebridge enough to be certain, but I think a good architecture would to split mapping of capabilities into their own files and then mix them together when homebridge-miio sees the device.

[Bluebie]

For now my plan remains to use device.type strings as the main way of understanding what I'm dealing with, and gradually introducing support for devices on a type by type basis as I figure out the right way to map their functionality in to homekit's device types and required interface specs. Capabilities will be useful to understand the different versions of one type of device, like the different plugs.

I was trying to ducktype devices in the earlier releases, by querying properties and seeing which ones they respond to, but I quickly got a lot of complaints from users that a lot of devices were being exposed in useless ways, and it was a big hassle cleaning up that mess, so now i'm taking a more conservative approach.

[aholstenson]

Ok! The type that a device is in will of course continue to be there and significant, but capabilities will be how you can know what a device can actually do.

Capabilities are a little bit like an extended version of querying properties, but they are mostly set from the model of the device. I've seen a few cases where I think the available properties might be a good way to figure out if a certain sensor value is supported, but I'm trying to keep them tied to model for now.

I have a few more devices to test before I'm locking down the API for a 1.0 release and after that I think most devices should remain stable in their capabilities. Actual methods and properties on types (base API) and capabilities will definitely stay stable all through 1.x, which I hope will be the major release for some time.

[Bluebie]

Sounds good to me!