Is it normal that the datechooser for eg. the logbook is showing the calendar starting with Sunday instead of Monday which would be correct?
Why aren’t the local settings used like for 24h time?
1 Like
hi Canedje,
I do not see any network tools in Developer Tools, so my solution was to simply uninstall/reinstall the apps on iphone, ipad and osx. Cache flushed
For me, this has broken DIYHUE. I notice that it no longer finds the DIYHUE hub even if I try and set up from scratch.
I also have a variable: section in my config file which it now complains about.
quite a few other little niggles too with custom integrations that Im going to have to wait for the authors of those to sort out it seems.
Rolled back to core-2021.5.5 to get everything working again, 
No, it’s not normal.
But it is how it’s done in HA.
Anyone facing issues with colors of history graphs (both history tab and regular card) in mobile app on iOS? On the first load all colors are replaced with either white or black and view needs to be refreshed to get proper colors being loaded. Here is side by side comparison of how it looks and how it should look:
1 Like
all good here, 2021.6 version
probably the version key missing in the manifest.json of each CC., add it manually, you don’t need to wait for the repo to be updated to fix that
Which people would know if they read the thread. The same question asked a dozen times, and answered as many times. Very frustrating.
Update breaks/not working: - brematic
…or could be updated on the fly by update procedure.
But seems it’s easier to cut out effectively working components and then move responsibility to end-user.
That did the trick. Thanks
This again has been tried before and people complained about HA messing wit their files and changing stuff.
Perhaps they are waiting for a PR to change that behaviour 
Maybe it has been tried wrong way?
I’m pretty sure manifest files are not “their files”. Those files are part of integrations. Adding missing version to existing manifest, or create dummy one in case it’s missing couldn’t hurt anyone.
But of course decision to kill all components which doesn’t comply with new specification may be also the way. I doubt however such a decision, which lead to such impact, has been conscientiously made. To me it looks like nobody cares about final user experience. Nobody says: “guys we cannot do that, this is wrong to break peoples smart homes”. It seems there is more pressure on development without care about its quality and users.
There were deprecation warnings that clearly stated that integrations that did not comply would be blocked. Whether individual developers made a conscious effort to kill their integrations is a separate question. I note one integration has had an open PR that had been ignored for 5 weeks that could have avoided blockage.
these are custom integrations and not HA provided files, so yes they are “theirs”
I understand. But depreciation warning are for developers. Not for users.
I’m talking about users experience.
Also depreciation warning left for a few months is not enough obviously. If it kills so many installation, maybe another design decisions should be made instead.
Again, at the end it’s all about users and their families who will struggle in case if their smart home turns into dumb one.
Then consider asking HA admin for a consent to “fix” such custom integrations automatically.
Or just give people more time for transition. recently it seems that every new version brings more hassle than new features. Maybe it’s time to stabilize the situation before doing next step
Do you understand how access rights work? This is not doable on github. Stop trying to be a anti-everything-ha-does. The people who maintain the custom integration need to maintain it. End of story.
10 Likes