Sensor Control

FAN Configuration (Sensor Control)

Sensor Control is a framework-level feature that provides a centralized way to configure which Home Assistant entities provide sensor data (temperature, humidity, CO₂, absolute humidity) for each device.

Sensor Control is configured for FAN devices. CO₂ is still a supported metric inside that FAN-oriented configuration, but Sensor Control no longer presents a separate standalone CO2 device type in the options flow.

Purpose and Scope

Sensor Control is intentionally limited to choosing which existing entities provide sensor inputs. It does not create new entities and it does not contain device-specific automation logic.

The feature acts as a single source of truth for sensor wiring across all other features, sitting between raw devices on one side and features/cards on the other.

Resolver Precedence and Boundaries

The SensorControlResolver applies a deterministic precedence order, per device and per metric:

1. Compute an internal baseline entity ID from INTERNAL_SENSOR_MAPPINGS (expanded from {device_id} templates).

2. Apply the per-metric override from the sensor_control options tree:

   • kind = "internal" uses the internal baseline.
   • kind in {"external", "external_entity"} uses the configured entity_id only if the entity exists in HA.
   • kind = "none" disables the metric.

3. Invalid kinds or missing external entities fail closed: the metric is treated as unavailable (entity_id = None) and marked invalid in the source metadata.

Absolute Humidity Handling

Absolute humidity is handled differently from other metrics:

• indoor_abs_humidity and outdoor_abs_humidity are driven by the abs_humidity_inputs option tree (temperature + humidity inputs, or a direct absolute humidity entity).
• The resolver reports those metrics as kind = "derived" when abs_humidity_inputs is configured for that metric, otherwise as kind = "internal".

Integration with Humidity Control

Humidity Control uses SensorControlResolver to obtain indoor/outdoor temperature and humidity for each FAN device. The automation logic never hardcodes entity IDs:

• Internal default sensors are taken from INTERNAL_SENSOR_MAPPINGS.
• If the user configures an external entity for a metric, that entity is used instead — as long as it exists in HA.
• If an external entity is missing or invalid, the metric fails closed and is treated as disabled for that device.

This keeps Humidity Control logic simple and decoupled from how sensors are wired in a given installation.

Indoor Humidity Spike Configuration

The indoor humidity source also carries spike detection settings that feed into Humidity Control's indoor spike logic. These are configured in the Internal Fan Sensors group of the Sensor Control config flow:

Setting	Key	Default	Purpose
Spike enabled	spike_enabled	false	Enable/disable indoor humidity spike detection
Spike rise percent	spike_rise_percent	10.0	Percentage rise above baseline to trigger a spike
Spike window minutes	spike_window_minutes	5	Time window (minutes) for baseline comparison
Spike: Ignore Outdoor	spike_ignore_outdoor	false	Bypass the outdoor absolute humidity comparison so the spike triggers extraction unconditionally

When spike_ignore_outdoor is true, the indoor spike triggers fan extraction regardless of whether outdoor air is more humid than indoor air. This is useful for bathroom/kitchen extraction where you want unconditional moisture removal. See Humidity Control for the full decision logic.

The spike_ignore_outdoor setting can also be toggled at runtime via the HVAC Fan Card settings panel or via the ramses_extras/sensor_control/set_spike_ignore_outdoor WebSocket command.

A per-area spike_ignore_outdoor toggle is also available on each area sensor (configured in the Area Sensors group). It can be toggled at runtime via the ramses_extras/sensor_control/set_area_spike_ignore_outdoor WebSocket command, which takes device_id, area_id, and spike_ignore_outdoor parameters.

Absolute Humidity as a Hybrid

Absolute humidity is handled as a hybrid between Sensor Control and the default feature:

