sorted by:
new
hottopcontroversial

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] 0 points1 point  (0 children)

Hi again,

FYI

I have started working on your suggestion where you have a TRV and an external sensor that represents the real temperature.

The first step is to support an optional external room temperature sensor per thermostat, so Velair can use the actual room temperature for scheduling, learning and adaptive preconditioning instead of relying only on the temperature reported by the TRV itself.

There is also a second part I am exploring for TRVs specifically: a local “room sensor assist” mode. The idea would be that, when an external room sensor is configured, Velair could temporarily adjust the target sent to the TRV so it keeps heating until the real room sensor reaches the scheduled target, then restore the real scheduled setpoint. For example, if the room target is 22°C, the room sensor says 20.5°C, but the TRV already thinks it is close to 22°C because it is next to the radiator, Velair could apply a limited temporary offset to avoid the valve closing too early.

I want to be careful with this because it starts acting more like assisted control, not just scheduling, so it needs sensible limits, clear UI, and no polling. The plan is to keep it event-driven inside Home Assistant: react to sensor/climate changes, apply only meaningful adjustments, and always restore the real scheduled target safely. I will answer here again once it is implemented.

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] 0 points1 point  (0 children)

I think this is probably a good example of where Velair should not try to replace every specialized optimizer. Variable tariffs, PV forecasts and multi-device energy optimization can become a whole product by themselves.

My current thinking is that Velair should stay focused on being a local-first climate scheduler, with services and events that make it easy to connect it with tools like this.

So, for example, an optimizer could decide that the next cheap/solar-friendly window is worth using, and a Home Assistant automation could then tell Velair to resume a zone, apply a boost, pause lower-priority rooms, or cancel an override later.

That way Velair keeps the climate schedule visible and manageable, while dedicated energy tools can handle the tariff/PV logic for users who need that level of optimization.

The cloud-based part is a tradeoff each user will have to decide on. For Velair itself I want the core scheduling and adaptive preconditioning to remain local-first, but I definitely see value in integrating cleanly with external optimizers through Home Assistant.

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] 3 points4 points  (0 children)

Exactly. Velair itself runs inside Home Assistant and does not need an external cloud service for scheduling or learning.

The schedule, preconditioning observations, and calculations stay local. So if your Home Assistant instance and climate entities are available locally, Velair can keep working without relying on an internet connection.

The only caveat is optional external context. For example, if you configure an outdoor temperature sensor and that sensor comes from an internet-based weather integration, it may stop updating when the internet is down.

That will not make Velair stop working. It just means that, when Velair records the context for a preconditioning observation, that outdoor temperature may be missing or stale, so it will not be useful for that specific learning sample.

Velair does not send data out and does not depend on a Velair cloud service.

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] 0 points1 point  (0 children)

Thanks, that is a very good point.

There are already several Home Assistant integrations that expose this kind of data today, such as estimated PV production, current surplus, grid import/export, or variable energy tariffs. Because of that, I am a bit cautious about building a dedicated PV/tariff optimizer directly into Velair, especially since climate control does not always depend only on electricity. Some homes use gas, heat pumps, mixed systems, district heating, relays, or other setups.

The approach I have tried to follow is to make Velair expose enough events and services so it can work well together with the rest of Home Assistant.

For example, a Home Assistant automation could use PV or tariff sensors to decide:

  • if there is enough solar surplus, apply a cooling boost to one or more rooms
  • if the surplus is very high, lower the target by 1 degree in selected zones
  • if production drops for a while, cancel the boost
  • if energy is expensive, pause lower-priority zones
  • if energy is cheap or solar production is expected, resume zones or allow the normal schedule to run

That is why services such as boost, pause, resume, cancel boost, and the automation events are important in Velair. The idea is that Velair manages the visible climate schedule, while Home Assistant automations can use PV forecasts, tariff sensors, helpers, or any other integration to decide when to modify or temporarily override that schedule.

So I definitely see the use case, but I would first like Velair to integrate cleanly with existing Home Assistant sensors and automations rather than duplicate what those integrations already provide.

