-
Notifications
You must be signed in to change notification settings - Fork 2
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ZBDongle-E flow control #4
Comments
Thank you for the hints. This is very helpful. I will use a different CTUNE value in the next build. But why not simply use 133, when this was the best value in the tests? An individual value per model is not problem at all with this build infrastructure. Regarding the HW flow control on the ZBDongle-E: I have several of those, and mine work very well with my firmware. Can you please explain what kind of problems you were experiencing with Skgsergio's builds? I tried his v1.2 with 115200 baud on my ZBDongle-E before I built my own version, and, as far as I could see, it worked for the short time I tested it. Are we talking about the current version of the dongle, Zigbee 3.0 USB Dongle Plus, Model ZBDongle-E, EAN 6920075777659? |
So, I just built a version for the ZBDongle-E without hardware flow control for those who need it (ending in |
I read the mentioned answer by itead again. I am really not sure if 128 or 133 is the correct value, but since they stated to use 128 for best performance, I initialized a new build, now with the value 128. |
Yes I am using the current -E dongle. I couldnt get the Silicon Labs addon to connect to the dongle with v1.2 build, but then it worked straight away when I switched to v1.1. I will test again though and see. |
So did you flash the RCPMultiPAN or the EmberZNet version? I am currently using the RCPMultiPAN version with 230400 baud and hardware RTS-CTS handshaking in an experimental setup of Home Assistant on x86-64 with the Silicon Labs Multiprotocol add-on v1.0.2 and zigbee2mqtt (edge). Therefore, I set the SONOFF Zigbee 3.0 USB Dongle Plus V2 integration to be ignored. Perhaps there is just something wrong with the EmberZNet firmware? I will check this version again. |
I am using the RCPMultiPAN firmwares and Silabs Multi addon, with test instance of HA running in a VM. Just tested again with 4.2.2 builds Ive not tested the EmberZNet NCP firmware. |
Also what do you use to flash these? Universal Silabs flasher is failing to probe via CPC once I have one of your firmwares flashed, where as I pretty sure Skgsergio's builds were working ok with that. I ended up having to use the physical boot button and Elelabs flasher to upgrade from these. |
I use the same NabuCasa Universal Silicon Labs Flasher when trying my firmware builds. No problems with this whatsoever. The only three things to make sure:
|
Is there any difference in using the NabuCasa flasher vs a terminal and xmodem? |
Well, the results should be the same. The NabuCasa flasher can start the bootmanager of the dongle without pressing a button. It also has some additional checks and functionality (e.g., changing the EUI-64 = IEEE address). After starting the bootmanager, the NabuCasa flasher also uses XMODEM to upload the firmware, just like manually with a terminal. |
This should be fixed in v0.0.10 of NabuCasa flasher, however it does rely on patches to the Openthread SDK so will only work with firmware built using those, so probably wont work with other random community built firmware. |
Thank you for the hint. I have seen that there have been changes to the NabuCasa flasher regarding this point. Since I ported their SDK patches, it should also work with this firmware builds, but I have not tried the new flasher yet, so I cannot really be sure. I will try it and report back. |
Hi, I just discover your build. 👍 nice job. I'm using Zigbe2mqtt edge, rcp-uart-802154-zbdonglee-230 -> not working fine. (just like SkyConnect) Hope 460800 will come soon. On Debian, I use last build universal-silabs-flasher from NabuCasa. Fred |
Hi Fred, if you want to use the rcp-uart-802154-zbdonglee-230, you need to use a software component to handle the Zigbee stuff called zigbeed. The rcp-builds are not intended to be used directly with zigbee2mqtt. They can easily be used with the Silicon Labs Multiprotocol add-on for Home Assistant. Since zigbee2mqtt currently does not support Thread/Matter, it does not make much sense to use the rcp builds in a pure zigbee2mqtt environment without the add-on. But when you use Home Assistant and the Multiprotocol add-on with the RCPMultiPAN builds, you need to configure your Home Assistant
should do the job. |
My config was like you said. But not working.
Fred |
I am really not sure what is happening here. I have the same configuration running on an experimental system. |
Thank you for the feedback. I will check what I can do. So you use the same ZBDongle-E in in the same location in both cases, once with my NCP firmware, and once with my RCP firmware. With the NCP firmware, you do not get LQI errors. But when you use the same ZBDongle-E with my RCPMultiPAN firmware, you get lots of LQI errors. Is this the case? Did I understand you right? |
I just compared the configuration of the PA in the source code of the EmberZNet and the RCPMultiPAN firmware. They are completely identical. It could be an error in the build process, but i have found none, so far. I will try to search a little bit more. But I also have had no detailed look into the Zigbee daemon zigbeed. Since it is a software layer between zigbee2mqtt and the hardware and only active when using the RCP builds, it could also cause some effects. |
After pairing all my devices, all working fine. So RCP and NCP firmware work fine. Fred |
Glad to hear that. I intend to close this issue soon, unless there are more related problems. If there are other unrelated problems, please open a new issue. You can also use the discussions on this page if your topic is not a firmware issue. Thank you. |
Hi, Why LQI NCP are different from LQI RCP ? RCP is always 255, with NCP according to room, it is between 255 and 100. Fred |
Similar to the issue about the LQI errors, the root cause of this problem could be multiple things:
The firmware source code is essentially published by Silicon Labs, the modifications are minimal, just to support the respective hardware. If there really is an error in the reporting of the LQI in the firmware, I suspect that it is already in the original source code. But I guess it is more the way zigbee-herdsman communicates with the hardware in this special case. Please also note that the RCPMultiPAN concept is still in an early stage, I would not really consider it as production ready. In a larger setup, it might make much more sense to use two communication units (dongles), one exclusively for Zigbee (with EmberZNet), and one just for Thread (with OpenThreadRCP, also in an early stage), even if the lower layers 1 and 2 (essentially PHY and MAC) are IEEE 802.15.4 in both cases. But since the higher layers differ significantly, it might make sense to handle both protocols completely separately. |
Thank you for answer. "I suspect that it is already in the original source code" I made the test with SkyConnect and was having same issue with ZBDongle-E. Fred |
That is very interesting. Thank you. Have you also tried the SkyConnect firmware provided by NabuCasa? It should be the same, since I forked their project, but did not change anything for the SkyConnect. |
I tested with : Fred |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Nice work getting these builds up and running.
I dont think the ZBDongle-E supports hardware flow control and needs to use software flow control. In fact i recall reading somewhere the CTS and RTS lines are not connected on this device.
I havent tested your specific builds yet, however I have been running Skgsergio's RCP builds for ZB-GW04 v1.1 on my ZBDongle-E which works well. His ZB-GW04 v1.2 builds with hardware RTS/CTS do not work on the ZBDongle-E in my testing.
CTUNE should probably also be set to 128 on this device, per this comment from iTead
grobasoz/zigbee-firmware#28 (comment)
The text was updated successfully, but these errors were encountered: