Where to implement DIY thermostat Logic: Python or OpenHabian?

Setup, Configuration and Use Items & Sitemaps
1

Assume that OH is new to the author and that if the author does not indicate a fact, assume that he does not know it.

If you have experience designing thermostats (HVAC controllers) and marrying it to OH, please state this in your reply and provide any relevant example. Lesson-learned are appreciated.

I will define on-board thermostat-logic or on-board logic as the decision algorithm (sitting on the rPI) to engage the 24V AC HVAC relays (cooling (yellow) / fan (green)) that sits on the HVAC controller (raspberry pi). The algorithm must reside on the controller and not on the network. Specifically, the algorithm switches HVAC cooling when the temperature setpoint is measured or the user sends a command. A setpoint time schedule is also desired.

An industrial building with 3 zones and 3 air conditioners is to be temperature controlled. I am prototyping a single controller (thermostat) to control the 3 ACs:

Openhabian has been installed and the relay board is controllable from python.

I have experience with sensors, however, the Openhabian platform is new and I have questions. I understand that OH is typically used with finished devices (i.e. thermostats) and provides bindings so that OH can control different devices from a single platform. (if my understanding needs correction please advise).

Goals include:

  • use a single raspberry pi (preferable a pi-ZW because it uses the least current)
  • network independence: The controller can not fail because of a network failure
  • simplicity: simple software solutions are preferred over complicated’
  • control 3 ACs from single controller: each AC to have independent temperature-feedback control
  • extensibility: thermostat logic should provide interface (API) for other platforms: OpenHAB, etc.
    If the raspbery pi is disconnected form the network, it must implement logic and function as a thermostat. Access to the controller can not be dependent on a third party / cloud services: the rPI is SSH-WAN accessible

QUESTIONS

The relay commands are implemented in Python. On-board Logic can be designed in Python or OpenHabian. What are the pros and cons of either direction? I am under the impression that if I am to use OH on-board logic then I will need to use a more powerful (3B+ or even a 4B) raspberry pi.

I realize that system requirements ultimately drive decision making, however, I would like to pick the language that provides the most flexibility and is easier to maintain \ troubleshoot.

If the thermostat logic is to be implemented with OpenHabian, does this mean using IFTTT command set or are there other OH command sets to implement thermostat?

My initial thought is that a Raspberry Pi ZW outfitted without Raspbian and Python-Thermostat Logic would be the simplest solution and that a LAN networked OH server could update the temperature setpoints / schedules. I am open to suggestions & solutions that provide advantage in terms of the goals. I am also open to considering other good goals.

  • Platform information:
    • Hardware: Raspberry PI 3B+ to migrate to rPi Zero-W
    • OS: openhabian-pi-raspbian-201908050414
2

OH needs a bare minimum of a Pi 2.

You mean Python or Java?

3

@Bruce_Oborne Thanks for the reply and input.

If I implement the controller with the pi-ZW then I will need to implement the on-board logic in Python to meet system requirements. If OH is the logic platform then it sounds like I will be required use my on-hand 3B+ and if necessary a 4.

Because OH is new to me: if OH is a JAVA platform then I suppose that logic can be written in JAVA.

I am seeking to understand the pros / cons of implementing the thermostat logic in Python vs OH JAVA \ IFTTT. If IFTTT is not an appropriate language to implement thermostat logic, please to advise as such. Thank you for helping to hone the request

4

Avoid OH / IFTTT unless you host your own OH cloud service.
Some newer rules can be written in Jython which is basically Python 2. @5iver or @rlkoshak can comment further on that.

5

I didn’t design it, but I do have a HestiaPi which is basically an openHAB based thermostat. I’m currently rewriting all of their rules to be more generic and therefore shorter and easier to maintain.

That’s basically how the HestiaPi works, though the logic isn’t all that complex yet. It’s pretty much just setpoint and sensor reading based. Though I am going to add hysteresis and some timing guards to avoid cycling the unit too fast for those of us with forced air systems. I’ve already implemented the hystersis but haven’t checked it in yet.

Anytime the word “industrial” is used in the context of openHAB alarm bells go off in my head. OH might be fine in this situation but it lacks many features that IMHO are required for any industrial application including stuff like real-time processing, fail safe, transactions, etc.

Pretty much. It’s designed and intended to be a bridge between lots of different technologies. Usually it doesn’t implement a device on it’s own (HestiaPi being an exception to the rule).

The HestiaPi is based on an RPi0w. It’s really really slow. I’m talking 10-20 minutes to reboot. 5-10 minutes just to parse and activate changes to rules. And it doesn’t fit in the RAM so you will need to use swap which means even more slowness and extra writes to the SD card which will wear it out faster. And when an SD card wears out, it does so silently. Just all of a suddenly the device starts to behave strangely.

All Linux based computers are sensitive to power loss file system corruption which is amplified when running off of SD card. Do you want to potentially have to run around replacing SD cards every time one of these controllers loses power?

It’s not just OH that I would say is unsuitable for industrial applications, at least not out of the box.

You can use the Python commands directly from openHAB Rules. Either using Scripted Automation with Python (see [beta testers wanted!] Jython addon w/ helper libraries (requires OH 2.5.x)) (note, it’s Python 2.7 so there might be problems depending on the libraries your Python code uses).

Or using any OH rules language you can execute your existing Python code using the Exec binding or executeCommandLine Action.

Or you can have a separate Python service that you communicate with from OH using MQTT or HTTP or something like that.

If you already know Python, I’d stick with that. If you already know how to program, I recommend one of the Scripted Automation languages (Python, JavaScript, or Groovy). At this point I would not recommend getting started with Rules DSL.

At the moment, as a new user IFTTT isn’t an option for you. And the latency is sooooo long that I wouldn’t recommend it for you anyway. People were abusing the myopenhab.org service which is the way OH connects to IFTTT so the ability to expose new Items to IFTTT has been turned off.

Also, this completely violates one of your requirements. You want these devices to be network independent. IFTTT not only requires network, it requires Internet access as all the processing takes place on IFTTT’s servers, not locally.

And I’m not really sure what you mean by “command set.” OH provides several choices in programming languages in which you write rules. They are all fully functional Turing Complete languages. If a Von Neumann computer can do it, you can write Rules in OH to do it. But this also means there is no thermometer or thermostat specific commands. It’s all at a much lower level than that.

One other minor quibble. openHABian is a series of scripts that will install and configure openHAB and a bunch of related software on an apt based Linux distro. openHAB is the software you would use to implement this, if that’s the direction you choose to go.

Personally, I would drop the RPi 0s and use microcontrollers instead. They can control relays just like the RPi 0s but they don’t have any of the problems with power loss and file system corruption. They are also super simple. They only run the one program you load onto it. It is very possible to implement a stand alone thermostat on the microcontrollers and then, as you plan, run openHAB on as beefier RPi to essentially adjust the settings or issue commands to the microcontrollers.

1 Like
6

@rlkoshak Terrific response! Good suggestions.

The building is a storage building and in hindsight, “industrial building” was not the best choice of wording. The ACs are currently running on CT50 Radio Thermostats and the prototype will bewired in parallel to prove itself out. Now that I mention and think about it, it, I think that having both controllers on by default and wire up the rPi’s relays to turn off the CT50’s at will. I think that SD-card failure is a topic is something to keep in mind such that one makes decisions to allow future solutions to boot-only from the SD or other strategy.

Hestia Pi was the inspiration for my project. I have been wondering if I could use the Hestia Pi’s raspberry pi image or start with a fresh OH install. I purchased the same waveshare display in the hope that I could leverage the Hestia-Pi .img I have posted questions regarding Hestia Pi at: "triple" Hestia Pi Mod

7

See my answers on that thread. tl;dr, ask on the HestiaPi forum.

HestiaPi is currently running a version of OH that is over a year old and the image is highly customized to their hardware and overall approach. I think it would be more work to try and shoehorn in your solution into it than it will be to start from scratch.

8

Others have connected openHAB to CT50 thermostats (but the discussion is very old). Would that be a consideration, or are you more interested in this approach as a hobby project?

9

@rpwong Russ, thanks for increasing my awareness of the Radio Thermostat binding. It probably make sense to test Openhab with the CT50 bindings. The questions that I am posing are coming from the standpoint of making decisions that will make the project either very easy or difficult as I progress “down the road”.

That being said, I have bought the relay board and a number of temperature sensors to test. I am interested in keeping my technical skills from fading so I like to build simple projects to keep technically active.

10

Then you are in the right place. :wink: I’ve learned quite a lot from the folks here, and pick up a little more with every conversation. The expertise level ranges from people who have no programming experience at all to cybersecurity experts like Rich and many other DIY/hardware experts. So, the community benefits from a wide-ranging perspective.

Out of curiousity, you say that you’re new to this, but your avatar says that you joined in December 2015. Am I correct in thinking that you explored OH four years ago, but didn’t take the plunge?

11

