You are “setting and calculating” (every /10 min) where as the example is just “getting/compare” the automations last_updated_state
Have you tried that template in template editor ?, every /10min
I think you have to call that script, in the action, and have the script call the service: homeassistant.update_entity
EDIT: or maybe use a “helper”
On the other hand, i think maybe you are “overdoing it” , if you live in the northern or southern part of the world, the sun(daylight) various more during winter/summer time, and it’s mentioned max 50 request a day , with a 10 min interval per hour, it covers about 8hour ( not sufficient about 6month of the year ), maybe that’s why they also shows 20min as an example (16+ hour) a day
But if your “goal” is to max the “output” (even thou you look at the result 5 times a day), then calculate the " daylight-min / 50" from the sunrice-sunset and use that “time-interval” (variable_timedelta) output as the (n condition) for the service cal
You only need to “get” the update time-interval once a day (not every 10 min)
I can’t explain the behaviour you are seeing in your history strip chart. Even if your condition was somehow erroneous and allowed all triggers through, it still should not trigger more often than every 10 minutes with this trigger:
@petro That is what I was trying to accomplish with this state of the automation. If this had been successful, instead of putting the server into a restart cycle, then I would have iterated on the solution.
The next version of the Integration is bringing in changes that will cause further iteration, but I wanted to do something with this version.
Ok, well you’re going to run into issues using next_rising and next setting. Do this instead.
Create an input_select helper with the name Update OpenUV.
Use the following automation
alias: Set Schedule for OpenUV
trigger:
- platfrom: time
at: "00:00:00"
- platform: homeassistant
event: start
action:
- service: input_select.set_options
target:
entity_id: input_select.update_openuv
data:
options: >
{# change updates for the number of updates between sunrise and sunset #}
{% set updates = 30 %}
{# change include_senset to True to include the sunset as the last trigger time #}
{% set include_sunset = False %}
{% set setting = (state_attr("sun.sun", "next_setting") | as_datetime | as_local).replace(day=now().day) %}
{% set rising = (state_attr("sun.sun", "next_rising") | as_datetime | as_local).replace(day=now().day) %}
{% set ns = namespace(items=[]) %}
{% set inc = (setting - rising) / (updates - 1 if include_sunset else updates) %}
{% for i in range(updates) %}
{% set ns.items = ns.items + [ (rising + i * inc).strftime("%H:%M") ] %}
{% endfor %}
{{ ns.items }}
This automation will schedule times throught the day that the automation will run. The scheduled times are calculated at midnight when rising and setting are correct for the current day.
If by chance you restart, the rising and setting may be slightly different depending on when you restart. However, you’ll still get a schedule that is “close” to the times you want.
The second automation is what will run at each period.
Going this route removes all issues you’d have from the other route.
Anyone see why this automation is the alleged cause of the problem?
It’s designed to fire every 10 minutes, no more, no less.
Its Sun Condition limits its actions to (apprx) daylight hours.
Its Template Condition doesn’t appear to contain anything the Jinja processor can’t easily digest. It’s a linear sequence of simple calculations (no control structures like if or for).
Its sole action is straightforward and doesn’t influence its own trigger.
It might be useful to review the automation’s most recent traces, especially the times when each trace was produced.
Just to explain some things, when the sun component passes the sunrise or sunset, it calculates the next sunrise or sunset. Which slightly changes the overall calculation. If you’re looking for the most accurate result, you want to use todays sunrise and sunset only. Which means you can only run the calculation before todays sunrise.
I’d wager the issue lies with the updating of the entity and mode single but that remains to be seen. The template he’s using is odd and will behave odd when it crosses the transitions (although I don’t think that will cause HA to crash).
@NathanCu Thanks for your input. Yeah, I’ve been in the dark trying to figure this out.
I am out of bootloop land now, and I’ve installed the add-on, but it refuses to start. It’s shows CPU activity after I hit the start button, but then immediately stops and refreshing the page just says it isn’t started. And, of course, I can’t access the logs to see why this is happening.
Looking at logs is quite an important task, I would have hoped that there was a builtin way of accessing this information.
I’ll need to set aside some time to try and gain access to the logs. That time is not right now, unfortunately.
Are you willing to share your possible reasons on what could be wrong with the automation that would cause HA to enter a bootloop, or would you prefer to wait for the logs?
I agree the revised sunrise/sunset times will be altered by a minute or three. However I don’t see how that small change would cause the kind of catastrophic failure that’s been described.
It uses a simple Time Pattern Trigger so single mode ought to be fine … unless the action takes more than 10 minutes to complete which seems highly unlikely.
The nature of the failure suggests that something is taxing the system to the extent it can no longer process additional tasks. I did this once by mistakenly putting a repeat into an endless loop (without any delay within the loop) and, yes, it was a bear to regain control of the system. However, I don’t see anything in that Template Condition that is capable of this result.
Of note is that the automation says that it was last triggered 16 hours ago, which is well before I finally managed to get the bootloops to stop. The automation is now disabled, so won’t be triggered now. My assumption here is that the time the automation is triggered is updated after the conditions are evaluated and that’s why it wasn’t being updated.
Unfortunately I can’t access the traces because the server has rebooted.
From memory looking at earlier traces when I could there wasn’t anything helpful in them. Either they would stop at the condition, or they would complain that the entity wasn’t available. (because I was over the quota)
The various tabs of the trace didn’t show anything that stood out to me; no resolved variables, etc. Copying the variables to the template renderer showed what I expected the values to be.
I tried both the variables: section of the yaml, and the template code that I posted in this thread. I don’t remember if the variables: caused the bootloop, but it obviously wasn’t working correctly to cause me to move to the template.
That seems nominal and serves as evidence that there’s nothing inherently wrong with the automation.
The sensor’s unavailable status should be explored. The OpenUV integration marks it as unavailable when you have exceeded your daily allowance of polling inquiries?
I don’t know how Home Assistant (and/or the OpenUV integration) handles an attempt to update the state of an unavailable entity. I assume gracefully (along with an error or warning message) but maybe not.
EDIT
Pure Speculation:
Imagine that the OpenUV integration doesn’t like being instructed to update a sensor’s value after you have exceeded your daily quota. It proceeds to malfunction and overload Home Assistant. It’s cleared after a restart but misbehaves again the moment when the automation tells it to update the sensor. Basically, the automation looks like the culprit but it’s actually the integration.
@petro If you’re able to describe what it “odd” about the template that would help with me learning.
Understood about the runrise/set changing based on the time of the day, which is why the template coerces the times with today_at to approximate the time to be close enough for what was supposed to be a “small iteration” of the automation. The next version of the Integration will provide additional information that will change the calculations anyways. This thread isn’t intended to discuss improvement, but to question why the bootloops.
When you say transitions, do you mean the sunrise/set transitions? The bootloops in the history grab are well before sunrise.
I have reenabled the Integration in order to get that screenshot. (to make sure there wasn’t a difference when the Integration is enabled/disabled.)
I guess we will find out soon if it’s the integration. But note that disabling the Integration hasn’t fixed the issue previously. It was only after disabling the Integration and then disabling the automation that HA would stop the bootloop.
Update:
Oh, and the fact that the bootloop happens when I have a full quota at the start of the new day.
What is responsible for the ‘forced update’ in those messages? The integration or your automation.
If it’s your automation then why has the integration not created those entities yet … unless (speculation) it’s designed not to if it detects you’ve exceeded your daily quota.
