An automation turns Home Assistant from a monitoring system into an operating system. The first sensor reports temperature; the first automation acts on that temperature — sending an alert when the greenhouse gets too hot, starting a fan when humidity climbs, sending a morning summary to the grower's phone. This page walks through building a first agriculturally meaningful automation: an alert when the greenhouse temperature exceeds a threshold for a sustained period. Every step is explained — the trigger that starts the automation, the condition that refines when it should fire, the action that does something useful, and the testing that confirms it all works. The pattern learned here applies to every subsequent automation. By the end, the grower has a working alert automation and understands the mental model well enough to build more on their own.
Before the first automation.
Prerequisites from prior pages:
Home Assistant running. Installed and onboarded.
A working sensor. At least one sensor reporting real data, per [Your First Sensor](/home-assistant/getting-started/first-sensor).
A notification destination. The Home Assistant mobile app installed and logged in (per [First Hour with Home Assistant](/home-assistant/getting-started/first-hour)). The app is the simplest notification path for a first automation.
If the sensor is not yet reporting real data, build the automation anyway — the structure is the same. Testing with realistic values comes later.
The automation mental model.
Every Home Assistant automation has three parts.
Trigger. What starts the automation. A sensor crossing a threshold, a specific time of day, a sun event, a state change on a device, a webhook, a voice command. An automation can have one trigger or several; any of them firing starts the automation.
Condition. A check that refines when the automation should actually run. The trigger fires, conditions are evaluated, and if the conditions pass, the actions execute. Conditions prevent automations from firing when they shouldn't. A temperature alert should probably not fire at 3 AM when temperatures naturally drop; a condition restricting to daylight hours addresses that. Conditions are optional — an automation with a trigger and an action but no condition just fires every time the trigger does.
Action. What the automation does. Send a notification, turn on a fan, set a target temperature, run a script, call an API, log a message. Actions can be sequential or parallel, with waits and branches for more complex logic.
The full sequence: trigger fires → conditions evaluated → if conditions pass, actions execute.
This model applies to every automation, simple or complex. Learning it in the context of a first simple automation makes complex ones accessible.
The automation to build.
"Alert when the greenhouse temperature is above 85°F for 15 minutes continuously, during daylight hours."
Why this specific automation:
Immediately useful. A real alert that protects real crops from real heat stress.
Covers trigger, condition, and action. A temperature threshold (trigger), sustained time plus daylight (conditions), a notification (action). All three parts of the model get exercised.
Includes a "sustained" pattern. The automation fires only when the condition has been true for 15 minutes — not on every brief spike. This pattern ("persistent" or "sustained" thresholds) prevents false alerts from transient sensor noise and is fundamental to good agricultural automation.
Easy to test. The grower can temporarily set the threshold low (75°F for example) to trigger the automation on demand during testing, then raise it to the real threshold.
Adapt the temperatures and thresholds to the specific operation and location. The collective's default is 85°F as a summer-day-too-hot signal for most temperate-climate greenhouse operations; adjust for specific crops and conditions.
Building the automation through the UI editor.
Home Assistant has two primary automation editors: a graphical one (easier for beginners, fine for most automations) and a YAML view (more powerful, sometimes necessary for complex patterns). Start with the graphical editor.
Settings → Automations & Scenes → Create Automation.
Home Assistant asks whether to start from a template or a blank automation. Choose "Create new automation" (blank) for learning purposes — templates are efficient later but hide the mechanics during the first one.
Give the automation a name.
Name it descriptively. "Alert when greenhouse temperature is high" or "Greenhouse Zone 1 high temperature alert" works. The name appears in automation listings and notifications; clarity pays off later.
Optionally add a description explaining what the automation does and why. Documentation that lives with the automation is documentation that stays current.
### Setting the trigger.
Click Add Trigger. Home Assistant shows a list of trigger types.
Select "Numeric state." This trigger fires when a numeric sensor crosses a threshold in a specified direction.
Configure the trigger:
Entity. Select the greenhouse temperature sensor (for example, `sensor.greenhousezone1_temperature`). As the grower starts typing, Home Assistant autocompletes from available entities.
Above. Set to 85. This is the Fahrenheit value. (If the system is set to metric, use the Celsius equivalent — approximately 29.4°C.)
For. Set to 15 minutes. This is the crucial "sustained" part — the automation fires only when the sensor has been continuously above 85°F for 15 minutes, not on every brief spike. Without the "for" setting, every momentary reading above 85°F would fire the automation.
The trigger is configured.
### Setting the condition.
Click Add Condition. A list of condition types appears.
Select "Sun" condition. This condition checks the sun's position.
Configure the condition.
Condition. "After sunrise, before sunset."
This restricts the automation to daylight hours. A greenhouse can get above 85°F briefly in the early morning or late evening as the sun heats up or cools down; during nighttime, 85°F is genuinely unexpected and the conditions might call for an alert anyway. The "daylight only" condition matches the common case where the alert is most actionable during working hours.
For a different operation or crop sensitivity, this condition can be adjusted or removed. The point is to exercise the condition capability.
### Setting the action.
Click Add Action. A list of action types appears.
Select "Call service." This action calls a Home Assistant service, which is how actions are actually performed.
Service. Select `notify.mobileapp
Data (service data). This is the content of the notification.
```yaml message: "Greenhouse Zone 1 temperature is {{ states('sensor.greenhousezone1_temperature') }}°F — above threshold for 15 minutes." title: "Greenhouse High Temperature Alert" ```
The `{{ states('sensor.greenhousezone1_temperature') }}` is a template — Home Assistant substitutes the current sensor reading when the notification sends. The message dynamically reports the current temperature.
The automation is now complete: trigger (temperature above 85°F for 15 minutes), condition (during daylight), action (send notification to the mobile app).
Save the automation.
Testing the automation.
An automation that has never been tested is not an automation.
### The trigger test.
Two approaches to testing the trigger.
Temporarily lower the threshold. Edit the automation and change the "Above" value from 85 to something below the current sensor reading (for example, 70 if the current temperature is 75). Save. Wait 15 minutes. The automation should fire and send the notification.
This is the most realistic test — the actual trigger fires on the actual sensor.
Use the manual trigger. On the automation's detail page, there is a "Run Actions" button. Clicking it executes the actions regardless of the trigger, bypassing trigger and conditions entirely. This tests that the action (the notification) works correctly.
Both tests are useful. Start with the manual "Run Actions" test to confirm the notification mechanism works. Then the real trigger test confirms the automation will actually fire when conditions warrant.
After testing, restore the real threshold (85°F or whatever was chosen) and save.
### The condition test.
The daylight condition means the automation does not fire before sunrise or after sunset. Testing this specifically is awkward because it requires waiting for the wrong time of day. For a first automation, the manual tests above are usually enough; the condition works correctly if the code is right.
For more confidence: the Developer Tools → Services page lets the grower manually test conditions by constructing a service call. Advanced and usually unnecessary for a first automation.
### What happens if the trigger fires but conditions fail.
The automation does not execute the actions. No notification is sent. This is often what the grower wants — a nighttime high-temperature reading was what the condition was designed to ignore. The automation log shows that the trigger fired and conditions were not met, so the grower can confirm the logic is working even when no notification arrives.
Looking at the YAML view.
Click the "more" menu (three dots) on the automation page and select "Edit in YAML." The editor shows the automation as YAML code.
It looks something like:
Understanding this YAML is optional for a first automation but worth a brief look. The structure mirrors the graphical editor's fields exactly — `trigger`, `condition`, `action`. Each has its own fields that configure it.
For complex automations, the YAML view becomes essential — some patterns are awkward to express graphically. For simple automations, either view works.
Switching between views. The YAML editor has a button to return to the graphical view. Either view can be edited; changes save to the same underlying automation.
Common first-automation mistakes.
A few patterns that trip up new automation builders.
Forgetting the "For" duration. An automation without a sustained-threshold check fires on every brief reading above the threshold. Sensor noise, a wind gust, an errant reading from a cheap sensor — any of these triggers a notification. The "For: 15 minutes" (or whatever duration matches the situation) prevents the noise-triggered alerts while still catching real problems.
Over-alerting. A greenhouse high-temperature alert that fires during every summer afternoon teaches the grower to ignore notifications, which defeats the purpose. Tune the threshold, the sustained duration, and the conditions so alerts fire only when genuine attention is warranted. A notification that arrives rarely is a notification that gets attention; a notification that arrives constantly becomes spam the grower silences.
Forgetting to test. An automation written but not tested is assumed to work but has not been proven to work. When conditions warrant it actually firing, discovering a bug is the wrong time to discover it. Test every automation, at least with the manual "Run Actions" approach, before depending on it.
Using a single sensor for critical control. For notifications, a single sensor is fine — the worst case is a missed or false alert. For automations that take action (turning off a heater, opening vents, shutting off irrigation), a single sensor's failure mode can cause real harm. Critical control automations should cross-check multiple sensors or include reasonableness checks. The [Advanced Automation Patterns](/home-assistant/automations/advanced-patterns) page covers these patterns.
Automating immediately what the grower is still learning. Automations that act on data the grower does not yet understand produce unpredictable outcomes. The collective's recommendation for a new grower: build notifications first (automations that tell the grower something happened) before control automations (automations that do something) for any given sensor or pattern. Spend a week or two watching the notifications before promoting them to actions. This builds understanding of when alerts actually fire and whether the thresholds are calibrated correctly.
Complex logic in the first automation. Keep the first one simple. Notification to mobile phone on a sustained threshold with a daylight condition is genuinely a useful automation and straightforward to build. Multi-branch logic with parallel actions and timers is for later. The [Automation Fundamentals](/home-assistant/automations/fundamentals) page covers the more advanced patterns.
Expanding the automation over time.
Once the first automation is running reliably, the pattern extends naturally.
More thresholds. A low-temperature alert (below 50°F, for example) alongside the high-temperature one. The same pattern with different numbers.
More sensors. The same alert pattern for every growing zone. Home Assistant's automation can reference multiple sensors, either in one big automation or in separate per-zone automations.
More action types. Alongside mobile notification, email notifications, SMS through a service like Twilio, voice calls, or integration with a team messaging platform.
Conditions that match the crop. A propagation automation with tighter thresholds than a finishing greenhouse automation. The conditions refine alerts to what matters for the specific zone's use.
Control automations (carefully). After notifications are reliable, promoting specific patterns to actual control — starting a fan, closing a vent, activating a sprinkler — is a natural next step. Always with safety considerations (hardware interlocks for critical functions, sanity checks in the logic).
The [Agricultural Automation Cookbook](/home-assistant/automations/cookbook) collects tested automation patterns specific to agriculture. Once the first automation is working, the cookbook is a good source of ideas for subsequent automations.
What to do next.
With a working first automation, options for the next step:
Build a dashboard that shows the sensors and the automation's state. [Your First Dashboard](/home-assistant/getting-started/first-dashboard) covers the design — a mobile-first layout with the greenhouse readings prominent and the alert status visible at a glance.
Add more sensors. More sensors enable more automations, more specific alerts, and a more complete monitoring picture. [Your First Sensor](/home-assistant/getting-started/first-sensor) covers the pattern.
Study the Automation Fundamentals. A deeper understanding of triggers, conditions, and actions unlocks more sophisticated automation. [Automation Fundamentals](/home-assistant/automations/fundamentals) covers the mental model in more depth and introduces advanced patterns.
Let the first automation run and observe. Sometimes the right next step is to watch the automation in action for a few days. Does it fire when expected? Does it miss anything? Does it fire too often? The answers inform how to tune it, and build the understanding that makes subsequent automations better.