Support for slae.sh CC2652RB stick

[MarhyCZ]

Hi,
does anyone tried this stick with this library? I am having problem to have it properly initialized.

It does work in zigbee2mqtt software, not here.

I tried to exclude all other factors, so instead of passing it to Home Assistant docker and using in ZHA, I downloaded zigpy-znp library to the host os (Arch Linux) and tried to launch the Energy scan tool.

It cannot even connect to the stick

• Its flashed with latest Koenkk firmware for CC2652RB
• No other software/container should currently be using the dongle
• If I connect generic Texas Instruments CC1352 board with Koenkk firmware, the energy scan works.

The error I am getting:

`python -m zigpy_znp.tools.energy_scan /dev/serial/by-id/usb-Silicon_Labs_http:_slae.sh_cc2652-_slaesh_s_iot_stuff_00:12:4B:00:21:A8:EB:55-if00-port0
2020-09-17 20:47:29 SERVER main[4075] INFO Starting up zigpy-znp
2020-09-17 20:47:34 SERVER zigpy.application[4075] ERROR Couldn't start application
Traceback (most recent call last):
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/api.py", line 472, in request
response = await response_future
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/lib/python3.8/runpy.py", line 194, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.8/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/tools/energy_scan.py", line 98, in
asyncio.run(main(sys.argv[1:])) # pragma: no cover
File "/usr/lib/python3.8/asyncio/runners.py", line 43, in run
return loop.run_until_complete(main)
File "/usr/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete
return future.result()
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/tools/energy_scan.py", line 94, in main
await perform_energy_scan(args.serial, num_scans=args.num_scans)
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/tools/energy_scan.py", line 26, in perform_energy_scan
app = await ControllerApplication.new(
File "/home/user/znp/lib/python3.8/site-packages/zigpy/application.py", line 68, in new
await app.startup(auto_form)
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/zigbee/application.py", line 152, in startup
await znp.connect()
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/api.py", line 215, in connect
ping_rsp = await self.request(c.SYS.Ping.Req())
File "/home/user/znp/zigpy-znp-dev/zigpy_znp/api.py", line 472, in request
response = await response_future
File "/home/user/znp/lib/python3.8/site-packages/async_timeout/init.py", line 55, in aexit
self._do_exit(exc_type)
File "/home/user/znp/lib/python3.8/site-packages/async_timeout/init.py", line 92, in _do_exit
raise asyncio.TimeoutError
asyncio.exceptions.TimeoutError`

@slaesh Would you mind trying to use this library on your own stick?

[Adminiuga]

can you run the same command but with -v switch to enable debug output?
and when trying to run this commend, you've stopped any other instances of z2m, etc so there's no concurrent access?

[MarhyCZ]

@Adminiuga Many thanks for quick reply! Really appreciate it!

• No other software that would use it is running

• PC is rebooted before the test

• Debug log is attached in screenshot (The color formatting is probably more nice to read than just pasting it herer)

[puddly]

Probably due to Koenkk/zigbee-herdsman#196

[MarhyCZ]

So it shoud just skip invoking the bootloader on this device?

[puddly]

I'll have to research the problem itself (and figure out what the terminology means). Try playing with the following setting:

zha:
  zigpy_config:
    device:
      flow_control: hardware  # or software

I believe the fix might require changing the flags in https://github.com/zha-ng/zigpy-znp/blob/54b21cfbeae58ed7275a4de58291ab8d143010f9/zigpy_znp/uart.py#L232

If you want to try playing around with it and finding what flags need to be set for your stick, the PySerial flags are all documented: https://pyserial.readthedocs.io/en/latest/pyserial_api.html#serial.Serial.__init__

[slaesh]

hey :)

sure, will try that during the weekend!

just some quick ideas:

• use the debug-fw (mentioned on my docs-page, so we can see in which state the cpu is)
• could be something with the serial pins (rts, dtr) as already mentioned -> those need to be "released"

@puddly maybe you can contact me on telegram? https://t.me/slaesh =)

[slaesh]

https://github.com/JelmerT/cc2538-bsl/blob/733e6f5b496402e40ad6d12df3d0372e205b8883/cc2538-bsl.py#L219

this method will invoke the bootloader. we should do the same but with the inverse of DTR to NOT invoke it ;)

[MarhyCZ]

I already tried the flow_control flag in the Home Assistant's UI wizard.
Software is probably the default value - That will show the "Cannot connect to ZHA Device". The hardware option actually crashes my Home Assistant instance. The last line in the docker log is same as in my original post "asyncio.exceptions.TimeoutError".

I can try look in the code as slaesh mentioned to not invoke the bootloader. But that will take me longer as I haven't properly seen the code yet. (I didn't even know it has verbose mode lol )

[MarhyCZ]

I will check it asap

[puddly]

@MarhyCZ I've pushed a preliminary fix a few minutes ago so it should work if you install the latest dev release within your virtual environment:

$ pip install git+https://github.com/zha-ng/zigpy-znp/

Not 100% sure if HA will end re-installing the latest stable version on startup so you might have to use something like the approach in here: https://github.com/zigpy/bellows/#testing-new-releases

[MarhyCZ]

Awesome! I was installing it from a local git folder. I tried to make a patch, but I just couldn't quickly absorb the asyncio documentation :(

[MarhyCZ]

It still timed out when it was trying to send the SYS.Version.Req() command.
I will try it with maybe with a longer toggle delay.

EDIT: Nope, increasing to 0.3s did not do anything.

[puddly]

Darn. You can use -vv for more verbose output but unfortunately this is the same procedure that Z2M is using so I'll just have to wait until I get some hardware that requires this to start up.

The only other thing that I can think of is adding a 1s delay to ZNP.connect, before the bootloader skip bytes are even sent. PySerial also reconfigures the serial port after each property update so perhaps removing the transport.serial.dsrdtr = False lines in uart.py might also work.

[MarhyCZ]

I will try to flash it with the debug fw as slaesh mentioned so we can see if it succeeded to switch it into correct state.

Thank you very much for this huge effort! Really appreciate this. I am going to try all above.

[MarhyCZ]

So adding the 1second delay in ZNP.connect did not help and removing the transport.serial.dsrdtr = False commands also did not have any effect :/ I will try it with the debug fw.

LOGGER.debug("Waiting 1s before the skip bytes are sent")
await asyncio.sleep(1)
skip = bytes([c.ubl.BootloaderRunMode.FORCE_RUN])
self._uart._transport_write(skip * 256)

[puddly]

Hmm, perhaps the correct way is to set transport.serial.dtr and transport.serial.rts instead of transport.serial.dsrdtr and transport.serial.rtscts (near the end of uart.py).

Those appear to generate the same ioctl calls as the Node.JS serial port library that Z2M uses. The Node.JS library sets both in a single ioctl call but doing this with PySerial would generate two, which hopefully won't affect anything.

[MarhyCZ]

That was freaking it!! I couldn't understand the difference between these two.
Changing the commands to dtr and rts worked! However the 1 second delay in ZNP.conect is also needed. It is not working if I remove the delay. I am making a PR.

[MarhyCZ]

Confirming that it works!

[MarhyCZ]

Thanks a lot for the patience! I really appreciate it!

[puddly]

Awesome, thank you for remotely debugging this!

[puddly]

One thing to note: if you've previously used this stick with a default Z2M install, zigpy-znp will not overwrite the configured network settings when used with HA. These include a fixed PAN ID and network key. You may want to run python -m zigpy_znp.tools.nvram_reset /dev/slaesh and re-run the energy scan, which will re-form the network with a random key and PAN ID.

[MarhyCZ]

Oh, thanks a lot! Didn't think about it. Thats very helpful!