Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Class: Thermostat
#11
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.
Dean Roddey
Software Geek Extraordinaire
Reply
#12
Updated to clarify read/write access and multi-unit naming stuff.
Dean Roddey
Software Geek Extraordinaire
Reply
#13
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.
Dean Roddey
Software Geek Extraordinaire
Reply
#14
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'll do the same for FanMode, adding a FanOpMode.
Dean Roddey
Software Geek Extraordinaire
Reply
#15
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.
Dean Roddey
Software Geek Extraordinaire
Reply
#16
I think what you propose will work for the AprilAire thermos
Reply
#17
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.
Dean Roddey
Software Geek Extraordinaire
Reply
#18
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.
Dean Roddey
Software Geek Extraordinaire
Reply


Possibly Related Threads...
Thread Author Replies Views Last Post
  Class: SceneCtrl Dean Roddey 20 2,618 03-31-2015, 12:38 PM
Last Post: Dean Roddey
  Class: Irrigation Dean Roddey 8 1,363 01-28-2015, 12:09 PM
Last Post: Dean Roddey
  Class: NowPlaying Dean Roddey 8 1,351 09-23-2014, 02:01 PM
Last Post: Dean Roddey
  Class: Switcher Dean Roddey 9 1,484 08-20-2014, 08:17 AM
Last Post: Dean Roddey
  Class: Security Dean Roddey 33 4,331 08-13-2014, 03:02 PM
Last Post: Dean Roddey
  Class: Projector Dean Roddey 29 3,205 08-11-2014, 08:56 AM
Last Post: Dean Roddey
  Class: Lock Dean Roddey 5 1,007 07-31-2014, 01:24 PM
Last Post: Dean Roddey
  Class: ContactClosure Dean Roddey 7 1,131 07-31-2014, 10:14 AM
Last Post: Dean Roddey
  Class: DIO Dean Roddey 7 1,357 07-31-2014, 10:08 AM
Last Post: Dean Roddey
  Class: Relay Dean Roddey 4 917 07-31-2014, 09:56 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)