True, I just saw that after upgrading and it is in safe mode.
I suggest updating the breaking changes section, which does not mention that the x_url config is moved from http: to homeassistant: as well as the linked doc pages, which only links “http” and “config” (why config at all, is this a mistake?).
yeah, i commented out also element by element, then it worked indeed, the uncommented like i was back before, and no issue anymore , verry strange
It got it’s own section in the blogpost explaining it https://www.home-assistant.io/blog/2020/05/20/release-110/#internal--external-urls
Hi @pergola.fabio.
I have the same issue and it was working fine on 109.x too.
Cheers,
José Henrique.
also the audi card? from audi mmi ? or just another ?
I asked about this too and was told to just install docker to run it. Hopefully we can get some non-docker instructions as well 
Personally I am waiting on Lock support to be added before I attempt to swich. Maybe by then we will have something. Otherwise I will just run Docker to get it over with lol.
QT being a dependency is a OZW decision. I am just happy that we are getting official OZW support and they are building things to work better for us and others.
can you make a screenshot of your big black bar? can you let me know if you find the issue?
this is verry frustating …
Amazing work, thank you!
The same as yours…
Tried to make a brand new Lovelace dashboard, but also then I get that bar on the bottom.
I know, it still does not mention that the old one was under http and has to be moved.
I also think the breaking changes part is the important one and should contain all relevant breaking info.
are you also missing other stuff? seems my lovelace just doesnt render good anymore…
my headers texts are coming slow , missing my header button bar, no red error there though
custom:battery-entity
Just for feedback not as comment, developers do a great job with this software.
issues i have with build 110:
Use case Internal and external adress???, i suspect that this is the reason TTS is broken? I don’t understand the use case? If you enable SSL, then the internal adres and external adres both should be starting with https As far as i know there is no possibility to differentiate between the use of normal http for internal use and https for external use.
The example in the update anouncement suggest this (external adress: https://myhome.duckdns.org, internal adress: http://10.10.100.10:8123). Have i missed this?
I could understand the use case for some addons (for example addon Unifi controller) who do not support ingress and where you want to use the internal adress to call the underlying service with the internal adress. If this would be the use case for the internal adress then you should only set the adresses without supplying a port in the adress, because the port is defined by the http component of home assistant. For the external adres it is logical that you specify a port, because this depends on how you configured your port-forwarding in the router.
For now i have rolled back to the previous version.
How did you restart Home Assistant after making the change?
I had an issue with the beta when it complained about this when I restarted HA by restarting the Home Assistant service from the OS (I run it in a venv) or by rebooting the Raspberry Pi.
When I restarted it from the UI (Configuration > Server Controls), the error went away even after subsequent restarts (however it was restarted). It seemed that restarting via the UI triggered an update that restarting by other means didn’t.
i always restart from this : Configuration > Server Controls
Allright so I got it working. Not sure what did the trick… Uninstalled the custom header, rebooted Home Assistant, still the dark bar on the bottom… Installed it again, uninstalled it, and rebooted again. Boom, the original header is back. Also after cache cleared. Whut…
The old base_url was in http component and didn’t need the “https://” part.
The new ones are located in homeassistant component and certainly need the “https://” part. This should have been informed better.
edit: But the perfect thing and long waited thing is, now I can make the same automation while I am connected to home network or not, with just passing the url:
url: /local/image.jpg
yes, installec custom-header 1.3.9 (beta) black bar is gone
Do you have mysterious warnings in the log about deprecated stuff?
There was a blog post aimed at developers that has impact on custom components. And it was not mentioned in the release notes for 0.110
The blog is here https://developers.home-assistant.io/blog/2020/05/14/entity-class-names/
This is mainly for developers. But it is important to know that if you e.g. use the AlexaMediaPlayer custom component you will find some of these warnings in the log
AlarmControlPanel is deprecated, modify AlexaAlarmControlPanel to extend AlarmControlPanelEntity
SwitchDevice is deprecated, modify AlexaMediaSwitch to extend SwitchEntity
SwitchDevice is deprecated, modify DNDSwitch to extend SwitchEntity
SwitchDevice is deprecated, modify ShuffleSwitch to extend SwitchEntity
SwitchDevice is deprecated, modify RepeatSwitch to extend SwitchEntity
MediaPlayerDevice is deprecated, modify AlexaClient to extend MediaPlayerEntity
and then you may - like me - spend some time trying to find what you need to fix in the configuration. You may even find some bug reports or other answers from developers saying it is a custom component bug with no further explanation.
Well. That is not the whole truth. There is a breaking change that is only announced in the blog post.
Don’t panic. It is just a warning that some class names are deprecated - to be renamed. And it is the authors of the custom components that need to fix it. So the problem should go away by itself when the custom components that triggers these warnings get updated and here and now all works like normal.
alright so I’m either stupid or extremely blind… Where do I enable ‘show beta’ in HACS? lol
