Velair: local-first climate scheduling for Home Assistant climates

Share your Projects! Custom Integrations
,
21

Hi Roberto,

Thank you very much for trying Velair, for signing up to share this, and for such a detailed explanation. I really appreciate it.

If I understand correctly, you are looking for something beyond climate scheduling: a local assistant that could learn how each room reacts to the climate device, fan speed, outdoor conditions, doors, windows, sun and wind, and then suggest actions such as opening or closing a window at the most appropriate time.

Velair already provides some of the building blocks, but it does not currently support that complete use case.

Adaptive Preconditioning learns how long a room takes to approach a scheduled target. It keeps heating and cooling observations separate and can optionally use the current outdoor temperature to select similar historical observations. However, it does not currently include weather forecasts, humidity, fan speed, door/window states, wind direction or solar exposure in its learning model.

Room Assist can use an external temperature sensor to adjust the target sent to a climate entity. A calculated Heat Index sensor might technically be usable if Home Assistant exposes it as a valid numeric temperature sensor, although this is not a configuration specifically designed or tested by Velair. Care would also be needed if VTherm is already performing its own target correction, as having both systems adjust the target could create two overlapping control loops.

Velair’s Comfort feature can evaluate temperature and humidity together, but it is intentionally informational: it reports the current environmental condition and exposes events for Home Assistant automations. Windows and doors can also be used with the optional blueprint to pause a zone, but Velair does not currently learn their thermal effect or recommend when they should be opened or closed.

The complete system you describe would be technically possible, but it would be a considerable project. Each room would need enough observations for many combinations of season, outdoor temperature, humidity, wind, solar exposure, fan speed and opening state. It would also be difficult to determine which factor actually caused a temperature change. Recommendations involving humidity would need to consider values such as absolute humidity or dew point rather than relative humidity alone.

For that reason, I would be cautious about adding such a broad and difficult-to-validate model directly to Velair’s core.

A smaller and potentially useful direction could be an optional, local “ventilation opportunity” indicator. It could initially use clear and explainable rules based on indoor and outdoor temperature, comfort targets, humidity or dew point, window state, climate activity and perhaps the short-term forecast. It would only provide suggestions, without controlling doors, windows or climate devices automatically. Starting with deterministic recommendations would also let us evaluate whether learning is genuinely necessary later.

So the full proposal is not currently supported, but I do think the underlying idea is interesting. The narrower ventilation-assistance use case may be worth exploring, provided it can remain local, understandable and reliable without making the normal Velair experience more complex.

Thank you again for sharing your setup and the idea in such detail. It is very useful feedback.

22

@roberto.mango you may look at RoomMind:

it has its own panel and configuration is very easy.

Lately there are a lot of heating/climate projects i dont managed yet to try all.
Each doing something different than another one. Often i wish to use parts o them together to fit my use case.

What about Working together, sharing workload? Creating a modular system like Music Assist => The shiny new Room Climate Assist.
I have the impression the wheel gets discovered several times.

@CristianGonzalezFern i miss the blue my button to add the interation in the first post.

1 Like
23

@vajdum I understand the idea behind joining efforts instead of having several projects solving similar problems independently. In Velair’s case, however, the project did not begin with the intention of becoming an alternative to another integration.

It started from a personal need that I could not cover with the existing options, particularly in terms of usability and having a clear interface for managing climate schedules. I have developed other projects for my own use and kept them private, but I decided to make Velair public because I had benefited from the Home Assistant community for years without having contributed a project of my own.

Building a shared and modular climate platform is an interesting possibility, but coordinating its architecture, direction and long-term maintenance would require considerable time. Most projects in this space are maintained by individuals investing part of their free time, and I could not currently commit to something of that scale.

That does not prevent projects from exchanging ideas or collaborating on specific areas where their objectives align. These projects also evolve over time, so it is difficult to know where that might eventually lead.

Regarding Roberto’s use case, RoomMind would not currently cover the complete requirement. I could not find documented support for:

  • Recommending when to open or close windows according to forecasts, indoor conditions and the desired comfort level.
  • Learning the effect of individual doors and windows, including thermal interaction between adjacent rooms.
  • Learning the effect of different fan speeds on temperature and humidity.
  • Considering wind direction when evaluating natural ventilation.
  • Using perceived temperature or Heat Index as the comfort target.
  • Comparing natural ventilation with active climate control and advising the user accordingly.

Roberto would therefore still have the needs described in his original message. His proposal goes beyond climate scheduling or predictive control: it describes an advisory system combining thermal learning, weather, comfort and human actions. It is an interesting direction, but it would need to be introduced progressively and supported by enough reliable data for its recommendations to be understandable and useful.

About the blue installation button: my account can no longer edit the first post because of the time that has passed. I have contacted a moderator to see whether they can help me add it. Thanks for pointing it out.

24

i think there are often similar projects one not aware of the other.
I found roomMind in the new HACS repos, there was nothing in the forums here.

Currently i have a blueprint doing scheduling and adjusting target temp in case it gets too hot / cold (can not be used with sort of better thermostat integrations), an integration for flow temp, i would like to use something made to heat the room in advance, so its warm at a distinct time rather then me adjusting heating times for different weather (this would need the flow temp for learning). And an ASHRAE-55 based thing considering outside conditions on calculating comfort temperatures.

Maybe some of this projects could work together if they could be configured to expose / read some values to / from helpers rather than using real devices/sensors for them.

Another motivation for working together is the uncertainty with projects with only one developer (what happens with it on permanent lost of interest, dead, …)

A sound, smart heating logic is something HA misses and we have seen several things got really good and integrated into HA (mushroom cards, rhasspy for speech, Music Assistant, ESPHome) and are not very probable to die.

1 Like
25

I see your point, particularly regarding continuity when most of a project’s knowledge is concentrated in one maintainer.

Before building Velair, I was aware of—and tested—some of the alternatives mentioned. They covered parts of the technical problem, but I did not find them comfortable enough for everyday configuration and use. Usability was one of the main reasons I created Velair instead of continuing to combine separate integrations and blueprints.

I believe the single-maintainer risk is becoming less critical with modern AI-assisted development. A technically capable user can now understand and continue an existing codebase much more easily. It remains a bottleneck, as it does in small companies whose product knowledge depends on very few people, but it is no longer the same barrier it once was.

This is also why Velair has extensive documentation organised for different audiences. Users have dedicated guides for configuration and normal operation, while developers have separate documentation covering architecture, APIs, scheduler behaviour, internal features, testing and contribution workflows. Together with the automated tests, the goal is to avoid having essential knowledge available only to me.

I agree that interoperability through Home Assistant entities or helpers is preferable to coupling projects directly. Velair is already moving in that direction:

  • It exposes an increasing number of sensors, including scheduler information and per-zone control and delivery diagnostics.
  • It publishes runtime changes through velair_event, allowing automations to react to Profiles, Modes, Preconditioning, Room Assist, Comfort, targets, boosts and pauses.
  • Its interface can be reused through independent Lovelace cards, so users can include only the relevant information or controls in their dashboards.

Helpers could provide additional context, but each value would need a clearly defined meaning, unit and fallback behaviour. Otherwise, flexibility could introduce silent and difficult-to-diagnose errors.

Regarding ASHRAE 55, a complete implementation would require information that Velair cannot normally infer, such as clothing, activity, air speed or mean radiant temperature. A partial model based on explicit assumptions would still be possible. Similarly, the preconditioning model could incorporate additional variables such as outdoor or heating-flow temperature; technically, adding contextual variables is not the main difficulty. The important part is proving their usefulness and handling missing or unreliable data safely.

If you are interested in ASHRAE 55, flow temperature or additional helper-based inputs, please feel free to open a GitHub Discussion for each concrete proposal. That would give us space to define the expected behaviour, available entities and real use cases before deciding how they should fit into Velair.

