New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setup of zha is taking over 10 seconds. -- homeassistant #120

Open
kenthua opened this Issue May 19, 2018 · 110 comments

Comments

Projects
None yet
@kenthua
Copy link

kenthua commented May 19, 2018

I see plenty of these references on the home assistant forums and other forums as well, however there is never really a clear way to debug other than, is your zigbee.db in the absolute path, reboot a few times and it started working. I'm not sure if my device is just dead or there is some configuration conflict causing problems.

Is my device broken? I only got it working once since I received it, paired 1 switch and then it stopped starting, even with a new zigbee.db

It seems nothing happens after this statement, as evident in bellows CLI itself

2018-05-19 16:07:37 DEBUG (MainThread) [bellows.uart] Sending: b'1ac038bc7e'

homeassistant.log

...
2018-05-19 16:07:33 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=group>
2018-05-19 16:07:33 INFO (MainThread) [homeassistant.loader] Loaded tts from homeassistant.components.tts
2018-05-19 16:07:33 INFO (MainThread) [homeassistant.loader] Loaded tts.google from homeassistant.components.tts.google
2018-05-19 16:07:33 INFO (MainThread) [homeassistant.loader] Loaded zha from homeassistant.components.zha
...
2018-05-19 16:07:37 INFO (MainThread) [homeassistant.setup] Setting up zha
2018-05-19 16:07:37 DEBUG (MainThread) [zigpy.appdb] Loading application state from /config/zigbee.db
2018-05-19 16:07:37 DEBUG (MainThread) [bellows.uart] Sending: b'1ac038bc7e'
2018-05-19 16:07:37 INFO (MainThread) [homeassistant.setup] Setting up updater
2018-05-19 16:07:37 INFO (MainThread) [homeassistant.setup] Setup of domain updater took 0.0 seconds.
2018-05-19 16:07:37 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=updater>
2018-05-19 16:07:38 INFO (MainThread) [homeassistant.setup] Setting up discovery
2018-05-19 16:07:38 INFO (MainThread) [homeassistant.setup] Setup of domain discovery took 0.0 seconds.
2018-05-19 16:07:38 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=discovery>
2018-05-19 16:07:38 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.yr
...
2018-05-19 16:07:40 INFO (MainThread) [homeassistant.setup] Setup of domain notify took 6.4 seconds.
2018-05-19 16:07:40 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=notify>
2018-05-19 16:07:40 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=config.config_entries>
2018-05-19 16:07:40 INFO (MainThread) [homeassistant.setup] Setup of domain config took 6.7 seconds.
2018-05-19 16:07:40 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=config>
2018-05-19 16:07:41 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=tts, service=google_say>
2018-05-19 16:07:41 INFO (MainThread) [homeassistant.core] Bus:Handling <Event service_registered[L]: domain=tts, service=clear_cache>
2018-05-19 16:07:41 INFO (MainThread) [homeassistant.setup] Setup of domain tts took 1.8 seconds.
2018-05-19 16:07:41 INFO (MainThread) [homeassistant.core] Bus:Handling <Event component_loaded[L]: component=tts>
2018-05-19 16:07:47 WARNING (MainThread) [homeassistant.setup] Setup of zha is taking over 10 seconds.

dmesg

  • most say this is a red herring?
[   28.021620] hassio: port 3(vethdc89de9) entered blocking state
[   28.021622] hassio: port 3(vethdc89de9) entered forwarding state
[   34.032822] udevd[7]: starting version 3.2.4
[   34.050590] udevd[7]: starting eudev-3.2.4
[   35.934614] cp210x ttyUSB1: failed set req 0x1e size 4 status: -32
[   35.934626] cp210x ttyUSB1: failed to set baud rate to 300

belllows

bash-4.4# bellows -v DEBUG -d /dev/ttyUSB1 info
debug: Using selector: EpollSelector
debug: Connected. Resetting.
debug: Sending: b'1ac038bc7e'
^C
Aborted!
bash-4.4# bellows -v DEBUG -d /dev/ttyUSB1 -b 115200 info
debug: Using selector: EpollSelector
debug: Connected. Resetting.
debug: Sending: b'1ac038bc7e'
^C
Aborted!
bash-4.4# bellows -v DEBUG -d /dev/ttyUSB1 -b 57600 info
debug: Using selector: EpollSelector
debug: Connected. Resetting.
debug: Sending: b'1ac038bc7e'
^C
Aborted!

