đŸ”„ Advanced Heating Control

Hi,

thanks for your reply.

I’m using a SONOFF TRVZB together with a SONOFF SNZB-02P in each room, using external calibration as the calibration method, as mentioned.

The recommendations and dependencies regarding the SONOFF TRVZB and external calibration were well described by the person who exposed this function in Z2M. “The Sonoff TRVZB has a built-in fail-safe mode whereby if the device has been configured to use an external temperature sensor and the external temperature has not been received by the device for more than 2 hours, the device will revert to using the internal temperature sensor
”, “A value of 3600 typically means the Zigbee device will report its state once every hour. It is advised to ensure this value remains under 7200 (2 hours) so that the device is still reporting during long periods of constant temperature
” Sonoff TRVZB External Temperature Sensor Calibration

As far as I know, most temperature sensors report at least once per hour by default. This is certainly the case with the SONOFF SNZB-02P, and the reporting interval can also be adjusted if needed. I’ve been using this setup since the very first availability of external calibration, and it has always worked perfectly.

For this reason, I don’t understand why a non-optional keep-alive every 10 minutes should suddenly be necessary.

Best regards

I found this very interesting looking project in HACS:

schedule_state allows you to create sensors that provide arbitrary values, based on the time of day and other criteria. Home Assistant can then use the state of these sensors to trigger other automations.

With a very nice functional looking dashboard card to show schedules

schedule-state-card image

@panhans could we use it together with AHC?
To set climate presets or temperatures for states, maybe based on number helpers or something like this?

Hi @panhans !!

long time no see :slight_smile:

Your blueprint works like magic. I’m loving it more and more every day.

There is however something that just now has thrown me off balance when I thought I had fully grasped how the whole blueprint works.

I work from home most of the days, and when I leave Home, I see that the system reacts and sets the target temperature to Eco. And this is beautiful. Full Stop :slight_smile:

As I was saying, most of the days work from home.

Long ago (2 years ago) I defined an input text to hold my different schedules, but I don’t typically change the schedules and it is always set to my “default heating schedule”. I thought I would be using this feature, but I simply forget to change the schedule when it is bank holiday
 Assume that I have not transitioned for months from my default schedule to the rest of the schedules that I have


My default schedule looks like this:

Note that I created this schedule long ago when I was not even working for my current employer, and my previous employer did not fancy WFH at all, which means that I would need to go to the office every day (hence the schedule that you see). And I have not switched schedules in years!

My recorder is configured to hold a few days span of data, but enough to proof that the active schedule has been indeed the default one (which corresponds to the image above).

My heating plan looks like this:

And today, the temperature has actually mimicked the heating plan

If my understanding of the blueprint is correct, what I see is not what should be expected from the blueprint right?

Meaning that,

  • even if the heating plan mandates taget temperature to be confort 22 and Eco 18.5 starting at 8am in the morning
  • even if I was home the whole day (presence = home)
  • knowing that party mode is set to off (see below)

given that the schedule that I have forces Eco from 8:30am to 4:30pm from Mon to Fri, target temperature should have had to be Eco within that timeframe despite the rest of the variables above, right :question:

Presence can’t override the schedule, can it?

I’m very curious to know what I’m missing!!!

Cheers!

Hi there

I just started implementing my smart home a couple of days ago and am now exploring this blueprint.
So far I encountered two things I would like to ask about:

  1. I use Bosch radiatior thermostats (II), and for one of them I receive this error message regarding calibration setting in Z2M z2m: Publish 'set' 'local_temperature_calibration' to 'HK-Thermostat Kinderzimmer' failed: 'Error: localTemperatureCalibration requires min of -25'. Does that has influence on the heating behaviour or is the heating controlled in another way? I fear it is influenced due to the following statement
    grafik
    edit: It seems there are other thermostats with the same issue in my environment → is this something that is known? If yes, how to tackle it (or do I need to replace the respective thermostats)?
    edit2: This seems to be a bug and is actively investigated atm - local_temperature_calibration error continues on 2.8.0 · Issue #30901 · Koenkk/zigbee2mqtt · GitHub
    I will try the second calibration method.

  2. I want to use this blueprint for a bigger room, where I have multiple radiator thermostats as well as multiple temperature sensors. For the thermostats this is fine as the blueprint offers to integrate all of them in one heating automation, yet I can only pick one temperature sensor. In order to get a mean value for the room temperature, I tried creating a helper (combination sensor), but the blueprint’s dropdown list doesn’t show this calculated sensor. How do I proceed to include the room’s mean value instead of a single temperature spot?

1 Like

There is something big
 :speak_no_evil:
AHC Integration

4 Likes

whats that?

First of all, I have to say, I do not follow this thread attentively enough to rule out that the following problems have already been addressed here, a quick search did not bring me to any result.

I currently use version 5.5.7, have exclusively Sonoff TRVZB thermostats and various external room thermometers. The thermostats/heaters are automatically controlled with these devices only with AHC, otherwise only manual in the Home Assistant Dashboard. In AHC itself, no extravagant settings have made, the usual I would almost say (window detection with sensors, scheduler for normal operation/holiday/illness, descaling drive, toggle helper for party mode/guests, number helper for comfort and eco temperature).
For 3-4 weeks, however, I have been observing different events that bring strange and seemingly mysterious attitudes. Some things seem to happen irregularly, others happen every Saturday e.g.
It actually only caught with the update to the “reconstruction” from offset/calibration to external temperature.

There would be, for example, the setting for the internal or external temperature source of the TRVZB - sometimes these are unexpectedly on “external_2” instead of “external”. Logically, with external_2, of course, nothing more happens on the thermostat, because no more data is coming. Can this be triggered by AHC? I wouldn’t know what’s going to change that right now. AHC is the only tool that speaks to my thermostats automatically.

Then there would be that, for example, the last three Saturdays at just after 11 a.m. several “comfort temperature” helpers were switched to 30 °C (usually 21 °C). The only thing I associate with this time is the descaling trip, which I have set in AHC on Saturday 11 a.m., but which should actually only be active outside of winter. Here, too, the history in Home Assistant points to AHC as the trigger.

Has anyone had similar experiences here and a solution or a workaround? The Sonoff TRVZB are also often represented. Mine are up2date - at least the Z2M, which is currently running in version 2.8.0, tells me.

What’s the point? What do you want to show?

Hi @panhans !

I can’t wait to see what you think about my (long) post. Your blueprint is a must-have for me. Can’t wait to fully grasp how it works!!

thanks!!!

Hi @panhans.
I installed your blueprint (v5.5.7) yesterday on my HA instance to automate my heating system. As a first test, I set up an automation for my bedroom (Fritz! Thermostat 302, external Aqara temperature sensor). Since the thermostat does not provide calibration entities I activated ‘Generic Calibration’ with

  • calibration timeout: 1min
  • minimum temperature difference: 0,2 °C
  • step size: auto
  • generic calibration:
  • generic calibration offset: 5 °C

As far as I understand the documentation, the automation will determine the difference between the internal sensor of the thermostat and the external sensor and add this difference to the target temperature of the thermostat. Right?

However, the room does not reach the requested temperature although the external sensor measures a temperature that is below the requested one. Also, I cannot see any automatic adjustment of the target temperature, neither in HA nor at the phyiscal thermostat.

As can be seen, the requested temperature (Eco) is set to 19,5 °C. The temperature measured by the internal sensor is 21,5 °C, the external sensor measures 18,6 °C. The target temperature displayed both in HA and the physical thermostat is 19,5 °C. The thermostat is closed.

I would have assumed that the automation adds about 3 °C to the target temperature since this is the difference between internal and external sensor so that the target temperature would become 22,5 °C and the thermostat would open again to increase the room temperature.

Do I miss something here? Is my understanding of the generic calibration correct and, if yes, why does the automation seem to ignore the temperature measured by the external sensor?

Thanks a lot for your help.

Regards, Sven

Oh boy, the problem sat in front of the computer as it is often the case :flushed:. I checked the automation again and noticed that I had put the entity of the internal sensor of the thermostat into field Room Temperature Sensor instead of the external sensor (very similar entity IDs). No wonder that the automation thought that were was no difference between the internal and external sensor and did not adjust the target temperature. After I corrected the configuration, it looks like this:

The difference between internal and external sensor is 19 - 17,8 = 1,2 °C and the automation enhances the target temperature from 19,5 °C to 20,5 °C accordingly. Now, everything seems to work as intended :blush:.

1 Like

Are you guys/gals using mini splits with this. I have to give it to the creator anywho wondering what type of systems are people using with ha I want a minisplit that works with ha natively

Something big is happening!

1 Like

Hi i have a problem with multiple schedules and motion sensor schedule(s).

Feature request :slight_smile:
It would be nice to allow Multiple Presence Sensor Schedules.

Keep up the good work!

1 Like

Not, atm. This may need a custom condition in order to block temperature changes. Will put this on my list.

Instead of on temperature you can set an entity_id, but its value will be read only on the point of time you’ve defined.

Seems your thermostat is unreachable or there are some problems / inteferences in your zigbee mesh. (Delivery failed) Which type of thermostat is this?

Thanks for the hint. Didn’t know that since sonoff didn’t release well documented changelog for the firmware updates. I will add a feature to configure the keel alives.

I will have a look. Thanks for the hint.

Just share a trace log of the point when you expect another behaviour. That would help the most.

I will add the option to set more than one sensor in the future release. As a workaround:

  1. You can try to set the entity in yaml mode. Don’t know if this works.
  2. Since the selector filters for device class temperature and domain sensor. You can setup a template sensor in order to calculate the mean value. Let me know If you need help. Here you can set the device class.
  3. Edit the blueprint and delete the filter in the sensor selector. reload you automation and you’re good to go. But you have to repeat this if you do an blueprint update.

What’s happening there? :smiley:

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.

Is physical change enabled?

I personally not but there are some people who do this. The automation should work with every climate entity.

1 Like

Just discovered this blueprint and it’s great for when we have guests over as I can customise the heating schedules for rooms that are otherwise not normally heated (or not much). However one sticking point is the hot water control. We have the Drayton Wiser system and the comprehensive integration exposes various hot water controls (button.wiser_toggle_hot_water, button.wiser_boost_hot_water, select.wiser_hot_water_mode) but these don’t form part of the Climate domain (and of course they don’t have a comfort temperature to set, as you don’t set your hot water temperature in that way). I am just wondering if there is a way I can use any workarounds to get it working with this Blueprint so I can set up Guest Mode and a Guest Schedule for my hot water controls - any thoughts?

Looks like an Integration based on ahc blueprint :wink:

2 Likes

I’m a little curious about that. Feel free to share the repo if you like. :wink: This was always my plan but never got into this. I’d just wrote a little rest based integration for fetching data of my energy provider. But instead of the default integration setup I had some ideas about fully customizable view for schedules ect. like Alarmo did. Lets say a completely independet dashboard.

A repo is currentlly not existing, is still on beta, but my functions are working great.
You can Test it later :wink:
Yeah, i also think about it to do it like alarmo :+1:t2:

2 Likes

This one worked for me, thanks for your help! :slight_smile: