Yet Another MySensors Thermostat (US 24VAC multi wire)

[TRS-80]

So, now that I've got my radios working reliably next step has been finally getting around to learning Arduino (really, C++) programming. And in several days (of all day every day) I think I have learned just enough to be dangerous.

So, other than basic things like temperature and relays, one of first significant things I have wanted to do for a long time is a thermostat (by that I mean HVAC control). I have been looking and thinking about it for many years and I am sorry but I really have a hard time paying $100+ for what is essentially a microcontroller and a few relays (and possibly some display). And more importantly, the device then will probably be locked down and limited as to functionality (although yes I know that there are a few more "open" devices, but those are few and far between).

Now, I will be developing my own node, for my own reasons, regardless. However, I started thinking "well, what if I were to generalize it a bit" and then I could possibly make it more useful for everyone. And here is where I wanted to get community feedback.

I have been reading for literally years about all the different MySensors thermostat implementations. It seems to me so far that the vast majority of them are very specific to each user's needs. And maybe this is the point?

But the way I think, is to make a more generalized thing, which could be tailored to each users needs (within reason) instead of re-inventing the wheel each time from scratch. Taking the initial impetus myself but eventually (as the project gets to working / maintenance state) share in the creation and maintenance of the device and code, in line with the spirit of MySensors and the entire F/LOSS sharing community we have created.

I have some ideas about what I would consider reasonable and minimal specifications for such hardware / software, however before I even get into that, I wanted to hear some opinions on whether it was (in general) a good idea or not. And maybe also flush out some implementation I have possibly overlooked.

In fact, I also considered a good starting point perhaps to do a thorough research and index (perhaps in one big table) of extant implementations (where columns = features), which would not only be helpful in researching how to best implement any particular feature, but also help those looking to perhaps rapidly discover an already made "off the shelf" (DIY) design that most closely fits their needs.

Discuss!

[TRS-80]

OK, I suppose it's time for an update, as I have actually had this working for some time already.

Aah, documentation though...

Why so many different "thermostat" projects already?

So first off, I think I learned a couple things from my (admittedly, non-exhaustive) research into existing MySensors (and other) thermostat projects:

1. Everyone is making a thermostat to work with whatever sort of HVAC system they already have. This varies throughout the world.

2. Everyone has a different idea about what the UI should be. Some people have nice touch screens, some people prefer physical controls, etc...

Multiplying #1 by #2 it becomes clear why there is such a proliferation of "MySensors thermostats", and why I did not at first find "the one" general project I thought I was looking for...

So now taking that into account, I have appended "(US 24VAC multi wire)" to the title, and I will begin by listing what I think a thermostat should be:

Specifications

1. Dictated by / must work with my existing HVAC system, which is the very common sort here in US of 24VAC with several wires (one each for heat, compressor, fan, etc...).

2. In my case, no common comes down from the central unit in the attic to the thermostat/controller. So I will need to provide my own power for the uC and radio (could be 1.b., really).

3. Personally, I don't really care about fancy UI, touch screens or any of that. In fact, for my purposes (mostly expediency) I am fine with controlling the thing strictly through the HA controller (OpenHAB) through web or other interfaces (voice, XMPP/Jabber, etc.).

4. I want to be able to make decisions (turn on/off heating/cooling) based on all the temperature sensors in the home, or perhaps an average of them, instead of just the one built in to the thermostat. And perhaps also other things (like weather forecasts).

5. However, at same time I have built in some failsafes in case the controller (or communication, or whatever other parts of system) should break down.

OK, I think that just about covers it. I went for an easy implementation, basically some temperature sensors and a few relays. Most of this implementation (besides research ) is in software (on the node as well as in OpenHAB).

Operational Model

In order to achieve #4 from Specifications, above, I will need to get the temp from the whole house back to the controller somehow. Well, if it wasn't for #5 I could do everything in the controller (OpenHAB) and just have the node be some dumb relays. But since #5 is a requirement, we must do the actual logic in the node.

So my plan is to send the average temp in the home to the node every minute or so let's say. Then the node will store this value and make it's decisions based on that value.

Redundancy / Fallback

Which leads into this topic. What if the node does not receive the average temp from the controller? Well, the code in the node features a time out. After some configurable time (currently 5 min, which is still less than short cycle minimum cycle limit (more on that below)) the node will simply begin to use the directly attached temperature sensor, instead of the received average value, to continue to make it's own decisions, independently of the controller.

As a further backup against some catastrophic failure of the node itself (or any part of system really), I have simply left the existing/old unit hooked up. I connected the wires from my new unit straight to the old one (screw terminals) and set the switch on the old one to "OFF." This way, worst case I just unplug my (perhaps failed) unit and turn the switch on the old one back "ON" and we would be right back in business.

Hysteresis and Short Cycling

Finally, if you have read anything about this topic, or ever thought about doing it yourself, you will at some point come across some mention of these topics.

I will admit to being overly worried of them too for a while (what if I break my main HVAC unit, etc.), until I simply started paying close attention to my existing HVAC unit, including actually timing the cycles.

When I realized that (in our case) the thing seems to run for at least 30-40 minutes at a time, I quit worrying about it so much. Also I found some other info online that basically said the longer you run the unit for at each cycle, the more efficient it is.

But I have read some threads where people go really bananas on this topic, and to put it simply, I am almost certain that very few if any thermostat manufacturers fret over "hysteresis" as much as some of these various online fora pontificatiors do. Anyway, I suppose I have done enough research by now to not be worried about it any more.

I have made provision to set some minimum cycle time in the node (so far 20 min), and that is good enough. I may adjust this value over time.

For "hysteresis" I have the code in the node currently written like:

if (ROOM_TEMP >= HVAC_SET_COOL) {
  // turn on A/C
}

Careful observers will note that the >= (as opposed to just >) builds in 1 degree a sort of "hysteresis" (in addition to the minimum cycle time).

I think I wrote enough for today. I need to clean up the whole code before I post it. The hardware is uninteresting, but I guess I can post pics if anyone is interested. Let me know.

Screen shots of UI (in OpenHAB / Basic UI)

One thing that is easy to share is a screen shot from the interface in OpenHAB. I guess I can post that as a teaser (I have dark theme set on almost everything, including browser, use your imagination if you prefer white background ) :

OK, fine! Since it's really hard to see the "raised card" effect of OpenHAB with a dark background, I turned off my dark browser theme, so here it is in white:

Let me know what you think. Any questions, etc...

[nagelc]

@TRS-80 I have similar thoughts for a controller for my heater (hot water radiators with an oil boiler and 4 zones).

For 1 and 2, I realized I could wire my node into the zone controller. It has a common, so I can derive the node power from the controller. Since it works over radio, it doesn't have to be where the old thermostat was. I have temperature sensors in all the rooms.

The node controls 4 solid state relays that are wired in parallel with the existing zone thermostats. That helps with 5. The idea was to set the conventional thermostats at a low value. Then if my node failed, at least the old thermostats would kick the heater on before the pipes started to freeze. Also as a fail safe, if the node has the heat on and doesn't hear from the controller periodically, it will shut off. Still working on that part.

As for controlling it, there is a domoticz plug in here: https://www.domoticz.com/wiki/Plugins/Smart_Virtual_Thermostat.html
It only works for heat, but the underlying code is pretty straight forward, and it lets you average sensors. There might be something there you can adopt. I ran it with a MySensors modified space heater all last winter and it worked well.

Unfortunately, something kept killing the radio on my node, maybe a spike from zone controller relays. I haven't sorted it out yet, so the heater thermostat remains a work in progress.