Mind you Iām not the the in charge of leaving doors and windows open around here so it can get messy.
Yep you could do that, Iād do a date change (or maybe noon each day depends when you wish to sample temperatures) then adjust your input number based on that difference (youāll probably need to have ann āoffsetā added to the mix) Just create a template sensor, test the outside_sensor against these limits and output the result. Do you need help with that ?
Better still (based on your last post) fire an automation at the same time everyday then write the result to an input_number
Again, do you need help or are you okay from here ?
So in your case ā¦
The reason Iād go with a 10 minute base cycle is a) to bisect your 15 minute update every āotherā time (lessened if you go with brahmafearās suggestion of extra sensors, so Iād coincide with the sensor update values (as this will save Valve Motion thus Batteries) @15 mins
So you mean in my case, do you mean an initial āmark-timeā of 10 minutes , or a duty-cycle of 10 mins?
My āsensorsā are the eTRVs. Not obvious to me as to why I would go and procure another 6 thermostats? The eTRVs do this job, or supposed to - granted not as well perhaps as 6 wall thermostats , but this is the entire reason for the OP? I have eTRVs in 6 rooms but I would not want to use these to aggregate some overall measure because each room is heated to a different setpoint.
This brings me to the reason for confusion. I did admittedly set out to simply things above by using a single eTRV and use suggestions around duty-cycle and monitoring to adjust future duty-cycle durations. However, I actually have 6 eTRVs each at different setpoints and each driving the same single boiler in the home. So actually, it isnāt straight forward because of course any given duty-cycle will be heating mutliple rooms to different setpoints. Iām confused now as to how to deal with this. It was easy-ish when using a single eTRV, one duty-cycle, one mark-timer, and a single heating demand with a single boiler.
Head hurts Not sure what to do now.
Thank you to all the inputs by the way @tosion@CaptTom@brahmafear@Mutt@Sand but prob need more input/ideas on this.
automation:
trigger:
- alias: Varastoheat_off_2
platform: state
entity_id: input_boolean.varastoheat
to: 'on'
for:
minutes: >
{% if states('sensor.ulko_temppi') > 0.0 %}
{{ 4 }}
{% elif 0.0 < states('sensor.ulko_temppi') < -5.0 %}
{{ 6 }}
{% eif -5.0 < states('sensor.ulko_temppi') < -10.0 %}
{{ 10 }}
.. you get the idea ..
{% endif %}
action: ..
EDIT
p.s. your logic needs tweaking as your comparators do not account for equality.
For example, what if the sensor is 0.0 ? Your logic doesnt account for this. It only considers >0 or <0 but not 0. Same for other temps. Adjust the template code I gave - accordingly - but assuming these are linear levels as in +4 ā¦ 0 ā¦ -5 ā¦ -10 then I would suggest:
{% if states('sensor.ulko_temppi') >= 0.0 %}
{{ 4 }}
{% elif 0.0 < states('sensor.ulko_temppi') <= -5.0 %}
{{ 6 }}
{% eif -5.0 < states('sensor.ulko_temppi') <= -10.0 %}
{{ 10 }}
.. you get the idea ..
{% endif %}
Back to my problem. Iām stuck guys with the logic given 6 eTRVs I have and that they all output their own heat demands via generic_thermostat component, and the endpoint for all these is a single boiler switch. Help !
sorry, editing my post as you sent yours. see my previous post.
Not sure what you mean - sorry? The temperature will always be changing will it not, it depends on the resolution of your sensor. For example, if the resolution is 0.0000001 then it is āforeverā going to change , is it not?
I meant as an example. If āforā starts to ācountā 4 minutes when outside temperature is +0.1 C and when during the counting outside temperature changes to -0.1 C.
Does it stop after 4 minutes or 6 minutes or at all? Do you understand what I mean?
Good question. The trigger should be reset to start counting again if the change is across the boundaries, for example from +0.1 to -0.1 will start counting again for 6 minutes (when it was counting for 4 previously). Programmatically I would not expect the previous āticksā to count toward the āforā. However, I am unsure as to whether this is how it actually operates. Logic deduction does not necessarily mean that is how the world functions !
If this is undesired, then you would need a different template probably better using the template platform and using a template_value. in fact, this is probably more prudent than my original suggestion - in environments where your sensor is changing as described.
Your numbers donāt seem to match up but by adding an extra threshold you can get them in, the point is as ninjaef says - you get the idea (but the above is āleanerā than ninjaefās
The value ākicks inā as the āfor: valueā when the trigger for that happens so you can update every 30 seconds if you want, it wonāt care (the time is then set in concrete).
NOTE: You ALWAYS need an ELSE to complete an IF but you can have 0 to 1000ās of elifās as long as they march in the same direction
I real life I think this would be a minimal problem. I think it would be very rare and on the other hand if in this example case the switch would be on max 10 minutes (instead of 4 or 6). It would not be a disaster.
The other sensors may update quicker is all I meant.(see ā*ā later)
Determining if your boiler should be on or not : -
UK heating systems have a bypass (or should to be ālegalā) this may result in one of your rooms getting hotter than the rest
Donāt these eTRVās try to modulate to achieve the āset temperatureā ??? (ā*ā Iām really confused about how these valves operate, thereās conflicting information here)
The other classic way of doing this is monitor each sensor value, either average them or take highest or take mid point between those two. use that as the āsensor valueā for a generic thermostat (software based) and output that to a template switch, have another automation turn on the boiler if your mark space and the template switch are both āonā (the āmark-endā of this is the bit you monitor to adjust the mark-space)
Note: will be AFK for about 2 hours
Xcept that the mark-space should start at the point the boiler comes on so the automation will have to cater for the exception
They all are set as an immutable 15min tx periods but the phasing will for sure be different as they were not all powered up at the same time.
They get hotter because the eTRVs do not completely close off the valve (another issue). Also rooms heat up at varying levels of speed because other parameters are at play such as room size, compass direction of room (i.e. south rooms warm up quicker than north) , radiator size, time of day, and so on - as I alluded to in my OP.
This is a prudent insightful suggestion. I will scribble out some ideas on paper.
Can you elaborate please , Iām not grasping the concept / your terminology.
Thank you both @ninjaef@Mutt very much for excellent help. I am sorry I can not help OP too much.
My English is definitely not from London, so I have to try my best to understand everything I am reading - so my stupid question here still is:
The value ākicks inā as the āfor: valueā when the trigger for that happens so you can update every 30 seconds if you want, it wonāt care (the time is then set in concrete).
Do I understand correctly here - the right answer in this case is 6 minutes?
Correct! that is my understanding.- sort of (!) - because the automation mode will define what the outcome will be. Read onā¦
As @Mutt asserts, the trigger event is processed each time the event occurs. However I would elaborate on what @Mutt mentions because it isnāt so cut and clear. An important clarification is that how the triggers are handled is user defined by you using the mode: key/value pair (Automation Mode). Read onā¦
If you have a trigger condition then the code is executed when the trigger condition is met.
If the trigger event is fired multiple times then they are honoured in a certain way - which can be configured. For example one can have multiple āstackedā responses to triggers processed in chronological order , or each triggered event can āreplaceā the previous event. Called āAutomation Modesā (see below). You can thus enforce whatever you want in terms of how your automation will respond to changes in your outside sensor. For example, set mode: restart to restart your for: counter each time the outside temp changes - if that is what you want. Other mode values can change this behaviour. My impression is that you need to set a mode because the default does nothing but issue a warning into /config/homeassistant.log file.
Each time your outside temp changes, as you suggest it will, then changes in outside temp within 4 , 6 (or whatever) seconds are going to be processed according to the mode , so think about it and set it explicitly. I still abide by the golden rule I learnt back in the 1970s coding in Z80A assembler:- In software, never assume anything !!
Itās all explained as per link above, and othersā¦
I am a curious about your heating system in OP . I am not familiar with British heating systems, but basically you have hot water circulating in 6 radiators with those thermostats (honestly I did not quite understand the system). Which part you are trying to control with HA. The water temperature (some water heater)? Doesnāt those thermostats control them self the amount of hot water in each radiator based on set value in the thermostat? And the thermostat itself has the temperature sensor included and that value is transported to HA in every 15 minutes? So is the only thing you will control with HA the water heater? Right? Or is there a way to control the valve in radiator?
Not sure what to do now.