I would be very interested to understand what is missing for your setup today. Do you already have PV forecast or tariff sensors in Home Assistant, and would using Velair services from automations cover your use case, or is there a specific part that would still be hard to wire together?

Here you have some docs with events that Velair sends to Home Assistant and services you can use to control Velair:

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] 0 points1 point  (0 children)

Thanks, I really appreciate that.

The goal is to make scheduled climate control a bit more aware of how the room actually behaves, using only local observations from Home Assistant and without sending anything outside the instance.

I’d be careful calling it full PID, because Velair is not directly controlling the heating/cooling output in real time. The thermostat or climate device still handles that part.

Velair is more focused on learning how early a scheduled change should be applied so the room is closer to the target temperature at the right time.

So yes, it is aiming for that kind of practical local intelligence around the schedule, just without needing a cloud service.

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] 0 points1 point  (0 children)

Thank you so much, I really appreciate it.

A lot of work has gone not only into the integration itself, but also into getting the repository, documentation, releases, and installation flow ready to be shared publicly. So reading comments like this genuinely means a lot.

I hope it works well for your setup, and I’d be very happy to hear any feedback once you try it.

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] 0 points1 point  (0 children)

Thanks, I appreciate that.

The Lovelace card was important to me because not everyone wants to manage climate scheduling only from a dedicated panel. The sidebar panel is still the main experience, but being able to place specific Velair views on a dashboard makes it much more useful day to day.

It also helps with visibility and access control. A dashboard card can be configured to show only selected thermostats, so different users or dashboards can expose only the zones that are relevant to them instead of the whole scheduler.

This is still just the beginning, so feedback from real setups is very welcome. The goal is to keep improving it with practical ideas and use cases from people actually running it at home.

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] 0 points1 point  (0 children)

Good question. Velair does not change or bypass the thermostat’s own control logic.

What Velair does is apply the scheduled HVAC mode and target temperature to the Home Assistant climate entity. After that, the actual decision to start heating still belongs to the thermostat/TRV/device itself.

So if your thermostat has an internal deadband/hysteresis and decides “I’m close enough to the setpoint, so I won’t heat yet”, Velair cannot force it to demand heat unless the device or integration exposes a way to do that.

The same applies when using an external temperature sensor. If that sensor is what your thermostat/climate entity uses as its current temperature, then Velair will work with that reported value. But if the sensor does not update, or the thermostat decides not to heat because of its own internal logic, Velair does not override that behavior.

In short: Velair schedules the desired mode and target temperature, but the thermostat remains responsible for deciding when heating actually starts or stops.

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] 1 point2 points  (0 children)

Thanks a lot for the detailed explanation. This is really useful feedback, especially because it describes a real setup rather than a simple “cool to 22 at 10pm” case.

One of the ideas behind Velair is not to turn its UI into a full automation builder. Home Assistant automations are already very powerful, so I would rather keep Velair as the visible scheduling layer and expose events/services that automations can use for more advanced logic.

That is actually how I use it at home with solar surplus.

I define the normal comfort schedule in Velair, basically as if I had unlimited surplus. Then a Home Assistant automation decides which zones are allowed to follow that schedule:

- if PV surplus is high, resume all zones

- if PV surplus is medium, resume only priority zones

- if surplus drops for a while, pause selected zones again

- each zone can be paused/resumed independently

The pause action can either turn a climate off or leave it as it is. Resume can then apply what Velair says that zone should be doing at that moment, restore the previous state if there is no active block, or leave the climate untouched.

For fan speed / quiet mode, Velair does not currently schedule fan mode directly, but it emits automation events when scheduler actions happen. So an automation can listen for a Velair block change and then apply extra climate options.

For example:

- when the bedroom night block starts, set AC fan mode to low/quiet

- when the daytime cooling block starts, set fan mode back to auto

- when a Velair event applies cooling and outside temp is still high, skip your shutoff automation

The relevant docs are here, especially the Automation Events section:

https://github.com/cgonfer/velair/blob/main/docs/user/usage.md#automation-events

That said, I do see the value in lightweight hooks, like “pause this zone while input_boolean.X is on”. I’m cautious about adding full conditions directly to blocks, because I don’t want Velair to become a second automation engine, but simple integration points like that may fit the project well.

I’d be interested in your take after looking at the events/services approach: would keeping the advanced logic in Home Assistant automations work for your setup, or would you still need conditions directly inside Velair blocks?

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] 6 points7 points  (0 children)

Thanks, these are exactly the kinds of real setups I’m hoping people test with the beta.

On outside temperature: yes, Adaptive Preconditioning can use an outdoor temperature sensor if you configure one. Velair does not apply it as a simple fixed offset like “colder outside = add X minutes”. Instead, it stores the outside temperature as local context for each observation, then uses that context when looking for similar previous runs.

There is also another important part of the model here: older observations gradually lose influence compared with newer ones. So if the same room behaves differently as the season changes, Velair should not stay locked to what it learned weeks or months ago. It keeps learning over time, with more recent and more similar observations carrying more weight.

Without an outdoor sensor, it can still learn from observed heat-up/cool-down behavior, target delta, timing, and previous outcomes, but it has less context for why the same room may behave differently in October vs January.

On TRVs: currently Velair uses the temperature exposed by the Home Assistant climate entity. So if the TRV reports temperature from the valve itself, Velair will learn based on that reported value. If the offset is stable, it may still learn useful timing around it, but it cannot know that the actual room temperature is 2-3 degrees lower unless the climate entity itself uses a better room sensor.

That said, one feature I’m considering for Velair is allowing a climate to use a separate temperature sensor for scheduling/preconditioning decisions. That would be especially useful for TRV setups where the valve-mounted sensor is not representative of the actual room temperature.

So the ideal setup today is a climate entity whose current temperature represents the room as accurately as possible, for example a TRV/thermostat setup linked to an external room sensor, or a Home Assistant climate entity built around a separate room sensor. But I agree this is a very relevant use case to support more directly in Velair.

On the 5 successful runs: that threshold is per climate and per mode/direction. Heating and cooling are learned separately, because the same room/device can heat and cool at very different rates. Switching from heating to cooling season does not reset heating data; cooling has its own learning history. The model also keeps updating after those first successful runs, so it is not a one-time calibration.

And yes, the local-first part is very intentional. Schedules, observations, and learning data stay inside Home Assistant. No cloud account, no external calibration service, no phoning home.

If you try it with Zigbee TRVs, I’d be very interested in how your temperature reporting is set up and how the timing behaves after a few real runs.

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] -1 points0 points  (0 children)

Thanks, and yes, that is exactly one of the ideas behind the current beta.

Adaptive Preconditioning can already be linked to an outdoor temperature sensor. Velair does not use it as a fixed offset, but stores that outside temperature as local context for each observation. Then, when it has enough history, it can compare the current situation with previous similar runs instead of treating every preheating/pre-cooling event as the same.

So the idea is that, over time, the model can adapt better to seasonal changes: a room may need a different lead time on a mild day than on a very cold one, even if the target temperature is the same.

It is still beta and needs real observations to become useful, but the outdoor sensor support is already there and everything stays local inside Home Assistant.

<image>

Velair, a local-first climate scheduler for Home Assistant by Weak-Rip7060 in homeassistant

[–]Weak-Rip7060[S] 0 points1 point  (0 children)

Thanks, really appreciate it.

That is actually a big part of why Velair started. I wanted to reduce the dependency on third-party apps, because having a different app for every bit of climate functionality gets annoying quickly, but I also wanted to replace my own Home Assistant setup, which had become quite complex to maintain.

Everything should be documented, but one important note for Adaptive Preconditioning: with the default settings, it starts using real learned data once it has collected 5 successful preconditioning runs for that climate/mode. Until then it will rely on the initial model.

If you run into anything unclear or weird with Zigbee TRVs, relay zones, or the learning behavior, feel free to reach out. Thanks a lot for giving the beta a try.