Core: hass.io won't start when zha component enabled

[iamwillbar]

Home Assistant release (hass --version):

core-ssh:/config# hassio supervisor update
{
  "result": "error",
  "message": "Version 0.52 is already in use"
}
core-ssh:/config# hassio host update
{
  "result": "error",
  "message": "Version 1.0 is already in use"
}
core-ssh:/config# hassio homeassistant update
{
  "result": "error",
  "message": "Version 0.50.2 is already in use"
}

Component/platform:
zha

Description of problem:
After adding the zha component configuration and restarting Home Assistant never completes startup and the web UI is unavailable.

Running hassio homeassistant logs | grep zha only shows two lines:

2017-08-10 20:06:59 INFO (MainThread) [homeassistant.setup] Setting up zha
2017-08-10 20:07:09 WARNING (MainThread) [homeassistant.setup] Setup of zha is taking over 10 seconds.

The zigbee.db file is created in /config and is 45056 bytes in size.

Expected:
Successful startup and ability to join Zigbee devices or at the very least for homeassistant to still start even if the zha component can't be used.

Problem-relevant configuration.yaml entries and steps to reproduce:

zha:
  usb_path: /dev/ttyUSB1
  database_path: zigbee.db

Additional info:
Using a Nortek/GoControl Z-Wave & Zigbee USB Adaptor - Model HUSBZB-1.

core-ssh:/config# hassio host hardware
{
  "result": "ok",
  "data": {
    "serial": [
      "/dev/ttyUSB1",
      "/dev/ttyUSB0"
    ],
    "input": [],
    "disk": [],
    "audio": {
      "0": {
        "name": "bcm2835 - bcm2835 ALSA",
        "type": "ALSA",
        "devices": {
          "0": "digital audio playback",
          "1": "digital audio playback"
        }
      }
    }
  }
}

[JustinPM]

Having this same issue. Same hardware as well.

{
  "result": "error",
  "message": "Version 0.53 is already in use"
}
core-ssh:~# hassio host update
{
  "result": "error",
  "message": "Version 1.0 is already in use"
}
core-ssh:~# hassio homeassistant update
{
  "result": "error",
  "message": "Version 0.51.2 is already in use"
}

I have no other indication of what is going on just like you as well. I know that it's zha doing it. It is creating the file, but it doesn't do anything.

[JustinPM]

Hey, willbar are you running this from a docker container or hass.io?

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[dshokouhi]

As a new user of the HUSBZB-1 I have seen this issue as well. It seems to happen randomly and I may need to try and restart hass 3-4 times until it will actually load up. I am on version 0.58.1 installed in a venv on my raspberry pi3. So far I have paired a few zigbee devices but I am also seeing this issue when I restart after adding a zwave device so I am not sure what the problem is.

[jeeloo]

New user here as well and I set up a new card with hass.io yesterday and I had the exact same problem. Never managed to get Homeassistant started with zha in the configuration. I don't have the exact numbers for the versions installed but I did a fresh installation with hass.io image for Raspberry PI 2, https://github.com/home-assistant/hassio-build/releases/download/1.1/resinos-hassio-1.1-raspberrypi2.img.bz2

[dshokouhi]

FYI the issue still exists in 0.59.1 as well as 0.59

For other users having this issue I recommend restarting a few times until hass actually starts up. That is what I have been doing and it seems to work for the most part.

If there are any more logs we can give to developers to get better stability please let me know and I will gladly supply more logs.

[abriasffxi]

Ditto on 0.59.1. I can't get it to start no matter what- running in a virtualenv.

[dexrex347]

Same issue as noted above.

[abriasffxi]

I was able to get mine working after replugging my USB stick. It seems
like the zha component has no failure mechanism for the usb device so if
it's not responsive then bootup of all of ha gets stalled.

On Dec 14, 2017 4:42 PM, "dexrex347" [e-mail] wrote:

Same issue as noted above.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/8922#issuecomment-351858481,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATttjfPrO4ceXcAUQIwnQaf-NgFYuOguks5tAaQ5gaJpZM4O0Ne2
.

[ryanwinter]

I am having the same problem with 0.60.1 and a HUSBZB-1. Replugging in the USB stick appears to resolve the problem.

[abriasffxi]

I'm having this issue again after updating to .61 and no amount of reinstall or reconnecting the USB will work.

[iamwillbar]

@JustinPM I'm running the Hassbian image natively on a Raspberry Pi. Can we remove the waiting-for-reply label, as you can see a number of us are hitting this issue.

