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:
raspberry pi (3B+ and Zero-W are available) for logic
Channel Relay Board: Sequent Microsytems for switching HVAC on & off via Python commands
Temperature sensors TBD for each AC
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).
- 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