Maybe some of you have a solution for my sensor. I have a temperature sensor to my boiler that can be heated with two energy sources. I have created this template trigger sensor to update another somewhat virtual temperature sensor I use to calculate the energy created by each sensor using further templates. In short I want the following sensor to only update when switch.burner_on is active, and otherwise retain its value. When the switch is off I want it to ignore all updates. This new sensor does not copy any values but increments its own based on the diff calculated from the difference between trigger.to_state and trigger.from_state. The sensor works kind of. When the switch is turned off it enters “unknown” and resets to 0 which is not what I want. If I skip handling this case it turnes to “unknown” itself instead. I do not understand why.
The configuration check confirms that nothing in your configuration will prevent Home Assistant from starting. It doesn’t necessarily confirm everything in your configuration is functionally correct.
If you move the condition into state, the template will still have to report a value for the case when switch.burner_enabled is off.
Thanks @123
Yeah I did not see the condition in the docs but thought it might be worth a try. Was hoping the check would tell me it was not supported although I do understand it cannot evaluate my templates.
As you can see the “off” condition of the switch should be covered by the “else”. Although when the switch is off I end up getting the state unavailable which I guess then gets in a bad loop possibly setting itself to unavailable with the return of this.state. (this is why I added the “return 0” cases) I don’t really know how to debug this but returning 0 ruins my usecase as it jumps.
Thanks man. Had not thought of the case where trigger.from_state may not have a value. Also added an availability block to my sensor and will now try it out.
Thats great. Just wonder about the case when its not, the state still has to be updated hence the “0” right? Hopefully the availability entry gets around this as it seems the value block never runs if the conditions in it are not met. Still the issue of missing the from_state of course, but maybe I’m asking too much. The switch could definatly be unavailable when HA starts as it belongs to a ESPHome device.
This looks very nice! Thank you. I noticed that the sensor did never update, just kept the last value. And removing the has_value from the trigger solved it, so thanks. I’ll try this new one. I was hoping to put the from_state also as an availability condition to avoid updates when there is none. Zeroing my sensor messes up the data I’m trying to generate so let’s see if I can add id.
Edit:
Tested just some now including some HA restarts without zeroing data and updates seem to work (the switch has been on though, but the off case should be simpler).
I took your example code and refactored it to better suit my styling and moved the has_value checks to the availability section to avoid the updates when they are not.
@123 After letting this run for a while I can see they are already several times it zeros. I am not using your code straight of but with my mods, although it has the exact same logic I would say. I purged the history of my sensor after the last change. The source sensor looks steady.
Any thoughts? They are lots of possibilities to get zero but maybe the most likely is this.state not providing a value for some reason? I have not restarted HA while this has happened. I’m considering ignoring negative values so that the zeroing does not generate positive changes, this as I use the data in a Utility Meter only monitoring positive changes. That solution may work fine but its a bit sad I don’t get the negative development then as well.
This may or may not have anything to do with it but does sensor.temperature_boiler have any attributes whose value changes? Because when it changes, it will trigger the State Trigger (even if the sensor’s state value remains unchanged).
No, the sensor.temperature_boiler does not have any attributes. The sensor is read from an ESPHome device and from what I can see it seems to be continuous throughout the time of these screenshots.
The screenshots you posted don’t have identical time periods. Can you re-post them for the same time periods so that I can see the relationship between the source sensor and Template Sensor.
Wouldn’t you know. Look at that… Has to be the culprit. The source sensor actually has missing samples in it (or this may just be that it is unavailable?). Just did not show when zoomed out. Wonder why this case is not handled with the availibility block having trigger.from_state in it. Or do you think the source sensor comes in to the trigger as well as unavailable? I’ll have to think on this one. As mentioned the device reporting the temp is on ESPHome and on wifi. Could be it becomes unavailable briefly. Will have a look at the other entities related to that device to see if they show the same pattern
edit:
Other e.g. binary sensors on the same device do have unavailable status in their log but not during the time period I have been monitoring here. I’m thinking this may be a HA restart.
edit #2:
Another thought… Having the trigger.* | is_number condition under availability may be bad. When the value is not a number then the sensor becomes unavailable. Trying to then set {{ this.state | float(0) }} may result in non numeric value defaulting to 0. Maybe it would otherwise have just become unavailable/missing. I’ll give a go to removing the cast to float. Also adding a check for this.state | is_number so we do not default there either.
Code now looks like so. Also changed the defaults to easier see whats causing the issue.
You probably already know this but just a reminder:
If the availability template evaluates to false, the Template Sensor’s state value becomes unavailable. That’s displayed as a gap on Template Sensor’s graph.
That’s what I thought. Having the gap itself on the resulting sensor is fine when this is the case, e.g. the source is unavailable. But the problem seems to be that I can’t get the previous state from before it was unavailable, hence resetting to the default (0). Do you think this is what’s happening too? I see no solution and was hoping that the this.state would still contain the last valid reading/value after the source sensor goes back to being available.
I’ll try it. My understanding was though that if the availability check did not go through them it won’t offices the “state”. That in my mind would be the requirement for it to keep old values. But apparently it doesn’t work like that
If you use availability the state of your sensor will change to unavailable, and you will therefore lose the option to retain the numeric state as it is no longer available.
Don’t use availability if your state template relies on this.state