I’ve been trying to setup a sensor template, but have issues getting the template updated correctly. Let me explain, I have tried to understand HA’s sensor.date and sensor.time. I have followed the topic about daily update of meterstanden to mindergas.nl (link).
I initially added sensor.date to the yesterday sensor, so it would update daily. However after a couple of configuration setups (and days) I have found it would only update after a reboot os HassIO and not at midnight (which is to be expected) (link to documentation, at the end of the template examples).
Changing it to date.minute and a nightly reboot to hassio I got it to work last night, but it feels so wrong.
Can anyone explain to me what is the best way to just do a nightly update of a sensor.template, so that at midnight you get a custom/template sensor updates right after midnight, so you can use it after that in a service call to mindergas.nl?
If you have suggestion I would love to hear, because updating a sensor every minute that only changes once a day is not very efficient.
That seems to be the problem then, I had no configuration for the sensor.date_time setup. After changing that and adding it to the configuration it showed this:
@Mariusthvdb thanks that must be the solution, going to this it tonight. Just one question, maybe you know… why is the sensor.date_time not a ‘default’ sensor since it seems that you would want to use it in more than just this scenario.
Hope this saves it for you.
As there is no such thing as coincidence, I stumbled upon one of my sensors, using sensor.date, that wouldn’t update either. That is t say, not after startup, which is when most all sensors update. Im puzzled somewhat by this, but will check the important thing tonight: updating on sensor.date.
Because there are no default sensors; all sensors have equal standing in Home Assistant. If you want an automation to trigger based on the time, date, position, status, light-level, etc then you define an appropriate sensor.
So when you see an automation containing sensors, like sensor.date_time, you will have to define those sensors because there are no default sensors.
as an update to this, for reference:
my sensor updated just fine overnight, which is the main thing.
Why this sensor doesn’t automatically initiate at HA startup is yet to be disclosed to me… I do use a now() template, which isn’t updated automatically during runtime, hence the need for the entity_id, in this case sensor.date.
It should however update on Ha start shouldn’t it?
afval_overmorgen:
friendly_name: Afval overmorgen
entity_id: sensor.date
value_template: >
{% set date = (as_timestamp(now())+2*86400)|timestamp_custom('%d-%m-%Y') %}
{% if date == states('sensor.trash_papier') %} Papier
{% elif date == states('sensor.trash_gft') %} Gft
{% elif date == states('sensor.trash_plastic') %} Plastic
{% elif date == states('sensor.trash_restafval') %} Restafval
{% else %} Geen
{% endif %}
@Mariusthvdb if you really want this to work I think you do need to configure the sensor.date_time in the configuration.yaml. I have done that last night and now it actually works.
It’s not enough to use the sensor.date, you need to configure it, so sensor.date actually triggers on a state change.
You are so right @Mariusthvdb, you solved my issue… sorry for that…
I think you are right it should update on reboot, and entity_update is triggered. So it is weird that the sensor does not update on reboot, I have seen the sensor’s on HA update on the reboot, there is no reason why this should not update. It’s the same type of template as for ‘yesterday’ I have used.
maybe @123 would you know why this sensor doesn’t update on homeassistant start?
Only reason I could think of is the underlying sensors aren’t yet initialized a time of startup, but I don’t get any errors in the logs for that. Also, If I check these after startup, they seem to be correct.
Of course after that time, the template sensor wont get updated until the date changes, so a manual (or automated) update is necessary…
It reports a different color when I restart Home Assistant. That’s because the Template Sensor’s value_template is always evaluated on startup even if the template contains no identifiable entities and there’s no entity_id specified. Of course, in such a situation the template will only be evaluated on startup and never again (not until the next restart). In this example, it updates on startup and then when sensor.date changes state (at the beginning of each new day).
You’re saying your Template Sensor doesn’t update on startup. So what does it report? unknown or Geen or what?
The cause may be as you’ve already stated, at startup the trash sensors being tested don’t have a state yet so the states() function returns unknown. This causes each test to evaluate to false and so it ends up in the else catch-all.
yes, hope to proof that’s the case, though I would have expected the individual sensors to throw an error.
This might well be a race-condition, especially since I don’t want to poll each minute and only use sensor.date.
I could maybe try to add the individual sensors to the entity_id list.
If all fails, I can add homeassistant.update_entity to the list of action of my delayed-startup sequence.
I haven’t experimented with this but I’ve wondered if, on startup, Home Assistant loads the sensors in the order it finds them in the configuration file. So if you create a Template Sensor that’s dependent on other sensors then it may be best to put that sensor’s configuration last in the file. The theory (the hope?) is that you’re giving the referenced sensors extra time (milliseconds?) to initialize themselves.
Of course, even if it does work, it’s a hack because you don’t really have direct control of the timing involved. Your ‘delayed startup’ automation is more deterministic and a better solution.
In a similar vein, I use this ‘delayed startup’ concept in my own system (albeit in Premise, not currently in Home Assistant). I have two drivers (a.k.a. integrations) that sometimes don’t initialize correctly after a full restart. So shortly after Premise restarts, an automation disables/re-enables the driver’s network port. This causes the driver to re-initialize itself, clears up any issues it had, and the driver works flawlessly thereafter. Just another little hack to keep things running smoothly.
thanks, seems all very true and sometimes we just have to find a way of dealing with things.
Sharing that experience is most certainly to the benefit of all interested.
Just so you know I have experimented with the order of things. That was a long time ago, before I had as many entities as I have now.
Even then, it didn’t make a difference So I took it upon me to use the delayed_startup sequence which has proven to be a life safer now and then. Has the benefit of taking things in our own hands.
The input_number allows me to experiment from the frontend, and not have to change code all the time…
You are so right