OK, I suppose it's time for an update, as I have actually had this working for some time already. :sunglasses:
Aah, documentation though... :smile:
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:
-
Everyone is making a thermostat to work with whatever sort of HVAC system they already have. This varies throughout the world.
-
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
-
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...).
-
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).
-
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.).
-
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).
-
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 :smile:) 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 :smiley: ) :
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...