Yes. I joined several years ago, however, I did not really have a good project and time until now. The Radiothermostats were installed last year; that and the Hestia Pi has inspired me to build my own controller. I have other controllers (Honeywell), however, I have a real problem with being dependent on a cloud service: just another failure point.

1 Like
12

exactly, wemos, nodemcu or basically any esp will do just fine. Create own sketch for it is matter of couple of minutes.
But I personally would not run rules/logic on the board as it is not very convenient to manage.

I do have wemos with tasmota, wifi and → rules running on OH via mqtt. Solid and stable solution. Which if I want to can manually override on the wemos itself.

2 Likes
13

I’d suggest starting small: get a Pi3/4, install openHABian, and get comfortable with it. Pick up some cheap WiFi plugs to test it at home, expand to the CT50’s, and then get into building your own controller. That way, we can support your efforts as you learn your way in, and you’ll know that everything’s working when you get into the experimentation phase.

You’re probably already thinking along these lines, but I’m saying it anyway. I think starting small is the best way to learn anything: driving, playing piano, renovating, writing novels, etc.

Enjoy!

1 Like
14

Throw my 2 cents in on this (old) thread.

Since virtually every single thermostat out there is closely tied to the manufacturer who actually has a vested interesting in not being totally transparent with allowing access - not only $$ to use their services, but security as well, I am going to also make my own.

My current plans are Pi. Or maybe even less capable. A thermostat is not rocket science. In the olden days… it was simply a bimetalic strip to turn on/off the AC or Heat. Unless you have heat pumps (which are still not that much more complicated) the function of a thermostat is still the same. Turn a device on or off at a set point. The biggest thing with electronic devices now is - scheduling and remote access. But the core function is still to turn a device on or off at a set point.

The only real trick is to determine the “anticipator” algorithm for your particular system so the heat turns on when needed and not requested when needed and turn on minutes later after the furnace heats up.

Here’s my plan:

Using Pi or similar with a local touch screen, I am going to create a dedicated thermostat device. I do not plan on having openHAB directly on the device. But it will connect on a local network on a UPS for power backup. I will program in Python (likely).

The device will need to be able to monitor temperatures, and turn on/off Heat or AC as selected. I plan on having it (eventually) configured with a normal target temp, but also with outer limits to force switch from AC to HEAT or HEAT to AC if required. ie: I have AC on with a target of 72F. It gets cold outside. Temp drops to 65 inside. FORCE a change to HEAT at some kind of set default (maybe simply not allow any COLDER than 65). Flip side for HEAT. If I go above 78, force AC.

Whether a local Pi display, or a tablet locally displaying OH, there will be a local touch screen. On this screen I can display status, schedule, override, etc.

My system is a simple gas fired furnace with typical AC. No heat pump. So, it is 5(?) wire. 24v, Common, Heat, AC, and FAN.

I may add humidity to this.

I live in a manufactured home and true zoning is not easy. I do plan on adding some motorized “register” controls to help do some zoning type functions though.

It has been commented by others out here on other threads that this is unreliable. However - it should not be inherently any less reliable than any commercial dedicate use device. The commercial devices, regardless of programming language (firmware) do exactly that same thing with very similar hardware. There is not reason at all that a Pi with backup power should not be every bit as reliable as a commercial device.

The advantage? I KNOW I can make it OH compatible by design. I can intentionally make it integrataeble with OH.

Note: In my case, the Pi will be the controller. My OH instance will be on a separate device. I have not decided if the “schedule” should reside on the Pi or be fed from OH. I’ll figure it out as I go.

BTW - 40 years programming experience in anything from mainframe to micro devices including PID control (the furnace anticipator!). 30 years of hardware design for machine motion control including similar interface requirements and UI presentation.

15

Honeywell makes a version of their T6 (maybe T7?) that’s Zigbee (doesn’t get more standards based local than that really) and there are a number of other Zigbee and Zwave thermostats.

For WiFi, thermostats from VenStar support a local only API and have an OH binding to support them.

You should look into Hestia Pi. It’s current incarnation is a bit old and it might be challenging to get the parts for it but at least it shows you what it takes. Note, I didn’t develop the logic but I did rewrite the code that drives it for them (it’s built on an older version of OH).

Just be careful. The control boards built into some systems, particularly central air, may not be super robust. It’s not too hard to develop algorithms that are overly hard on your system or put it into states it that should not be allowed (e.g. heating without the fan running).

That’s easy, just set a hysteresis. For example, turn the heat on when the temp falls below 65 °F but don’t turn it off until the temp reaches 68 °F (choose a range that is appropriate for you). When the temp is between those two values, do nothing. If the heater is already on, leave it on. If it’s off, leave it off.

