0.110: Speed! OpenZWave beta, HomeKit Cameras, ONVIF, Calendars

Jer78 · May 24, 2020, 8:15pm

Upgraded to 0.110.2 and got safe mode:

2020-05-24 16:02:28 ERROR (SyncWorker_0) [homeassistant.util.yaml.loader] while parsing a block mapping
  in "/Users/macbookpro/.homeassistant/themes.yaml", line 401, column 7
expected <block end>, but found '<scalar>'
  in "/Users/macbookpro/.homeassistant/themes.yaml", line 414, column 108
2020-05-24 16:02:28 ERROR (MainThread) [homeassistant.bootstrap] Failed to parse configuration.yaml: while parsing a block mapping
  in "/Users/macbookpro/.homeassistant/themes.yaml", line 401, column 7
expected <block end>, but found '<scalar>'
  in "/Users/macbookpro/.homeassistant/themes.yaml", line 414, column 108. Activating safe mode
2020-05-24 16:02:51 ERROR (MainThread) [hass_nabucasa.iot] Error handling message
Traceback (most recent call last):
  File "/Users/macbookpro/homeassistant/lib/python3.8/site-packages/hass_nabucasa/iot.py", line 94, in _async_handle_handler_message
    result = await handler(self.cloud, message["payload"])
  File "/Users/macbookpro/homeassistant/lib/python3.8/site-packages/hass_nabucasa/iot.py", line 154, in async_handle_webhook
    return await cloud.client.async_webhook_message(payload)
  File "/Users/macbookpro/homeassistant/lib/python3.8/site-packages/homeassistant/components/cloud/client.py", line 187, in async_webhook_message
    response = await self._hass.components.webhook.async_handle_webhook(
  File "/Users/macbookpro/homeassistant/lib/python3.8/site-packages/homeassistant/components/webhook/__init__.py", line 79, in async_handle_webhook
    peer_ip = request[KEY_REAL_IP]
TypeError: 'MockRequest' object is not subscriptable

So from what I can tell some of the themes are broken…that’s probably easily fixable but not sure what to do with the hass_nabucasa errors…any ideas?

bschatzow · May 24, 2020, 11:38pm

I have posted in core and it was moved to front end. Not seeing much here. A little more information. Today updating from .110.1 to 110.2 I tried the UI again to do the update. I then monitored my logs using SSH. What happened looking at the core logs is that it stopped loading. The last line of the update was

2020-05-24 14:45:39 INFO (MainThread) [homeassistant.setup] Setting up hassio
2020-05-24 14:45:39 INFO (MainThread) [homeassistant.setup] Setup of domain hassio took 0.0 seconds.

No errors, warning or anything else.
When HA is loading properly there is a lot more that loads after this the domain hassio line. Not sure what is happening, but I have been having similar issues since .102.X .After waiting another 10 minutes I did a Ha host shutdown. I restarted and all worked.
Any ideas?

walaj · May 24, 2020, 11:45pm

fixed in 0.110.2

speedfire · May 25, 2020, 4:48am

I’m surprise you still pursue this way and remove everything that made infra as code possible. This 110 is a no-go. I suggest YOU to read people’s comments against the « future of Yaml » which is just a one way conversation.

nickrout · May 25, 2020, 5:47am

While I agree with infra as code, you do have to realise that @ludeeus does not write all of home-assistant

c1c3r0 · May 25, 2020, 6:41am

I can confirm - looks like issue with layout (columns) is now fixed in 0.110.2.

g.nigro · May 25, 2020, 8:14am

i’ve the same problem, 5 Google Cast entities all unavailable, sometimes, on restart they are available but after some time they turn out to unavailable state

klogg · May 25, 2020, 8:22am

Interesting.

I’m on 109 and (I am pretty sure only since I upgraded to from 108) I sometimes get the same thing happen.

I do a restart and I cannot get to the frontend at all. Everything seems to be up though as I can SSH in and edit my config via Samba.

The only way to get it to work has been to restart the host.

As I said this is not every time I do a restart but it is definitely new behaviour and I have not added anything of any substance (that I can think of) that could be causing this.

Is there any way to troubleshoot this next time it happens?
(I’m a Linux novice so please spell it out if it involves the command line )

Wagoneermaster007 · May 25, 2020, 8:22am

Hi. Thanks, that solved the issue

nickrout · May 25, 2020, 8:27am

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.

bschatzow · May 25, 2020, 9:31am

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.

bschatzow · May 25, 2020, 9:35am

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?

Mariusthvdb · May 25, 2020, 2:38pm

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?

tom_l · May 25, 2020, 2:49pm

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.

Mariusthvdb · May 25, 2020, 3:12pm

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…

Mariusthvdb · May 25, 2020, 3:14pm

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?

tom_l · May 25, 2020, 3:27pm

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.

Mariusthvdb · May 25, 2020, 3:32pm

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:

github.com/home-assistant/frontend

developer-tools/state loading/acting very slowly

opened 03:27PM - 25 May 20 UTC

closed 07:57PM - 25 May 20 UTC

Mariusthvdb

Bug

## Checklist - [ ] I have updated to the latest available Home Assistant version. - [ ] I have cleared the cache of my browser. - [ ] I have tried a different browser to see if it is related to my browser. ## The problem  Using developer-tools/state used to be quite swift, and up to version 109.6 took most 2-3 seconds on , RPi4 4 meg instance. After having updated to 110.2 it really seems to to nothing at first, and then after about 15 seconds or so, finally loads the states. Typing in the filter field, really makes the interface unresponsive and long waits are a new fact. ## Expected behavior A swift interface. As a comparison, the new configuration/entities pages loads practically immediately, indicating it is not a system issue of the setup or config itself?  ## Steps to reproduce  ## Environment  - Home Assistant release with the issue: 110.2 - Last working Home Assistant release (if known): 109.6 - Browser and browser version: Chrome, Safari on Mac all latest software per 25-5-2020 - Operating system: Mac OS ## State of relevant entities  ```yaml ``` ## Problem-relevant configuration  ```yaml ``` ## Javascript errors shown in your browser console/inspector  ```txt ``` ## Additional information nothing to add, no errors in the log. I can add the other pages under developer-tools seem to be quicker than before, so that's good ;-)

tom_l · May 25, 2020, 3:34pm

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.

firstof9 · May 25, 2020, 4:12pm

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