Where to implement DIY thermostat Logic: Python or OpenHabian?

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


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

OH needs a bare minimum of a Pi 2.

You mean Python or Java?

@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

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.

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

@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

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.

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?

@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.

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?

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

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.


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.


1 Like