home-assistant/home-assistant#8922 (comment)

@kenthua

This comment has been minimized.

Copy link

kenthua commented May 19, 2018

Looks like the zigpy or bellows inside the hassio docker image needs to be updated or configured differently. On the same device if I run the same command in a different container, things look much better.

$ sudo docker run -it --device /dev/ttyUSB1 python bash

root@948e5ed58421:/# bellows -v DEBUG -d /dev/ttyUSB1 info
debug: Using selector: EpollSelector
debug: Connected. Resetting.
debug: Sending: b'1ac038bc7e'
debug: RSTACK Version: 2 Reason: RESET_SOFTWARE frame: b'c1020b0a527e'
debug: Send command version
debug: Sending: b'004221a850ed2c7e'
debug: Data frame: b'0142a1a8502805e67f627e'
debug: Sending: b'8160597e'
debug: Application frame 0 (version) received
debug: Configuring...
debug: Send command setConfigurationValue
debug: Sending: b'7d314321fb582815c3277e'
debug: Data frame: b'1243a1fb54fb737e'
debug: Sending: b'82503a7e'
debug: Application frame 83 (setConfigurationValue) received
debug: Send command setConfigurationValue
debug: Sending: b'224021fb592f15226f7e'
debug: Data frame: b'2340a1fb54c6107e'
debug: Sending: b'83401b7e'
debug: Application frame 83 (setConfigurationValue) received
debug: Send command setConfigurationValue
debug: Sending: b'334121fb792b15a2d77e'
debug: Data frame: b'3441a1fb54d32a7e'
debug: Sending: b'8430fc7e'
debug: Application frame 83 (setConfigurationValue) received
debug: Send command setConfigurationValue
debug: Sending: b'444621fb55d51534da7e'
debug: Data frame: b'4546a1fb5435d07e'
debug: Sending: b'8520dd7e'
debug: Application frame 83 (setConfigurationValue) received
debug: Send command networkInit
debug: Sending: b'554721bfb6607e'
debug: Data frame: b'5647a5bf54b4247e'
debug: Sending: b'8610be7e'
debug: Application frame 23 (networkInit) received
debug: Data frame: b'6647b1b1c487df7e'
debug: Sending: b'87009f7e'
debug: Application frame 25 (stackStatusHandler) received
debug: Send command getEui64
debug: Sending: b'6744218e08c37e'
debug: Data frame: b'7744a18ea70343b959fb4725ad9b7e'
debug: Sending: b'8070787e'
debug: Application frame 38 (getEui64) received
[00:0d:6f:00:0b:56:29:f3]
debug: Send command getNodeId
debug: Sending: b'7045218f65587e'
debug: Data frame: b'0045a18f542af0d57e'
debug: Sending: b'8160597e'
debug: Application frame 39 (getNodeId) received
[0]
debug: Send command networkState
debug: Sending: b'014a21b0ba147e'
debug: Data frame: b'114aa1b05617a27e'
debug: Sending: b'82503a7e'
debug: Application frame 24 (networkState) received
[<EmberNetworkStatus.JOINED_NETWORK: 2>]
debug: Send command getNetworkParameters
debug: Sending: b'124b21803b0c7e'
debug: Data frame: b'224ba180542b9fa97fa936b3120f78e6944127abedce677302c12ca97e'
debug: Sending: b'83401b7e'
debug: Application frame 40 (getNetworkParameters) received
[<EmberStatus.SUCCESS: 0>, <EmberNodeType.COORDINATOR: 1>, <EmberNetworkParameters extendedPanId=[138, 27, 38, 61, 124, 150, 184, 90] panId=45034 radioTxPower=8 radioChannel=15 joinMethod=EmberJoinMethod.USE_MAC_ASSOCIATION nwkManagerId=0 nwkUpdateId=0 channels=134215680>]
debug: Send command getCurrentSecurityState
debug: Sending: b'234821c160e47e'
debug: Data frame: b'3348a1c1545e154170c24125c5589275bc7e'
debug: Sending: b'8430fc7e'
debug: Application frame 105 (getCurrentSecurityState) received
[<EmberStatus.SUCCESS: 0>, <EmberCurrentSecurityState bitmask=116 trustCenterLongAddress=00:0d:6f:00:0b:56:29:f3>]
@rcloran

This comment has been minimized.

Copy link
Collaborator

rcloran commented May 20, 2018

Your debugging suggests that this is a hass.io issue, not a bellows issue. Am I missing anything?

@kenthua

This comment has been minimized.

Copy link

kenthua commented May 20, 2018

Yup, you are correct from what I'm seeing as I went through the debugging process. So it's the version of zigpy / bellows that's installed and/or configured on the hass.io docker image.

@kenthua

This comment has been minimized.

Copy link

kenthua commented May 20, 2018

It appears home-assistant zha component @rcloran, you are working through incrementing the bellows and zigpy versions?

EDIT: added package verions

0.69.1
https://github.com/home-assistant/home-assistant/blob/0.69.1/homeassistant/components/zha/__init__.py

REQUIREMENTS = [
    'bellows==0.5.2',
    'zigpy==0.0.3',
    'zigpy-xbee==0.0.2',
]

master and 0.70 betas
https://github.com/home-assistant/home-assistant/blob/0.70.0b0/homeassistant/components/zha/__init__.py

REQUIREMENTS = [
    'bellows==0.6.0',
    'zigpy==0.1.0',
    'zigpy-xbee==0.1.0',
]

Those are the latest versions? This may help lots of folks as this progresses.

@rcloran

This comment has been minimized.

Copy link
Collaborator

rcloran commented May 20, 2018

Yes, the dependencies were recently updated.

@kenthua

This comment has been minimized.

Copy link

kenthua commented May 26, 2018

So I updated to the beta version of the docker image homeassistant/qemux86-64-homeassistant:0.70.0b3. I confirmed that zigpy was 0.1.0 and bellows 0.6.0 libraries were installed.

Still having issues with it starting. On one occasion I was able to jump start it by running the bellows info command within the container, not sure if it was a coincidence. homeassistant was still in a broken state though, didn't fully initialize.

@dmulcahey

This comment has been minimized.

Copy link

dmulcahey commented May 27, 2018

please see the comment I added here and make sure this isn't what is causing the issue.

@kenthua

This comment has been minimized.

Copy link

kenthua commented May 28, 2018

Not sure if this helps the debugging process, but I was able to re-create this behavior in a standalone python container with zigpy and bellows installed.

This type of behavior appeared as well when the homeassistant container also tried to control/send commands to ttyUSB1 as well.

root@cfc0cbd40e95:/# bellows -d /dev/ttyUSB1 -v DEBUG info
debug: Using selector: EpollSelector
debug: Connected. Resetting.
debug: Sending: b'1ac038bc7e'
^C
Aborted!

When I shut off the homeassistant container, it ACK as expected along with many other request/response messages

@dmulcahey In my lsusb checking across multiple reboots, the positioning of the zwave and zigbee radios stay consistent. Same with my testing of the /dev/ttyUSB1 with a standalone container.

@pumbarger

This comment has been minimized.

Copy link

pumbarger commented May 28, 2018

I too am having this same problem. I switched to a hassbien installation (rp 3b+) because I had better access to things since they are not in docker containers. I checked the required library levels in the zha component and they are the newer versions given above.

REQUIREMENTS = [
    'bellows==0.6.0',
    'zigpy==0.1.0',
    'zigpy-xbee==0.1.0',
]

This does not seem to be specific to hass.io unless hassbien is just a variant of it.

@kenthua

This comment has been minimized.

Copy link

kenthua commented May 31, 2018

Something is up with the x86_64 homeassistant hassio docke image, because I installed HA on a python:alpine image and there were no issues loading zha.

@coreyo

This comment has been minimized.

Copy link

coreyo commented May 31, 2018

Was this issue closed as a duplicate, or as a docker flaw? I'm having the same problem in ubuntu 16.04 LTS using virtualenv (no docker).

@kenthua

This comment has been minimized.

Copy link

kenthua commented May 31, 2018

I closed it as a hassio docker image flaw

@pumbarger @coreyo Are you able to run the bellows commands successfully outside of home assistant?

EDIT, added @pumbarger

@pumbarger

This comment has been minimized.

Copy link

pumbarger commented May 31, 2018

This may be a homeassistant issue but it is not unique to x86_64 as I am having the same issue on a raspberry pi 3b with HASS.IO and with Haspien.

I suspect the HUSBZB-1 controller I just purchased may be bad. Running:
bellows -d /dev/ttyUSB1 -v DEBUG info

Would that be expected to hang if the underlying hardware were bad? I would expect some kind of timeout and returning bad data or an error.

@kenthua

This comment has been minimized.

Copy link

kenthua commented May 31, 2018

Is it hanging here?

debug: Using selector: EpollSelector
debug: Connected. Resetting.
debug: Sending: b'1ac038bc7e'
@coreyo

This comment has been minimized.

Copy link

coreyo commented May 31, 2018

@kenthua Yes, that's exactly what it's doing. pulling the device out and plugging it in a few times didn't seem to fix the issue.

@pumbarger While it's always possible there is a large batch of faulty devices, I think you're jumping to the wrong conclusion. There seem to be dozens of us all with the same problem. More likely the issue is that the version of bellows or zigpy has an issue.

@coreyo

This comment has been minimized.

Copy link

coreyo commented May 31, 2018

@kenthua just to be a little more thorough, these commands were issued in my virtualenv:

(homeassistant) hass@router:/etc/homeassistant$ groups hass
hass : hass dialout
(homeassistant) hass@router:/etc/homeassistant$ ps aux |grep hass
hass      1591  0.0  0.6 1064964 51824 ?       Ssl  May27   0:59 node /usr/local/lib/node_modules/smartthings-mqtt-bridge/bin/smartthings-mqtt-bridge
hass     25357  104  0.8 1855396 67892 ?       Ssl  11:19   0:05 /opt/homeassistant/bin/python3.6 /opt/homeassistant/bin/hass -c /etc/homeassistant --log-file /var/log/homeassistant/hass.log
(homeassistant) hass@router:/etc/homeassistant$ pip list |grep -E 'zigpy|bellows|homeassistant'
bellows                 0.6.0     
homeassistant           0.70.0    
zigpy                   0.1.0     
zigpy-xbee              0.1.0  
(homeassistant) hass@router:/etc/homeassistant$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 May 31 00:24 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 May 31 00:29 /dev/ttyUSB1
(homeassistant) hass@router:/etc/homeassistant$ bellows -v DEBUG -d /dev/ttyUSB1 info
debug: Using selector: EpollSelector
debug: Connected. Resetting.
debug: Sending: b'1ac038bc7e'
^C
Aborted!

I've got a little Celeron N3150 mini PC with 2 gigabit ethernet ports running Ubuntu Xenial LTS as a dedicated router. Home assistant is running in a virtualenv as a dedicated 'hass' user. It has both an aeotec zwave dongle (/dev/ttyACM0) and the HUSBZB-1 dongle (/dev/ttyUSB*)

--- UPDATE ---
Just because there seems to be some conjecture, I wanted to show that this has nothing to do with virtualenv:

XXX@router:~$ sudo pip install bellows zigpy zigpy-xbee
--- snip ---
Successfully installed Click-6.7 bellows-0.6.0 click-log-0.2.0 crccheck-0.6 pure-pcapy3-1.0.1 pycryptodome-3.6.1 pyserial-3.4 pyserial-asyncio-0.4 zigpy-0.1.0 zigpy-xbee-0.1.1
XXX@router:~$ sudo bellows -v DEBUG -d /dev/ttyUSB1 info
debug: Using selector: EpollSelector
debug: Connected. Resetting.
debug: Sending: b'1ac038bc7e'
^C
Aborted!
@pumbarger

This comment has been minimized.

Copy link

pumbarger commented May 31, 2018

@kenthua asked: Are you able to run the bellows commands successfully outside of home assistant?
I tried with a haspian distro and it hung just as @coreyo shows. But in hindsight I am not sure that the HA init was still waiting on the same command to complete. I should have killed that process first but I am not sure if I did or not. The info provided by @coreyo looks much more detailed and reliable.

@kenthua

This comment has been minimized.

Copy link

kenthua commented May 31, 2018

@pumbarger yea, if HA is running and stuck, it will block other tests from working.

@coreyo

This comment has been minimized.

Copy link

coreyo commented May 31, 2018

ahh, I should have shown that the problem persisted even after I stopped homeassistant. That is indeed the case.

@kenthua

This comment has been minimized.

Copy link

kenthua commented Jun 1, 2018

I take it all back, once I added a device to my zigbee network, same issue.

@kenthua kenthua reopened this Jun 1, 2018

@kenthua

This comment has been minimized.

Copy link

kenthua commented Jun 1, 2018

I got my environment back up and running a in virtualenv.

@coreyo

This comment has been minimized.

Copy link

coreyo commented Jun 1, 2018

@kenthua not sure what you mean by that last comment. Is it working properly, or are you experiencing the same 'hanging' behavior as the rest of us in your virtualenv?

@kenthua

This comment has been minimized.

Copy link

kenthua commented Jun 1, 2018

Yes, it works with virtualenv for me

@coreyo

This comment has been minimized.

Copy link

coreyo commented Jun 3, 2018

@kenthua mine still hangs. Even tried restarting the system. Did you do anything special? Do you have intermittent problems restarting homeassistant?

@drbios

This comment has been minimized.

Copy link

drbios commented Jun 5, 2018

Hello every one.
i use hassbian 0.70.1 rapsberry pi 3+ and a Xbee s2c conected tu a usb explorer. inicially i had the 10 second problem and web client not loading. but after configuring the xbee unit with API MODE ENABLED ass coordinator it's working perfect.
maybe some other usb zigbbe units suffers the same problem.
let me know if this help you
best regards

@dmulcahey

This comment has been minimized.

Copy link

dmulcahey commented Jun 5, 2018

http://www.sysrun.io/2017/10/20/quickfix-zigbeez-wave-usb-on-qnap/

Stumbled across this... I wonder if some of these docker installs don’t have these modules as well...

@thehomerepot

This comment has been minimized.

Copy link

thehomerepot commented Jun 14, 2018

@kenthua I was originally testing on Linux. I only tested on a windows machine to confirm the issue wasn't specific to the kernel/drivers. The driver for windows has timestamps from 2013, so I don't think anything changed there.

@nphil If you look at the release notes for those drivers, it seems for them most part they just modified the kernel.org driver to add GPIO support.

This bundle contains a modified CP210x driver for the 3.13.0 kernel (Ubuntu 14.04).

It contains:

- Fix for CP2104, now sets the baudrate via "SET_BAUDRATE/GET_BAUDRATE" command
- Fix for CP2105, now stores the interface number for the device for multi interface support
- Fix to support GPIO on all parts
- Fix to correct control request for MHS, Line Control and Break support

NOTE: This driver is an example of how to perform GPIO operations within the CP210x driver since
the driver on kernel.org does not support GPIO at this time. This driver has only been written
and tested on the Linux 3.13.0 kernel on Ubuntu 14.04. This driver is a modified version of the
existing driver in the Linux 3.13.0 kernel, which is maintained at kernel.org. It is recommened
to use the driver there that matches your specific kernel version:
@kenthua

This comment has been minimized.

Copy link

kenthua commented Jun 14, 2018

@thehomerepot There is one for 4.x https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers

I don't think the GPIO pins are used for what we need and aren't in main kernel because it wasn't developed according to standards.

I checked the kernel source and it already has the SET_BAUDRATE/GET_BAUDRATE
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/usb/serial/cp210x.c

@nphil

This comment has been minimized.

Copy link

nphil commented Jun 14, 2018

Well I opened up the stick and found both Z-wave and Zigbee SoCs present, so at least all the hardware is there. Do you guys think it's an issue with the cp2105 USB to UART bridge or a problem with the zigbee module firmware? I saw some notes on the EM3581 that the zigbee stack (ember something?) has been updated, not sure if this would affect anything.

I'm also trying to talk to the zigbee modem with AT commands via a serial terminal, but no go.

If i can't even talk to the zigbee modem, it might most likely be a USB comm issue? USB driver issue?

I also got the same response from E-mailing the seller, to update my USB drivers. Not sure if it's based on anything or just a generic "update drivers and reboot" type of response.

@egorian

This comment has been minimized.

Copy link

egorian commented Jun 14, 2018

@nphil I don't think that the stick will respond to AT Commands. Anyway, I also tried yesterday (knowing that it will not work) to use minicom with no success.
To summarize, I guess that we're dealing with different issues (seems that at least 3):

  • Stick works fine for a limited period of time and then hangs using bellows + HomeAssistant (+ docker ?)
    debug: Sending: b'1ac038bc7e'
  • Stick doesn't responds at all also without using HomeAssistant and HomeAssistant doesn't start when enabled ZHA component
    debug: Sending: b'1ac038bc7e'
  • Stick got an error when using HomeAssistant (+ virtualenv ?)
    Error frame: b'c20251a8bd7e'.
@coreyo

This comment has been minimized.

Copy link

coreyo commented Jun 14, 2018

I go mine here: https://www.ebay.com/itm/122055230717 . The price goes up and down, mine was much cheaper than what I see now. Anyway, definitely the same problem from a different vendor.