For your current setup, Velair could already consolidate a substantial part of the logic:

  • Profiles and Modes can represent reusable schedules and different operating situations.
  • Room Assist can compensate for differences between an external room sensor and the climate device.
  • Adaptive Preconditioning learns when each room should start so it reaches the requested temperature at the scheduled time.
  • Comfort monitoring provides additional environmental context.
  • Sensors, events and cards make the resulting information reusable throughout Home Assistant.

Dedicated heating-flow control would remain external for now, but it could potentially provide context to Velair in the future.

Have you tried Velair with this actual setup? I would be interested in knowing what it already replaces for you and which concrete gaps remain. User proposals are an important part of Velair’s development, and understanding the complete scenario helps determine how to support it without making the system unnecessarily complicated.

26

I try to configure it:

There are a lot zone mentions in the readme.
Looks like zone is only another name for climate.
My climate devices are TRVs, sometimes more than one per room.

Temperatures in Heating plans, like 21 °C - by clicking the input arrows i can only chose 20,5 19,5 18,5 …

27

@vajdum You understood correctly: currently, a Velair zone represents one managed climate.* entity, not necessarily one physical room. Multiple TRVs in the same room are therefore managed separately, although Profiles and Modes can coordinate their schedules.

Would you expect to configure one room once and assign several TRVs to it? That is not currently supported, but it is a useful scenario to understand.

The temperature sequence you describe (20.5 → 19.5 → 18.5) is not expected. Could you share the climate entity attributes from Developer Tools → States, especially min_temp, max_temp, target_temp_step, precision, and temperature_unit? Please also confirm whether this happens in the Default schedule, a Profile schedule, or both, and whether values such as 20 or 21 can be entered manually.

28

Yes

number.trv_kuche_comfort:

min: 5
max: 29.5
step: 0.5
mode: box
unit_of_measurement: °C
device_class: temperature
29

@vajdum This is useful, but number.trv_kuche_comfort is a separate number.* entity. It confirms that the device supports 0.5 °C increments, but Velair reads temperature capabilities from the managed climate.* entity.

Could you also share the attributes of the climate entity selected in Velair from Developer Tools → States? In particular, I need to check whether it exposes min_temp, max_temp and target_temp_step.

If target_temp_step is missing from the climate entity, that would explain the incorrect arrow behaviour. Velair should handle that case more gracefully, but it cannot safely infer the relationship with a separate number.* entity.

I also understand your answer regarding multiple TRVs: you would prefer one logical room to control several climate entities. I will treat that as a separate feature proposal from this temperature-input issue.

30 
hvac_modes:
  - 'off'
  - auto
  - heat
min_temp: 4.5
max_temp: 29.5
preset_modes:
  - eco
  - comfort
  - boost
  - away
  - Open
supported_features: 17
31

That confirms the cause. Your climate.* entity exposes its temperature range but not target_temp_step. The related number.* entity uses 0.5, but Velair cannot assume that an unrelated entity controls the climate’s target step.

Because the climate does not report its step, Velair currently falls back to 1. The temperature input uses the climate’s minimum value, 4.5 °C, as the starting point for that increment. This produces the sequence 4.5, 5.5, 6.5 … 19.5, 20.5, rather than allowing every 0.5 °C value. That explains the values you are seeing.

I’ve implemented a fix for the next version. When a climate does not report its step, Velair will show a Temperature step field for that climate in Settings. It defaults to 1, so in your case it can be changed to 0.5.

Velair will also remember the last valid step reported by the climate. If it reports 0.5 and later stops exposing the attribute, existing decimal schedules such as 20.5 °C will remain valid, including after a restart.

Other than that, have you tried Profiles, Modes or Preconditioning, Comfort or any other feature yet? I’d be interested to know whether they fit your setup and where you still find friction.

Edit:

Already implemented
This is what you will see in the settings tab in the next beta / release

image
image607×163 11 KB

32

Hi @cgonfer,

Thank you for developing VelAir; it represents a significant advancement over traditional reactive control strategies in Home Assistant.
I am thinking out loud and respectfully suggesting potential enhancements that could further strengthen the scientific rigor and practical applicability of your integration. Please apologize the long message.

