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

[blakadder]

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'

[omerk]

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

[blakadder]

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

[Hedda]

@blakadder Did you see other ideas from @omerk posted in https://github.com/Koenkk/zigbee2mqtt/issues/1429#issuecomment-625133560

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. "

[sanyatuning]

@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]

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

[sanyatuning]

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]

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

[omerk]

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]

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]

@blakadder FYI @puddly mentioned somewhat similar symptoms with the driver for CH340 serial chip used by the ZZH adapter, first in https://github.com/zha-ng/zigpy-znp/issues/10 and continued in https://github.com/electrolama/zig-a-zig-ah/issues/12

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

[blakadder]

what is a "later" linux kernel exactly?

[Hedda]

@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]

so you're just throwing general basic suggestions?

[Hedda]

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

See the comments by omerk in https://github.com/electrolama/zig-a-zig-ah/issues/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:

1. 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]

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

See the comments by omerk in https://github.com/electrolama/zig-a-zig-ah/issues/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:

1. 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.