zig-a-zig-ah! CC2562R - cannot add in HA

Question

zig-a-zig-ah! CC2562R - cannot add in HA

blakadder opened this issue 4 years ago · comments

Trying to get the prototype of zig-a-zig-ah! CC2562R stick working with ZHA but I'm getting this error message

2020-05-07 00:09:14 INFO (MainThread) [zigpy_cc.uart] Connection made
2020-05-07 00:09:16 DEBUG (MainThread) [zigpy.appdb] Loading application state from /home/blak/.homeassistant/zigbee.db
2020-05-07 00:09:16 DEBUG (MainThread) [zigpy.ota] Initialize OTA providers
2020-05-07 00:09:16 DEBUG (MainThread) [zigpy_cc.zigbee.application] Starting zigpy-cc version: 0.3.1
2020-05-07 00:09:16 DEBUG (MainThread) [zigpy_cc.api] --> SREQ SYS version tsn: None {}
2020-05-07 00:09:16 DEBUG (MainThread) [zigpy_cc.uart] Send: b'\xfe\x00!\x02#'
2020-05-07 00:09:16 DEBUG (MainThread) [zigpy.ota.provider] OTA image directory '/home/blak/.homeassistant/zigpy_ota/' does not exist
2020-05-07 00:09:50 INFO (MainThread) [zigpy_cc.uart] Connection made
2020-05-07 00:09:52 DEBUG (MainThread) [zigpy.appdb] Loading application state from /home/blak/.homeassistant/zigbee.db
2020-05-07 00:09:52 DEBUG (MainThread) [zigpy.ota] Initialize OTA providers
2020-05-07 00:09:52 DEBUG (MainThread) [zigpy_cc.zigbee.application] Starting zigpy-cc version: 0.3.1
2020-05-07 00:09:52 DEBUG (MainThread) [zigpy_cc.api] --> SREQ SYS version tsn: None {}
2020-05-07 00:09:52 DEBUG (MainThread) [zigpy_cc.uart] Send: b'\xfe\x00!\x02#'
2020-05-07 00:09:52 DEBUG (MainThread) [zigpy.ota.provider] OTA image directory '/home/blak/.homeassistant/zigpy_ota/' does not exist

Using HA 0.109.4 installed in venv on Manjaro linux. Tried with Z-Stack 3.X.0 CC26X2R1_20191106.hex and CC26X2R1_20200417.hex

Stick is working on zigbee2mqtt in venv installed on the same machine.

Using CC2652RB_20200417.hex i'm getting this:

2020-05-07 00:16:20 INFO (MainThread) [zigpy_cc.uart] Connection made
2020-05-07 00:16:21 DEBUG (MainThread) [zigpy_cc.uart] drop char
2020-05-07 00:16:21 INFO (MainThread) [zigpy_cc.uart] Bytes received: b'\x00'
2020-05-07 00:16:23 DEBUG (MainThread) [zigpy.appdb] Loading application state from /home/blak/.homeassistant/zigbee.db
2020-05-07 00:16:23 DEBUG (MainThread) [zigpy.ota] Initialize OTA providers
2020-05-07 00:16:23 DEBUG (MainThread) [zigpy_cc.zigbee.application] Starting zigpy-cc version: 0.3.1
2020-05-07 00:16:23 DEBUG (MainThread) [zigpy_cc.api] --> SREQ SYS version tsn: None {}
2020-05-07 00:16:23 DEBUG (MainThread) [zigpy_cc.uart] Send: b'\xfe\x00!\x02#'
2020-05-07 00:16:23 DEBUG (MainThread) [zigpy_cc.uart] drop char
2020-05-07 00:16:23 INFO (MainThread) [zigpy_cc.uart] Bytes received: b'\x00'
2020-05-07 00:16:23 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event timer_out_of_sync[L]: seconds=1.378969931989559>
2020-05-07 00:16:23 DEBUG (MainThread) [zigpy.ota.provider] OTA image directory '/home/blak/.homeassistant/zigpy_ota/' does not exist
2020-05-07 00:16:25 DEBUG (MainThread) [zigpy_cc.uart] drop char
2020-05-07 00:16:25 INFO (MainThread) [zigpy_cc.uart] Bytes received: b'\x00'
2020-05-07 00:16:26 DEBUG (MainThread) [zigpy_cc.uart] drop char
2020-05-07 00:16:26 INFO (MainThread) [zigpy_cc.uart] Bytes received: b'\x00'
2020-05-07 00:16:28 DEBUG (MainThread) [zigpy_cc.uart] drop char
2020-05-07 00:16:28 INFO (MainThread) [zigpy_cc.uart] Bytes received: b'\x00'
2020-05-07 00:16:30 DEBUG (MainThread) [zigpy_cc.uart] drop char
2020-05-07 00:16:30 INFO (MainThread) [zigpy_cc.uart] Bytes received: b'\x00'
2020-05-07 00:16:31 DEBUG (MainThread) [zigpy_cc.uart] drop char
2020-05-07 00:16:31 INFO (MainThread) [zigpy_cc.uart] Bytes received: b'\x00'
2020-05-07 00:16:33 DEBUG (MainThread) [zigpy_cc.uart] drop char
2020-05-07 00:16:33 INFO (MainThread) [zigpy_cc.uart] Bytes received: b'\x00'

Omer Kilic · Answer 1 · Thu May 07 2020 18:23:05 GMT+0800 (China Standard Time)

@blakadder Noticed that you are using CC2652RB_20200417.hex (meant for the CC2652RB chip) but zzh boards use CC2652R. Just FYI.

blakadder · Answer 2 · Thu May 07 2020 18:24:20 GMT+0800 (China Standard Time)

That was just a desperate attempt after exhausting all other options ;)

Hedda · Answer 3 · Thu May 07 2020 20:10:54 GMT+0800 (China Standard Time)

@blakadder Did you see other ideas from @omerk posted in Koenkk/zigbee2mqtt#1429 (comment)

He wrote " @blakadder sounds like you might be having trouble with the usb-serial drivers, can you check your kernel log to see if there are any relevant lines? for reference, zzh uses the CH340 chip and as long as you are using a relatively recent kernel there is good support for it. "

Balazs Sandor · Answer 4 · Fri May 08 2020 04:12:48 GMT+0800 (China Standard Time)

@blakadder I already made some tweaks in 0.3.2, pls try that version
As I remember I flashed my zzh with CC26X2R1_20200417.
I don't see any errors in your log.

blakadder · Answer 5 · Fri May 08 2020 04:31:21 GMT+0800 (China Standard Time)

logs don't show the error but the ui does

how do i get the zigpy-cc pip installation to persist, HA installs 0.3.1 whenever I try adding the ZHA integration

Balazs Sandor · Answer 6 · Fri May 08 2020 16:57:39 GMT+0800 (China Standard Time)

If you install zigpy-cc with Custom deps deployment
It will persist, even so you update HA.
You will need to remove it later.

blakadder · Answer 7 · Fri May 08 2020 19:00:21 GMT+0800 (China Standard Time)

Yes, that requires HA running as supervisor. I'm running HA in venv and the instructions given for alternative install don't do anything since HA still uses 0.3.1

Omer Kilic · Answer 8 · Fri May 08 2020 22:55:34 GMT+0800 (China Standard Time)

Not sure if this is of any concern for zigpy-cc but zzh does not use RTS/CTS for serial comms. In zigbee2mqtt config, under advanced, we set: rtscts: false.

@blakadder Maybe cause of your issues yesterday?

blakadder · Answer 9 · Sat May 09 2020 07:03:06 GMT+0800 (China Standard Time)

Good news everyone! Sort of...

Finally got it connected with zigpy-cc 0.4.2 with HA dev 0.110 but it did take replugging it a few times during connecting.

Hedda · Answer 10 · Mon May 11 2020 19:01:21 GMT+0800 (China Standard Time)

@blakadder FYI @puddly mentioned somewhat similar symptoms with the driver for CH340 serial chip used by the ZZH adapter, first in zigpy/zigpy-znp#10 and continued in electrolama/zig-a-zig-ah#12

@omerk suggested that issues with CH340 should solve later Linux kernels so make sure up-to-date.

blakadder · Answer 11 · Mon May 11 2020 19:22:38 GMT+0800 (China Standard Time)

what is a "later" linux kernel exactly?

Hedda · Answer 12 · Mon May 11 2020 20:35:00 GMT+0800 (China Standard Time)

@blakadder Guess that depends on exactly which computer/board and exactly which Linux distribution + version you are using since many single-board-computer projects support multiple Linux distros which each compile their Linux kernel and as such choose which base version and which patches to include, and some projects even compile their own custom Linux distro with custom Linux kernel. Home Assistant OS (formerly known as Hass.io/HassOS) is for example such as a project.

blakadder · Answer 13 · Mon May 11 2020 20:51:32 GMT+0800 (China Standard Time)

so you're just throwing general basic suggestions?

Hedda · Answer 14 · Mon May 11 2020 21:54:32 GMT+0800 (China Standard Time)

Well kind-off yes but based on specific comments that omerk posted CH340 driver and Linux kernel.

See the comments by omerk in electrolama/zig-a-zig-ah#12

I don't have zzh myself but it does sound logical based on my 20-years+ as a x86 server technician.

None-basic question; Are you using a Linux distro which Linux kernel uses latest CH340 driver code?

https://github.com/torvalds/linux/commits/master/drivers/usb/serial/ch341.c

Addressing your points:

zzh originally had CP2102N but had to find a replacement as it simply wouldn't fit the layout once I picked the enclosure. I did look at FT230X and FT234XD (the 'runner-up') but at many times the cost of CH340E and with much better driver support over the last year or so for CH340E, the decision was made.

The assumption here is that majority of the users of zzh will be using Linux and probably on a popular SBC (like a Raspberry Pi) that will have an up-to-date kernel. In the many months of testing I did with both Raspberry Pi and an Ubuntu box, I never had driver issues. I know @Koenkk had an issue initially with the drivers but that was solved with him updating his box.

Now of course this isn't an attempt at not acknowledging the issues you are having, just providing the rationale behind the design decision. For macOS, unfortunately I can't really comment as I don't have any Macs around but for your XU4, can I ask perhaps you give a more recent kernel (if available) a go? Some recent fixes in the kernel driver did improve the situation quite a bit. If you have the willpower and the time to tinker with the kernel on your XU4, perhaps we can get to the bottom of it? In the meantime, I can happily send you the hacked-with-the-FT234XD board I have in my box of prototypes. It won't look pretty but it sure is another collectors' piece :-)

blakadder · Answer 15 · Tue May 12 2020 00:24:25 GMT+0800 (China Standard Time)

Well kind-off yes but based on specific comments that omerk posted CH340 driver and Linux kernel.

See the comments by omerk in electrolama/zig-a-zig-ah#12

I don't have zzh myself but it does sound logical based on my 20-years+ as a x86 server technician.

None-basic question; Are you using a Linux distro which Linux kernel uses latest CH340 driver code?

https://github.com/torvalds/linux/commits/master/drivers/usb/serial/ch341.c

Addressing your points:

zzh originally had CP2102N but had to find a replacement as it simply wouldn't fit the layout once I picked the enclosure. I did look at FT230X and FT234XD (the 'runner-up') but at many times the cost of CH340E and with much better driver support over the last year or so for CH340E, the decision was made.

The assumption here is that majority of the users of zzh will be using Linux and probably on a popular SBC (like a Raspberry Pi) that will have an up-to-date kernel. In the many months of testing I did with both Raspberry Pi and an Ubuntu box, I never had driver issues. I know @Koenkk had an issue initially with the drivers but that was solved with him updating his box.

Now of course this isn't an attempt at not acknowledging the issues you are having, just providing the rationale behind the design decision. For macOS, unfortunately I can't really comment as I don't have any Macs around but for your XU4, can I ask perhaps you give a more recent kernel (if available) a go? Some recent fixes in the kernel driver did improve the situation quite a bit. If you have the willpower and the time to tinker with the kernel on your XU4, perhaps we can get to the bottom of it? In the meantime, I can happily send you the hacked-with-the-FT234XD board I have in my box of prototypes. It won't look pretty but it sure is another collectors' piece :-)

I think you missed the post where I say it is working and why and that the issue was closed because it is resolved.
I am not casually trying out a thing, but instead testing a prototype in different environments so potential bugs can be eliminated. That includes different kernels, from LTS to cutting edge.