1. Sensor Control stores (per device and per side - indoor/outdoor) which inputs should be used to compute absolute humidity in the abs_humidity_inputs option tree:

   • temperature.kind can be:
     • internal – use the internal temperature metric from INTERNAL_SENSOR_MAPPINGS (the FAN's outside-flow/outdoor temperature).
     • internal_supply – use the FAN's supply temperature entity (see the note below on sensor placement).
     • external_temp – use a specific external temperature entity.
     • external_abs – use a direct external absolute humidity entity.
   • humidity.kind can be:
     • internal – use the internal humidity metric from INTERNAL_SENSOR_MAPPINGS.
     • external – use a specific external humidity entity.
     • none – humidity input is disabled.

2. The default feature's shared FAN diagnostic sensors include:

   • sensor.indoor_absolute_humidity_{device_id}
   • sensor.outdoor_absolute_humidity_{device_id}
   • sensor.fan_control_mode_{device_id}

   The absolute humidity sensors are now resolver-aware. When they update, they:

   • Use SensorControlResolver to read abs_humidity_inputs and resolve the correct temperature/humidity or direct absolute humidity entity.
   • Compute absolute humidity via the shared calculate_absolute_humidity() helper when using temp+RH.
   • Fall back to the original ramses_cc-based temp/RH entities when no abs_humidity_inputs are configured for that side.

3. This makes those default absolute humidity sensors the single source of truth for:

   • Humidity Control's automation decisions.
   • The HVAC Fan Card's status display and graphs.

Sensor Control itself does not generate these entities; it only controls what goes into the shared default-feature sensors.

Note: where is the "outdoor" RH actually measured?

On some FAN units (notably Orcon HR models) the reported outdoor relative humidity is measured inside the supply duct, i.e. after the heat exchanger and bypass — not on the untreated outdoor air. Pairing that RH with the outdoor temperature produces a wildly swinging dewpoint (a physical impossibility over short periods), while pairing it with the supply temperature yields a stable dewpoint.

Symptom: when the bypass opens, reported outdoor RH rises sharply while supply temperature drops — the same air, measured after cooling.

For those units, set the outdoor absolute humidity temperature input to "Internal (from FAN's supply flow)" (internal_supply) in the Internal Fan Sensors group, keeping the humidity input on the FAN's reported RH (internal). The outdoor absolute humidity sensor then pairs the reported RH with the supply temperature entity and tracks supply-temperature changes. The HVAC Fan Card automatically moves the outdoor humidity row next to the supply temperature (bottom-right) in this mode.

Integration with HVAC Fan Card

The HVAC Fan Card also uses the same resolver via the ramses_extras/get_entity_mappings WebSocket command. For each configured device it receives:

• Effective entity IDs for the metrics it needs to render.
• Source metadata so the card can show whether a value is internal, external, derived or disabled.
• Shared FAN diagnostics such as the control-mode sensor exposed by the default feature.

The card then:

• Renders the correct entities regardless of how they are wired.
• Uses color-coded indicators to show when a metric comes from an external sensor, a derived sensor, or is disabled.
• Uses the shared control-mode sensor to display whether the FAN is currently under manual override, Extras automation, or unit-native auto control.

For absolute humidity specifically:

• The resolver exposes indoor_abs_humidity and outdoor_abs_humidity in sources as:
  • kind = "derived" when abs_humidity_inputs are configured for that metric.
  • kind = "internal" when no configuration exists (the default behaviour).
• The HVAC Fan Card's Sensor Sources panel includes indoor_abs_humidity and outdoor_abs_humidity alongside temperature, humidity and CO₂, showing them as derived when Sensor Control actively drives the inputs.

CO₂ Support

CO₂ support is currently focused on using a dedicated CO₂ device as an external input for a FAN:

• Real CO₂ mappings are configured under the CO₂ group on the FAN device in the Sensor Control config flow.
• The resolver treats CO₂ like any other metric: it starts from internal templates (if present) and then applies the per-device overrides.
• CO2 Control automation consumes those resolved inputs, while the shared fan-speed arbiter decides the effective final command when multiple features want fan control.

This architecture leaves room to later extend CO₂ behaviour without changing how other features consume the data.

Area Sensors

Sensor Control also supports per-device area sensor definitions.

An area sensor entry lets you describe one room or zone contribution for a FAN device using a stable source_id plus user-facing metadata such as:

• label
• temperature_entity
• humidity_entity
• optional co2_entity
• optional co2_threshold_entity
• optional comfort_temperature_entity – per-area comfort temperature target (any HA entity with a numeric state: input_number, number, sensor, climate current temperature, etc.)
• fallback co2_threshold
• zone_id
• trigger_on_high_humidity – demand dehumidification whenever the area RH exceeds the humidity maximum, without requiring a rise (default: off)
• weight – per-source weight (0.1–10, default 1.0) used by the weighted aggregation strategy
• spike_rise_percent – percentage rise to trigger a humidity spike
• spike_window_minutes – time window for spike baseline comparison
• spike_ignore_outdoor – per-area toggle to bypass outdoor absolute humidity comparison for spike detection (default: off)
• whether the area is enabled
• whether area CO2 is enabled for that source

These area entries are consumed by features and cards as structured inputs rather than as loose ad hoc entity references.

How area sensors are used

• Humidity-related area inputs are shown in the HVAC Fan Card's Balance section.
• CO2-enabled area inputs are shown in the card's CO2 section.
• CO2 Control can use those mapped area sensors as trigger sources.
• Temp Control uses area temperature_entity and comfort_temperature_entity for per-area comfort evaluation — each area is evaluated independently, and zone demands are published for areas that need actuation. A global comfort_temp_entity can also be configured in the Internal Fan Sensors group as a fallback for areas without their own comfort temperature entity.
• The card can highlight which specific area source is currently contributing to a humidity, CO2, or temperature trigger.

This makes Sensor Control more than a simple per-metric override table. It also becomes the place where multi-room sensor intent is described for FAN-related features.

Multi-source aggregation

A device-level Aggregation group in the Sensor Control config flow chooses how the internal humidity source and all enabled, valid area sensors are combined into the "effective" indoor reading used by Humidity Control's balance-mode threshold checks:

Strategy	Behaviour
first_valid (default)	Only the primary (internal) mapping is used — historical behaviour
max	The source with the highest RH wins
avg	Plain average of all valid sources
weighted	Weighted average using each area's weight (the internal source has weight 1.0)

Unavailable or invalid sources never contribute. Per-area spike and high-humidity detection is not aggregated — each area is compared against the primary indoor source ("the rest of the house"), so a humid bathroom can't mask its own trigger or be diluted by dry areas.

Practical Scenarios

Sensor Control is particularly valuable when you have heterogeneous FAN hardware or when built-in sensors are not representative for the rooms you want to ventilate or heat.

Scenario 1 – Mixed Hardware

• FAN A has a full set of internal sensors (indoor/outdoor temperature and humidity).
• FAN B is missing some sensors.
• Using Sensor Control, both FANs can still participate in the same automations and UI:
  • FAN A uses internal sensors.
  • FAN B points specific metrics to external HA sensors located in better positions or on other devices.

Scenario 2 – Non-Representative Internal Sensors

• A FAN is installed in a technical room or attic, while the rooms of interest are bedrooms or living areas.
• Internal temperature/humidity sensors do not reflect the target rooms.
• With Sensor Control, you can map those metrics to external room sensors, while still using the same Humidity Control logic and HVAC Fan Card.

In all cases, the resolver hides the complexity and exposes a uniform "effective sensors" view to consuming features.

Configuration Walkthrough

1. Enable the Sensor Control feature in the Ramses Extras config flow.
2. Open the Sensor Control configuration:
   • Select the FAN device you want to configure.
   • Choose a metric group (indoor, outdoor, CO₂, absolute humidity, or area sensors).
3. For each metric in the group, choose:
   • Internal to use the default internal mapping.
   • External and select an HA sensor entity.
   • For absolute humidity groups:
     • Choose between internal/default, internal supply temperature, external temperature + humidity, or a direct external absolute humidity sensor.
     • If you select a direct external absolute humidity sensor, Sensor Control treats the default absolute humidity sensor as a pass-through for that external entity (no internal calculation).
   • None to explicitly disable that metric.
4. Repeat for other groups and devices as needed.
   • For area sensors, add one or more named sources and provide the humidity and/or CO2 entities that should represent that area.
5. Optionally configure the Comfort temperature (Temperature Control) field in the Internal Fan Sensors group:
   • Select an HA entity with a numeric state (e.g. input_number.my_comfort) to use as the global comfort temperature.
   • When set, this overrides the FAN's param_75 comfort setpoint for Temp Control automation and the HVAC Fan Card.
   • Leave empty to use the FAN's built-in param_75 (default behavior).
   • See Temp Control for the full resolution priority (per-area → global → param_75).
6. Confirm changes in the main Ramses Extras confirmation step.

The Sensor Control configuration flow also provides two read-only summaries to make complex setups easier to reason about:

• A global overview step in the main Ramses Extras options flow that shows only non-internal mappings per device, including absolute humidity inputs.
• A per-device summary in the Sensor Control group menu that lists the current non-internal mappings for the selected device before you pick a group to edit.

Once saved, the new mappings are immediately visible to Humidity Control, CO2 Control, and the HVAC Fan Card.

Data Flow Overview

At a high level, the data flow with Sensor Control enabled looks like this:

Device sensors (internal + external HA entities)
          │
          ▼
 INTERNAL_SENSOR_MAPPINGS + user overrides
          │
          ▼
 SensorControlResolver (per device, per metric)
          │
          ├──► Humidity Control automation (uses effective metrics)
          │
          ├──► CO2 Control automation (uses effective metrics)
          │
          ├──► Temp Control automation (uses effective metrics + comfort_temp_entity)
          │
          └──► HVAC Fan Card (via get_entity_mappings WebSocket)

This makes it clear that Sensor Control is the single source of truth for which entities are used as sensor inputs across features.

Back to: Home Prev: Humidity Control Next: System Architecture