Adapters hardware flow control issues #943
Comments
|
I've re-checked the SkyConnect PCB and all past firmwares. The RTS and CTS pins are correctly hooked up to the CP2102N, I do not believe they are swapped. All known firmwares (including the version the SkyConnect ships with) use the same pin configuration. Similarly, I am not able to reproduce this problem with ZHA: 2024-03-01 15:03:56.364 ubuntu zigpy.serial DEBUG Opening a serial connection to '/dev/ttyUSB2' (115200 baudrate)
2024-03-01 15:03:56.369 ubuntu bellows.ezsp DEBUG Resetting EZSP
2024-03-01 15:03:56.369 ubuntu bellows.uart DEBUG Resetting ASH
2024-03-01 15:03:56.369 ubuntu bellows.uart DEBUG Sending: b'1ac038bc7e'
2024-03-01 15:03:57.458 ubuntu bellows.uart DEBUG RSTACK Version: 2 Reason: RESET_SOFTWARE frame: b'c1020b0a527e'I am able to trigger a |
what does "correctly" mean? Is it: ? |
So the first contact (RST from a cold start) also triggers a RESET_WATCHDOG ERROR frame, then it starts without problem (as in, retry logic kicks in, clears the NCP failed state, then proper RSTACK is received)? It is very strange that for @Mar1usW3 the firmware with swapped pins immediately makes the error disappear, and as soon as a regular firmware is introduced the error reappears... The issue seems predominant in "HA+Z2M addon", but that could just be because most users use that combo... Still, worth mentioning... I suppose someone will also have to go through the serial libraries (JS & python...), to make sure everything's alright in there, nothing swapped, nothing improperly set... |
Correctly here I think means CP2102N CTS -> EFR32MG21 RTS (PB00) and CP2102N RTS -> EFR32MG21 CTS (PB01). I can double check with a logic analyzer when I have a bit more time.
I am testing with zigpy-cli, which provides command line access to the zigpy libraries. It would be identical to restarting HA Core. If I connect after just plugging in the stick, the watchdog error is seen in logs. If I close the connection and re-connect after that, the watchdog error never appears again. |
But linked in config different |
|
Seems sky-swap firmware is indeed fixing the RESET_WATCHDOG init error... I've had several reports of it now. @darkxst People are reporting the same issue with the HA Yellow... Found logs as old as 2022 that have the same error (just searched the web with |
Gentlemen, I don't understand why this has become a problem - isn't it a matter of settings in fw? E.g. these ones: so just swap them to or is something else behind this topic? |
|
The fact that it eventually works with either configuration (and no configuration!) makes it sound like this is a software/kernel problem, not a hardware/firmware issue. The wiring diagram I've posted above is correct as far as I can tell. RTS and CTS are wired to the opposite pin, same as TX and RX (as in the datasheet): 
Similarly, from the same CP2102N datasheet:
So as long as the CP2102N is able to receive data, it keeps the CP2102N RTS pin low. When it can't, it pulls it high. The CP2102N RTS pin is wired to the EFR32's CTS pin: the EFR32 assumes it is "clear to send" as long as the CP2102N is signaling "ready to send". The watermark level being 448 bytes by default makes it sound like hardware flow control will never actually be used (i.e. the RTS and CTS pins will never toggle). The underlying problem is probably a CP2102N pin state configuration issue with the kernel driver or possibly a firmware bug keeping RTS pin in the wrong state until a reset. If that is the case, running with no flow control (i.e. no XONXOFF and no RTSCTS) should work fine. I'll try it out on an oscilloscope in a few days. |
|
@Nerivec your description of the problem somehow triggered some neurons here: I've seen similar issues with ZHA/bellows too, very early on. Those got fixed with zigpy/bellows#459. From what I understand, the EmberZNet firmware by default sends out a reset reason. However, on most devices this reset reason just get sent into nirvana, since the other side is not (yet) listening at all (and there is no flow control, so the firmware just starts sending). For USB devices this essentially might be a race condition, e.g. the SiLabs chip starts quicker than the CP2102N can be enumerated an initialized by the operating system. With Yellows/SkyConnects firmware/pin settings, the flow control is by default set to "not ready". Only when the host system actually opens the serial port, the flow control indicates "ready" such that bytes flow. That means you get this very first communication from the EmberZNet firmware (which is the reset reason). Swapping the pins likely lead to a configuration where flow control is set to "read" from a firmware perspective. So the reset reason ended up in nirvana (and Z2M subsequently working). |
|
That's not my area of expertise at all (I just gathered everything I could so someone else could figure this one out 😁) but my guess is, @puddly is right, it's OS-level stuff that's messing things up (even though the retry logic in ZHA/Z2M bypasses it most of the time). All I can say is, it seems very inconsistent; for some users, it never happens, for some, it always happens, for some, it happens sometimes, for some it happens but gets bypassed by retry logic, and for some it happens and retry logic sends the adapter into a tailspin. The one thing that definitely seems to remove the problem entirely at the moment -no more retries at all- (confirmed on SkyConnect, Yellow, and SLZB-07) is firmware with software flow control only... |
From what I remember, this is not in response to RST. I think this is sent before you even send a RST. Just open the port, and you'll see it. Now if you send a RST directly on open this might "look" like it is the respond to RST. But in the end that is the "beauty" of UART - universal asynchronous receiver / transmitter 😅 🙈 Now if that RSTACK frame is "normal firmware behavior" we can debate over, we'd probably have to ask SiLabs. From Silicon Labs own UG101: UART-EZSP Gateway Protocol Reference, it seems so:
Silicon Labs essentially gives two reset option, either through the hardware nRESET pin or the RST frame. It seems that in both cases the firmware is expected to send a RSTACK frame ("the NCP will send the RSTACK frame to the Host"). Now when you plug-in or (boot-up) a computer with a SkyConnect, on the SkyConnect the nRESET pin is essentially asserted. So inside the SkyConnect, the NCP firmware boots up an sends the RSTACK frame. Now since SkyConnect has proper hardware flow control, that RSTACK frame actually waits on the transmit buffer until the host side (Linux, Z2M/bellows or whoever is going to interact with the stick) opens the serial port. So the first thing you'll see is that RSTACK frame. That initial RSTACK "error" frame is just the firmware telling you that it got freshly out of reset. In the end Z2M (just like bellows) should properly process that frame, even when it is the first thing it sees. Ideally probably it should skip sending a RST in that case (as the frame is telling the host that the firmware just got booted, no need to send another reset). But then, just issuing another RST certainly also doesn't hurt... It just will slow down initialization by $firmware-statup-time... But yeah, during regular operation a RSTACK frame should be consider problematic, especially if
Afaik, software flow control starts with XON by default, meaning the flow is enabled. So this means the firmware on startup just starts to send things (like this RSTACK) even though the host is not listening yet. Which in the end is why you don't see the frame on startup. No big deal, as you'll send a RST and therfore reinitialize communication. But that explains why software flow control seems to fix the problem for you.
Not sure what you refer to here exactly, but as I've noted in the linked PR, the OS can influence behavior indeed, quote from zigpy/bellows#459:
In other words, the OS might have left the serial port in a state where "ready" is signaled through flow control. In that case you'll not get the initial RSTACK frame. So depending on what touched the serial port before, YMMV! But ideally, any software communicating with the EmberZNet firmware through Linux tty layer/serial port should not make assumption about how the serial port was/is configured. |
Just to be clear (for the below), I don't have a device with hw flow control at the moment (that sure is not making it easy to test any of this, but one is in the mail!)... These are only reports I got from other users, that I relayed to firmware builders (who certainly know more on the subject than I currently do 😄)
I can only refer to the logs for the moment... Can you confirm this on your end? Assuming the serialport logic is doing its job, I don't think it would be the case here. (In
What doesn't look right to me, is that it's not coming as an RSTACK (0xC1) at all, it's an ERROR frame (0xC2), which means the NCP is in failed state at that point... |
Nerivec
changed the title
|
@darkxst Any chance you had some time to debug on the SLZB-07? |
No not yet, been a bit busy with other projects this week.
From the UG101 doc linked above, it sounds like its ok to throw away these initial errors, until a valid RSTACK frame is received.
|
Kk, I see, so substitute "fix the problem for you" with "fix the problem for some folks" 😅
I tried quickly with a SkyConnect and it's vanilla firmware My thoughts are mostly from memory + what I've documented in those issue reports. Looking at those I am pretty sure that I did all those tests on Yellow back then. I am guessing SkyConnect could really behave different here.
This flushes the local buffers. If the port just got opened, (and with that hardware flow control released), it might be that those bytes come in after the flush....
At a baudrate of 115200 a character is sent every ~0.1ms (approximately, 8 bits + start/stop bits). So such an error frame of 6 bytes length should be transferred well within 1ms. If the response is "several milliseconds later", this feels like the failed state is in response to the reset, I agree. Especially since I can't see those bytes on SkyConnect.
Uh, I see, this is also different from my observations in zigpy/bellows#459 (comment), where the raw frame was So really looks like it is something different what is observed on SkyConnect. |
That's it 😁 By the way, re-reading this thread for the nth time, I noticed I forgot to mention you in the first post, sorry about that. I was sure I did... neurons of my own... misfiring... I ran some tests on the Dongle-E 7.4.1 (out of curiosity, to see exactly what happens with xon/xoff only). I can see a
Definitely, from the two dozen or so logs I've gone through on this, the fastest I've seen it coming in was approx. 600ms post-RST, most times it's about 1sec (which is about the time it takes for a successful RSTACK to come in too). From my observations, most times, the retry logic takes care of sending another
Yellow with `rtscts: false`, `xon: true`, `xoff: true`Yellow with `rtscts: true`, `xon: false`, `xoff: false` |
|
@Nerivec could you make some reproducible test script with herdsman that gets stuck during startup like this? I've yet to be able to reproduce this issue a single time on any platform I use. |
|
The "getting stuck" seems to be affecting the Yellow the most for some reason (see this recent one), some kind of "panic" around the third reset attempt... I've moved the ACKing a bit earlier to avoid I pushed several fixes to attempt to get around it so previous logs won't match current logic in dev (don't have a Yellow, can't confirm yet, but automated tests say it should work...). Doesn't solve the problem, but hopefully works around it until then. Have you been able to identify what's triggering that watchdog |
HA OS isn't virtualized. Once the device is passed through to the Docker container, it should behave identically to one accessed from outside the container (since you're passing the device file itself through, there's no passthrough USB or serial driver involved like with a VM). Home Assistant within HA OS runs in a container just like other addons so there should be no difference in functionality. Regarding that linked issue, the poster said this in a comment:
It sounds to me like something in the new
Not without being able to replicate the issue, unfortunately. Once I can get a hold of a reproducible test case I can start digging into it with a development kit or with a SWD debugger attached but I'd like to avoid doing so if a fix can be done in software 😄. |
#943 (comment) Regarding containers, there must be a difference somewhere in the handing over, because from all the tests I've ran (no matter the adapter, or hw flow control setting), the startup sequence is almost always "messier" (reset almost never succeeds on first try -especially with Z2M as HA add-on, on first start of add-on-). That never happens in bare setup (I've never been able to trigger that even once on bare debian or even windows). The startup sequence is entirely different in |
|
Just to make sure we're on the same page here, here are the only two startup sequences I'm aware of for newer firmwares: Sequence 1, fresh connect (1.3 seconds): $ zigpy -vvv radio --baudrate 115200 ezsp /dev/serial/by-id/usb-Nabu_Casa_Home_Assistant_Connect_ZBT-1_9e2adbd75b8beb119fe564a0f320645d-if00-port0 info
2024-05-09 17:57:01.693 homeassistant zigpy.serial DEBUG Opening a serial connection to '/dev/serial/by-id/usb-Nabu_Casa_Home_Assistant_Connect_ZBT-1_9e2adbd75b8beb119fe564a0f320645d-if00-port0' (115200 baudrate)
2024-05-09 17:57:01.697 homeassistant bellows.ezsp DEBUG Resetting EZSP
2024-05-09 17:57:01.698 homeassistant bellows.uart DEBUG Resetting ASH
2024-05-09 17:57:01.698 homeassistant bellows.ash DEBUG Sending frame CANCEL + RstFrame() + FLAG
2024-05-09 17:57:01.698 homeassistant bellows.ash DEBUG Sending data 1ac038bc7e
2024-05-09 17:57:01.867 homeassistant bellows.ash DEBUG Received data 1ac20203d20a7e
2024-05-09 17:57:01.868 homeassistant bellows.ash DEBUG Received cancel byte, clearing buffer
2024-05-09 17:57:01.869 homeassistant bellows.ash DEBUG Received frame ErrorFrame(version=2, reset_code=<NcpResetCode.RESET_WATCHDOG: 3>)
2024-05-09 17:57:01.869 homeassistant bellows.ash DEBUG NCP has entered failed state: NcpResetCode.RESET_WATCHDOG
2024-05-09 17:57:01.870 homeassistant bellows.ezsp INFO NCP entered failed state. No application handler registered, ignoring...
2024-05-09 17:57:02.940 homeassistant bellows.ash DEBUG Received data 1ac1020b0a527e
2024-05-09 17:57:02.941 homeassistant bellows.ash DEBUG Received cancel byte, clearing buffer
2024-05-09 17:57:02.942 homeassistant bellows.ash DEBUG Received frame RStackFrame(version=2, reset_code=<NcpResetCode.RESET_SOFTWARE: 11>)
2024-05-09 17:57:02.944 homeassistant bellows.ezsp DEBUG Switching to EZSP protocol version 4
2024-05-09 17:57:02.945 homeassistant bellows.ezsp.protocol DEBUG Sending command version: (4,)
2024-05-09 17:57:02.946 homeassistant bellows.ash DEBUG Sending frame DataFrame(frm_num=0, re_tx=False, ack_num=0, ezsp_frame=b'\x00\x00\x00\x04') + FLAGSequence 2, subsequent reconnect (1.0 seconds): $ zigpy -vvv radio --baudrate 115200 ezsp /dev/serial/by-id/usb-Nabu_Casa_Home_Assistant_Connect_ZBT-1_9e2adbd75b8beb119fe564a0f320645d-if00-port0 info
2024-05-09 18:03:41.979 homeassistant zigpy.serial DEBUG Opening a serial connection to '/dev/serial/by-id/usb-Nabu_Casa_Home_Assistant_Connect_ZBT-1_9e2adbd75b8beb119fe564a0f320645d-if00-port0' (115200 baudrate)
2024-05-09 18:03:41.983 homeassistant bellows.ezsp DEBUG Resetting EZSP
2024-05-09 18:03:41.984 homeassistant bellows.uart DEBUG Resetting ASH
2024-05-09 18:03:41.984 homeassistant bellows.ash DEBUG Sending frame CANCEL + RstFrame() + FLAG
2024-05-09 18:03:41.985 homeassistant bellows.ash DEBUG Sending data 1ac038bc7e
2024-05-09 18:03:43.062 homeassistant bellows.ash DEBUG Received data 1ac1020b0a527e
2024-05-09 18:03:43.063 homeassistant bellows.ash DEBUG Received cancel byte, clearing buffer
2024-05-09 18:03:43.063 homeassistant bellows.ash DEBUG Received frame RStackFrame(version=2, reset_code=<NcpResetCode.RESET_SOFTWARE: 11>)
2024-05-09 18:03:43.065 homeassistant bellows.ezsp DEBUG Switching to EZSP protocol version 4
2024-05-09 18:03:43.066 homeassistant bellows.ezsp.protocol DEBUG Sending command version: (4,)
2024-05-09 18:03:43.067 homeassistant bellows.ash DEBUG Sending frame DataFrame(frm_num=0, re_tx=False, ack_num=0, ezsp_frame=b'\x00\x00\x00\x04') + FLAGIs there an unrecoverable third case? I see identical behavior with and without RTS/CTS flow control on both the SkyConnect and the Yellow, no matter what platform I use. |
|
As far as I can tell, with Z2M add-on on HAOS, it goes like this: Yellow with hardware flow control firmware, Z2M add-on newly started (manual or update):
(You can see the mocked debug log used to test against here, ignore the rtscts setting, it's just from a mocked port) Yellow with software flow control firmware, any scenario:
Note: Just to be clear, lowercase is sent to the adapter, uppercase is received from adapter |
|
Do |
|
According to Silabs' code yes (it sends on next send, before whatever is supposed to be sent, so here, right before |
|
I'm trying this with exclusively SiLabs code ( I've set up two ASH parsers, one for the RX side and one for the TX side, to see what serial traffic is being sent. I've tried dozens of times to get anything to break and this is as broken as it gets: OPENED SERIAL PORT
===> TX: 2024-05-09 18:40:01,427 macbook bellows.ash[1138] DEBUG Received data 1ac038bc7e
===> TX: 2024-05-09 18:40:01,427 macbook bellows.ash[1138] DEBUG Received cancel byte, clearing buffer
===> TX: 2024-05-09 18:40:01,427 macbook bellows.ash[1138] DEBUG Received frame RstFrame()
<=== RX: 2024-05-09 18:40:01,427 macbook bellows.ash[1138] DEBUG Received data 1ac20203d20a7e
<=== RX: 2024-05-09 18:40:01,427 macbook bellows.ash[1138] DEBUG Received cancel byte, clearing buffer
<=== RX: 2024-05-09 18:40:01,427 macbook bellows.ash[1138] DEBUG Received frame ErrorFrame(version=2, reset_code=<NcpResetCode.RESET_WATCHDOG: 3>)
<=== RX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG NCP has entered failed state: NcpResetCode.RESET_WATCHDOG
CLOSED SERIAL PORT
OPENED SERIAL PORT
===> TX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received data 1ac038bc7e
===> TX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received cancel byte, clearing buffer
===> TX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received frame RstFrame()
<=== RX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received data 1ac1020b0a527e
<=== RX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received cancel byte, clearing buffer
<=== RX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received frame RStackFrame(version=2, reset_code=<NcpResetCode.RESET_SOFTWARE: 11>)
===> TX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received data 8070787e004221a8597c057e
===> TX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received frame AckFrame(res=0, ncp_ready=0, ack_num=0)
===> TX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received frame DataFrame(frm_num=0, re_tx=0, ack_num=0, ezsp_frame=b'\x00\x00\x00\r')
===> TX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received data 1a084221a8597d5e287e
===> TX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received cancel byte, clearing buffer
===> TX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received frame DataFrame(frm_num=0, re_tx=1, ack_num=0, ezsp_frame=b'\x00\x00\x00\r')
<=== RX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received data 1ac1020b0a527e0142a1a8592835c6ade27e8160597e
<=== RX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received cancel byte, clearing buffer
<=== RX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received frame RStackFrame(version=2, reset_code=<NcpResetCode.RESET_SOFTWARE: 11>)
<=== RX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received frame DataFrame(frm_num=0, re_tx=0, ack_num=1, ezsp_frame=b'\x00\x80\x00\r\x02 t')
<=== RX: 2024-05-09 18:40:01,428 macbook bellows.ash[1138] DEBUG Received frame AckFrame(res=0, ncp_ready=0, ack_num=1)Here is what happens on a freshly-connected SkyConnect: ===> TX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received data 1ac038bc7e
===> TX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received cancel byte, clearing buffer
===> TX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received frame RstFrame()
<=== RX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received data 1ac102029b7b7e
<=== RX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received cancel byte, clearing buffer
<=== RX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received frame RStackFrame(version=2, reset_code=<NcpResetCode.RESET_POWER_ON: 2>)
<=== RX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received data 1ac1020b0a527e
<=== RX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received cancel byte, clearing buffer
<=== RX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received frame RStackFrame(version=2, reset_code=<NcpResetCode.RESET_SOFTWARE: 11>)
===> TX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received data 8070787e004221a8597c057e
===> TX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received frame AckFrame(res=0, ncp_ready=0, ack_num=0)
===> TX: 2024-05-09 18:25:22,765 macbook bellows.ash[936] DEBUG Received frame DataFrame(frm_num=0, re_tx=0, ack_num=0, ezsp_frame=b'\x00\x00\x00\r')
<=== RX: 2024-05-09 18:25:22,766 macbook bellows.ash[936] DEBUG Received data 0142a1a8592835c6ade27e
<=== RX: 2024-05-09 18:25:22,766 macbook bellows.ash[936] DEBUG Received frame DataFrame(frm_num=0, re_tx=0, ack_num=1, ezsp_frame=b'\x00\x80\x00\r\x02 t')
===> TX: 2024-05-09 18:25:22,766 macbook bellows.ash[936] DEBUG Received data 8160597e7d314321a9fe2a04303a7e
===> TX: 2024-05-09 18:25:22,766 macbook bellows.ash[936] DEBUG Received frame AckFrame(res=0, ncp_ready=0, ack_num=1)
===> TX: 2024-05-09 18:25:22,766 macbook bellows.ash[936] DEBUG Received frame DataFrame(frm_num=1, re_tx=0, ack_num=1, ezsp_frame=b'\x01\x00\x01\xaa\x00\x11')I've yet to get it into an unrecoverable state, however, or one that isn't fixed by the host sending a normal |
|
I'll let you know in the next few days if I still see reports of "unrecoverable state" with the new fixes. Hopefully not. As for the watchdog... so sometimes it's |
|
Hi, just chiming in. Even with the latest zigbee-herdsman I still cannot start the LogsLet me know if anything I can do to give more information. Looking at the EZSP logs, it seems that recieveng an RSTACK takes 5 seconds after the RST request. |
|
@zalatnaicsongor As mentioned in various places, multiprotocol is no longer supported. https://www.zigbee2mqtt.io/guide/adapters/emberznet.html @puddly Seems 1.37.1 is able to work around the starting issue that resulted in failure (see example log below, for some reason, it's sending a NAK right after the RSTACK...). So, I guess, back to the original issue here, getting rid of that Yellow log (omitted some "waiting" lines for brevity") |
Is there any documentation of the issues with this? Zigbeed should implement the EZSP protocol. |
|
The issues aren't with the EZSP side, unfortunately. Zigbeed is built from the Silicon Labs Gecko SDK and the vast majority of the RCP firmware, the Zigbee stack itself, and host-side software are pre-compiled and linked straight from the SDK. There are a few outstanding bugs that make the firmware unstable (see the Home Assistant addon issue tracker). Even with the addition of firmware-level watchdogs and disabling buggy features (multi-channel and ZGP), it still is extremely unstable for many users and crashes nearly constantly. We've made SiLabs aware of the issues and they're working through them but there's no timeframe for when all of the critical bugs will be fixed. |
|
This issue is stale because it has been open 180 days with no activity. Remove stale label or comment or this will be closed in 30 days |
|
@puddly Out of curiosity, with a router firmware (logs-a-lot), I was able to get details on the One thing's for sure, it's not specific to NCP, since the router firmware also triggers it. |
This issue seems to affect all adapters supporting hardware flow control, even though the below uses the SkyConnect as example.
The SkyConnect has been exhibiting strange behaviors regarding hardware flow control (with both
ezspandember), and a few issues have been raised about it. This issue regroups previously started discussions in one thread.I dug out a couple of reports I remembered, but more are buried in other issues...
Currently reported behaviors:
c20203d20a7e), then resets properly if a second attempt is made immediately after.rtsctsis enabled (same as above, but crashes soon after).The issue is present in firmware as early as
7.3.2.0 build 212.NOTE: With
ezspdriver, 1.35.2 changes the behavior from having bothrtscts&xon/xoffenabled at the same time (ifrtsctsenabled) to justrtsctsif enabled, elsexon/xoff. While the change fixed issues for some devices; it also brought out the issue with the SkyConnect, that does not seem to want to work withoutxon/xoff. before / after@Rookman2022
ezsp / Home AssistantlinkLogs
@newlund
ezsp / Home AssistantlinkLogs
@Mar1usW3
ember / Home AssistantlinkHere, issue seems present with or without
rtsctsenabled... but appears only randomly on start/restart of Z2M (i.e. sometimes it works, sometimes it doesn't).See Koenkk/zigbee2mqtt#21462 (reply in thread) for more detailed logs on testing custom inverted RTS/CTS firmware vs regular firmware.
Logs
@Nerivec
@darkxst
@Nerivec
@darkxst
@puddly
@darkxst
A few TODOs that I can think off...:
If anyone with the issue is able to test any of this, feedback is appreciated.
I can also supply custom code on
emberto try to eliminate a few possible causes (find me on Discord).The text was updated successfully, but these errors were encountered: