Climate Control Patterns.

Before building climate-control automations.

Prerequisites from earlier pages:

Areas and naming conventions in place. Per [Organizing Home Assistant for a Farm](/home-assistant/agriculture/organizing). The automations here reference entities by name; the names need to be deliberate.

Sensors in thoughtful locations. Per [Your First Sensor](/home-assistant/getting-started/first-sensor). A sensor in direct sunlight reads 5 to 10°F higher than actual air temperature — a climate-control automation acting on that reading shuts down heat when the crop is cold. Placement drives everything downstream.

At least one working automation. Per [Your First Automation](/home-assistant/getting-started/first-automation). The trigger-condition-action model is assumed knowledge here.

Hardware safety interlocks already in place. The collective's clear position: Home Assistant is not the safety system. A high-temperature cutout on the heater, a high-pressure release on the boiler, a flood sensor on the water system — these live in hardware, independent of any software. Climate-control automations in Home Assistant make operations more efficient and responsive; they do not replace the hardware safety line.

Building climate-control automations without these foundations produces automations that fire in response to bad data or that fail unsafely when something breaks. The foundations are load-bearing.

The basic control loop.

Every climate-control automation fits a common pattern: read a sensor, compare to a setpoint, act on the difference.

Sensor. The input. Temperature, humidity, VPD, CO2, soil moisture, light level, whatever is being controlled. Good sensors, placed correctly, produce the data the loop depends on.

Setpoint. The target value or range. 75°F for daytime, 65°F at night. 80% RH upper bound, 50% RH lower bound. VPD between 0.8 and 1.2 kPa. Setpoints are how the grower encodes the crop's requirements.

Comparison. The logic that decides what to do. "If temperature is above the setpoint, do X. If temperature is below the setpoint, do Y." The specifics depend on what actuators are available.

Action. Turning on the vent fan, activating the heater, closing shade cloth, starting humidification, opening a vent motor. Home Assistant sends the command to the actuator through whatever integration manages it.

Feedback. The sensor reads again a moment later. If the automation brought the environment back toward the setpoint, good. If not, the logic iterates — the next trigger firing prompts another action.

This loop runs continuously. Every sensor update triggers evaluation; automations either fire or do not based on the current state. The system reaches and holds the setpoint through repeated small corrections, not through one big command.

Hysteresis — the most common mistake.

A naive climate-control automation says "if temperature is above 75°F, turn on the fan. If temperature is below 75°F, turn off the fan." This does exactly the wrong thing when the temperature is near 75°F.

The sensor reads 75.1°F — the fan turns on. The fan running drops the temperature slightly. The sensor reads 74.9°F — the fan turns off. Without the fan running, the temperature creeps back up. The sensor reads 75.1°F — the fan turns on again. And again. And again. The fan cycles on and off every few seconds or minutes, which is terrible for the fan motor, terrible for the contactors, terrible for the utility grid during the inrush, and produces an unstable environment for the plants that experience the short temperature wiggles.

The fix is hysteresis. Two setpoints instead of one: a turn-on threshold and a turn-off threshold, separated by a deadband.

"Turn the fan on if temperature rises above 77°F. Turn the fan off if temperature drops below 73°F."

Now the fan runs when the temperature hits 77°F, continues running while the temperature drops through the 73-to-77°F range, and stops when the temperature reaches 73°F. The fan cycles at most a few times per hour rather than a few times per minute. The plants experience a gentler temperature profile. The equipment lasts longer.

Typical hysteresis bands by application.

Temperature (ventilation, heating): 2 to 5°F (1 to 3°C). Wider bands for systems with slow thermal response; narrower for fast-responding systems.

Humidity (dehumidification, humidification): 5 to 10% RH. Humidity responds more slowly than temperature in most spaces, so wider bands are appropriate.

VPD (combined temperature and humidity): 0.2 to 0.3 kPa. VPD changes more smoothly than temperature or humidity alone; a modest deadband is adequate.

Soil moisture (irrigation triggering): 3 to 5 percentage points of volumetric water content. Wider bands for longer irrigation cycles.

