See my previous post : 0.110: Speed! OpenZWave beta, HomeKit Cameras, ONVIF, Calendars
Hope this helps
I think the opposite. 1.x says clearly the sw is pretended stable.
That is not what internal and external URLs are for. It has nothing to do with the HTTP configuration. The same as base_url, which essentially had nothing to do with the HTTP configuration either.
Hence, the new options are part of the core configuration, not the HTTP configuration.
It are solely overrides to instruct Home Assistant to use other URLs in case it needs one. For example, one could be running a reverse proxy causing Home Assistant to be available via that proxy on a different port than Home Assistant is configured with.
TL;DR, the new internal and external URL are not HTTP settings and do not change the working of the HTTP server.
1 Like
Just noticed my Hue motion sensors are also missing
it the AV python complaining about something wrong with a stream - either a video camera or similar. I’ve had it once.
Has something been changed in the card rendering code?
previously a web page of size “x” would render 3 columns, then x+1 would go to 4 - the cards would always be the same size.
under 0.110.0 it seems that the rendering code tries to resize the cards as well.
see Customising the BOM Weather and lovelace - now in HACS for examples
You can, you are looking at my personal configuration setting there (obviously changed my duckdns domain). But in my case, I’m using a reverse proxy for the outside world, inside my network the internal URL is used.
So in my case, Home Assistant Core does not run on SSL, the reverse proxy does.
EDIT:
Additional clarification attempt: What would you expect to happen when you set https://www.facebook.com as the external URL for Home Assistant? That your instance becomes available at that address? Just for clarification, that URLs have not much to do with the HTTP server.
1 Like
Unfortunately this doesn’t help.
it was when upgraded to the beta i noticed that it had to do with the new internal and external URL’s, it took me ofer a day to work that out after a number to restores 
Finally upgraded to 0.110.1. Another great release with no issues for me. Thanks to all contributors.
I switched over from zwave2mqtt to the new zwave mqtt beta and the experience was smooth. Only thing needed was to redo certain entity ids and names to match what i had already established previously.
I upgraded to .110 and didn’t have any issues, other than some random restarting of HA, at least according to my monitoring system. I updated HACS this afternoon and none of the custom cards in HACS work. When trying to display them, I get an error that they don’t exist. I’ve completely removed HACS from HA, including the deletion and re-install of the files in the custom components directory. I then removed the YAML config and used the integration config. None of this solved the issue. Even though, within HACS, the card repos are installed, HA doesn’t recognize them. There is no info on the Hacs.xyz site to help with this issue.
Solved my own issue after getting some time to really understand my troubleshooting steps. The fix was to go through and replace the resources urls in ui-lovelace.yaml for each of the custom components I am using with the /hacsfiles/{component}/{component.js}, etc. This was probably mentioned somewhere in the HACS upgrade info but I missed it and didn’t find it while searching around for a fix.
HACS has done from version 0.24 to 1.00 and there were a few breaking changes. Release 1.0.0 · hacs/integration · GitHub
in ssh
ha su options --channel dev
It is supervised of course. I don’t recommend doing this on your ‘production’ HA - I have this on a VM.
Then you update as per normal.
2 Likes
Yo thanks, i had the same issue with ‘–mdc-icon-size’, it now fixes the icon size issue
Now im trying to figure out how to make --iron-icon-fill-color work
“Pretended” is correct word proving what I said.
I know lot of sw with major version greater than 0 while unstable and full of bugs. I know sw which is in constant development but has major version being increased since long time ago.
Finally there is no measurment which arbitrarily says that sw can use major version. it’s developer’s decission and has nothing to do with sw quality.
Precisely, numbering is entirely arbitrary. However it is the stated intent that in home assistant version number 1.0 will signal a degree of stability that will be marked.
Of course nothing stays stable for long. Improvements are made. New integrations must be generated as manufacturers keep releasing new stuff. New ideas in home automation are thought up by clever and not so clever people. New versions of python are released. New versions of the huge number of underlying libraries/dependencies are delivered, or abandoned. New security issues arise.
You can’t just stay still in this space.
1 Like
Yes, Thank you!
Exactly. And this is why using the fact that HA has 0 in place of minor version as argument justifying its instability is off.
If one day HA get major version, it doesn’t mean development will stop. it doesn’t mean there will be no breaking changes anymore. Also it doesn’t mean that something will change in the process to ensure more reliability during updates.
Likely all will remain the same. Or it all might change during infinity beta stage.
that’s why using ver number for justifying anything makes no sense.