Since 2021.06 a Sensor graphic that shows a percentage (in this a value higher than 100, which is a good thing :-)) shows a flat line. When I click it to view the actual values are shown, but not in the frontend card itself.
I suspect the flat line is at 100%…
The yaml import only is being deprecated, if you have set them up via the UI your good to go
Have you checked there isn’t an update for localtuya in case your running a version that doesn’t meet the version requirements in this release
Oh ok, thanks for info.
As for LocalTuya, its working fine but yes I see
"Not Supported
Options cannot be edited when configured via YAML."
But I guess it will add new devices automatically.
thanks for the update, it has made me look into a direction I hadn’t thought of… disabling MariaDB on one of the affected, (I use that on all 3 instances because of its better db handling) seems to have a dramatic effect. Positive in this case… Now this is a small instance as I had already indicated, but even so, I can’t imagine why this is the case, it is supposed to give better experience, not frustrate it…?
and o dear, I made the error to restart without the add-on DB enabled, but yet setup in recorder.yaml… I really wish/think that should be guarded in the config checker, or simply be allowed to pass during startup, the misery this gives.
update
back online…: figured that since my MariaDB recorded everything on the instance (remember it is small and only holds my zwave add-on and devices/sensors), it might be interesting to see whether filtering the recorded entities would have any effect. And yes, it certainly does. I explicitly exclude almost all domains and services, include only switch/binary_sensor/device_tracker, and a couple of globs on sensor.
Huge difference… Still not back to the speed from before (where I had no filtering in place at all) but better. Think we’re on to a DB handling issue here indeed.
Thanks for the response.
I can understand that it is difficult to find a solution that works for everybody without overcomplicating things.
The problem is what to do for long running timers and I have some.
The documentation does not help you it only states that timers are (currently) not restored.
Not what to do about it which hints to me it could get implemented 
hence this request.
Let me give one example of many I have (this one uses a pretty long timer there are others with 1 hour or less). I have an automation which should trigger if I’m no one is home for more than 18 hours. The 18 hours are enough so that normally it does not trigger even on long working days. It turns off heating, and other stuff. This makes it so I don’t have to think about it and save money with no loss of convenience (by the way thank you home-assistant for that 
). If I restart home assistant during that time the timer is gone but I want it to continue.
There are more things like lights not turning off, etc…
Currently I only update after midnight to make sure no one is up and check everything.
This is for the planed down time, there might be others reasons why homeassistant restarts.
The workaround with a date-time helper is a good idea but how to set the date_time to now+18h. That gets very fiddle I had to google how to set the date time helper to now+x.
The way to do that is with templates if anyone is interested:
For me this looks like it was not the intended way, as it is not directly described in the documentation of date time helper.
Maybe add a feature would be nice which allows this more easily.
Timers just are the first go to thing I looked at for the problem because of their name.
I know of this workaround but I have been bitten too many times with custom workarounds which then break after an update and try to avoid those things.
It looks like a valid solution the only problem is that it complicates stuff. Now there is another automation which interacts with the timers, additional helpers, etc.
I like to keep the automations simple and understandable like code. With the UI currently, there is no way to comment anything for an automation without it being gone after saving again (not to complain the UI underwent some great improvements in the last year). So I like to have everything in the automation itself.
Timers currently even displays the target time why not store it and restore it after a restart if the timer is configured to do that. This is basically the workaround 123 mentioned, just build into homeassistant. Maybe an additional event timer_missed if the timer did not fire and the target time lies in the past, which would mean the timer was missed due to a down time. This seems to me like a reasonable behavior, which is easy to understand and should cover almost all use cases. Maybe not so easy implement, I’m no expert on the internal workings of homeassistant.
Or maybe date time helpers if this is the intended way of homeassistant.
But I feel like this duplicates stuff at makes it more complicated for the user.
For long time spans use this date timer helper pattern frenck mentioned and for short stuff use timers?
What is short, what is long?
Maybe others have the same problem? It just would be nice if the amount of manual oversight of restarts would get less over time and with future update.
Can anyone remember the days where states where not restored 
Please don’t understand this as a complaint I’m really happy with homeassistant and just wanted to propose that timers get so love to solve problems I personally have. I can understand that this might not be a priority.
I had two repositories installed
GitHub - ArtistAOP/localtuya: local handling for Tuya devices 1.1.2 - only climate thermostat moes
GitHub - rospogrigio/localtuya: local handling for Tuya devices 3.2.2 - all other device tuya
And now I had to uninstall ArtistAOP / localtuya / repository and leave only rospogrigio / localtuya working. It then lists the theromstat error: local tuya.climate not found
Solved:
I compared these two repositories and added the missing climate item to the rospogrigio repository.
Done, mentions removed.
I didn’t know about that rule but I will keep it in mind for the future.
the first repository doesn’t include version in the manifest file and needs updating from the dev ot you do manually before it would be available again
The second one already includes the version in the manifest file, so is good to go
Kudos to this dev @rospogrigio , he included the requirement in march after a user posted an issue.
I think Buienradar is broken. When I remove the config from my configuration.yaml as advised by the log, remove it from integration (to be sure) restart homeassitant, go to integration and add it back, it creates two entries back:
Both only return all entities “unavailabe”
you should be able to ‘enable’ these by default disabled entities in their config pane? until then, they are indeed ‘unavailable’
Crosspost from discord since I see the same thing is posted here as well:
Starting with Home Assistant 2021.6 all custom integrations (the folders (directories) that you have under the custom_components folder in your configuration directory) needs to have a manifest.json file, and in the file a version key need to exist containing a valid version.
If this is not present, the integration will not be loaded, and you will see logs like:
ERROR (SyncWorker_1) [homeassistant.loader] The custom integration 'awesome_integration' does not have a valid version key (None) in the manifest file and was blocked from loading. See https://developers.home-assistant.io/blog/2021/01/29/custom-integration-changes#versions for more details
ERROR (MainThread) [homeassistant.setup] Setup failed for awesome_integration: Integration not found.
This has been a part of the breaking changes section since 2021.3, and was first mentioned back in January https://developers.home-assistant.io/blog/2021/01/29/custom-integration-changes
If you maintain the integration yourself, have a look at that blog post and the documentation for the manifest file https://developers.home-assistant.io/docs/creating_integration_manifest.
If you are not the maintainer of the integration and this is missing, please report that to the maintainer of it, while you wait for the maintainer to implement it, you can just add "version": "1.2.3" to the manifest.json file yourself. use https://jsonlint.com/ to make sure it’s valid JSON before restarting.
I read that MIND was not supported anymore but it still worked…untill 2021.6:
Component error: mind - Integration ‘mind’ not found.
So no option to use it anymore?
Please read the post directly above yours
Aha, lol. Thank you!!!
would any of the dev’s here be able to answer this? Above I found that disabling the ‘enable polling for updates’ option immediately renders all entities Unknown…which of course it not very nice (and maybe unintended/bug?
however, I updated today to the latest 6.1, and tried again. At first all entities turned Unknown once more, but after a short while, 2 minutes maybe, came back to life.
It seems to still be updating the regular sensors though, while the forecast sensors haven’t been updated in over 32 minutes. Not sure if these were updated once an hour before too, so cant say if the enable polling for updates works or not…
can anyone chime in here please?
the weather.buienradar in fact doesn’t get updated, rendering the weather-forecast card into trouble… all in all a mixed experience so far
Short question (because I always used only custom:button-card and so never was aware of):
Is the confirmation dialog used in HA :button card related to the latest update or has it always been like that?
Aha, lol. Thank you, it works!
2021.6.1 brought old browser support back!!
I can login now.
Thank you to the devs!