1. Optional Physical & Behavioral Context Inputs

VelAir’s predictive model could benefit from optional, configurable inputs that ground the thermal model in physical reality without increasing complexity for users who lack advanced sensor setups. These would be additive parameters with sensible defaults (disabled = current behavior):

  • Occupancy as Variable Internal Gain: Beyond binary presence triggers, occupancy could be modeled as a continuous internal heat gain. Configuration could allow users to select their available sensor modality per zone: PIR with configurable decay timers, Matter/Thread presence sensors capable of people counting, CO₂/humidity rise rate proxies, or appliance power monitoring (e.g., kitchen circuits) as measurable gains. Depending on the chosen strategy, occupancy would be treated as either a predictable disturbance or a simple on/off trigger.
  • Proactive Solar Gain & Shading Modeling: Solar radiation is one of the most significant predictable disturbances. Optional static room parameters (geographic latitude/longitude, window orientation, azimuth, glazing g-value, wall insulation class) combined with dynamic irradiance data could enable pre-emptive load adjustment. Crucially, this should also integrate shades/blinds position reported by Home Assistant. Knowing whether shades are open, closed, or partially deployed allows the model to dynamically adjust effective solar gain coefficients in real-time, significantly improving prediction accuracy for rooms with automated shading.
  • Perceived Comfort Target Adjustment: Dry-bulb air temperature alone often misrepresents actual thermal comfort. An optional “real feel” mode could dynamically adjust the effective target temperature based on humidity, mean radiant temperature proxies, and air velocity. For example, in high-humidity conditions the effective setpoint could be lowered slightly to maintain equivalent perceived comfort, while in dry winter conditions it could be raised. This would ensures the optimizer targets human comfort rather than an arbitrary air temperature value.
  • Window/Door Open State Pause Logic (Debounced): Opening windows introduces uncontrolled air exchange that invalidates predictive models. An optional binary input per zone could trigger a configurable pause, but only after the sensor has remained in “open” state for a user-defined debounce period (e.g., 60 seconds). This prevents false triggers from momentary door openings. Once confirmed open, the system suspends output until the sensor returns to closed + a configurable recovery timer, allowing the thermal model to reset gracefully after genuine ventilation events.

2. Emitter-Aware Output Control & Valve Management

Different emitter types have fundamentally different thermal dynamics. Supporting emitter-specific output logic and explicit valve management scope could improve both comfort and efficiency:

  • Radiant System Inertia Configuration: Radiant systems vary enormously in thermal mass. Traditional thick-screed floors have high inertia, but modern low-depth dry systems respond in minutes. VelAir should allow users to either select a predefined emitter type (high-mass screed, medium-mass thin screed, low-mass dry system) or have the integration auto-calculate thermal inertia from historical response data. This prevents overshoot in quick-response systems and ensures adequate pre-heating in high-mass systems.
  • Fancoil / Ducted Splits: Emitter-Specific Airflow & Capacity Modulation: Optimization strategy must reflect the underlying zoning topology, which applies consistently regardless of whether the medium is hydronic or direct-expansion refrigerant. VelAir should support these distinct architectures as selectable configuration modes:
    ** Centralized Zoned Distribution (Hydronic or F-Gas): A single emitter unit serves multiple zones via motorized dampers or dynamic vents for per-zone airflow fine-tuning. Each circuit has ONE shared capacity control element (mixing valve for hydronic, compressor/inverter for F-gas) and typically one fan. Per-zone output is modulated by damper position; aggregate capacity is governed by the shared valve/compressor. The optimizer must coordinate per-zone damper positions against aggregate thermal demand, enforce static pressure coupling constraints, minimum aggregate airflow for coil protection, and central unit short-cycle limits. If the integration can control the shared mixing valve (hydronic) or receives compressor state feedback (F-gas), it performs multi-variable optimization; if the unit’s internal board manages capacity autonomously, the scheduler modulates only dampers and infers available capacity from supply/return temperature or suction/discharge pressure feedback. This topology applies identically to standard hydronic fancoils + Airzone AND F-gas canalized splits + Airzone.
    **Multi fans fancoils (e.g., Innova Ducto Multi): A single hydronic unit serves multiple zones via independent fans per zone, but all zones share ONE mixing valve on the water side. There are no dampers; per-zone output is modulated solely by individual fan speed. The optimizer treats fan speed as an independent per-zone variable while recognizing that water-side capacity is a shared, coupled constraint. If the integration controls the mixing valve, it balances individual zone airflow against aggregate thermal demand; if the valve is board-managed, the scheduler modulates only fans and infers available capacity from supply/return feedback.
  • **Standalone Single-Zone Emitters: Any emitter (hydronic fancoil, F-gas split, radiant panel) serving exactly one zone with dedicated capacity control and no cross-zone coupling. Fan speed, valve position, or compressor modulation can be optimized independently per zone with no aggregate constraints.

3. Domestic Hot Water (DHW) Integration Tab

DHW production has outsized impact on space conditioning, especially with single-circuit heat pumps. A dedicated DHW configuration tab could address this systematically:

  • DHW Priority Scheduling: Allow users to define preferred DHW heating windows (e.g., midday solar surplus, overnight off-peak). VelAir could then pre-heat DHW proactively during these windows to minimize space conditioning interruptions during peak comfort hours.
  • Single-Circuit HP Interruption Awareness: For non-dual-circuit heat pumps, DHW production completely halts space heating/cooling for 20–45 minutes. VelAir should account for this predictable interruption by:
    • Pre-conditioning spaces before scheduled DHW cycles
    • Extending post-DHW recovery periods based on thermal mass
    • Avoiding aggressive setpoint changes immediately before known DHW demand
  • Dual-Circuit HP Mode: For dual-circuit systems, simply flag that DHW and space conditioning can proceed simultaneously, removing interruption compensation logic.

This transforms DHW from an unmodeled disturbance into a scheduled, predictable event that the optimizer can plan around.

4. Heat Generator Integration Paradigms

Most schedulers treat heat generators as abstract sources. Two distinct modes, selectable per installation, could be considered:

Paradigm A: Curve Shift (Generator-Led Control) Rationale: Minimizes integration risk; respects OEM tuning; compatible with any generator exposing curve shift parameters.

  • VelAir calculates required supply temperature offset (±K) based on predicted aggregate load and sends only the shift value via Home Assistant.
  • Question for consideration: Even in curve-shift mode, would calculating aggregated demand internally still be valuable for DHW scheduling, interruption anticipation, and multi-zone coordination logic — even if only the shift value is sent externally? The internal demand model may still inform better shift decisions.
  • Generator applies shift to its native curve, retaining all manufacturer safety limits.

Paradigm B: Aggregated Demand Signal (Scheduler-Led Control) Rationale: Enables true multi-zone coordination; prevents short-cycling; compatible when the generator accepts direct targets.

  • VelAir sums predicted zone loads + DHW + distribution losses into a single kW or flow temperature demand signal.
  • Generator modulates to meet demand within its operational envelope.

Both paradigms would benefit from configurable local safety bounds (max/min flow temp, max ramp rate) enforced by VelAir independently of generator feedback latency, preserving the local-first safety guarantee.

These suggestions are offered purely as constructive considerations for VelAir’s continued evolution. The foundation you have created is already exceptional.

Thank you again for your contribution to the community.

33

Not yet, need to read about Profiles, Modes and it was late. But i will.
Currently i have standard HA week schedules per room and per mode like normal, holiday at home.
They have “normal”, “holiday”, … included in there name and get used from the blueprint by selecting “normal”, “holiday”, … from a select helper.

Comfort - is there any automatic planned? What humidity boundary to choose considering its dependent from temperature? Thats what integrations like Thermal Comfort deal with - or every new ones implementing again :wink:

Diagnostics looks nice, better than looking at logs.

34

@vajdum Your current normal / holiday at home setup maps quite naturally to Velair. A Profile can contain the effective weekly schedules for one or more rooms, while a Velair Mode can activate the corresponding Profile or combination of Profiles through the native select.velair_mode entity.

Your point about humidity is valid. The current Comfort implementation was deliberately introduced as a simple and transparent foundation: configurable temperature and relative-humidity boundaries, with CO₂ and data quality kept as separate signals. It was designed this way so it could remain predictable while being extended gradually instead of starting with a large and difficult-to-understand comfort model.

Relative humidity changes meaning depending on temperature, so fixed boundaries alone cannot provide a complete comfort assessment. I am planning to extend this foundation with optional calculated environmental information. The initial candidates are:

  • Humidex, for perceived heat under warm and humid conditions.
  • Dew point, to better explain moisture and condensation conditions.
  • Absolute humidity, which is more useful than relative humidity when comparing air at different temperatures.

Velair could calculate this small set locally from the configured temperature and humidity sensors, without requiring another integration. Users could alternatively select an existing Home Assistant entity provided by Thermal Comfort, a template or another integration.

These values would initially complement the existing Comfort assessment rather than automatically change climate targets. This would keep Velair’s behaviour predictable while providing richer information for its interface, dashboards and automations.

If you already use Thermal Comfort, I would be interested to know which of its values you find most useful in practice and what you would expect Velair to do with them.

Glad to hear the Diagnostics view is useful — making runtime decisions understandable was precisely the reason for adding it.

35

Hi @glcparma,

Thank you for taking the time to write such a thoughtful message. You have given me quite a few things to consider, especially around the distinction between adding useful context to Velair’s learning and turning it into a controller for the entire HVAC installation.

The ideas closest to Velair’s current direction are the optional contextual inputs. Occupancy, solar exposure, shade position, open windows and predictable interruptions could all help explain why a room behaves differently from one cycle to another. My preference would be to consume generic Home Assistant entities and let Velair learn their observed effect, rather than asking users to provide glazing coefficients, insulation classes or other physical parameters they may not know accurately.

Window pauses are already available through the Velair blueprint. What I find particularly interesting here is the learning side: Velair should know that a window was open and avoid treating that period as a normal heating or cooling response. The same principle could apply to DHW cycles or other events that temporarily interrupt space conditioning.

Adaptive Preconditioning already learns each room’s response instead of assuming that every emitter behaves alike. Explicit emitter types could perhaps provide an initial hint, but I would be cautious about making them authoritative. Two installations using the same nominal emitter type can still behave very differently because of construction, hydraulic balance, control logic and room characteristics.

Comfort is another area I am actively extending. I would prefer to build this progressively: first measure and explain the relevant conditions, then provide careful recommendations, and only later consider optional target adjustments. Automatically changing a target based on perceived comfort needs to remain understandable and bounded, particularly when factors such as air movement, radiant temperature, activity or clothing are unknown.

The plant-level proposals require a different level of caution. Coordinating dampers, shared valves, compressors, flow temperatures, minimum airflow and short-cycle protection is highly dependent on the equipment and its native safety controls. I can see value in Velair exposing estimated demand or accepting external state through Home Assistant, but directly taking responsibility for those systems would significantly change the scope and risk profile of the project.

For DHW, a useful first step may be simpler: allow Velair to know that a scheduled or active DHW cycle will interrupt space conditioning. That could improve learning and preconditioning without making Velair responsible for managing the heat pump or DHW production itself.

I do not want to dismiss the larger vision, but I think it needs to be divided into smaller, testable areas. If you are interested, please open separate GitHub Discussions for the parts most relevant to your installation. Describing the equipment you have, which entities Home Assistant exposes and the practical problem you want to solve would help determine which ideas belong in Velair’s core and which are better handled through integrations, helpers or automation interfaces.

Of everything you described, which part would make the biggest practical difference in your current installation?

36

Hi @cgonfer,

Thank you for the thoughtful response. I completely Understand your philosophy that VelAir should remain a learning scheduler that consumes generic HA entities, not an HVAC controller.