@nphil

This comment has been minimized.

Copy link

nphil commented Jun 18, 2018

anyone got any ideas or made any progress with this? I'm about to return the stick back to Amazon. What do you guys recommend for a cheap Z-wave/Zigbee combo that works well with HASS?

@kenthua

This comment has been minimized.

Copy link

kenthua commented Jun 18, 2018

@nphil While mine does work, there are definitely some limitations with the zha/bellows implementation. One being the issue of not working, but others once it does work could be:

  • lack of compatibility with your devices
  • not reporting battery for devices which can lead to issues depending on the use of the devices

As far as future investment goes, I'd be looking to zwave devices.

@nphil

This comment has been minimized.

Copy link

nphil commented Jun 18, 2018

Thanks, I have a Smartthings hub already and have all of my zigbee devices paired to it and talking to HASS via a MQTT bridge. Looks like I'll just stick with it until there's a more reliable long-term solution for zigbee. I'm definitely sticking to Z-wave for all my future sensor purchases. On the other hand, cheap xiaomi sensors are so difficult to give up!

On a sidenote, it looks like Silicon Labs purchased Z-wave tech from Sigma designs!

@kenthua

This comment has been minimized.

Copy link

kenthua commented Jun 18, 2018

I was on the path of moving from ST to pure HA, but I'm hesitant to move all my devices over now. @Yoda-x and his fork of zha does do battery I believe for the xiaomi sensors.

@egorian

This comment has been minimized.

Copy link

egorian commented Jun 19, 2018

Strangely enough, I flashed Hass.io on a different SD Card and put it on a different raspberryPI (Rpi3B) but using the same zwave+zigbee stick and then I moved all my zigbee devices to this environment. After 24 hours is still working and not longer presenting this issue:

Stick works fine for a limited period of time and then hangs using bellows + HomeAssistant (+ docker ?)
debug: Sending: b'1ac038bc7e'

I'm guessing that my previous environment ((Rpi3B with Raspbian+docker) have some kind of resource (CPU? memory? USB timing?) issues that somehow made that bellows doesn't respond in a timely manner to the stick and the stick fall down on a failure state.

@iRanduMi

This comment has been minimized.

Copy link

iRanduMi commented Jun 22, 2018

Just found this thread and wanted to mention that I'm attempting to configure this same stick on an UNRAID docker instance of Home Assistant and have been experiencing the exact same issues. Not really sure what else to do...

@nphil

This comment has been minimized.

Copy link

nphil commented Jun 22, 2018

I managed to talk to someone technical at Home Controls about this and they're actually working with Nortek on this. He mentioned something about Nortek not flashing the Zigbee firmware properly, and how they sold a lot of sticks to Duke energy and they also had the same issue as us.

Regardless, he said there were some replacement sticks with proper Zigbee firmware loaded coming in around next month, so I'd recommend that you guys give Home Controls (or whoever your reseller was) a call - they assured me a free replacement.

Hoping this is truly a fix for people like me who can't get the Zigbee portion working at all, in or out of docker.

@kenthua

This comment has been minimized.

Copy link

kenthua commented Jun 22, 2018

That's great news for those who can't get it working at all.

It doesn't fix it where it's broken in a docker container.

@iRanduMi

This comment has been minimized.

Copy link

iRanduMi commented Jun 22, 2018

Thank you for the follow up nphil! I've contacted Home Controls, Inc.

@steve28

This comment has been minimized.

Copy link

steve28 commented Jun 23, 2018

FWIW, I have a HUSBZB-1 and have been using it with HA in docker on intel NUC since ~Jan. A couple of weeks ago, all of my zigbee stuff (about 5 devices) stopped working. HA would load however, but I would get the warning "Setup is taking longer than 10s" in the log.

Today I finally set about tackling this. Updated HA, updated Ubuntu, restarted server, etc. Not until I unplugged/re-plugged the stick and THEN rebooted, would it come back.

@kenthua

This comment has been minimized.

Copy link

kenthua commented Jun 23, 2018

It worked a few times in a docker image in the beginning. After that no reboots, clean installs, zibgee.db wipes could bring it back. After switching to native virtualenv it's been fairly stable.

@egorian

This comment has been minimized.

Copy link

egorian commented Jun 23, 2018