[commandcontrolit]

I ran into the same issue and spent days at a time trying to figure this out. Glad it wasn't something I was doing wrong - I was going a bit crazy over it.

My thread for help is here: https://community.home-assistant.io/t/web-interface-failing-to-come-up/42380/3

Hope this gets fixed.

I'm running hass.io over Ubuntu. When it works - it works great.

[csmatt]

Using the HUSBZB-1 on 0.63.2 inside a docker container running on hassbian and I have the same issue. Zwave from the HUSBZB-1 works perfectly fine.

zha:
usb_path: /dev/zigbee
database_path: /config/zigbee.db

[anderwm]

Me too, is the .db file not getting created/linked because it is in docker?

[MtotheKay]

I tried hass.io and hassbian. Same Problem on both installations (OotB).
I am using XBee Pro S2C on a Sparkfun USB Dongle.

The Log seems same same. I inceased the Log Level to DEBUG:

2018-02-23 16:37:14 INFO (MainThread) [homeassistant.setup] Setting up zha
2018-02-23 16:37:14 DEBUG (MainThread) [zigpy_xbee.uart] Connection made
2018-02-23 16:37:14 DEBUG (MainThread) [zigpy.appdb] Loading application state from home/homeassistant/.homeassistant/zigbee.db
2018-02-23 16:37:14 DEBUG (MainThread) [zigpy_xbee.api] AT command: AP (2,)
2018-02-23 16:37:14 DEBUG (MainThread) [zigpy_xbee.api] Command at (1, b'AP', b'\x02')
2018-02-23 16:37:24 WARNING (MainThread) [homeassistant.setup] Setup of zha is taking over 10 seconds.
2018-02-23 16:37:24 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: timestamp=1519403844.2756693, exception=, message=Setup of zha is taking over 10 seconds., source=bootstrap.py, level=WARNING>

[aetimmes]

Also running into this issue. Would appreciate any updates. I'm on Hassbian so let me know if you need extra information from me.

No amount of rebooting/restarting the service brings the zha component online.

[alexbremel]

Same issue here as well. Hassbian, raspberry pi 3 b+, using an XBee S2C on a Sparkfun USB Dongle. No rebooting/resetting/replugging usb helps.

[abriasffxi]

Hey guys -

I just reinstalled via creating a new virtualenv with python 3.6 and it
works now. Not sure if it was the fresh virtualenv, python 3.6, or the
newest version of hass, but it magically started working.

On Sat, Apr 7, 2018, 2:46 PM alexbremel [e-mail] wrote:

Same issue here as well. Hassbian, raspberry pi 3 b+, using and XBee S2C
on a Sparkfun USB Dongle. No rebooting/resetting/replugging usb helps.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/issues/8922#issuecomment-379494509,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ATttjR7ojwfZuWJgv44QR_2V7ZEcyaJ6ks5tmReigaJpZM4O0Ne2
.

[alexbremel]

Interesting - No such luck for me. Just tried a fresh install of raspbian, installed python 3.6.5, created a virtualenv, and installed homeassistant - still seeing the issue here.

[iusegithubtoo]

broken for me, too

fresh install hass.io on raspberry pi today 0.66.1

works ok (HUSBZB-1) until I add
zha:
usb_path: /dev/ttyUSB1
database_path: /config/zigbee.db

hass.io web interface broken

[zenturacp]

Same issue here

2018-04-26 00:13:44 WARNING (MainThread) [homeassistant.setup] Setup of zha is taking over 10 seconds.

Added the XBee device i see it in my Docker container as /dev/ttyUSB0 - and the baud_rate options is not working.

I tested the XBee Pro S2C on my Win10 laptop and its confirmed working - and i see it in dmesg beeing added as USB device

Do i need some kind of special firmware for the XBee device?

[zenturacp]

2018-04-26 00:19:48 DEBUG (MainThread) [zigpy_xbee.uart] Connection made
2018-04-26 00:19:48 DEBUG (MainThread) [zigpy.appdb] Loading application state from /config/zigbee.db
2018-04-26 00:19:48 DEBUG (MainThread) [zigpy_xbee.api] AT command: AP (2,)
2018-04-26 00:19:48 DEBUG (MainThread) [zigpy_xbee.api] Command at (1, b'AP', b'\x02')
2018-04-26 00:19:58 WARNING (MainThread) [homeassistant.setup] Setup of zha is taking over 10 seconds.
2018-04-26 00:19:58 INFO (MainThread) [homeassistant.core] Bus:Handling <Event system_log_event[L]: timestamp=1524694798.7819579, level=WARNING, message=Setup of zha is taking over 10 seconds., exception=, source=bootstrap.py>

[bakazm]

Same issue here using a HUSBZ-B1. Installed Hass.io on ubuntu server 18. Zwave works fine. Multiple reboots do not fix the problem. Initial zigbee.db file is successfully created. Commenting the component allows the system to boot. No errors in the log other than the 10 second warning.

[KLUSEK]

I've got the same using XBee module

[kenthua]

There has got to be a better way to debug this. For me it's hit a point where it won't startup regardless. Remove the old zigbee.db, plug / unplug device, reboot.

This is for the husbzb-1 device.

A dmesg has this printing on periodically.

cp210x ttyUSB1: failed set req 0x1e size 4 status: -32
cp210x ttyUSB1: failed to set baud rate to 300

For those that have it working say they get these messages as well, so it may be a red herring.

[zenturacp]

Anyone havet it working at all?

[kenthua]

I was able to get it started at times on 0.68 and lower when my zigbee.db didn't have any devices registered.

Now with 0.69+ no combination works, even an empty zigbee.db. I'm not sure if there were updates in 0.69.

[dshokouhi]

I have the component working fine since I moved off a Pi and on to my own ubuntu server that I setup for home assistant. I no longer see this issue with home assistant not loading. I do see "zha taking longer than 10 seconds" but after 30-60 seconds things load up again. I do know that on my faster hardware restarts are a lot faster so the time you need to wait may be longer than me.

[bakazm]

More details.... I'm running .69 on Ubuntu server 18.04. Here is what I tried:

When I use the following config, the zigbee.db file gets created but then Home Assistant fails to load (even after a reboot).

zha:
usb_path: /dev/ttyUSB1
database_path: zigbee.db
Removing that from the config allows it to boot correctly.

Then I read that I might need the full path to the db file. So I changed the config to read:

zha:
usb_path: /dev/ttyUSB1
database_path: /usr/share/hassio/homeassistant/zigbee.db
That allows Home Assistant to boot, but I have a setup error on my overview screen that says “The following components could not be set up…” and it refers to the ZHA component. Checking the log files reveals this:

sqlite3.OperationalError: unable to open database file
I’ve verified that’s the correct path in SSH and FTP.

[zenturacp]

Okay well i run on a NUC with NVME - and lighting fast reboots on a Debian installation / docker.. My host sees it and its working (detected) did not test it on the host though...

And havnt waitet more than 1-2 mintes then i gave up..

There was a note about how / what firmware should be loaded right? There is a ton of firmware available for the XBEE some is with different functions - can someon elaborate on what version is the correct?

[kenthua]

@bakazm was the zigbee.db file created and could there be possible permission issues?

@dshokouhi I guess I'll have to be more patient and see what happens? I haven't let it run longer than a few min like what @zenturacp references. I am also not running on a pi, something a bit faster running on fedora with homeassistant in a container via hassio.

[kenthua]

Unfortunately waiting doesn't resolve the issue

[alexbremel]

@zenturacp @MtotheKay @KLUSEK Thinking there might be a separate problem for those of us experiencing issues with the xbee s2c - I finally got my hands on a HUSBZB-1 (https://www.amazon.com/gp/product/B01GJ826F8), and after swapping to that have everything working fine now. Current hassbian image, latest updates applied to OS, homeassistant 0.68.1 - running on a raspberry pi 3 b+. Still get the taking longer than 10 seconds message, but otherwise things are behaving.

[zenturacp]

@alexbremel thats cool that it works - just anoying that the XBEE X2C should work as well.. :-) And does not - i can't get a HUSBZB-1 in Denmark - thats why i got the other device since it shipped from Adafruit to Denmark.. Guess i will just have to dont use Zigbee - or wait till there is better support (I have like 2-3 devices) so no worries - as of now i use my Homey with MQTT - but want to get rid of my Homey

[kenthua]

Looks like something needs to be updated on the hassio image side, further debugging I did here:

https://github.com/zigpy/bellows/issues/120

[dmulcahey]

@all any chance you haven't locked in the address of the zigbee radio? there are 2 radios in the nortek stick and if you don't lock them in it can cause this issue when they flip after reboots. My guess is that the radios aren't mapped to the same device name anymore and that's why things are hanging at startup.

see this link for how to handle this on an RPi. or this link from the zwave docs for hass should help too. It's probably a good idea to give both radios persistent names.

[kenthua]

@dmulcahey Thanks for posting some suggestions. I ran the udevadmin commands as noted in the first link and both ttyUSB0 and ttyUSB1 both report the same serial number so it won't help with the udev rules. A dmesg doesn't seem to help either.

[kenthua]

This is still appearing with bellows 0.6.0 and zigpy 0.1.0 on homeassistant 0.70b7

EDIT: removed FYI

[dshokouhi]

@dmulcahey I had also ran similar udev rules as well for a persistent device name that has been working well for me.

[dmulcahey]

Same here. I’m confused by the people who are saying it won’t make a difference. I’m really thinking it is the cause of their issue.

[Mibix]

I am using Ubuntu 17.10 in a VirtualBox VM with HA running in venv. I'm using persistant names and having the same issues setting this up.

[dmulcahey]

Have you tried flipping the devices? Just to make sure you’re pointing at the right one?

[Mibix]

I have tried swapping them and restarting a few times now with no luck.

[dmulcahey]

What does your full zha config look like? And can you jump on discord?

[Mibix]

Zigbee

zha:
usb_path: /dev/zigbee
database_path: /home/homeassistant/.homeassistant/zigbee.db
zigbee is set to ttyUSB1 at the moment
I have also tried using ttyUSB1 and ttyUSB0 I am in the Home Assistant #general channel on discord

[kenthua]

I've tried switching ttyUSB0 and ttyUSB1 as well to no avail. The symlink variation doesn't work with hassio containers as the device symlinks don't transfer from the host to the container.

It seems to be however the zha component leverages the bellows libraries. As I've been able to consistently get an ACK with a vanilla python container with zigpy and bellows libraries on ttyUSB1.

I have the typical zha config:

zha:
  usb_path: /dev/ttyUSB1
  database_path: /config/zigbee.db  

[adamomg]

After numerous troubleshooting steps on Discord with zombu2, we have discovered that the Nortek stick that I have only has the Zwave portion on it. I purchased mine from Gate Openers Unlimited on Amazon (https://www.amazon.com/s?marketplaceID=ATVPDKIKX0DER&merchant=A36RV344P5JWP3) - I am asking for a refund.

[bakazm]

Interesting... can you outline the steps to verify if a Nortek / Linear HUSBZB-1 really has a zigbee radio in it? Some people with this stick have it working while others can't get it to work. Is it possible that some of them don't have zigbee?

[alexbremel]

@adamomg - was your stick a husbz-1 or husbzb-1? I started to see a lot of the first popping up while the second were really hard to find, and some of them were advertised in a fairly misleading fashion. I'm only seeing husbz-1's from the store you linked, and those are the zwave only ones.

[kenthua]

I believe the theme has been, if you have /dev/ttyUSB0 and /dev/ttyUSB1 you have zwave and zigbee. If you have only a /dev/ttyACM0 it's the zwave only.

These assume the husbz(b)-1 is the only device connected.

[Mibix]

I dunno we tried to get my ttyUSB0 and ttyUSB1 working for at least an hour and it seems like it is a dud (at least the zigbee part)

[kenthua]

At least for my situation, there is something wrong with the hassio x86_64 homeassistant image because I installed homeassistant in the python:alpine image and no issues with zha loading.

[adamomg]

@alexbremel - I ordered a HUSBZB-1 and was sent a HUSBZ-1.

[Temeriki]

Husbzb-1 confirmed getting USB0 and 1. Linux hassbian 4.9.80-v7+ #1098 SMP Fri Mar 9 19:11:42 GMT 2018 armv7l os ras pi 3b+. Zwave component loads fine, hangs if I try to add zha. DB was created, let sit overnight to see if it would load and no dice.

[adamomg]

Confirmed having a Nortek HUSBZB-1

Attempt 1: NUC | HASS installed on Docker Container
Enabling ZHA on HUSBZB-1 does not work. Aeotec Z-Wave stick works fine. ConBee stick works fine. Tried booting with only Z-Wave side of the HUSBZB-1 enabled and HASS started up fine. Enabling ZHA breaks HASS.

Attempt 2: Rpi3 - HASS.IO
Same as results

Attempt 3: Rpi3 - Raspbian - HASS installed in a Virtual Enviroment
Same as results

Is there a way to test my HUSBZB-1 stick somewhere besides HASS?

[dmulcahey]

@adamomg you can try running bellows on its own from the command line

[coreyo]

See https://github.com/zigpy/bellows/issues/120

As best we can tell, there's a problem with bellows or zigpy* . Would appreciate more feedback.

[Temeriki]

@dmulcahey @coreyo I could dual boot on another partition on my desktop and install some ubuntu or something if someone wants to give me a quick rundown on how to help troubleshoot bellows/zigpy My linux background is about 10 years old and rusty but its coming back. I got a i5 3570-k and 12gb of mismatched ram in my desktop, running win 7 so I dont think a VM would work so well.

Edit: That is if testing the the ras pi 3b+ isnt an option.

[corylulu]

@adamomg I ordered mine from the same place. The manual that it came with says HUSBZB-1 and it shows as having 2 ports, one of which is labelled as zigbee... Does yours do the same? How can I verify if mine is bad?

Discord: corylulu#0001

[abdealikhurrum]

Same source, same problems. Tried it with openHAB too, havent had much success there either.

[nphil]

exact same issue - HUSBZB-1 and running official Home Assistant docker image on my QNAP. Z-wave starts up but if I enable zigbee, same issue as above posters.

[justin8]

I'm seeing the same thing with the elelabs rpi shield zigbee adapter. It's listed as compatible, but enabling zha component stops hass from showing the web ui. Everything else seems fine until then.

This is on the latest hass.io, clean install as of today. I can't get the service to start up at all with zha enabled, it shows the "taking longer than 10 seconds" error, never shows the domain finishing setup, and never starts the webserver.

It seems this has been an ongoing issue for almost a year now, is there really still no fix?

edit: The solution to my issue, was to RTFM. If you use an adapter attached to the uart pins on RPI 3b's (the ones with bluetooth), they have bluetooth hooked up to the uart RX/TX pins (8/10). So you have to disable it in the config.txt file in the boot partition by adding dtoverlay=pi3-miniuart-bt to it and rebooting. ZHA worked fine after that, and I could add devices without issue.

[cinghialino]

they have bluetooth hooked up to the uart RX/TX pins (8/10). So you have to disable it in the config.txt file in the boot partition by adding dtoverlay=pi3-miniuart-bt to it and rebooting

any idea on how to do this on a hassio installation (since there is no /boot/ partition)?

edit: maybe RESIN_HOST_CONFIG_dtoverlay=pi3-miniuart-bt

[justin8]

You can put the SD card in to any other computer and modify it, /boot is fat32, so windows/mac should be able to read it. Windows doesn't support multiple partitions, but it should read the first one fine.

[cinghialino]

I have discovered that my adapter was faulty. I replaced and now everything works fine.

[DocCox]

I grabbed my HUSBZB-1 stick from Home Controls Inc and started encountering these issues. Originally didn't connect the dots and spent a couple weeks troubleshooting on a thin client PC, an Odroid XU4, and a pi3
Per their advice I purchased a second stick - and it has the same problem. They did mention they were aware there was a batch of sticks that had an issue when getting flashed but mine wasn't from the 'bad batch' either time. Using just a z-wave stick, or commenting out the zigbee portion resolves the issue every time.

[shortbloke]

FWIW I have just installed the Elelabs ZigBee Raspberry Pi Shield and once zha was configured hass.io wouldn't work. I thought it might be a conflict with my z-wave USB stick, but it wasn't. I was only able to get to work by moving from the 64-bit version of hass.io to the 32-bit version. I know the 64bit version is only in beta, but I thought I'd mention it here in other stumble over the same issue.
I was using version: 0.82.1

[Firemogle]

I am finding I have this same issue with a HUSBZB-1 stick as well but only if I restart home assistant from the reboot command. If I reboot the entire raspberry pi, it will come up normally. Currently only have 1 device installed through ZHA.

[iamelk]

Hi - helping issue springcleaning! Is this still an issue you are experiencing? Can you please try upgrading to the latest version of Home Assistant (0.90) and report back if this is still a problem? There has been a lot of zha enhancements lately! Thanks!

[DougEdey]

I can confirm I am experiencing this issue after moving from RPi to a X86-64 based HASS.io image.

What I've noticed is that if I stop all my containers, everything works locally, but if I start the supervisor (homeassistant/amd64-hassio-supervisor) container, it immediately stops working.

SO I tried to just start the home assistant container (homeassistant/qemux86-64-homeassistant) and that immediately got access to ZHA (/dev/ttyUSB1) and everything is working fine, until I need to restart Home Assistant & have the supervisor running.