I found this thread searching Fritz DECT climate.
The solution, you prepared for wurzel12 looks perfect for me. However, I would like to take care of two extra conditions. While in the FritzBox, the two states „comfort“ and „eco“ are set as two specific temperatures, there is another option: You can switch off the thermostats completely in a defined summer time period. This period should be excluded in the automation as well. And, there is another option, I think, that it would reduce the interaction of sensor and thermostat, concerning outdoor temperature. In my environment, there is no need to close the valves, when the outdoor temperature is above 16 °C.
My quick and dirty selfmade automation works fine, but as you could imagine, it should be improved.
Currently I have two automations working for switching the thermostat „on“ or „off“, while the „on“ automation sets the temperature simply to eco, not to the previous state:
alias: WC-Temperatur-Aus
description: Wenn das Fenster auf ist, WC-Thermostat ausschalten
triggers:
- entity_id:
- binary_sensor.sensor_2_contact
from: "off"
to: "on"
for:
hours: 0
minutes: 1
seconds: 0
trigger: state
conditions:
- condition: template
value_template: >-
{% set today = (now().month,now().day) %} {{ today <= (6,1) or today >= (9,15) }}
- type: is_temperature
condition: device
Device_id: ID von GW1000 Outdoor Temperature
entity_id: Aktuelle Temperatur von 355xxxxxxxxxx
domain: sensor
below: 16
- condition: device
device_id: xxxxx
domain: climate
entity_id: Fritz!Smart Thermo WC
type: is_hvac_mode
hvac_mode: heat
actions:
- device_id: xxxxx
domain: climate
entity_id: Fritz!Smart Thermo WC
type: set_hvac_mode
hvac_mode: "off"
mode: single
I replaced the unreadable YAML IDs by the text, which is shown in the UI. Now, I am wondering, if I should try to integrate the solution you showed for wurzel12 in October 22 into my version or if I can somehow manage to modify your solution? I am mainly interacting with the UI and do not understand everything, written in this blueprint.
@SmartLiving.Rocks I am having a problem with this automation. Everything works as expected but this one condition here before the start of a custom action. i think it does this because it expects a window sensor but i’m using zwave to use my own ring sensors i had from before and they report as a “safety” device in device class. i tried making a group sensor and having the settings in there set to appear as a window sensor but the automation still skips actions. it has to be this template thats breaking it, what would be a workaround for this? the ac turns off and on appropriately it just skips actions i put in.
Hi!
My intention is not specific for AVM products. I think, that AVM‘s strategy to reduce power consumption at the thermostat‘s battery intents on reduce the communication by using ULE DECT. In addition, I would like to reduce the amount of interaction, which would not only concern AVM. Thus, when shutting of the thermostat, the motor must move the valve and the display needs a refresh. This is avoided, when the complete control „sleeps“ in summer time, which can be defined by AVM, but, as I showed in my example, can also be build into the automation. And, moreover, I can avoid the closing of the valve, when there is no need to. That is, because the outdoor temperature is above of the temperature set in the thermostat.
For AVM, it is a little bit more complicated, because I set the temperatures for the two states „eco“ and „comfort“ inside the FritzBox. Thus, if I want to decide, wheather or not the thermostate should be closed in dependance of the outdoor temperature, I need to know, which temperatures have to be controlled. As an example, I do not want to close the thermostate, if it is in „eco“ mode, which is set to 15 °C in the FritzBox, and the temperature outside is 16 °C. However, if the thermostate is in „comfort“ mode, which is set to 21 °C, it should be closed. Currently, I use the „eco“ mode in this room most of the day and so I just have to decide, if the outdoor temperature is above 15 °C or not. I try to keep it simple, as my skills are not good enough for more sophisticated solutions.
I understand the intention, but to be honest, these two conditions go beyond what I would call a “simple” automation. Adding seasonal behavior and dynamic outdoor temperature checks introduces complexity that is better handled by more advanced logic.
There are already several established and more robust solutions in the community that fulfill exactly these kinds of requirements. They offer better flexibility and reliability than trying to pack all of this into a basic automation.
