Overview of my home assistant setup

I run my smart home on Home Assistant for integrations and state, and I keep most of the decision logic in Node-RED via the Home Assistant integration. Home Assistant gives me a consistent set of entities (sensors, lights, switches, climate, cameras). Node-RED is where I decide what should happen and when, then I call Home Assistant services to apply it.

The mental model is simple: compute the desired state, compare it to the current state, and only push changes when something is genuinely different. That one choice cuts a lot of noise.

A few patterns show up everywhere:

• One shared home/away mode (plus a manual override) drives most behavior.
• Most flows react to state changes, with a periodic reconciliation tick that re-applies intent in case an event gets missed.
• I target areas, labels, and groups instead of maintaining brittle lists of entity IDs.
• Anything that tends to flap (presence, lux, temperature thresholds) gets hysteresis and minimum-duration checks.

Presence and modes

Presence is the backbone.

Inputs:

• A binary “someone is home” sensor.
• An input_select used as a manual override (examples: Auto, Away, Visitors).

Effective mode logic:

• Override Away forces away behavior.
• Override Visitors forces home behavior even if presence is uncertain.
• Otherwise, presence decides.

Once that effective mode exists, every downstream system can reference it. Lighting, HVAC, power management, housekeeping: they all read the same mode and behave consistently. I like not having to debug three different definitions of “away.”

Hvac control (thermostat + fan)

I treat HVAC as a single decision step followed by a guarded apply step.

1. Compute what the system should be doing right now.
2. If the current state already matches, do nothing.
3. If it differs, call services to correct it.

Behaviors:

• Mode-based setpoints Away uses setback temperatures; home uses comfort targets.

• Time windows Setpoints shift by time of day (daytime, evening, and a couple of special midday windows).

• Energy-aware tweaks If local solar/battery metrics show surplus generation or a high battery state, I allow slightly more aggressive comfort targets during specific windows. This is one of those cases where “good enough” beats perfect optimization.

• Fan control with hysteresis The fan goes high only when a bedroom is hot and the room is occupied (occupancy/motion). It drops back to auto when the temperature falls or the room goes inactive. Hysteresis keeps the fan from bouncing around a threshold.

• Command rate limiting Thermostat writes are throttled (for example, one command per minute). This avoids bursts of back-to-back setpoint updates when sensors get noisy.

Lighting automation

Lighting is split into practical buckets, mostly based on how I want it to fail. A missed motion event is annoying. A porch light stuck on all day is also annoying.

exterior lighting

Exterior lighting is driven by a single “desired state” decision:

• It turns on during a sunset-to-night window when conditions match (for example: it’s dark and there is activity downstairs).
• It turns off outside that window, with a few exceptions (porch-only rules, visitor mode exceptions).
• Changes only get applied when the desired on/off state flips, which keeps service calls down.

motion-driven interior lighting

For rooms with occupancy or motion sensors:

• Motion turns lights on only in the right time windows and only when ambient light is low.
• Shutoff uses a Trigger (extend) pattern:
  • Turn on immediately on motion.
  • Turn off after a timeout if motion does not recur.
  • Extend the timer while motion continues.

This is one of those patterns that stays readable months later, which matters more than it sounds.

ambient-light (lux) automation with hysteresis

For rooms with illuminance sensors:

• Lux thresholds use a “for X minutes” requirement (example: 5 minutes) so passing clouds do not cause flicker.
• On/off thresholds use hysteresis (different values for turning on vs turning off) to keep behavior stable near the boundary.
• Some bedroom lights dim or shut off when daylight is already doing the job.

Power and energy management

Power flows are mostly about removing wasted draw without creating a house that feels “fussy.”

• Occupancy-based outlet control: Some plugs stay on while a room is occupied and can turn off after inactivity windows.

• Away shutdown: When the home goes to away, groups of switches and lights turn off together.

• Solar/battery integration: Solar production and battery charge state feed into the HVAC logic in selected time windows.

Safety and “left on” notifications

When the home transitions to away, I run a quick sanity check:

• Look at a few power-monitoring sensors (example: oven circuit load, living room load).
• If a monitored load stays above a threshold, create a persistent notification in Home Assistant.
• Deduplicate notifications so they fire once per away session, not repeatedly.

This catches the stuff you only notice when you are already halfway down the street.

Housekeeping automations

A couple of routines ride on arrivals and departures:

• Robot vacuum: Start after the home has been away for a short time. Send it back to the dock when someone returns.

• Override reset: When someone re-enters the home zone, the override can return to Auto, unless Visitors is active on purpose.

Cameras and entity refresh

I also have a small maintenance flow for cameras:

• A periodic Blink snapshot/refresh routine triggers updates so the camera entity stays current.
• This helps with integrations that only refresh on demand.

It stops the “why is the last snapshot from yesterday” problem.

Philosophy

The principles are about not getting annoyed by my own house:

• Everything still works in ‘dumb mode’ if someone uses the manual switch, or Home Assistant dies
• One shared home / visitor signal, used everywhere.
• Hysteresis and minimum duration for noisy sensors (presence, lux, temperature).