Climate

Vacation rental thermostat automation

Heating an empty house for three days is the cost. Handing a guest a cold one is the review. Both come from the same gap: the thermostat has no idea whether anyone is there.

Homatic’s automations know, because they read your booking calendar. That single fact makes the difference between a schedule and a rule that actually fits a rental.

The four rules worth writing first

1. Pre-arrival comfort

A set number of minutes before check-in, bring the property to a comfortable setpoint. Booking-driven, not clock-driven — so a late check-in moves it, and a cancelled stay never fires it at all.

2. Checkout setback

After checkout, fall back to a holding temperature. Add once per stay and it happens once, not again each time a cleaner triggers a sensor that afternoon.

3. Vacant-property protection

Gate on occupancy: present, absent, or any, with an optional “at least N minutes since checkout”. A property with no completed stay yet fails the grace period rather than passing it, so a freshly connected home does not fire an alert on day one.

4. Freeze protection

If the indoor temperature falls below your floor, raise the setpoint and notify. This is the rule where the retry machinery earns its place: cap the attempts and attach an escalation, so a thermostat that cannot be reached tells you instead of retrying into the void.

Details that decide whether a rule works

A repeating rule with no cap and no alert is flagged. It retries for as long as the conditions hold, which is correct for “hold this setpoint” and wrong for “keep trying”. It is a warning rather than a refusal, because unbounded is genuinely right for a maintain-this rule.

Temperature comparisons are normalised before comparing. You think in whole degrees Fahrenheit; the thermostat stores Celsius. 71 °F is 21.666… °C, while a threshold typed as “71” saves as 21.7. Compared strictly, a thermostat sitting exactly on target still reads as below it — so a rule that sets a setpoint and watches that same setpoint never satisfies itself and re-fires forever, every run logged green. Rounding to a tenth of a degree is coarser than the conversion error and finer than any threshold a person means.

A rule targeting its own boundary gets a warning. If a condition’s threshold and an action’s setpoint are within half a degree, the rule is fragile however the numbers round, and the builder says so.

Everything is stored in Celsius and shown in your unit. One canonical representation, converted at display — including in the AI assistant, which converts at the tool boundary and refuses a setpoint that is implausible in the unit it claims. “Set it to 72” arriving as Celsius would otherwise be silently pinned to a safe maximum and applied as 95 °F.

An unreadable thermostat is not a cold one

A device the poll could not read yields no answer, not false. Counting it false let one offline thermostat veto an entire rule indefinitely, with nothing reporting why — because “I could not read this” and “this does not match” were the same value.

Unreadable devices are now excluded from the decision, with a guard: a rule where nothing is readable never fires. If your rule’s claim is genuinely about every device — “if all the windows are closed, arm” — there is a switch to require them all, because that is your call and not something the conditions reveal.