Just as an FYI, Node Red on HassOS is working great for me via add-on.
You can. There is an option in the app to reset the frontend cache for the app.
Kenneth is probably using that awful safari browser
Awesome update again.
I have a feature request with these update becoming more frequently it would be nice if timers would get some love and get restored after a restart.
A little background:
I really like the current pace of the updates and I’m normally not hesitant to update. In the “old” times that was not such a big problem as the updates where not so often.
Normally I read the release notes, check for breaking stuff if there are no red flags on to the update and then check all the new warnings and deprecations and fix them. But with the minor .1, .2, … updates I would like to simply click update and I’m sure many other feel the same.
But I can’t do that because every time I have check before which timers are running and make sure that everything is correct after a restart.
It would be nice if timers would be restored like other states without some hacky workarounds.
Maybe an option which configures the behavior like it was introduced for the automations.
I understand that there are tricky edge cases like what should the timer do if the tigger would have happened during the downtime.
In that case maybe fire a custom event after the restart like timer_missed which then can be handled in the automation and the user decides what should happen.
1 Like
Hmm. I am always just using my normal Safari browser. But the app uses the same Webkit code like all browsers in IOS so it is good hint next time I get the problem then I will try that
Yes that awful Safari browser. Even if you think you run Google Chrome in IOS it is still the same rendering code that is used with the same bugs
Small update on the Logbook issue.
I raised a bug report on the frontend project but we have found it is a backend problem.
The time it takes the database code to fetch a record from the SQLite database has increased from 0.3 ms to 71.8 ms - per record. Or in human terms. A 3 hour busy logbook update goes from a few seconds to 2 minutes.
And I have also discovered that the same performance issue can be seen when you click on entities to see their own little status and history. In 2021.5.5 it loads instantly. In 2021.6.0 it takes up to 10 seconds. The user experience is really bad this way.
On Discord there seem to be a pattern that it is only SQLite users that have the problem. So it smells like a bug injected in the code that reads from SQLite.
I know many will say - then upgrade to SQL database. But as a community we need to get the SQLIte db to work properly again and I am trying to do my part analysing what is happening and finding patterns
I have reverted my HA to 2021.5.5 for now as I also have a problem with Camera streams. They hardly work at all. 1 or 2 of my 10 cameras will stream.
Avoid the use of long-running timers. Restoring timers is something (in my opinion) that should not be done. The reason is that: What if a timer ends when it is offline? How long was it offline? Does it continue where it was? Or does it take into account the offline time?
There are many variables, that are hard to solve or solve in a way that pleases everybody.
So, how to solve this… right?
A better solution is to use a date and time helper (input_datetime in YAML) when a “longer-running timer” is needed.
The beauty of that thing is, you can set a date+time in it and next automate with that. For example, this will trigger a persistent notification when set date+time is reached:
automation:
- alias: Trigger when next is reached
trigger:
- platform: time
at: input_datetime.next
action:
- service: persistent_notification.create
data:
message: "Times up!"
To start this “timer” programmatically, use the input_datetime.set_datetime service to set the timer for the next trigger on the input_datetime.next entity.
There you go, a “timer” that survives restarts 
5 Likes
its become less frequent. Used to be every 3 weeks, now every 4 weeks
After managing a fleet of a couple hundred IOS devices the last few years, i can tell you we had less dramas from user running chrome than we did safari. regardless of the underlying code
I am getting the same issue, and reported it (and see the reports) in the Jandy iAqualink pages of the HA community. It worked perfectly before the upgrade to 2021.6. What is dismaying is that I restored a snapshot of 2021.5.4 and still it is broken. I tried removing then reinstalling the integration, but it won’t let me do that.
you need to create a github issue if its an official integration, posting on a community thread isnt the same. Issues · home-assistant/core (github.com)
In fact an issue has already been done, and seems it has nothing to do with this release as it was happening before, hence why you rolling back to previous version still presents the issue… iAqualink integration no longer works. · Issue #51389 · home-assistant/core (github.com)
I offered a way of doing that here:
An active timer, interrupted during its countdown by restarting Home Assistant, is restored when Home Assistant starts. It is restored with a new duration representing the remaining time left of its original duration minus however long Home Assistant was offline. If the timer’s duration expired while Home Assistant was offline, the timer is not restored on startup.
NOTE
Timers, and restoring them, should be used judiciously. I agree with frenck that they’re not a panacea, especially not for long intervals when better techniques are available. FWIW, I don’t use any long-duration timers.
But the answer was incomplete (it’s better to use maintained software than to patch your own non-maintained local version…unless you want to of course) and I didn’t know if you knew there was an alternative. So I pointed it out.
Yeah, turns out Jandy changed the URL, so this is not a version issue. Fortunately, the dev is already aware and working on a fix.
Hmm, remote console working here, and no such errors. With nabucasa on 2021.6.1
Love the update, system is snappy!
Does anybody when and how the “illuminance” disappeared?
I had this:
- platform: illuminance
name: Estimated Illuminance
entity_id: weather.home
But [check configuration] says
“Platform error sensor.illuminance - Integration ‘illuminance’ not found.”
And weather.home doesn’t show this as a state attribute (anymore).
Illuminance is a custom_component and it’s working fine for me.
Thanks @DavidFW1960 - forgot that was a custom component, I just needed an update from GitHub - pnbruckner/ha-illuminance: Home Assistant Illuminance Sensor
Back in business.
1 Like
Updating to 2021.6.1 causes my CPU to run one core flat out. I grabbed a profiler capture but am having no luck seeing what is going wrong.
I have same smartplugs, under localtuya I can see energy consumption.
Now it’s gone and Tuya integration allow me only to switch on/off