Interestingly the HestiaPi does have an older version of OH on it. But that’s not required by any means. And because it’s running on an RPi there are compromises.

Two setpoints (one for heat, one for cooling) coupled with hysteresis (and obviously checks to ensure that the AC target is higher than the heater target) is a great way to handle this.

If you plan on powering the RPi from these you’ll need a transformer to convert from 24VAC to 5VDC 3A 15W or what ever is required to drive the RPi/microcontroller you plan on using plus whatever is plugged into it (touch screen). In my experience with the HestiaPi that’s been the big limiting factor. It’s relatively huge and dumps a lot of heat.

You have to be careful with doing that with forced air. The systems are designed to have a certain amount of airflow and closing off too many vents can cause the fan to have to work harder than usual, wearing out the motor and operating a much less efficiency (i.e. it’ll cost more to heat/cool those fewer square feet). The rule of thumb I was given by our HVAC guy is no more than 20% of the registers should be closed at any given time which significantly reduces the flexibility such systems provide.

I ran with Hestia Pi for a good bit until we had an AC installed. At that point they installed a Honeywell T6 WiFi. I had more flexibility with the HestiaPi (especially since I wrote the rules) but the Honeywell is way more reliable. I’ll still support HestiaPi and when/if they move to OH 3/4 I’ll even rewrite their rules for them, but I don’t think I’ll ever go back to using it to drive my HVAC. I’ll either get the Zigbee T6 which should just be an unplug/plug in process to install it, or I’ll get a VenStar.

16

Thank you for the useful info. The register comment is in particular an interesting thought. You saying the furnace may not be thrilled with me requesting MORE AND MORE heat, yet shutting every register in the house? LOL!

I will take a look at Venstar. Since data would not be constant, I would think Zigbee might work ok as well. Honeywell? I’m using a HW (Residio) right now, but it is not a T6/T7/T9. So you must use their cloud and I keep hearing that the OH binding is so-so for it, and – since you have to use “their” API, if they shut down, you are out of luck.

17

By the way. It’s not that I’m against using a commercial product. I’m against using a commercial product that is not totally “stand alone” so I don’t have to use the internet and their cloud to make things work. I want to connect to the product and the product only directly with OH! And I’ll be happy!

It’s like what I consider to be the camera nightmare.

18

I currently have a T6 WiFi. I’m unaware of any OH binding that supports it (if there is I’ll give it a try. I wrote some rules to work with the Resitio API but authentication was always a problem and I gave up. If I had a choice I would have chosen the T6 Zigbee and might even move to it someday so I can independently control the fan. The Lyric line of thermostats all appear to use the same base so all I’d have to do is pop the old one off and pop the new one on, and of course reprogram it. But at least there’s no rewiring.

But for now I have the T6 linked to Alexa and use the Amazon Control binding to access it through Alexa. I only have a couple of controls (setpoint and mode) but it’s sufficient for my needs (change the setpoint and change from heating to cooling automatically based on season, interior temp and exterior temp). Sufficient enough that I don’t want to mess with it (plus it has all sorts of secondary stages now that I’m not sure how to program into a new thermostat properly and I’m too lazy right now to figure that out).

When I got the HestiaPi I was using the heater fan as the AC since the basement was always 10-15 °F cooler than the top floor (and we didn’t have an AC). I had thermometers all over the place and had a bunch of complicated logic to run the fan when the top floor was a certain temp above the bottom but only during the summer and reminders to open/close windows and such.

When COVID started and the whole family spent the whole day at come coupled with smoke from fires (can’t open the windows when air quality is really bad) proved that was no longer sufficient so we got the AC. Now our HVAC controls are very simple. There is almost always someone home so there’s not even a need to mess with home/away logic.

I’ve been all over the place on this one and I have come down on the side of assumed risk. The Zwave version of the T6 runs $100 on Amazon. Other thermostats with OH support run between $75 and $250. I’m willing to run the risk that I may have to spend $75-$200 plus a couple of hours sometime in the future if Honeywell decides to shut down their API. In all likelihood I’ll want to replace the thermostat for other reasons before they shut down their API.

I don’t have to use their cloud. If Honeywell shuts down their cloud, the thermostat will still work stand alone. It just wont have interaction with Alexa, Google Assistant, or openHAB.

19

You mentioned the VenStar. Is it able to be used directly? or is it just another variation of the same?

20

VenStar has local only control. They are more intended for commercial installations though so tend to be pricier than others.