Thermostat and Z-Way API discrepancy?

[pz1]

@Zwave>me team
I guess you have given ample thought about the control of discrete multi-state devices. However since I haven't seen much of that in writing, I am posting this to get some clarification about future directions.
In Home Automation the temperature setting on my StellaZ thermostatic radiator valves are done with a dimmer, and not with the setTemp as I would expect from Z-Way API specification. See excerpt in screen dump below:

Mode.PNG (12.8 KiB) Viewed 2275 times

In the automatic creation of virtual devices from Z-wave devices, the setTemp apparantly is mapped to the standard basic device dimmer. That is fine, because that makes that part compatible with LogicalRules, Scenes and similar.

Since long I am waiting for a solution to set thermostat operation mode directly. In home automation for me it just functions with a workaround where I had to manually create 30 JS functions to control 10 thermostats. I dearly want that to be a more principled solution though.

Your apparant mapping of setTemp to dimmer made me aware that the Z-Way API thermostat type probably is to complex for the virtual device level, and automation specifically. Therefor I propose to add two simple basic virtual deviceTypes to wich the metric:mode can be "mapped":

• SensorEnumState
• SwitchEnumState

I am agnostic about the exact names; could not think of anything more approriate at the moment.
Don't know anything about locks, so can't comment on how it would work out there.

[pz1]

No one here with opinions about these type:enum devices?