openHAB also serves up the web UI.
openHAB calls a Python script called bme280.py which uses the Adafruit libraries to get the sensor readings using the Exec binding.
openHAB has a GPIO binding that it uses to set the pins to high/low which triggers the relays.
Yes. The rules process the sensor readings and when anything relevant changes goes through the logic to determine whether or not to turn on or off a device. When the correct state is calculated, the rules send a command to the Item that represents the GPIO pin that controls the device. the GPIO binding then changes the state of the pin to turn on/off the relay activating/deactivating the device.
The Exec binding runs periodically and calls that bme280.py script. That updates three Items that represent the sensor readings, MyTemp, MyHumi, and MyPressure. When these Items change, the “Process Sensor Changes” rule runs and checks to see if the sensor reading has changed enough to process the change. That keeps the noise in the sensor readings from causing the rules to run unnecessarily.
If the change is enough, the PreviousTempReading (or Humi or Pressure) Item is updated with the sensor reading. That triggers the “Sensor or Setpoint Changed” rule which looks at the sensor reading, the corresponding setpoint, and figures out which device may need to be adjusted to react to the change. Let’s follow a temperature change so this rule will send a command to “Heating Check” or “Cooling Check” if Heating or Cooling Mode is in a state where it might turn on (ON, or BOOST, or AUTO).
“Heating/Cooling Check” runs and looks at the setpoints, sensor readings, and modes and determines whether or not to turn on or off the heating or the cooling. It in turn sends the ON/OFF command to an Item representing the device, let’s say heating in this case which would be the HeatingCtrl Item. This triggers the “Heating Control” rule.
The “Heating Control” rule checks to see if it’s safe to turn on/off the heater, controls the turning on/off of the second stage heating, and ensures that the fan gets turned on prior to the heat and turned off after the heating is turned off. To turn on the device it sends ON command to the HeatingPin Item. This triggers the “Map Pin to GPIO” rule which sends the ON command to the Item representing the specific GPIO pin that is attached to the correct relay.
This seems a little complex but one of my driving motivators was to avoid duplicated code where possible. Therefore, if one decides to run a boost for 10 minutes of the heater, the same “Heater/Cooling Check” rule gets called as gets called when the temperature changes. Adding new sensors and behaviors is easier now as well as all the code is in one place. So, for example, if one were to have second stage cooling instead of heating, the logic for second stage heating could be moved to the “Cooling Control” and no matter how cooling is activated the second stage will activate. If another relay were added to control another device (lets say you have a house fan not connected to the HVAC blower) you only need add the Items and add them to the right Groups and add a Check and Control rule to run it and you can leave much of the rest of the logic unchanged. So if you want to control this fan using a boost mode, you don’t actually have to copy that logic and reimplement it. Instead you just need to add the right Items to the right Groups.