Where to implement DIY thermostat Logic: Python or OpenHabian?

[rlkoshak (Rich Koshak)]

@gatorback

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

@gatorback

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.

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.

@gatorback

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:

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.

@gatorback

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

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

@gatorback

use a single raspberry pi (preferable a pi-ZW because it uses the least current)

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.

@gatorback

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.

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.

@gatorback

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

@gatorback

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?

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.

@gatorback

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.

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.