Possibly the single highest-impact enhancement for the installation would be treating DHW cycles and window-open events as labeled interruptions in the learning model, rather than unexplained thermal anomalies.

From a physics standpoint, when the heat pump diverts to DHW or a window opens, the room’s thermal response deviates from its learned baseline not because the model is wrong, but because the boundary conditions changed.
If VelAir could accept a binary HA entity (e.g., binary_sensor.dhw_active or binary_sensor.window_open) as an interruption flag, it could exclude those periods from thermal mass/loss estimation and adjust preconditioning timing accordingly.
This possible requires no new control authority, no physical parameters, and no emitter-type definitions — only a generic entity input and a learning-mask mechanism.

Thanks again for your work on VelAir.

37

Another thing i want to try is using target temperatures calculated by ASHRAE 55/EN 16798-1.
This blueprint does it:

38

Just installed to use with my Honeywell T6 Pro Zwave Tstats. I was having issues with Ecobee Premiums and going to try zwave with local control instead so I can use manual sensors in each room.

I’ve combined 3 sensors into a helper group for downstairs (taking the median) and 4 sensors upstairs (median) and using that as room assist. I’ll see how that does or if it just runs all day and can never hit temp. I’m using Sonoff zigbee external sensors in multiple rooms to give it the readings. Thanks for setting this up. Hopefully it works as the room with the thermostat is 5-6 degrees cooler than the others…example 72 on the thermostat, sensor reads 71 in that room (echo dot in that room reads 67.5 but other upstairs rooms are 76.8 and 77.7)

Downstairs is usually with 1-2 degres but upstairs is usually way off.

39

Thanks for trying Velair and for sharing the details of your setup. Using the median should help prevent one noisy sensor from skewing the result.

The main thing I’d watch is whether the upstairs median represents the rooms you care about most. If the thermostat room is consistently 5–6°F colder, the system may satisfy the median while that room still feels cool. In that case, using the coldest representative sensor might work better.

Room Assist can adjust the target, but it cannot compensate for limited HVAC capacity or uneven airflow, so it will be interesting to see whether the upstairs temperature eventually settles or keeps calling for heat. The Diagnostics view should help show what target Velair is applying and why.

Please feel free to post any questions or observations. If something is clearly not working as expected, opening an issue is the best way to report it. For questions about intended behavior or possible improvements, the GitHub Discussions section is also a good place to continue the conversation.

40

Hi @vajdum, small update on this because part of what we discussed here is now available in Velair 1.8.0-beta.1.

Comfort is no longer only a fixed temperature + relative humidity rectangle. The beta adds a temperature-aware comfort model, so the acceptable humidity range can change depending on the current temperature instead of being completely flat.

It also adds optional calculated environmental values:

  • Humidex
  • Dew point
  • Absolute humidity

Each one can either be calculated by Velair from the configured temperature/humidity sensors, or linked to an existing Home Assistant entity from another integration or template. So if someone already uses Thermal Comfort or another integration for one of those values, Velair can use that entity instead of calculating it again.

This is still intentionally observational. Velair shows the comfort state, exposes sensors/events/attributes, and can compare indoor/outdoor conditions for ventilation context, but it does not automatically change climate targets based on Humidex, ASHRAE 55 or EN 16798-1.

About the EN 16798-1 / ASHRAE setpoint blueprint you mentioned: I think that is a related but separate question. If another automation is actively calculating and enforcing target temperatures, it could overlap with Velair’s own scheduling unless the responsibility is clearly separated.

The part I would like to understand better is what you would expect Velair to do with those calculated setpoints:

  • use them only as comfort information;
  • expose them next to Velair’s own comfort state;
  • allow a Velair schedule/Profile to read a target from a helper/entity;
  • or eventually adjust Velair’s target automatically within safe bounds.

The first two fit the current direction more naturally. The last two would need more design, because they change who owns the final climate target.

If you try the beta with your setup, I would be very interested in feedback, especially around whether the new temperature-aware comfort model and external metric sources cover part of what you had in mind.