OK, so first thing, you don’t need to use getstate() to get the value of variables that are in other expressions in the same ReactorSensor. You can just say, for example, HeatTime = (DeltaTemp / 6) + 2. If you’ve exported those variables that currently are the targets of getstate() in these expressions, that is also not necessary.
In order for this to really work out, you need ArrivalTime to be an actual date/time. You can do that with this expression: date( 2021, 01, 30, 08, 00 ). This sets not just a time, but a specific date (Jan 30 2021 in this example) on which you will arrive, which eliminates a problem I’ll describe later. The result of this expression will be a Unix Epoch time (time in seconds since midnightZ Jan 1 1970).
From there, you can easily compute the full date/time when heating should start: StartHeating = ArrivalTime - ( DeltaTemp / 6 + 2 ) * 3600. We have to multiply by 3600 because your units are hours, but timestamps are seconds (so 3600 seconds per hour applied).
Then an expression to see if it’s time yet: TimeToStart = time() >= StartHeating. This checks the current time against the computed heating start time, and if it’s passed, the expression result is true.
Now, in your ReactorSensor’s conditions, you make two groups:
- Group “Start Heating”
- Condition: Expression Value, variable “TimeToStart” is TRUE
- Group “Tick”
- Condition: Interval every 300 seconds (5 minutes).
The first group is your active group that will make the heater come on when it’s time to start heating. It’s just looking at the “TimeToStart” expression value, and if it’s true, that condition and its parent group will be true as well. The “is TRUE” activity for this group should turn on your heater.
The second group uses an Interval condition that just fires every 5 minutes, and this causes the expressions to be force-evaluated. Reactor does not continuously evaluate expressions that contain time values; you have to make it update. The Interval condition is good for this.
I mentioned earlier that there’s a problem with “hours only” use of ArrivalTime. It doesn’t consider that these conditions will be running continuously, so this logic can potentially fire every day (because date isn’t considered) and cause you heater to come on when you’re not there. Being more specific with that variable by making a full date and time resolves this.
The other thing not resolved in this logic is a way to turn it off and stop insisting the heat be on. Since TimeToStart will be true from the moment the anticipated start time is reached to forever more, you need a way to say “I’m not here any more, stop what you are doing.” You can do that either by disabling this ReactorSensor when you leave the property, or by adding, for example, a DepartureTime variable to hold another date/time when you are expected to leave, and amend the logic of TimeToStart to something like time() >= HeatTime and time() < DepartureTime. That’s just one easy way, there are many things you can do, many ways to approach it, it just depends on the semantics that work best for the way you use the property and want the heat to perform.
I would also caution you that you would be well-advised to build in additional safeties if you are controlling your heat by automated controls like this. There are dangers aplenty with running heating systems unsupervised, and given the natural instability of the Vera platform and the “nothing guaranteed” nature of ZWave and other subsystems, there are lots of opportunities for failures that could range in consequences from heating an empty house to an unexpected cold arrival to being greeted by a pile of ashes that was the building. Caveat user; the risk is entirely yours.
