0.113 stuck "Home Assistant is starting up"

[robyevolution]

The problem

After updating to the latest version, home assistant gets stuck in:
Home Assistant is starting up, not everything will be available until it has completed booting.
I have a NUC so it starts fairly quickly but after waiting half an hour it always remains blocked, the frontend loads but the template sensors and automations do not load, returning to 112.5 everything works correctly.
How can I solve it?

Environment
Home Assistant Core release with the issue: 0.113
Last working Home Assistant Core release (if known): 0.112.5
Operating environment (OS/Container/Supervised/Core): Core
Integration causing this issue: ALL
Link to integration documentation on our website: ALL

[sagitt]

same issue.
tested anything..... removing custom components
removing hue integration
creating new 0.113 proxmox vm and restoring backup without restore Hass version but onlu addons\config.... nothing.

Sometime i see "automation" platform can't start.....

restoring vm snapshot all works fine.

[goldbe4804]

believe i have the same kind of problem with a Rpi4 when i try to log into HA name:8123 it can take over 5min's to load
and ones it does load if i switch screen ( to hacs, node-red....so on) it can take 5 or so mins for that page to load

[schoenof]

I had the same problem....I disabled the tensorflow stuff and the upgrade to 0.113 finished now....re-enabling tensorflow after 113.0 upgrade results in some errors and hangs the HA startup again....seems there is some issue with 113 and tensorflow

[Scialla]

same problem here. HA core in venv on Raspian buster and python 3.7.5.
On start get stuck and lost possibility to restart or shutdown HA from webgui.
Lost all template sensor, announce don't work, some automation don't work.
logger, at debug, don't report anything wrong, no error, no warning.

For template sensor, state is unknow but, if i put template in jinjia model, returns correct value

i don't use tensorflow

Rollback to 0.112.5 resolve and all work fine

[caimale78]

Same problem for me,Nuc

[maxcanna]

same here on HA core on docker

[nicx]

+1

[blackscreener]

Maybe bad config. It was nmap config for me.

[sagitt]

Maybe bad config. It was nmap config for me.

Well, bad config.. how check what config? I have 50 packages, over 200 automations ...

[Scialla]

Maybe bad config. It was nmap config for me.

Config work well with 0.112.5

No error in log (debug) in 0.113

[blackscreener]

Maybe bad config. It was nmap config for me.

Well, bad config.. how check what config? I have 50 packages, over 200 automations ...

How long HA turn on? With my bad nmap config (too much IPs scan) it turns on few minutes on 112.4, with 0.113 it never starts... With proper nmap config it is lightning fast.

[robyevolution]

i removed nmap from my configuration but the problem persists

[dshokouhi]

Are you guys all using tensorflow? I think there is an issue with tensorflow and docker installations including HassOS and core.

[maxcanna]

@dshokouhi no, not at all. I'm not using TF but I got the starting up message

[dshokouhi]

and you guys checked the logs for HA? tried turning on debug logging to see what other issue there might be?

[maxcanna]

I think problem is related to template evaluation since template sensors don't work and template triggers don't start automations

[dshokouhi]

There should be logs suggesting that. Especially if HA is not starting up you should see something.

[maxcanna]

As stated above by other users:

No error in log (debug) in 0.113

[robyevolution]

I have removed all the integrations and now it seems to work, the integrations that I have not reinstalled are: transmission, fritzboxtools, onvif camera

[sagitt]

I have removed all the integrations and now it seems to work, the integrations that I have not reinstalled are: transmission, fritzboxtools, onvif camera

I have onvif and fritz tools. I’ll try

[robyevolution]

i removed fritzbox tool from yaml configuration and added via integration and it works, i think it is an onvif or transmission problem

edit: now i reinstalled transmission and it works, i think the problem is the onvif integration

[Scialla]

i don't have onvif integration... no transmission, no fritz. Tried to reinstall 0.113 and same problem, template sensor don't work, template trigger don't work, restart and shutdown from webgui don't work. Probably there will be some other problem but i'm back to 112.5 again

[robyevolution]

try to uninstall all the integrations and restart HA, if it starts normally try to reinstall the integrations one by one, restarting each time until it crashes, once it crashes try to remove the last integration and restart.
I solved it like this

[bdraco]

Since this problem is being caused by specific integrations, it would be helpful to open an issue for each integration that is causing the issue with your specific configuration.

[Scialla]

but there are non problem with the integration, template sensor are not related to them..

[dshokouhi]

Can you post an example of a template sensor that is no longer working?

[maxcanna]

Exactly. I don't think it's caused or related to any integration. Several integrations have been listed here but there's no common subset so it is not an integration. Automation is not an integration, sensors are not integration either.

[maxcanna]

@dshokouhi if you create an automation with a trigger like this

{{ state_attr('sun.sun', 'azimuth') > 250 }}

it won't start. If you evaluate the same condition in the dev tools it gives True. I think this is related to the problem of the template sensors. As if there's something wrong with the template evaluation

[Scialla]

tried to install 0.113.0b0 same problem

all this template sensor don't work anymore in HA 0.113:

  - platform: template
    sensors:
      air_quality:
        friendly_name: "Air Quality"
        value_template: "{{ state_attr('air_quality.air_quality_sensor_3c26cf', 'air_quality_text') }}"
  
  - platform: template
    sensors:
      temperatura_ingresso:
        friendly_name: "Temperatura Ingresso"
        value_template: "{{ state_attr('climate.netatmo_ingresso', 'current_temperature') }}"
        unit_of_measurement: '°C'
      temperatura_cucina:
        friendly_name: "Temperatura Cucina"
        value_template: "{{ state_attr('climate.netatmo_cucina', 'current_temperature') }}"
        unit_of_measurement: '°C'
      temperatura_esterna:
        friendly_name: "Temperatura Esterna"
        value_template: "{{ state_attr('weather.casa', 'temperature') }}"
        unit_of_measurement: '°C'
      umidita_esterna:
        friendly_name: "Umidità Esterna"
        value_template: "{{ state_attr('weather.casa', 'humidity') }}"      
        unit_of_measurement: '%'

These are some in lovelace:

Same template sensor in jinja return correct temperature:

Same sensor in State return unknown:

[Scialla]

For example, this automation don't work anymore on 0.113:
automation:

  - alias: Apertura CONTATTI e reset
    trigger:
    - platform: state
      entity_id: group.contatti_magnetici
      to: 'on'
      for:
        seconds: 3
    condition: []
    action:
      service: mqtt.publish
      data:
        topic: tele/SonoffBridge/RESULT
        payload: '{"RfReceived":{"Data":"key_clean"}}'
        retain: false

contatti_magnetici:
  name: Contatti magnetici
  entities:
    - binary_sensor.pir_ingresso
    - binary_sensor.pir_studio
    - binary_sensor.box_davide
    - binary_sensor.box_giovanna
    - binary_sensor.cantina_grande
    - binary_sensor.cantina_piccola
    - binary_sensor.camera_letto
    - binary_sensor.cucina
    - binary_sensor.ingresso
    - binary_sensor.studio
    - binary_sensor.telecomando_a
    - binary_sensor.telecomando_b
    - binary_sensor.telecomando_c
    - binary_sensor.telecomando_d
    - binary_sensor.porta_casa

Config of first binary sensor (all are similar):

- platform: mqtt
  name: "PIR Ingresso"  
  payload_on: "on"
  payload_off: "off"
  device_class: opening
  state_topic: "tele/SonoffBridge/RESULT"
  value_template: >
    {% if value_json['RfReceived'].Data == 'EC1DEE' %}
      on
    {% elif value_json['RfReceived'].Data == 'key_clean' %}
      off
    {% else %}
      {{ states('binary_sensor.pir_ingresso') }}
    {% endif %} 

i think problems are related to value_template

[bdraco]

@bdraco Sure #38160

But for some reason your code didn't output anything in my case.

Thanks for testing. It shouldn't output anything unless it is blocked for 60 seconds. Did you wait that long ?

[divanikus]

Thanks for testing. It shouldn't output anything unless it is blocked for 60 seconds. Did you wait that long ?

Yup, I've waited until supervisor did the rollback to 0.112.4. Nothing popped up.

[bdraco]

Thanks for testing. It shouldn't output anything unless it is blocked for 60 seconds. Did you wait that long ?

Yup, I've waited until supervisor did the rollback to 0.112.4. Nothing popped up.

How long was it before it rolled back?

[divanikus]

@bdraco I'm not sure, 10-15 minutes I guess.

[bdraco]

@bdraco I'm not sure, 10-15 minutes I guess.

It should have definitely logged. We only want to log tasks that are taking more than 60 seconds to avoid spamming the logs. I wonder if there is a chain over tasks that never finish in this case?

[divanikus]

@bdraco I've posted my edits above. I see my "Pending tasks: " lines in the logs, but not yours "Waited ...". I guess it doesn't reach that point somehow.

[snakuzzo]

@bdraco is it possible to reopen the issue?

[bdraco]

@bdraco is it possible to reopen the issue?

Why do you want to reopen the issue?

[Scialla]

Because 113.1 don't resolve issue (for me), the problems persist

[bdraco]

Because 113.1 don't resolve issue (for me), the problems persist

This change won't solve every integration that is blocking startup, it will only show you which integration is causing it when the debug logging is on so we can get an issue opened against the integration to fix it.

Did you enable the debug logging?

[Scialla]

thanks bdraco, i will try again in a few weeks, i'm starting for holidays

[divanikus]

@bdraco If you do not believe me, that nothing shows up in the logs in my case, here's the logs.
https://gist.github.com/divanikus/afe67903ac428a8d8e0a7f58a2f4f2f0

[bdraco]

@bdraco If you do not believe me, that nothing shows up in the logs in my case, here's the logs.
https://gist.github.com/divanikus/afe67903ac428a8d8e0a7f58a2f4f2f0

Its not that I don't believe you. I looked though the kodi code and the way the websocket is created looks fine as it eventually ends up calling self.hass.loop.create_task(ws_loop_wrapper()) to avoid having the task tracked. The task referenced on line 417 should block for a few microseconds while its being setup. Your log is showing that to be the case as it continues on past 00:01:47

[bdraco]

@divanikus Is your startup still blocked or does the problem go away when you disable kodi?

[divanikus]

@bdraco it goes away. Also, I have enabled that websocket in Kodi itself and now HA starts even with it enabled. The major problem is that 0.112.4 was able to survive that problem.

[bdraco]

@bdraco it goes away. Also, I have enabled that websocket in Kodi itself and now HA starts even with it enabled. The major problem is that 0.112.4 was able to survive that problem.

0.113 startup is a lot faster so its much more likely to hit these type of problems in integrations before bootstrap is finished

[divanikus]

@bdraco Anyway, I guess we need more logging to easily nail such problems. It was really weird and cryptic.

[snakuzzo]

Hi all!
@bdraco I don't know if this can helps...
My friend @Scialla confirmed the issue after 0.113.1 upgrade (HA Core)
He sent to me his .homeassistant directory...and I'm working on that.

I added on his configuration:

debug level on core

logger:
  default: info
  logs:
    homeassistant.core: debug

sensor template

- platform: template
  sensors:
    prova:
      friendly_name: Prova Template"
      value_template: "{{ state_attr('sun.sun', 'elevation') }}"     

automation to send persistent notification on HA start event:

- alias: start_event
  trigger:
  - platform: homeassistant
    event: start
  action:
    service: persistent_notification.create
    data:
      message: "HA STARTED"
      title: "YUPPIIIIIIIIIIIII"

I removed all custom components from custom_components directory and I tried to start HA but the result was...

• sensor template -> unknown
• HA start event never happened

after some checks I found this command_line sensor on sensor.yaml ...

- platform: command_line
  name: Scadenza certificato SSL
  scan_interval: 43200
  command: "/usr/bin/sudo ssl-cert-check -b -c /home/homeassistant/dehydrated/certs/hisdomain/cert.pem | awk '{ print $NF }'"

Now... consider that I'm working on my macbook and both ssl-cert-check binary and pem file are not present in my local directories

I tried to remove the command_line sensor and result was:

• sensor template -> correctly valued
• HA start event happened and the automation sent the persistent notification

Trying to re-add that sensor...

• sensor template -> unknown
• HA start event never happened
• and no DEBUG messages on that. Just this ERROR...

2020-07-25 02:16:44 ERROR (SyncWorker_17) [homeassistant.components.command_line.sensor] Timeout for command: /usr/bin/sudo ssl-cert-check -b -c /home/homeassistant/dehydrated/certs/hisdomain/cert.pem | awk '{ print $NF }'

Removed again and...

• sensor template -> correctly valued
• HA start event happened and the automation sent the persistent notification

Finally I tried all @Scialla custom components one by one and I noticed that minitemp_bt doesn't allow HA to start correctly (also confirmed on custom-components/ble_monitor#98)

Let me know if you need other details

[bdraco]

@snakuzzo Waiting on integrations to complete setup <-- do you see this in the log?

[bdraco]

I tried your command line sensor example and it didn't block startup for me

- platform: command_line
  name: Scadenza certificato SSL
  scan_interval: 43200
  command: "/usr/bin/sudo ssl-cert-check -b -c /home/homeassistant/dehydrated/certs/hisdomain/cert.pem | awk '{ print $NF }'"

[snakuzzo]

@bdraco I tried to add this package on another HA instance and everything works fine :(
all this is absurd!

sensor:
- platform: command_line
  name: Scadenza certificato SSL
  scan_interval: 43200
  command: "/usr/bin/sudo ssl-cert-check -b -c /home/homeassistant/dehydrated/certs/hisdomain/cert.pem | awk '{ print $NF }'"

- platform: template
  sensors:
    prova:
      friendly_name: Prova Template"
      value_template: "{{ state_attr('sun.sun', 'elevation') }}"     

automation:
- alias: start_event
  trigger:
  - platform: homeassistant
    event: start
  action:
    service: persistent_notification.create
    data:
      message: "HA STARTED"
      title: "YUPPIIIIIIIIIIIII"

[snakuzzo]

@bdraco my mistake about that sensor... sorry :)
I'm trying executing HA in foreground and the command present in command_line sensor is executed with sudo and it asks for password...but I didn't notice in all log messages :D

anyway...in @Scialla and @maxcanna case...we can say that minitemp_bt component was the problem.

...and sorry again for waste your time about command_line sensor :P

[ArneMayer]

I am still having this problem. Sometimes it gets stuck on initializing and sometimes it is not. Is there a solution or at least a workaround?

[bdraco]

This issue has been closed for over a year. If you are having a similar issue, please open a new issue as startup has been mostly rewritten since this issues was originally opened and the comments made above will likely confuse any attempts to resolve your issue.