I use Zigbee curtains (covers) from Lonsonho. They get properly exposed via zigbee2mqtt plugin panel with the “open” and “close” states. But in HA it became unavailable. I can’t operate my covers in 2021.6. What have changes? Should I restore to 2021.5 or is there a quick fix to that?
I"m getting this too, is your HA behind a proxy of some sort?
snitun issue happens to me about twice a year. Never got help. Fortunately restart of HA always helped. Recently when it happened to me on I noticed snitun related change in NC github a few days back. Maybe coincidence.
if you check github it’s know but never resolved because of lack of evidences. In short devs require debug logs, which obviously nobody can provide since it would require to have debug logs enabled for a whole year.
Hope you will make it working again
I reverted via snapshot to 2021.5.5, all working again.
Hi all, I found this in the log usin external mysql…
Logger: homeassistant.components.recorder.util
Source: components/recorder/util.py:68
Integration: Recorder (documentation, issues)
First occurred: 8:51:30 PM (1 occurrences)
Last logged: 8:51:30 PM
Error executing query: (MySQLdb._exceptions.OperationalError) (1071, 'Specified key was too long; max key length is 1000 bytes') [SQL: CREATE INDEX ix_statistics_statistic_id_start ON statistics (statistic_id, start)] (Background on this error at: http://sqlalche.me/e/14/e3q8)
Nope, no proxy.
that really is too bad, and cant reproduce here (3 instances all Pi3/4)
that being said, I feel somewhat relieved that I am not the only one experiencing ‘network issues’. On 1 of my 3 instances I see connection errors regarding the image files in my www folder (only certain files though, so I don’t understand it at all, and can’t put a finger on it) On the 2 other instances that are almost empty except for the MQTT add-on and the ZwaveJS add-on respectively, I see my customizations being loaded sometimes after a few seconds (up to 12) while they are immediate on the other instance and have always been before the last couple of updates…
So I would tend to agree there is something in the backend frustrating that. (I do serve all my instances over duckdns, so there is actual networking going on. most of the files do render immediate though, making the exceptions really hard to understand)
Don’t have a clue just yet how to debug 
Screenshot: controls for open/close unavailable in HA:
Screenshot: controls for open/close available in z2m:
glad you got it sorted (not using HACS myself, I simply reload resources after having changed the version number.)
I have the same issue. It appears to be associated with a custom card that uses Lit, which has moved to V2.0. The custom card will need to be updated to accommodate the new version. If the card hasn’t been maintained, you might need to find an alternative.
https://developers.home-assistant.io/blog/2021/05/19/lit-2.0/
1 Like
I just gave up on it, did a hard reboot of the raspi outside HA and now everything looks fine. The MariaDB shows quite a few messages about integrity checks and so on but it all turns out green and seems to work by itself.
Thanks for designing the system in a robust way!
Anyone here using WallPanel for Android? Since updating to version 2021.6 nothing is rendered, just the top bar without icons and an empty page.
My node red would also not start. sorry no logs I just rolled back and all is good. If I have time this weekend I will update again and get logs.
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