Support for slae.sh CC2652RB stick about zigpy-znp

[puddly]

Awesome, thank you for remotely debugging this!

[MarhyCZ]

Confirming that it works!

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

[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)

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

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

[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!