hello @rcloran I appear to be experiencing the same issues as @gregg098 is with HASS not starting randomly. I am also seeing all zigbee devices just stop responding after several hours and HASS needs a restart to regain control. Any advice on what to do? I don’t see anything in the logs either. Would love to see if I can get things to be stable so I don’t need to restart often.
Nope, I’m running the same stick on a pi3 with hass.io and it’s rock solid.
I had a case where I thought stuff wasn’t working and it turned out to be a flaky motion sensor. Sometimes it worked after reboot, sometimes not. You say “all zigbee devices” so if that’s 1 or 2 devices, maybe, but more than that, probably not…
As for logs, Developer Tools > Info, I believe 0.58 and newer make it easier to find issues.
So is the only thing that stops working after several hours zha devices? Nothing else?
Well since I setup the stick 3 days ago I was losing control of all zigbee devices (6) when I woke up in the morning. Today was the first morning that the devices still worked! Not sure what I did wrong but hopefully it stays that way 
It was only the zha devices and nothing else when this issue occurred. I looked at the logs and couldn’t see anything really. If anything changes I will report back. Hopefully this issue won’t come back.
I also have home assistant installed in a venv with python 3.5.3. Might try installing hass.io and see if that helps since everyone who has been using it says its flawless with the same stick.
I am running latest Home Assistant (0.59.2) on Raspberry PI (hassbian).
Purchased a ETRX357USB-LRS+8M and flashed with new firmware using this guide: EU USB sticks for the new Zigbee component
The zha component is loading, and with debug log enabled there is a lot of “[bellows.*]” related messages in log but nothing shows up in Home Assistant after pairing a Xiaomi Human Body Sensor.
However:
sqlite> select * from attributes;
returns:
00:15:8d:00:01:e0:30:03|1|0|5|lumi.sensor_motion.aq2
00:15:8d:00:01:e0:30:03|1|1024|0|12
00:15:8d:00:01:e0:30:03|1|1030|0|1
So it looks like the sensor is paired, but why doesn’t it show up in Home Assistant?
Does anyone know? I’d be happy to provide logs, but I don’t know which logs are relevant. And with debug on, there is a lot of logging going on…
Anyone have any luck with getting the Lutron Connected Bulb Remotes working?
1 Like
welp back to devices not responding over night. I turned on debug logging for the ZHA component but still nothing shows up. No idea where to start looking
Iris Key Fob Remote (2nd Gen) DOES NOT work.
Ouput of bellows devices
> Device: > NWK: 0xbbd2 > IEEE: 00:0d:6f:00:05:76:74:ca > Endpoints: > 1: profile=0x104, device_type=DeviceType.REMOTE_CONTROL > Input Clusters: > Basic (0) > Power Configuration (1) > Identify (3) > On/Off Switch Configuration (7) > Poll Control (32) > Diagnostic (2821) > Output Clusters: > Identify (3) > On/Off (6) > Ota (25) > 2: profile=0x104, device_type=DeviceType.REMOTE_CONTROL > Input Clusters: > On/Off Switch Configuration (7) > Output Clusters: > On/Off (6) > 3: profile=0x104, device_type=DeviceType.REMOTE_CONTROL > Input Clusters: > On/Off Switch Configuration (7) > Output Clusters: > On/Off (6) > 4: profile=0x104, device_type=DeviceType.REMOTE_CONTROL > Input Clusters: > On/Off Switch Configuration (7) > Output Clusters: > On/Off (6)
I poked at it a bit, but was never able to get beyond it joining the network (i.e. it doesn’t appear as an available device in HASS after pairing).
Same. I connected. I see it in the DB…and that’s all I’ve got so far.
Just wanted to provide an update that I had recently gotten a new SD card and decided to fresh install everything and moved over my entire config directory. Things are pretty stable now and I don’t need to restart home assistant to regain control of zigbee.
What is the DeviceType that it reports as? If it’s REMOTE_CONTROL, then there doesn’t appear to be a Clusters entry for that type in the profiles. (Which is probably one of the problems I’m having with the Iris Key Fob)
what configuration were you using? zha?
@gohassgo what zha configuration are you using? i am seeing the same lock up problem as noted by others- curious if its a setup or configuration issue
@dexrex this is what my config looks like:
zha:
usb_path: /dev/zigbee
database_path: zigbee.db
for the record the issue came back a few days later. I am starting to wonder if maybe its a faulty usb stick
there is another thread on this, which highlights some specifics on the configuration definition. I still have not got this to work, but perhaps there’s a hint in there
ok. i got it to work, at it seems reliable.
the format of the configuration is very specific, my indentation was wrong and i was missing a space, and i had to remove all other USB devices (not sure why yet)
here’s the configuration, you seem to also need to include zwave, or zha gives an error and hangs hassio.
(indent usb_path, database_path attributes)
zwave:
usb_path: /dev/ttyUSB0zha:
usb_path: /dev/ttyUSB1
database_path: zigbee.db
will report back on device testing.
Yea mine is also indented properly and it works. I have my USB paths mapped out too. You will probably see the lock up show up in a few days or so is my guess. Again its a HASS restart required not a computer restart which means something is happening between the communication of hass and the USB stick as the computer still recognizes it. Just stops responding to zigbee.
The device_type from the database is 2080, which when converted to hex becomes 0x820. I had a look at the ZLL profile definitions and 0x820 looks to be defined as CONTROLLER
Here’s my config (looks like you settled on something similar for zha):
# Z-Wave
zwave:
usb_path: /dev/ttyUSB0
network_key: "0x00,0x11,0x22,0x33,0x00,0x11,0x22,0x33,0x00,0x11,0x22,0x33,0x00,0x11,0x22,0x33"
# Zigbee
zha:
usb_path: /dev/ttyUSB1
database_path: /config/zha.db
Confirming the newest Samsung SmartThings Outlet works great, at least for on/off. Using the HUSBZB-1.
2 Likes