After 5 days of being trying hass.io, the stick is still working fine. Now, I'll not be able to perform more test for the following days, but after those days I'll try to put the hass.io sdcard on the "old" rpi3 (where I was using Raspbian+Docker) to see if hass.io did the trick or if there is any other factor involved, eg. Power supply, case (the "new" rpi3 is using a flirc case that dissipates heat better than the official case that I'm using on the "old" one), or other hardware issue. I'll post the results here once I be able to perform those tests.

@iRanduMi

This comment has been minimized.

Copy link

iRanduMi commented Jul 3, 2018

Just want to follow up on this. As previously mentioned, I had ordered my HUSBZB-1 stick via Home Controls, Inc. After contacting them, they informed me that they've had quite a few of these issues with people. I ordered a new one through them and am returning my current one via Amazon. I received the new stick yesterday and bam, worked instantly. The original was definitely a defective unit.

@nphil

This comment has been minimized.

Copy link

nphil commented Jul 8, 2018

Just got my replacement from Homecontrols also - can confirm that the issue is fixed. Zigbee and Z-wave interfaces are detected properly. Now to figure out just how the hell I'm supposed to pair a Zigbee device, the process seems a bit more involved than my old ST hub and the documentation for it on HA is pretty barebones..

@iRanduMi

This comment has been minimized.

Copy link

iRanduMi commented Jul 9, 2018

It's actually really easy. Go to Services > zha.permit. Call the service. Go to your light and turn it off an on. It'll likely appear within HA. If not, you may need to reset the light if it's still attached to ST.

My main issue with Zigbee support is that HA doesn't poll/monitor the status of the light. So if you turn off the lamp when the light was previously on, HA still thinks it's on. Same with rebooting HA or anything like that.

@BobAmelung

This comment has been minimized.

Copy link

BobAmelung commented Jul 17, 2018

I received my replacement HUSBZB-1 stick from Home Controls yesterday. Same issue :-(

I enable zha, the web UI is inaccessible and I see "'utf-8' codec can't decode byte 0x80 in position 99: invalid start byte" in the zigbee.db

@pumbarger

This comment has been minimized.

Copy link

pumbarger commented Jul 28, 2018

After reading someone finally has success after returning and replaced the HUSBZB-1 stick I decided to do the same. I figured the safest bet would be to purchase one from the same vendor as the person who had success. So I purchased one from Home Controls via Amazon.

I wanted so start from scratch so I removed all z-wave devices from current controller and flashed a new hass.io image. After first boot I added samba so I could edit the configuration.yaml file and add the basic config for z-wave and zha.

I restarted and it did not hang as it always had before, configuring zha. When brought up the web interface the z-wave controller was there, as before. I then checked services and found zhz.permit and zha.remove.

I have not tried to add any devices yet because while waiting to see if this problem would resolve, I replaced the Zigbee bulbs I had with Z-wave bulbs which I prefer because they also act as repeaters.

So it appears the problem is a batch of bad devices which I would venture a guess that it is bad firmware rather than hardware.

It would be nice to know if there is a way to identify the good/working sticks from the bad.

Thanks to all you came up with theories on the source of the problem and who tested a myriad of things to prove or disprove the theories.

@matt1

This comment has been minimized.

Copy link

matt1 commented Aug 19, 2018

I am not so sure it is just batch of "bad devices".

I have a cp210x based zigbee USB stick which is not a HUSBZB-1. It works 100% fine in Windows 10, and on a RPi3 with OpenHAB - zigbee devices are detected and can be controlled no worries so the firmware on the stick is fine. However it does not work at all with Hass.io on the same RPi3, and in fact causes hass.io to not even start as noted in this and other issues.

tl;dr - Please dont close this resolved as there is a larger issue here I think.

@kenthua

This comment has been minimized.

Copy link

kenthua commented Aug 19, 2018

This thread morphed into a firmware / "bad device" thread. I originally started it because there is an inherent initialization issue with bellows/zigpy and this device in a docker container. Inconsistent behavior to not properly initializing at all in a container. Since it appears a majority are not running in a container, it's not being looked into. I have since given up on this device and HA handling my zigbee/zwave devices. One crucial missing element is lack of battery sensor, which is a fairly significant problem.

@coreyo

This comment has been minimized.

Copy link

coreyo commented Sep 2, 2018

For what it's worth, I just got my replacement from Home Controls as well. Bellows is working and Homeassistant is now starting up nicely with the zha option. The zha.permit and zha.remove services are now available in the homeassistant interface.

@ajayjohn

This comment has been minimized.

Copy link

ajayjohn commented Oct 12, 2018

I agree with @matt1
I got 2 HUSBZB-1 replacements and yet, it has not fixed anything.
I hope the following logs are helpful. These are from my hassio setup on an Intel NUC.

Home Assistant Config

usb_path: /dev/ttyUSB1
database_path: /config/zigbee.db
baudrate: 57600

Home Assistant Logs (Full bellows logs)
https://hastebin.com/kuhotanaya.bash

dmesg from underlying OS on host startup

[ 46.174001] cp210x 2-2:1.0: cp210x converter detected
[ 46.177116] usb 2-2: cp210x converter now attached to ttyUSB0
[ 46.177137] cp210x 2-2:1.1: cp210x converter detected
[ 46.178395] usb 2-2: cp210x converter now attached to ttyUSB1
[ 46.189659] cp210x ttyUSB1: failed set req 0x1e size 4 status: -32
[ 46.189662] cp210x ttyUSB1: failed to set baud rate to 300`

@ebr

This comment has been minimized.

Copy link

ebr commented Oct 23, 2018

I just got an Elelabs Zigbee USB stick (confirmed working as per https://www.home-assistant.io/components/zha/).

  • Raspberry Pi 3 / raspbian
  • Docker
  • homeassistant/raspberrypi3-homeassistant:latest

Seeing the same or similar issue:

....(logs truncated)
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.ezsp] Send command setConfigurationValue
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Sending: b'554f21575479068e594e147e'
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Data frame: b'564fa157547915c3177e'
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Sending: b'8610be7e'
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.ezsp] Application frame 83 (setConfigurationValue) received
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.ezsp] Send command setConfigurationValue
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Sending: b'664c215754790eb4591cd87e'
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Data frame: b'674ca157547915ec1b7e'
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Sending: b'87009f7e'
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.ezsp] Application frame 83 (setConfigurationValue) received
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.ezsp] Send command networkInit
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Sending: b'774d2157543d0cfe7e'
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Data frame: b'704da557543d15cf8a7e'
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Sending: b'8070787e'
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.ezsp] Application frame 23 (networkInit) received
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.ezsp] Send command getNetworkParameters
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Data frame: b'004db15754338566017e'
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Sending: b'8160597e'
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.ezsp] Application frame 25 (stackStatusHandler) received
homeassistant_1  | 2018-10-22 22:54:55 DEBUG (MainThread) [bellows.uart] Sending: b'015221575402629c7e'
homeassistant_1  | 2018-10-22 22:54:56 DEBUG (MainThread) [bellows.uart] RSTACK Version: 2 Reason: RESET_POWER_ON frame: b'c102029b7b7e'
homeassistant_1  | 2018-10-22 22:55:03 WARNING (MainThread) [homeassistant.setup] Setup of zha is taking over 10 seconds.

is this a confirmed problem with bellows on Docker? I don't think "bad hardware" is the answer here, as we're seeing many different devices and setups in this thread, and Docker seems to be the common theme.

EDIT: actually, I'm seeing this exact behaviour outside of Docker as well, natively on the Pi, with and without virtualenv. bellows==0.7.0.

debug: RSTACK Version: 2 Reason: RESET_POWER_ON frame: b'c102029b7b7e'
@drewzh

This comment has been minimized.

Copy link

drewzh commented Oct 29, 2018

For what it's worth, I've been attempting to get Zigbee to work, on and off, for over a week now. I've tried using an Elelabs USB and a Telegenesis USB device (thinking the problem was due to the hardware). This is using both Docker on a Synology NAS and also using hass.io on a raspberry pi 3 (another avenue I went down to try and resolve. Same results as users above. Note that I'm using the very latest release of home assistant 0.81.1

@jooprzol

This comment has been minimized.

Copy link

jooprzol commented Oct 31, 2018

FWIW, I have a HUSBZB-1 and have been using it with HA in docker on intel NUC since ~Jan. A couple of weeks ago, all of my zigbee stuff (about 5 devices) stopped working. HA would load however, but I would get the warning "Setup is taking longer than 10s" in the log.

Today I finally set about tackling this. Updated HA, updated Ubuntu, restarted server, etc. Not until I unplugged/re-plugged the stick and THEN rebooted, would it come back.

This did it for me. Though, in my case, I shut down, unplugged the stick and then powered up the machine and plugged it back in as it was booting. HASS sees the device and brings up the web UI now, whereas before it would hang and never load the UI.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment