Platform

Short-term rental smart home automation

Describe what your rental should do, in a sentence. Homatic builds the automation, runs it, and explains why it fired — across locks, thermostats, lights, sensors and your booking calendar.

Most smart-home platforms are built for a home somebody lives in. A rental is different in one way that changes everything: the building knows when it is occupied, because the calendar says so. Every rule below depends on that.

Write it in English

“Thirty minutes before check-in, set the thermostat to 72 and turn on the entry lights.” The builder reads your actual devices, produces a draft, and shows it to you before anything is saved. You review and adjust; nothing runs until you accept it.

Drafts are validated against reality, not just parsed. If a rule names a room that has no devices in it, you are told the room exists and is empty — not that it does not exist, which sends you hunting a typo instead of moving a device. If a room name is ambiguous, it is refused rather than guessed: with a Guest and a Primary Bedroom, “bedroom” is not a decision software should make on your behalf.

What you can automate

Trigger	Typical rule
Check-in approaching	Pre-cool or pre-heat, entry lights on, guest code activates
Checkout	Setback temperature, lights off, code removed after your delay
A device changes state	Door left open, leak detected, lock jammed, temperature out of range
A schedule	Nightly checks, seasonal changes
Another automation finishing	Chain a follow-up without duplicating conditions

Occupancy is a first-class condition

Rules gate on present, absent or any, optionally with “at least N minutes since checkout”. Mark a rule once per stay and it behaves like a task rather than a watchdog — it happens once per occupancy and then stays quiet, instead of re-firing every time a cleaner opens a door.

That flag is refused on smoke and CO rules. A life-safety alert that fires once per stay leaves a rule that still looks armed while a later, real alarm reaches nobody.

Rooms, not vendor menus

Devices group by where they are, not whose app they came from. A thermostat from one brand and a sensor from another in the same bedroom appear together, instead of under two different vendor accordions.

Area-level controls are derived from what is in the room plus what those devices can do — nothing to configure. Three things are deliberately excluded from any bulk action: locks and unlocks, door and valve hardware, and anything needing an argument. A bulk control is a verb with no parameter, and it can never do something the same tap on the device card could not.

Booking calendars

Two-way iCal sync works immediately with Airbnb, Vrbo and Booking.com. Direct PMS connections cover OwnerRez, Guesty, Lodgify, Hostaway and Cloudbeds, pulling reservations with guest details and rates where the vendor exposes them.

Where a PMS supports webhooks, changes arrive in seconds; otherwise reservations sync on a schedule. Either way the calendar is what your automations read, so a moved check-in moves the rules that depend on it.

When a rule does not fire

Every run is logged with what each condition was expected to be, what it actually read, and whether it was met — in your temperature unit, not the stored one. If a device could not be read, the log says that rather than showing it as a mismatch. You can ask the assistant why a specific rule has not fired and get an answer grounded in that log and current device state.