For a number of reasons I want to replace my home thermostat with a rule. The heating system is an electric boiler. The whole home runs pretty much on mqtt.
The factors to take into account are: day and night temperature presets, high/low electricity tariff, maybe the anti-freezing temperature preset (below that heating will be ON regardless of the tariff). Tariff is also taken from mqtt bus, since it is dynamically switched by distributor 6 times a day and scheduled approach is not ideal. Maybe there’ll be some watchdog/alarm for the cases like home temperature’s not changing in time (sensor stuck) and not reacting to heating command.
One way would be to create a triggers from all that – temperature presets, sleep/wake up times, tariff change. Alternatively, I can just poll everything each, say, 60 sec., calculate a decision and fire an mqtt command.
Somehow I am more inclined to the second variant. Sending a repeated command to the relay (tasmotized Sonoff) may be silly, but makes no harm. In fact it may be even more fault-tolerant, in case of reboots or some state inconsistency.
What would you guys say? Triggers or cron, poll and tons of if-s?
Of course I will keep the old thermostat connected with a wired OR, as a last resort for anti-freezing.
I probably do your second option equivalent. Every time any of the items in the group used to calculate average house temperature is updates (received update trigger) Then it evaluates.
Since those items are diy temperature sensors it’s actually between 30-60 seconds
Then I run through the time of day to decide on a lower threshold temperature (it’s higher when I want it forced on ie 5-7 am And after 6pm till 22:00). During the day it drops to a lower threshold and goes off, but we manually operate it depending on if any windows open, no one home etc.
I have it both ways. Every room has a room handler that is triggered by integrity change, occupancy, set temp or ambient temp change. This will decide if the room needs heating and how much.
Every 15 minutes I run a rule that collects all the heating requests from the rooms and will set the new target for the heating system.
I’ve implemented this before in HestiaPi. I used an event driven approach mainly because the temperature sensor reports once a minute anyway and I wanted the system to immediately react to changes in the setpoints and modes. So I trigger the logic when the temp reading changes, the setpoint charges, or the mode changes. The logic calculates what state the heater should be in and then only send commands if the system isn’t already in the right state.
Rich, where did you keep the state of the system? Just a variable, file, db record?
Items. That’s what Items are in OH, state and a way to charge state.
I could use mapdb to restore on startup the state of everything but opted just to restore settings (i.e. setpoints and heading/cooling modeand wait for a temp reading before kicking off active heating or cooling.
If you’re not using Items for this, you are but using OH how it’s designed to be used.
Yes, I was surely planning to use items for setpoints, but did not think about storing the current heating state there. Hey, why not. Since I have a persistence service confugured, it will be backed by db. With a proper channel configuration it will even send mqtt command automatically. Thanks.
You said " logic calculates what state the heater should be in and then only send commands if the system isn’t already in the right state." Is this optimization necessary? Would it be a problem if the item will be commaned on every cycle regardless of its currents state?
So one has to ask, how are you controlling the system from OH then if not sending commands to Items?
Depends on the hardware and other factors. But it’s often a good idea to not do something if there is nothing to do.
For HestiaPi which is running in an RPi 0w with relatively involved logic spanning multiple rules we it’s fail safes and such. Not doing stuff that doesn’t need to be done is a big deal.
Just be aware that every time you send a command that’s going to go out to the devices.
You are right of course, it just escaped my attention that the heater item will have a state.