RFC: Venting guidance

[RubenKelevra]

What is the feature?

I'm testing for half a year or so a system for recommending ventilation for each room and it is working pretty well now.

It takes into account the outside temperature and moisture, the inside temperature and moisture, the setpoint in the room and in case of the kitchen and the bathroom will take also a VOC sensor into account.

It will then recommend an open or closed state for the windows in each room, which obviously can also be used to turn on ventilation fans. I've also heard that window opening motors start to become a thing in home automation, slowly.

Description

Ventilation is hard. It's not always obvious when it's useful to open a window to reduce the moisture content of the room, as the outside moisture might actually be higher or equal if the temperature difference is accounted for.

Additional Information

That feature is essentially what dew point ventilation controllers are doing.

My controller is a bit more advanced, as it will ask you to stop ventilation, if the room gets too cold and will also take "bad air" via VOC sensor into account.

The development effort is basically done at this point tinkering with sane defaults over the span of the summer and a bit of winter.

RFC:

So I'm interested in what you're thinking, would that a useful feature for some of you?

Would that be sensible to add as additional feature to BT?

[folfy]

I'm doing something similar, but overall it requires quite a few things, like calculating absolute humidity (thermal comfort integration), determining the critical point temperature (mold indicator), and for ventilation also considering the forecast and "ventilation performance" (not really an issue with normal venting, but there's only so much air that a ventilator or dehumidifier can move).

So I like the idea overall, but there's two major issues:
a) This requires a highly individual setup, so not easy to implement in a generic way (lots of variables need to be created and documented)
b) I absolutely don't see this as part of BT. It's not related to the heating control at all, and I don't see any dependencies, besides using some similar sensors as a reference.

Therefore I can imagine this more as a totally seperate integration to be implemented. Besides having basic flaws like #1513 just barely analyzed rn, so not rly a good base for new features in my view atm.

Dewpoint vs absolute humidity

For determining if venting has a positive effect on humidity, ofc the dewpoint works as well as a reference. I'd recommend the absolute humidity though for any "is it rly properly worth it" comparison, and figuring out "how much" it helps -> You easily see how much drier the air is in absolute numbers. Compared to that, the dewpoint is a rather abstract, non-linearly scaling value.

[RubenKelevra]

Yeah maybe I wasn't clear enough: I'm already done with the work. Of course I'm using the absolute humidity delta.

a) This requires a highly individual setup, so not easy to implement in a generic way (lots of variables need to be created and documented)

I don't see a reason for much additional variables. This maybe makes sense for future iterations, if users report back that there's need for this. Otherwise I would just use what I found out works well here for me over the span of a year and gather feedback by shipping it.

I mean configuration is nice, but most people just want to tick a box and use it.

b) I absolutely don't see this as part of BT. It's not related to the heating control at all, and I don't see any dependencies, besides using some similar sensors as a reference.

I don't follow your argument. Why wouldn't that be a good part of BT? I mean many heating systems these days integrate ventilation, so it's pretty natural to have a heating controller also make recommendations when the air needs to be exchanged.

It's literally what the V in HVAC stands for 🤔

[wtom]

Just as a reference, this is my Template Sensor for Venting.

{% set dew_point_min = states('sensor.badezimmer_thermal_comfort_dewpoint') | float(0) - 1.0 %}
{% set dew_point_outside = (states('sensor.wetter_dewpoint') | float(10)) %}
{% set temp_diff = (states('sensor.badezimmer_snzb_02d_temperature') | float(0)) - (states('sensor.weather_temp') | float(0)) %}

{% if ((states('sensor.badezimmer_snzb_02d_humidity') | float(0) > states('input_number.ziel_luftfeuchtigkeit') | float(0)) and (temp_diff > 3) and dew_point_outside < dew_point_min) %}
Lüften
{% else %}
Nicht Lüften
{% endif %}

[folfy]

Oh yeah, I'm seeing this feature to be way more sophisticated 😅

I mean, you also wanna vent if it's spring and it might be warmer outside, or not? So you need a threshold for that, when it's "worth it" for you. Then add an AC in the mix or a dehumidifier, and it starts getting quite hard to give a universal answer to those things, what's even rly more economical.

The target humidity has to be set, but you'll again have at least different targets for winter and summer most probably, so it will also need to be an adjustable input, not just a fixed parameter. The threshold for venting is also a personal preference, and needs to be configurable. There are quite a lot of things to be added, even for the most basic version like you pasted there. I'm not saying "no way" of integrating it, but like BT is not a HVAC system, it's a device controlling heating and cooling atm (combining those is kind of mandatory, for both UI and control reasons). I mean we barely got cooling working properly afaik. Adding such feature to the current state of BT, just is gonna make the mess even worse. I'm not saying it couldn't be added, but why not just make it a separate, tiny integration "venting sensor"? Like for seperation of concern, those two don't have any dependency off each other. Maybe you make that a dedicated venting/humidity controller in the future, for ppl that rly have venting as a feature in their HVAC.

BT is a component, not an eco system. So if I buy a complete HVAC system, I buy a whole system of components, like when installing HA with various integrations. That's why I don't understand why it should be part of this integration instead of making it a separate component of HA.

Like the only somewhat common connection I see, is if the HVAC rly is combined, but even then one controller can deal ventilation, while the other does set the heat pump / source controls. In my view there is one dependency, which is when you wanna run in dehumidication mode instead of heating for example. But in that case I think there should just be a clear override interface and behavior defined between the two, like also more transparent to the user, besides being more modular and avoiding a giant monolithic tool. External override of BT is requested/needed anyway, no additional feature required for that at least.

@wtom
FYI, as I wrote before, I'd recommend using the absolute humidity in your check there, so you can do a meaningfull comparison like h_abs_in * 0.8 > h_abs_out, so only vent if there's at least 20% difference for example.

Like there is a correlation as you see, but 2°C dew point difference can have a lot of different meanings, depending on if your starting from a dew point of 5 or 15°C.

[folfy]

Also, TL;DR; why I wouldn't add any new, major feature atm, besides thinking that BT should be just a thermostat, as in not be giving venting guidance: #1568

So just make it a separate, tiny integration, like thermal comfort? Ppl might use other (i.e. versatile thermostat) or no advanced heating controller at all (e.g. because they don't even have smart heating at all), and still wanna be able to get a "venting" sensor, so if you rly wanna share it, then I'd say spend that extra hour and do it properly 🙃

[RubenKelevra]

@Folly the reason why it makes sense is because an AC can also be tasked with reducing the humidity. Some AC systems can also vent, so it makes perfect sense to calculate if it is sensible to do dehumidify or not.

If you don't want to use it guys, you're fine to not use it, so I can't really follow your critism here. Just don't tick the checkbox 🤷‍♂️

Anyway, having the humidity sensor in BT also allows for economical reduction of the heat, without increasing the moisture in the room too much. So BT can lower the setpoint if it's safe to do so without a high mold risk. And in case the venting is automatic, it can use venting to reduce the moisture while the room cools down.

[folfy]

@RubenKelevra I agree it might be controlling the same device, but still, temperature and humidity control are two quite different tasks in my view. Like yes, an AC can do both, but it's also two very different modes of operation, and it can only be either/or, not simultaneously. What's the argument in this, for two different functions being one instead of two integrations?

Like besides this argument, just for me to understand, what is technically, from a code point of view and also user point of view, speaking for adding it to BT over making it a separate integration? To be clear, I'd highly support the idea overall, I like it, but not rly in BT. I mean just some of the arguments I see against adding it in BT:

• Separation of concern (logic for both seems 95% independent, so except for the part of maybe controlling the same AC entity, see below)
• Higher modularity
• Better transparency for the user, which controller/logic is active / the commanding master
• Better debug-ability and traceability (smaller code bases, tickets don't need to be classified for what part is affected, smaller documentation is also clearer to the user, independent logs...)

Anyway, having the humidity sensor in BT also allows for economical reduction of the heat, without increasing the moisture in the room too much. So BT can lower the setpoint if it's safe to do so without a high mold risk.

That's the only point where I'd see some dependency, but in my view still comes down to two basic scenarios (also similar for venting):

• Minimal temperature set in BT and controlling. if hygrostat is satisfied (BT behaves as usual, no change)
• Hygrostat is calling for de-humidification, either by:
  • turning on a dedicated dehumidifier
  • enabling AC in dehumidifying mode (if available; BT override enabled, hygrostat in command of HVAC)
  • enabling AC/TRV in heating mode (fallback; BT override enabled, hygrostat in command of HVAC/TRVs)
  • asking user to vent

So the only real dependency between the two which I see, would be the control override flag for BT (#1446), which we need/should have anyway, or what else you're seeing?