Beiträge von Dmytro Rozovyk

    I'd like to ask to share "thermostat" component API info.

    I'm currently upgrading a driver for Hubitat on a request with this new beta functionality [https://community.hubitat.com/t/shelly-wall-display/124247]. At the moment device notifications are working fine. So system gets state updated from the module. But control part is missing. I'm assuming there are 'Thermostat.GetStatus' and 'Thermostat.Set' commands. But as I dont have such device on hand I can't try guessing. And set of arguments are also a mistery.

    I'm interested specifically in functions that turn thermostat on/off and change heating setpoint.

    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.

    Having such informations allows to make a single generic extendable driver for 
    a target platform even for devices that are not yet released.

    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)