It is certainly true that all that matters is controllable thermos. And it's also true that some features just won't be part of the standard. Doesn't mean the driver won't support them, those features just won't be generically accessible. Just the way it will always be, I'm sure.

Ugh... The Z-Wave thermos don't have a symmetrical set of settable vs. current operating modes. To support these types of thermos, we really need to have separate SetMode and CurMode fields. That's probably how it should have been from the start, but I didn't foresee this issue.

So yet another decision, do we whack current V2 thermo users or not? I guess we have to because otherwise we will probably end up not being able to support other thermos in the future, and the separate modes allows for full flexibility. It would break V2 Elk, Omni, and RA2 users if they are using the CurMode to set the mode.

Actually, we could avoid breakage by leaving CurMode as a read/write for the set mode, and adding an OpMode (readonly) for the current operating mode. For those thermos were they are symmetrical, OpMode will be sort of redundant, but portable code would use OpMode to see the current operating mode, not CurMode.

I updated the spec to match the above, and I'll update the currently shipped V2 drivers that support thermos to match this scheme for the next (4.5.9) drop. I'll do the Z-Wave driver that way to start.

OK, updated to reflect this change. I've got the Omni driver updated. I'll do the Elk and RA2 drivers tomorrow. I wanted to do some more 'modern times' improvements to the Omni driver so that took the rest of my time today, but well worth doing.

Unfortunately I'd already started on the Z-Wave driver or I'd just get a new drop up tomorrow and a doc update and get them into sync. But I need to finish the Z-Wave driver changes first, at least the V2 support initially just get that up and get a doc update up. I've not uploaded the changes fro 4.5.8 docs yet and I don't want to do it twice. So I'll get the Z-Wave driver done then upload both release and docs and get everything into sync.

So, its becoming more and more apparent that there are too many thermos that can't quite make the cut for this device class. If it was just because they were pathetic, weenie implementations that would be one thing. But, apparently, some people live in places where the temperature only goes one way and so many thermos, by design, only have one or the other set point.

Other things, like not exposing a fan mode, are easily faked. Just have a single settable mode called "Auto", and have Off/On operating modes which you set based on whether the thermo is running or not. But the set points thing is too much to really fake in a meaningful way.

The gotcha with trying to deal with this is that, the whole point of these device classes is to allow folks to create user interfaces and user logic that just works, and still just works if you replace the current thermo with another one, or if you use some third party user interface or logic. The extent to which things are optional the likelihood of this working, or the difficulty of making it work consistently, goes downwards quickly.

About the only thing I can think of would be to have a new field:

THRM#Kitchen~SPType

which would have the predefined values: Low, High, and Both. So, for any given thermostat, you can check the type field and know what set points the thermo supports. For user interfaces, you'd use that to disable and/or hide the controls related to the set points. For user logic, you'd just have to check it and do or skip operations related to a given set point.

Since it wouldn't change anything to do with the existing fields, it would be backwards compatible for those folks who have currently created any logic or interfaces based on the current scheme. Presumably, if they have, then their thermos have both set points, so nothing would change or break for them. But, moving forward, it would allow for single set point thermos to be supported.