-
Autor
Hello,
I'd like to request a way to get device configuration for driver for home automation hub.
More specificaly: available components and their count.
Shelly PRO 2PM is a good example what whould be nice to have on the entire PRO line. It has so called profiles. Profiles are optional atm. But they provide driver with the count of inputs, switches and covers. Thus driver can configure itself accordingly without relying on some sort of device type list table.
Basically it is a request to make profiles mandatory on all the PRO (and maybe other v2) devices even if they have only one profile available.
As a part of it the RPC method Shelly.ListProfiles needs to be considered made unauthentificated in the same way as the RPC method Shelly.GetDeviceInfo.a target platform even for devices that are not yet released.
Having such informations allows to make a single generic extendable driver for
Same could be made for other single instance components. Right now there is a way to get a full list of available methods. A report with component type/name can be added with numeric value like: missing entry or "0" - unavailable, 1..x - version or feature tear (in case if component will ever need some update/deprecation/extension/interface change). This will make report shorted but more meaningfull. Actually 2 numbers could be usefull: current version and minimum version that current version is compatible with (like 3,2 for example: if driver was written to support 2 and device has component tier 3, driver can continue to operate with the component safely if it has tier 2 or less reported as backward compatible).
Depending if component might have single or multiple instances it should go to the profile list or straight to the device info (for example).
Shelly, thanks for making great devices)