Light level (supplemental lighting, shade cloth): 20 to 50 μmol/m²/s PPFD. Light changes rapidly with cloud cover; wider bands prevent nuisance switching.

These are starting points. Specific operations, specific crops, specific equipment may benefit from different bands. The grower adjusts based on observed equipment cycling — if something cycles too fast, widen the band; if the environment hunts too far between switches, narrow it.

Home Assistant's Generic Thermostat integration implements hysteresis for simple temperature control cases, which can be easier than writing automations manually. For more complex control (multi-stage ventilation, multi-variable conditions, fail-safe logic), custom automations are usually better.

Setpoints that match the crop.

A working climate-control system has setpoints that reflect the crop's actual needs, not arbitrary defaults or round numbers.

Different crops want different conditions.

Lettuce: 65 to 75°F day, 55 to 65°F night. Tomatoes: 70 to 85°F day, 60 to 70°F night. Cannabis (flowering): 75 to 80°F day, 65 to 75°F night. Cucumbers: 70 to 85°F day, 65 to 75°F night. Propagation and seedlings: warmer and more humid than finishing plants. The specifics vary by variety and growth stage and should come from the grower's crop-specific knowledge or extension resources.

Day and night differ.

Most plants prefer cooler nights than days. The daily temperature differential (DIF — day minus night temperature) affects internode elongation, flowering, and other plant responses. An automation that maintains the same temperature around the clock misses an important growing lever.

Climate-control automations therefore need day/night logic. Home Assistant's sun integration provides `sun.sunrise` and `sun.sunset` states that can condition automations. For operations with supplemental lighting rather than solar daylight, the lighting schedule defines day and night.

Growth stages shift setpoints.

Propagation stage wants high humidity and stable temperature. Vegetative stage tolerates wider ranges. Flowering stage (for crops that flower) often wants slightly cooler nights and lower humidity. An automation that runs the same setpoints from seedling through harvest is a compromise for every stage.

For operations with sophisticated control, the automations can reference a "growth stage" variable that the grower updates as the crop progresses. Simpler operations adjust the setpoints manually as the stage changes.

Seasonal tuning.

Setpoints that work in summer may not work in winter. Winter ventilation with outside air at 20°F cools the crop too aggressively; the setpoint and the equipment sequencing need different logic for winter than for summer. A grower who tunes for summer and never revisits has a winter climate that struggles.

The pattern is to review setpoints seasonally (at least at equinoxes, ideally monthly) and adjust as needed. Some operations use season-specific "modes" that switch the entire control logic between summer and winter profiles.

Ventilation patterns.

Ventilation is usually the primary climate-control tool — moving air addresses temperature, humidity, CO2 depletion, and air circulation simultaneously. Several patterns serve different situations.

Single-stage exhaust.

The simplest. Temperature rises above threshold → exhaust fan on. Temperature drops → fan off. Appropriate for small greenhouses with one large fan or where staged control isn't available. Hysteresis as discussed above.

Two-stage exhaust.

Two fans (or one fan with two speeds). Stage 1 runs for moderate cooling; stage 2 adds capacity for harder cooling. The staging prevents using full capacity for light cooling work, which saves energy and reduces stress on equipment.

Typical logic: Stage 1 on at 75°F, off at 72°F. Stage 2 on at 80°F, off at 77°F. Stage 2 implies Stage 1 — if Stage 2 is running, Stage 1 is also running.

Variable-speed ventilation.

Modern EC fans or variable-frequency drives support continuous speed adjustment rather than discrete stages. The automation maps temperature (or other variables) to fan speed smoothly — 30% at 75°F, 60% at 80°F, 100% at 85°F. Provides tighter climate control with less on-off cycling than staged control.

Home Assistant supports this pattern through integrations that expose fan speed as a numeric value (0-100%). An automation can set the fan speed based on a template that evaluates the current temperature.

Passive ventilation (vents, louvers).

Many greenhouses have powered vent motors that open roof or side vents. The automation logic is similar to fan staging — open the vents as temperature rises, close as it falls — but with slower dynamics. A vent opening takes minutes; the control loop should not try to adjust faster than the vents can respond.

Combined passive and powered.

A common pattern in well-equipped greenhouses: open vents first (quiet, free), add exhaust fans as needed, add evaporative cooling or misting as last resort. The automation sequences through these stages based on how much cooling is needed:

- Stage 1: Open roof vents 25%. Temperature above 75°F. - Stage 2: Open roof vents 50% + side vents 25%. Temperature above 78°F. - Stage 3: Open all vents + stage 1 exhaust fan. Temperature above 82°F. - Stage 4: All above + stage 2 exhaust fan. Temperature above 86°F. - Stage 5: All above + evaporative cooling or misting. Temperature above 90°F.

Each stage adds capacity. Cooling back down reverses through the stages. Hysteresis separates the "on" and "off" thresholds for each stage.

Night ventilation.

Night ventilation handles humidity buildup and moisture removal. Different logic than day cooling — the goal is not to cool (nighttime outside air may be too cool), but to exchange air to reduce humidity and prevent condensation on surfaces. A common pattern: run exhaust fans briefly every hour overnight if humidity is above a threshold.

Heating patterns.

Heating is the counterpart to ventilation — needed when the environment falls below the lower setpoint.

On-off heating.

The simplest. Temperature below threshold → heater on. Temperature above a higher threshold → heater off. Hysteresis prevents cycling. Appropriate for most greenhouse heaters that are designed for on-off operation.

Typical logic: heater on at 62°F (night setpoint), off at 66°F. Daytime setpoints are usually higher and the heater rarely runs during the day.

Staged heating.

Multiple heating sources (primary boiler plus backup electric heaters, for example). Stage 1 handles most heating; stage 2 adds capacity during cold events. Similar logic to staged ventilation but in reverse — stages activate as temperature drops.

Radiant heating.

Heated benches, root-zone heating, or radiant floor systems respond differently from forced-air heaters. The thermal mass means slower response — turning the heat on produces gradual warming over an hour, not immediate. Hysteresis bands should be wider to account for the slow response. A narrow band with a slow system produces constant hunting.

Heat plus humidity.

In cold weather, heating can drop humidity to crop-stressing levels. Pairing heating with humidification (or at least monitoring for low humidity and alerting) prevents winter-dry-air damage.

Fuel-aware heating.

Operations that pay for heating fuel benefit from automations that minimize unnecessary heating. Heat only when needed; precool the space slightly before sunrise to reduce morning heating load; don't heat during daylight if the sun will handle the work shortly. These optimizations can produce significant fuel savings over a season.

Cooling patterns.

When ventilation alone can't keep the environment cool enough, active cooling enters.

Evaporative cooling (swamp coolers, pad-and-fan).

Moves outside air through a water-wetted medium, cooling by evaporation. Effective in dry climates, less so in humid ones. Typically staged after ventilation.

Logic: If temperature above 85°F and humidity below 70%, run pad-and-fan. The humidity check prevents running evap cooling when it won't help (high humidity limits evaporation).

Misting and fogging.

Fine water droplets cool air through evaporation similar to swamp coolers but distributed throughout the space. Usually operated in short bursts. Automations time the bursts and can condition on temperature and humidity.

Logic: Temperature above 85°F, humidity below 75%, no rain/irrigation active → 30-second mist, 5-minute cooloff, repeat. Hysteresis on start and stop thresholds.

Shade cloth and shading systems.

Automated shade cloths reduce solar load before cooling is needed. Deploy shade above a light intensity or temperature threshold; retract when the load drops. Shade operation is slow; the automation logic should account for the time the cloth takes to deploy and retract.

Air conditioning.

For operations that use air conditioning (often smaller propagation houses or precision-environment applications), standard thermostat control applies. Home Assistant's Generic Thermostat or climate integrations handle this cleanly.

Humidity management.

Humidity is coupled to temperature — cooling air raises relative humidity, heating it lowers it. Managing humidity therefore often means managing the ventilation, heating, and cooling together rather than independently.

Relative humidity vs. VPD.

Relative humidity is easier to understand but less actionable than VPD (vapor pressure deficit). VPD captures what plants actually respond to — how much more water the air can hold. [VPD-Based Control](/home-assistant/agriculture/vpd-control) covers the specifics. For climate-control automations, monitoring both is useful — humidity for human intuition, VPD for accurate control.

Dehumidification.

Active dehumidifiers are common in indoor operations, less common in greenhouses. Automation logic is straightforward — humidity above threshold → dehumidifier on, with hysteresis for stop.

More often, "dehumidification" in a greenhouse means ventilation when outside humidity is lower than inside humidity. The automation becomes "if inside humidity above 75% and outside humidity lower than inside, exhaust fan on." Requires outside humidity monitoring in addition to inside.

Humidification.

Underfoggers, evaporative systems, humidifiers. Logic: humidity below threshold → humidifier on, hysteresis for stop. Typically needed during winter heating or in dry climates.

Condensation management.

Dew point nearing air temperature means condensation is imminent — often on the lowest-temperature surfaces (plant leaves, cool walls). Condensation drives disease pressure. An automation can watch dew point vs. surface temperature (approximated by air temperature or measured directly) and ventilate or warm to prevent the condition.

Fail-safe design.

A climate-control automation that fires correctly when everything works is only half-designed. The other half is what happens when something breaks.

Sensor failure.

A sensor that stops reporting goes "unavailable" in Home Assistant. An automation that uses its state blindly may see `None` or `unavailable` and take unexpected actions. The automation logic should check for sensor availability before acting.

Pattern: before triggering on temperature, verify the temperature sensor's state is a valid number. If it's unavailable, send an alert to the grower and take no cooling or heating action (or default to a safe middle state).

A sensor that reports wildly incorrect values is worse than one that reports unavailable. A temperature sensor reading 400°F clearly has failed; an automation that acts on it by running the AC at full blast wastes energy and cools the crop inappropriately. Reasonableness checks in the automation logic catch this — "only act on temperature readings between -10°F and 120°F; anything outside this is a sensor failure, alert but don't act."

Actuator failure.

A fan that has failed won't cool when commanded. An automation should verify the actuator's state (is the fan actually running?) rather than assuming the command succeeded.

Pattern: if the fan should be on but the power monitor shows no draw, alert the grower — the fan has failed. Smart plugs with power monitoring, energy monitors on circuits, or vibration sensors on equipment all enable this kind of feedback.

Without feedback, automations assume equipment works when commanded. A failed fan that no one notices produces a crop disaster over a hot weekend.

Network or Home Assistant failure.

If Home Assistant crashes or the network goes down, none of the automations run. The environment floats until Home Assistant is restored.

This is why hardware safety interlocks matter. A high-temperature cutout on a greenhouse that shuts off the heater when the air temperature reaches dangerous levels protects against any failure mode, including Home Assistant being completely unavailable. The same for low-temperature heat backup for winter crops.

The collective's position is clear: Home Assistant improves operational efficiency and provides valuable monitoring and alerting. It should not be the sole protection against climate disasters. Hardware interlocks are the safety layer; Home Assistant is the operation layer.

Multi-sensor redundancy for critical controls.

For automations that take consequential actions (heating, cooling, lighting schedules), relying on a single sensor is risky. A failed sensor produces a failed control loop.

Pattern: use two or three sensors in each zone, average their readings (or take the median to reject outliers), and build the automation on the averaged value. A single sensor failure produces a modest error; two failures would have to align to produce a bad outcome.

Alternatively, cross-check: "only act if sensor A and sensor B both agree on temperature within 3°F." If they disagree by more, alert — something is wrong, don't act automatically.

Sample automation pattern.

A complete climate-control automation for a greenhouse zone might look like this, pulling together the patterns above:

The automation in practice is longer and more detailed — real production automations include additional conditions (time-of-day restrictions, humidity checks, outside-weather conditions), integration with other automations (don't fight with heating automation), and logging for diagnostics. The [Agricultural Automation Cookbook](/home-assistant/automations/cookbook) collects tested patterns that can be adapted.

Seasonal tuning.

The climate control that works in summer does not work in winter. The automations usually need seasonal adjustment.

Summer profile.

Aggressive cooling. Ventilation as the primary tool; evaporative cooling or shade cloth for harder loads. Heating rare. Humidity management focused on preventing high-humidity disease pressure.

Winter profile.

Heating as the primary tool. Ventilation only briefly to manage humidity and air exchange. Different setpoints — crops that tolerate 60°F nights in summer may need 65°F in winter because humidity profiles differ. Condensation management prominent.

Transition seasons.

Spring and fall shift between modes. Some operations switch automations between profiles at specific dates or based on average outside temperature; others use multi-variable logic that handles the full seasonal range in a single set of automations.

Review cadence.

At minimum, review climate-control setpoints at each equinox (four times a year). More frequently for operations with sensitive crops or tight margins. The review catches cases where setpoints calibrated for one season are now inappropriate — common and easy to miss.

Common failure modes.

Specific things that go wrong in climate-control deployments.

The sensor that reads the heater. A temperature sensor mounted too close to a forced-air heater reads the heater's exhaust, not the zone temperature. Heating automation runs, sensor reads 95°F, heating shuts off, zone is actually still 55°F and heating never restarts. The fix is sensor placement — farther from the heater, near the crop.

The sensor that reads the cold wall. A temperature sensor on a cold exterior wall in winter reads colder than the zone. Heating runs continuously to try to warm the wall. Fuel bills skyrocket; crop gets overheated away from the wall. Fix: place sensors where the crop is, not on cold surfaces.

The hysteresis band too narrow. Equipment cycles on and off every few minutes. Motors wear out early, contactors fail, utility inrush causes power fluctuations. Fix: widen the hysteresis band (from 1°F to 3°F, for example).

The missing fail-safe. A sensor fails (battery dies, radio drops, cable chewed by rodent). The automation using the sensor sees stale or invalid data and keeps acting. The climate drifts out of range. Fix: reasonableness checks and sensor-health checks before acting.

The heater that fights with the ventilation. Two separate automations — one turns on the heater below 65°F, the other turns on the fan above 70°F. On a sunny winter day with the heater still running from an overnight setback, the fan kicks on and the automations fight each other. Fix: single coordinated automation logic that handles heating, cooling, and ventilation together, ensuring they don't run simultaneously.

The sensor that was right but moved. A grower moves a sensor during crop change-out and forgets to update its name in Home Assistant. The automation for Zone A is now acting on Zone B's data. The climate in both zones drifts. Fix: physical sensor labeling, device discipline during crop change-outs.

The setpoint drift. Setpoints were adjusted for one crop; the grower plants a new crop with different needs and forgets to adjust the automations. The new crop suffers. Fix: setpoint review as part of every crop change-out protocol.

The weekend temperature spike. On a hot Saturday when no one is in the greenhouse, the cooling automation hits a failure mode — a fan that was marginal fails under load, no one notices for four hours, the crop is damaged. Fix: alerting on unusual climate conditions plus power-monitoring on critical equipment plus cross-sensor confirmation so the system catches the problem automatically.

What not to do.

Don't use a single sensor for all climate control in a zone. At least two sensors; more for zones larger than a few hundred square feet. Average or median the readings.

Don't skip hysteresis. Equipment that cycles rapidly fails early and is unpleasant to be near.

Don't trust a reading that doesn't make physical sense. Reasonableness checks belong in every climate automation.

Don't let different automations fight each other. Coordinated logic — heating, cooling, ventilation, humidification all in one mental model — beats independent automations that may conflict.

Don't forget to verify actuators actually ran. Feedback from power monitoring, vibration sensors, or state confirmation catches failed equipment before the crop suffers.

Don't let Home Assistant be the only safety line. Hardware interlocks handle the catastrophic cases. Home Assistant handles the operational ones.

Don't set and forget. Seasonal review, crop-change review, occasional full reset-and-tune passes all belong in the operational rhythm.

Don't automate control before notification has been reliable. If the temperature-high notification hasn't fired when expected, the temperature-high response automation shouldn't be running either.