Hi. Thanks, that solved the issue 
1 Like
Don’t forget every service is a separate program (or app or executable or whatever).
ssh is up because sshd is running. samabd is up becaise smbd is up. home assistant is not up because hass is not up.
Just because one thing is running it doesn’t mean everything is.
I have asked here and in many other forums as well as the discord channel and I have not gotten any answers as of yet. I have learned how to use CLI in ssh and I monitor the update, shut down and restart looking at both the SU logs and core logs for errors and what is loading. I have asked what should be happening? Is there a script that runs that somehow on my HA instance stops?
My update from command line procedure:
ha core stop
This stops the core. I found not doing this sometimes caused the update to fail. This takes less than 1 minute.
ha core update
This takes about 5 minutes. You can also run ha core update --version=x.y.z for a specific update version.
ha core info
I use this to verifies that the update worked.
ha core logs
This lets you see what is happening. I run this many times during the steps above.
ha su logs
This lets you see what is happening. I run this many times during the steps above.
ha host shutdown
I use another command window on my pc and run a ping to my RPI4. i.e ping 192.168.1.48 -t. When the ping fails I turn my device off and then back on and log back in with SSH and monitor the startup with
ha core logs
ha su logs
Hope this helps. It has allowed me to update since .102.x. Sometimes I can update the point releases from the UI and sometimes I can’t. Lately they have also failed for me until I do a shutdown / restart.
Any idea on why an update from the ui and the restart do not trigger all the services to start? When I update from the UI most of the time I can not get back to my lovelace UI. Looking at the log it looks like many of the services that should have been restarted were not. A shutdown / restart from CLI gets me back running again. Would running docker commands from the CLI help in figuring out what keeps failing for me? If so, any idea on which ones?
please let me add my variant to the base_url transition/breaking changes
Carefully prepared, I removed base_url from my production system and updated. This went flawlessly btw, thanks to the team and custom card authors! (had my own doing with custom-ui, which still holds…) Started with a clean system, as @nickrout described above.
only thing I hadn’t expected was the tts not functioning after the update. Which of course it didnt. Only the beep, but no tts.
(hadn’t experienced the issues mentioned in the link above before,so guessed I would be fine in that department)
After having experimented with internal and external url, in various combinations and places,(under homeassistant:, under tts: and Not under http:, all remained silent.
Only thing that brings back my tts notifications, is the former base_url setting under http: ??!
Now how can this be? Shouldn’t this trigger all alarm bells in the config check?
I don’t know about base URL still working but all I did was update with it still in place (so Home Assistant could automatically convert it to the new format). This didn’t happen, probably something to do with me using YAML for the basic setup rather than the UI. So I read this post, then removed base URL, added the old base URL to the new internal / external options (both https!) and restarted. And I think all is well. I cant really tell because I’m not home to hear any announcements.
ok thanks Tom, will checkup on that post.
if you say:
do you mean to have the identical values there? or is internal you local IP address:8123, and external your duckdns.org:port address…
as a separate post:
updating to 110.2 makes my developer-tools/state behave like syrup. Or should I say mud… where 109.6 would take most 2 or 3 seconds, and behave immediate after that, it now is slow as, well, syrup ;-(
Is this a know issue? didnt see a post in that yet?
1 Like
Yes exactly. This,
base_url: mydomain.duckdns.org
Became:
external_url: https://mydomain.duckdns.org
internal_url: https://mydomain.duckdns.org
Note, I actually just had to add https:// to my existing base url secret then re-used that in both new options.
I’m not seeing it personally but have heard this complaint previously.
no ports configured on your base_url? Ive had my ports there too, since I have 3 instances that need their own port on my router to forward to…
just posted an issue:
I use 443 external to 8123 internal. Port 443 is the default for ‘https’ so no need to specify it.
If you have more than one external port open you could consider a reverse proxy to reduce that to one.
1 Like
I’ve used the base_url under the tts for many a release now like so:
tts:
- platform: google_translate
service_name: google_say
language: 'en-au'
base_url: http://192.168.1.203:8123
keeps the TTS working
It only changed in this release.
The base_url under tts allowed you to use base_url under http without trying to have the tts routed externally.
So previously I had my base_url set to my external FQDN this would make the google home devices try to use the FQDN which didn’t work (before I changed my router out due to no hairpin NAT).
1 Like
Sorry, missed that it was the tts config you were talking about. I must be blind, you mentioned it more than once.
1 Like
I am using SSL/HTTPS for my local communication, too. I was hoping that I could use TTS without disabling SSL - but there is no way to only use http for tts? I tried usting http://local-ip in the base_url in the TTS setup but that would not work - only the https://mydomain.duckdns.org works flawlessly.
There appear to be a couple of issues:
- The async_get_events method in the Todoist integration (which the Calendar API calls to get the events for a specific date range) can’t handle tasks without a due date and throws an error. (I’ve posted a comment regarding that on this issue)
- If any calendar throws an error, the entire calendar panel will display blank
I found that, with mine, it was my Alexa Shopping List calendar (synced from Alexa to Todoist) which caused the issues and deselecting that calendar allowed the events to appear.
1 Like
Tom are you using secrets for the base URL config in the GUI?
and solved: https://github.com/home-assistant/frontend/issues/6044#event-3371156457
thanks Bram for the immediate action!
1 Like
well, base_url is no longer supported according to the docs for tts: ànd http:
you use it for tts: to keep it talking, and I use it under http: …
tts:
- platform: google_translate
service_name: google_say
cache: false
http:
base_url: !secret base_url
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
ip_ban_enabled: true
login_attempts_threshold: 10
isn’t that odd?