You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With a move towards modularized smartdevice (#757), we can get rid of separate files for different device types.
We should probably keep the same interface in place for the time being, but in the future the available "features" (#741) should be enough to decide how the device should be controlled.
For example, KS205 is a wallswitch that allows turning it on and off, but doesn't support a brightness feature like KS225 does (based on the component list). Instead of hard-coding this per device-basis in our discovery machinery to decide which class to initialize, we can expose the set of features for downstream users like homeassistant, which can query if the device supports "brightness" and act accordingly.
The text was updated successfully, but these errors were encountered:
Uh oh!
There was an error while loading. Please reload this page.
With a move towards modularized smartdevice (#757), we can get rid of separate files for different device types.
We should probably keep the same interface in place for the time being, but in the future the available "features" (#741) should be enough to decide how the device should be controlled.
For example, KS205 is a wallswitch that allows turning it on and off, but doesn't support a brightness feature like KS225 does (based on the component list). Instead of hard-coding this per device-basis in our discovery machinery to decide which class to initialize, we can expose the set of features for downstream users like homeassistant, which can query if the device supports "brightness" and act accordingly.
The text was updated successfully, but these errors were encountered: