Iāve noticed the same. I find itās when I update an automation, and they all āreloadā and it sets them to the max temperature setting. I havenāt found a workaround yet. My post seems to have gone unnoticed anyone else noticed this? My original post is hopefully linked below.
Iāve experienced the same (it didnt happen any more), in my case the thermostat went to 30 when there was an update of HA, after the soft reboot. The only way to solve this was to completely power down proxmox so that the ramses rf usb stick (in combination with honeywell evohome) had no power and then boot it back up.
Now when this adjustment triggers, all my TRVs go up from 22°C to the 24°C.
How do I get it to work so that only this one TRV has a special additional schedule without creating another helper?
the problem is that you only use 2 variables for comfort and eco for all configurations. if you set the comfort in the adjustemt, the value will overwrite the helper for the comfort variable. So in this case you have to create 2 separate variables for this room, than it will work!! But only until you will set some adjustements to one of the other configurations!..So at the end it will be better to set comfort und eco helpers for each of your 25 automations!!
Hmm, this shouldnāt happen since there is a keep alive option that force the setting of the temperature value periodicaly. Ther thermostat switches to external_2 as a backup when external data is missing for a certain duration.
I thought so, but why then the switch to external_2 as a backup? I read that the Sonoff TRVZB actually switch to internal, if from external for one (or was it two?) hours no more messages coming. In this case, the heater would still heat to some extent, although not very accurate.
Is physical change enabled?
Yes, physical change is activated - but I donāt think anyone on the thermostat has adjusted the comfort temperature. Seven radiators in seven different rooms at the same second sounds like a mission impossible
Or do you believe the error is in the option?
Iām currently working on turning the logic of this blueprint into a native Home Assistant integration to make it even more powerful and easier to use.
The only thing Iām missing is a catchy name.
Iāve had a few ideas, but Iām worried about trademark issues:
Climatix (Possible conflict with Siemens?)
Climatrix (Potentially taken by a company in Belgium?)
Atmox (Like atmosphere/ambience)
CLIMAXIS
CLIMAX (maybe also in use?)
ā¦
Do you have any creative or technical suggestions that capture this ādual-characterā (Heating & Cooling)? Iām open to anything ā let me know what you think!
I think I solved the issue myself. I had apparently not defined correctly the input selector. Although I had included all my schedules in the automation, the input selector was not correctly picking up my schedules, hence the automation was getting a 24x7 ON instead of the real schedule I wanted to have in operation.
the question will be: are there 2 different ways in the future to use AHC and will they be identical (i mean the support, bugfixing etc.) or is it a different version with different support!?
If its the same i would say the name should be the same as it is now! So everyone can find it!
I also had physical change enabled. I think there is some error in the logic somewhere which sees a refresh as the device setting max temp, which then adjusts the automation to copy it. I have disabled physical change and have not had that problem since.
I managed to figure this out using ChatGPT. You can install the Template Climate integration from HACS, then create a custom Climate sensor that maps the typical Climate sensor calls and modes onto your own device (eg: heat = turn on, auto = turn off, etc). You could I guess extend this to air conditioners and the like that are not exposed as Cimate entities natively in Home Assistant, as long as you have some way of controlling them.
In the traces of the automation right at the beginning where one of five conditions (calibration, scene, change, reset or position trigger) has to be met to go on, it says it stopped, because one of the conditions failed. I quite new to Home Assistant and automations especially. Where can I find out, which condition failed and why?
I have a question about the āDynamic Valve Positioningā setting. At the risk of making things more complicated: Would it be possible to configure the starting value at which the valve actually begins to let hot water through? For example, Dynamic Valve Positioning starts at 10% open. However, water doesnāt actually start flowing until the valve is 17% open. As a result, AHC will not actually start heating, until the Dynamic Valve Positioning reaches a value of 20%āassuming the calculation is performed in 10-percent increments. This issue is likely to affect most radiators.
Sonoff TRVZB already has similar functionality called āAdaptive Modeā, which can be flipped On/Off with a switch. In off state it seems āPessimisticā approach is taken - valve fully closes when temperature is reached.
Question is, is there a way to manipulate this switch as part of āscheduleā changes? (I prefer Adaptive mode at night for smoother and slower adjustment, and common mode during the day for faster heating in the morning).
I can flip it with separate automation using same schedule I use in this blueprint, but wanted to confirm if thereās a suggestion how to add it to this one, maybe as part of āAdjustment / Overridesā?
I use this for 2 years now, and it is working very well, the only issue i have, is that i have floor heating which is very slow to respond the start of heating.
It would be a nice feature to have to add a break of 10 minutes after heating for 20 minutes, both of that should be configurable, for best fitting.
Is help wanted to implment such a feature?
Hi there! Iāve been using **AHC for a while nowāhuge thanks for this project, itās been a lifesaver!
I ran into a bit of a cooling issue yesterday and wanted to check if this is expected behavior. According to my logs, my window entities briefly became āunavailableā. This triggered the automation to lower the temperature (which is correct), but unfortunately, the temperature did not restore to its previous state once the entities became available again.
Are there any recommended ways to ābulletproofā the blueprint against these types of sensor dropouts?