Set "window open" on (Fritzbox) climate device

Feature Requests
,
Tags: #<Tag:0x00007fc407d09580> #<Tag:0x00007fc407d09418>
#1

Many TRVs feature a “window open” mode that is activated when the device detects a temperature drop. Having window open/close sensors, I would like to control that mode.

The Fritz DECT API offers a feature for that: sethkrwindowopen (and sethkrboost - also interesting!). So I would like see that feature exposed to Home Assistant. This could be done via the climate entitiy (new service / preset_mode / hvac_mode?) or via a seperate entity (maybe a switch?).

Looks like other smart home solutions already feature this:


#2

+1
I would love this!

I have a window sensor who should send window_open command to my AVM thermostat.

#3

+1!
would be great to set window open from an actual window sensor.
Window open usually comes with an open time though, so this might have to be considered as well.
(Same for boost mode)

I would like to set the climate device to window open when I actually open the window, and turn it back to window closed.
As a workaround, I can turn the climate device to “off” of course. But the problem is: I can’t easily turn it back on to the scheduled temperature. I could only turn it to comfort or eco mode, but would not know which mode is the correct one for this time of the day when the window closes.

I was able to add the window mode to the configuration.yaml, but only to read the status, not to set this. Would be great if this came out of the standard.
Here is what I came up with, maybe this is useful for anyone else:

sensor:
  - platform: template
    sensors:        
      dachgeschoss_windowopen: 
        friendly_name_template: "{{states.climate.dachgeschoss.name}} Fenster auf"
        value_template: '{{states.climate.dachgeschoss.attributes["window_open"] }}'
#4

@sevorl
I’m using the same workaround.

When I open my bedroom window in the morning, I send an off command to the thermostat.
Sending commands to the thermostat is easy, but the funny thing is data fetching/changing by my fritzbox.
If you’re lucky, then the thermostat is changed a moment after you opened the window.
Otherwise it can take (i think) up to 10min till the data is fetched by the fritzbox.

Anyway.
It works well and my eco mode of 16°C never turned on due too low temperature in my bedroom in winter after opening the window.

When i close my window, I wait for 10min to set eco mode again.
In best case it takes almost 20min to get back to eco - which is good imho.
So I never had the problem of “knowing” what temperature was set in the first place.

#5

it seems like many integrations make use of the same fritzapi, e.g. in node red.
Upvote this if you want to set window open or boost mode, maybe this gets added one day: support features for window open and boost · Issue #45 · andig/fritzapi · GitHub
(It is already in the code, but commented out because it was not tested)

#6

Done :slight_smile:

@sevorl How would you use window_open when it’s finally done?

Lets say you open your window for 30min, next day for 40min.
What would be your endtime for window_open when you don’t know how long it will be open?

#7

In the fritz.box configuration, you can set a time for window open. You can also set this time when you activate the “window open” mode manually. Usually something between 5-90 minutes.

In my personal setup, I want to use actual window sensors (Aqara). When the window is open, I would set the window-open mode for “a long time” (like 24 hours maybe?). When the Aqara sensor notices the window is closed, I would turn off the window mode on the climate device.

#8

I would set it to a short period like 10 minutes and refresh it every 5 minutes as long as the window is detected open. So just in case something breaks, the window open mode will deactivate itself soon.

I guess the TRVs will still try to automatically activate the window open mode on temperature drop, so to me this features is actually more about deactivating the window open mode once I know the window is closed instead of waiting for a preset timeout that is doomed to always trigger too early or too late.

One issue here is the unceraint delay of communication between the Fritz Box and the TRV. I guess to save battery power, the TRV periodically (and maybe triggered by events like user interaction) initiates communication to the box and then sleeps for several minutes. Thus we will probably observe the same delay no matter whether we send “off” or “window open”.

But still, I’d like to see these features (window open and boost state read and write) exposed to Home Assistant. I put the “Fritzbox” in the title in braces because I think this also applies to other climate devices and should be considered a generic (optional) feature of the climate device representation.

PS: @sevorl and @fragger please consider also voting for this thread to raise attention and direct more users to vote for the github issue.