Closed El-mou33 closed 1 year ago
502 usually means that the add-on did not start properly, check your add-on logs
I don't know exactly what happens but the logs repeat this several times:
setsockopt - SO_RECV_ANYIF: Protocol not available
Should I need to flash the OTBR before to use this addon?
In theory is prefhashed
Maybe @agners knows
The setsockopt
error is related to the mDNSResponder, but not harmful from what I can tell.
There was an error in the add-on when hardware flow control was off, I just merged a fix with #39. Can you try version 0.1.3 again?
It could also be that the border router firmware is too old, but I would expect some type of message in the logs.
This are the logs:
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[13:02:43] INFO: Starting mDNS Responder...
mDNSResponder (Engineering Build) (Apr 19 2022 18:37:56) starting
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
mDNS_AddDNSServer: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP & NAT-PMP announcements
[13:02:45] INFO: Starting otbr-agent...
otbr-agent[230]: [INFO]-UTILS---: Running 0.3.0-f8399eb-dirty
otbr-agent[230]: [INFO]-UTILS---: Thread version: 1.2.0
otbr-agent[230]: [INFO]-UTILS---: Thread interface: wpan0
otbr-agent[230]: [INFO]-UTILS---: Backbone interface: eth0
otbr-agent[230]: [INFO]-UTILS---: Radio URL: spinel+hdlc+uart:///dev/ttyUSB2?uart-baudrate=115200&uart-flow-control
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
otbr-agent[230]: 50d.00:21:03.461 [C] Platform------: BSD TCP function() at radio_spinel_impl.hpp:2236: RadioSpinelNoResponse
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
setsockopt - SO_RECV_ANYIF: Protocol not available
[13:03:17] INFO: otbr-agent ended with exit code 6 (signal 0)...
[13:03:18] INFO: Starting otbr-agent...
otbr-agent[415]: [INFO]-UTILS---: Running 0.3.0-f8399eb-dirty
otbr-agent[415]: [INFO]-UTILS---: Thread version: 1.2.0
otbr-agent[415]: [INFO]-UTILS---: Thread interface: wpan0
otbr-agent[415]: [INFO]-UTILS---: Backbone interface: eth0
otbr-agent[415]: [INFO]-UTILS---: Radio URL: spinel+hdlc+uart:///dev/ttyUSB2?uart-baudrate=115200&uart-flow-control
Oh I see now:
otbr-agent[230]: 50d.00:21:03.461 [C] Platform------: BSD TCP function() at radio_spinel_impl.hpp:2236: RadioSpinelNoResponse
That issue is relate to missing network drivers. I've recently added them to all supported HAOS platforms: https://github.com/home-assistant/operating-system/pull/1870
What platform are you on? Can you try the latest dev build? You should be able to upgrade with something along these lines:
ha su options --channel=dev
ha su reload
ha os update --version=8.0.dev20220427
That's a problem for me I have Home assistant core and home assistant supervisor. I change to the latest development mode but that error still happening. I don't know if there is other way to get the drivers.
@El-mou33 can you link me the firmware you have been using?
I've not tried TI sticks so far, so quite possible something is not working with that particular model. From the logs it seems the stick doesn't answer:
otbr-agent[230]: 50d.00:21:03.461 [C] Platform------: BSD TCP function() at radio_spinel_impl.hpp:2236: RadioSpinelNoResponse
I think here is the firmware:
https://github.com/Koenkk/Z-Stack-firmware/tree/master/router/Z-Stack_3.x.0/bin
Because Im not fully sure that's what you need, this is the page where I found that link and other instructions about firmware:
https://slae.sh/projects/cc2652/
At the end of the last link, they say they have telegram for technical support.
https://github.com/Koenkk/Z-Stack-firmware/tree/master/router/Z-Stack_3.x.0/bin
Those are Z-Stack firmwares, that is Zigbee so something else.
The OpenThread Border Router add-on is really built from recent upstream sources, and should work with any of the supported RCP firmwares (as long as they work with the spinel+hdlc+uart
protocol, and from what I understand the CC2652R
should work with that protocol).
It seems that there is a OTBR firmware on this page, however, there is no date code or version information.
At the end of the last link, they say they have telegram for technical support.
Yeah it's probably best if you contact him and ask what type of firmware that exactly is and with which version of OpenThread it has been built from. Probably best to send him the link to this issue, so we can sort it out directly.
Ok I contacted him. This is what they said:
Looks like that this add-on expects an "RCP" device. But our firmware is currently an "NCP" .. I will try to create another firmware for you 👍😎
Looks like that this add-on expects an "RCP" device. But our firmware is currently an "NCP" ..
Yeah, at least going to need to new build, compile and flash an OpenThread Border Router (OTBR) RPC firmware for that adapter.
Also note that Texas Instruments CC2652-based adapters from different manufacturers do maybe not use the same pinout or use chips with the same storage site, so a firmware image file built for the CC2652R-stick made by slaesh will not work on Electrolama's zzh (zig-a-zig-ah) adapter by omerk or the ZigStar Stick V4 by mercenaruss and vice versa as all of those use slightly different pinout schematic for CC2652R, CC2652RB, and CC2652P GPIO pins and/or have a different sized firmware image.
The same goes with other popular CC2652-based adapters, such as cod.m ZigBee CC2652P Raspberry Pi module and cod.m ZigBee CC2652P2 TCP Coordinator, Gio-dot Z-Bee Duo, Egony Stick V4, and Tube's Zigbee Gateways which most will need images compiled specificly for their pinouts and size.
Thread Spinal RCP mode vs Thread Spinal NCP mode is summarized here:
https://openthread.io/platforms/co-processor
https://groups.google.com/g/openthread-users/
OTBR should be a "Thread Certified Component" Texas Instruments CC2652 based chips and here are some references FYI:
https://github.com/openthread/ot-cc13x2-cc26x2/blob/main/src/cc2652/README.md
https://github.com/openthread/ot-cc13x2-cc26x2
https://github.com/openthread/openthread/tree/main/examples/platforms
https://dev.ti.com/tirex/explore/node?node=APzU0zOtgnQIe0sFnHCfxg__BSEc4rl__LATEST
https://openthread.io/vendors/texas-instruments
https://www.threadgroup.org/What-is-Thread/Thread-Benefits#certifiedproducts
This is what the logs said after flashing the new RCP firmware built by slaesh, they said the next week they will have a look at this addon by themselves.
[23:26:38] INFO: Starting otbr-agent...
otbr-agent[8831]: [NOTE]-AGENT---: Running 0.3.0-9fea68c-dirty
otbr-agent[8831]: [NOTE]-AGENT---: Thread version: 1.2.0
otbr-agent[8831]: [NOTE]-AGENT---: Thread interface: wpan0
otbr-agent[8831]: [NOTE]-AGENT---: Backbone interface: eth0
otbr-agent[8831]: [NOTE]-AGENT---: Radio URL: spinel+hdlc+uart:///dev/ttyUSB2?uart-baudrate=115200
otbr-agent[8831]: [INFO]-NCP-----: OpenThread log level changed to 4
otbr-agent[8831]: 49d.21:30:57.289 [W] Platform------: Wait for response timeout
otbr-agent[8831]: 49d.21:30:57.289 [C] Platform------: HandleRcpTimeout() at radio_spinel_impl.hpp:2229: RadioSpinelNoResponse
@El-mou33 Can I suggest that you edit/change your original to be a little more generic to include all TI CC2652-based adapters?
Suggestion: "Thread Spinel RPC firmware for Texas Instruments CC2652 to use OpenThread Border Router (OTBR) Add-on?"
The reason for that suggestion is that not only Slaesh CC2652R stick should work but all CC2652/CC2652P/CC2652R/CC2652RB and CC1352 based adapters (today commonly sold as "Zigbee Coordinator" adapters as preloadeed with Zigbee NCP firmware) as long as someone in the community builds matching OpenThread Spinel RPC firmware image for each adapter and user flash that:
https://www.zigbee2mqtt.io/guide/adapters/#based-on-texas-instruments-cc2652-cc1352-chip
See Koenkk's Z-Stack-firmware repo as a good example of sharing (Zigbee NCP) firmware patch and images for same adapters:
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0/bin
https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0
PS: This discussion should probably also be moved from issues here to a new thread in the Home Assistant's community forum?
PS: This discussion should probably also be moved from issues here to a new thread in the Home Assistant's community forum?
FYI, I started a new discussion thread in Home Assistant's community forum to discuss OTBR RPC firmware for CC2652/CC1352:
@agners That dicussion is posted under the Zigbee section now so maybe can move once create a Thread/OpenThread section?
the current RPC FW and OTBR build need to come from the same OT versions - down to commit to work best. You can see this in the Matter examples from the SI Labs knowledge bates https://community.silabs.com/s/article/Matter-getting-start-guide?language=en_US
The multi-protocol implementation relies on the SI Labs stack. I found a stale PR from them that I think would bring the function to the main OT implementation which potentially could mean a compatible RPC fw for multi-protocol could work with TI or Noridic or ... radios. https://github.com/openthread/openthread/pull/6258
the current RPC FW and OTBR build need to come from the same OT versions - down to commit to work best. You can see this in the Matter examples from the SI Labs knowledge bates https://community.silabs.com/s/article/Matter-getting-start-guide?language=en_US
The multi-protocol implementation relies on the SI Labs stack. I found a stale PR from them that I think would bring the function to the main OT implementation which potentially could mean a compatible RPC fw for multi-protocol could work with TI or Noridic or ... radios. openthread/openthread#6258
@agners Will your "OpenThread Border Router Add-on" be compatible with all manufacturers/models of 802.15.4 SoC platforms as long as has OTBR RCP firmware with Spinel or does it also have to be a specific OpenThread version and/or radio version?
https://openthread.io/platforms
I thought the only important requirement is that firmware build uses OpenThread's standard RCP (Radio Co-Processor) design with Spinel serial protocol for communicating with the host as there is no mention of OpenThread version and/or radio version?
https://openthread.io/platforms/co-processor
PS: Slightly off-topic but FYI, I believe that the ZHA integration gained a lot of additional users and developers because its devs added support for hardware adapters from many manufacturers/stacks and all protocol versions for those so that it today is both hardware independent and FW backwards compatible -> https://www.home-assistant.io/integrations/zha#compatible-hardware
@agners Will your "OpenThread Border Router Add-on" be compatible with all manufacturers/models of 802.15.4 SoC platforms as long as has OTBR RCP firmware with Spinel or does it also have to be a specific OpenThread version and/or radio version?
Generally yes, as long as the RCP firmware with Spinel uses the upstream/official Spinel implementation.
https://openthread.io/platforms
I thought the only important requirement is that firmware build uses OpenThread's standard RCP (Radio Co-Processor) design with Spinel serial protocol for communicating with the host as there is no mention of OpenThread version and/or radio version?
The RCP API does change from time to time, but it is fairly stable and moves fairly slowly. Also, the host (add-on) supports multiple API versions (backwards compatible to some degree). So an older firmware is quite likely to work with a newer OTRB.
See also: https://github.com/openthread/openthread/blob/main/src/lib/spinel/spinel.h#L369-L392
https://openthread.io/platforms/co-processor
PS: Slightly off-topic but FYI, I believe that the ZHA integration gained a lot of additional users and developers because its devs added support for hardware adapters from many manufacturers/stacks and all protocol versions for those so that it today is both hardware independent and FW backwards compatible -> https://www.home-assistant.io/integrations/zha#compatible-hardware
:+1:
FYI, missed that tube0013 posted on Twitter that be uploaded experimental OpenThread RCP firmware images for his CC2652P based (TubesZB Gateway devices) as well as CC2652R/CC2652R1 based dongles like Electrolama zzh!
https://twitter.com/TubesZb/status/1552823766136373251
https://github.com/tube0013/tube_gateways/tree/main/openthread_boarder_router_fw
https://www.tubeszb.com/shop/2
https://electrolama.com/projects/zig-a-zig-ah/
So those could now also be used for development and testing as he confirmed those working with agners OTBR addon from addons-development so that could be of interest for those early adopters interested in Thread/Matter support inside Home Assistant.
FYI, slaesh has now also released updated OpenThread Border Router (OTBR) NCP and experimental OpenThread RCP firmware images for Slaesh's CC2652RB development stick here so now you could test it if want to try Thread instead of Zigbee:
https://github.com/slaesh/cc2652-stick/issues/23
Originally posted by @slaesh in https://github.com/slaesh/cc2652-stick/issues/23#issuecomment-1279806400
NCP firmware
ncp_CC2652RB_115200_v6.20.00.29.bin.zip ncp_CC2652RB_230400_v6.20.00.29.bin.zip
RCP firmware
rcp_CC2652RB_115200_v6.20.00.29.bin.zip rcp_CC2652RB_230400_v6.20.00.29.bin.zip
I guess just flash one of his RPC files the following file as described here and one of the LEDs should slowly blink while running:
https://slae.sh/projects/cc2652/#flashing
Warning! Note that flashing any OpenThread firmware images you will loose your Zigbee network if you been using it for that! Also make sure you flash the correct firmware! Flashing the wrong firmware might lock your bootloader preventing future flashing, meaning that flashing the wrong firmware image can brick your device and need to buy a cJTAG adapter to manually flash it in order to unbrick it , see https://electrolama.com/radio-docs/advanced/flash-jtag/
Suppose those should now cover most CC2652P, CC2652R, and CC2652RB based devices that follow the community pin standard?
Warning! Note that flashing any OpenThread firmware images you will loose your Zigbee network if you been using it for that! Also make sure you flash the correct firmware! Flashing the wrong firmware might lock your bootloader preventing future flashing, meaning that flashing the wrong firmware image can brick your device and need to buy a cJTAG adapter to manually flash it in order to unbrick it.
https://github.com/Koenkk/Z-Stack-firmware/blob/develop/coordinator/Z-Stack_3.x.0/bin/README.md
Adapter | TI Chip/Module Used | Firmware to Flash | BSL Trigger Pin (1) | Auto-BSL (2) | RF Switch Control Pins (3) | LED(s) | Hardware Flow Control |
---|---|---|---|---|---|---|---|
TI LAUNCHXL-CC26xR1 | CC2652R | CC2652R_*.zip |
DIO_13 | No | N/A | DIO_6 (Red) DIO_7 (Green) |
? |
TI LAUNCHXL-CC1352P-2 | CC1352P | CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | No | DIO_28: 2.4Ghz DIO_29: 20dBm PA DIO_30: Sub-1GHz |
DIO_6 (Red) DIO_7 (Green) |
? |
Electrolama zzh | CC2652R | CC2652R_*.zip | DIO_13 | No | N/A | DIO_7 (Pink) | ? |
Slaesh's CC2652RB stick | CC2652RB | CC2652RB_*.zip | DIO_13 | Yes | N/A | DIO_7 (Blue) | ? |
ZigStar Stick v4 | CC2652P (RFSTAR RF-BM-2652P2) |
CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | Only for CH340C ver. | DIO_28: 2.4Ghz DIO_29: 20dBm PA |
DIO_6 (Green) DIO_7 (Red) |
? |
CircuitSetup.us Zigbee Stick | CC2652P (RFSTAR RF-BM-2652P2 PCB Ant.) |
CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | No | DIO_28: 2.4Ghz DIO_29: 20dBm PA |
DIO_6 (Green) DIO_7 (Red) |
? |
Tube's CC2652P2 USB Coordinator |
CC2652P (RFSTAR RF-BM-2652P2) |
CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | N/A | DIO_28: 2.4Ghz DIO_29: 20dBm PA |
N/A | ? |
Tube's Zigbee Gateways (CC2652P2 variant) |
CC2652P (RFSTAR RF-BM-2652P2) |
CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | N/A | DIO_28: 2.4Ghz DIO_29: 20dBm PA |
N/A | ? |
Tube's Zigbee PoE (Power Over Ethernet) Serial Coordinator (CC2652P2 variant) |
CC2652P (RFSTAR RF-BM-2652P2) |
CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | N/A | DIO_28: 2.4Ghz DIO_29: 20dBm PA |
N/A | ? |
Egony Stick V4 (RFSTAR ver.) |
CC2652P (RFSTAR RF-BM-2652P2) |
CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | Yes | DIO_28: 2.4Ghz DIO_29: 20dBm PA |
DIO_7 (Green) DIO_6 (Red) |
? |
cod.m Zigbee CC2652P RPi Module | CC2652P (RFSTAR RF-BM-2652P2) |
CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | No | DIO_28: 2.4Ghz DIO_29: 20dBm PA |
N/A | ? |
cod.m ZigBee CC2652P2 TCP Coordinator | CC2652P (RFSTAR RF-BM-2652P2) |
CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | No | DIO_28: 2.4Ghz DIO_29: 20dBm PA |
DIO_7 (Green) DIO_6 (Red) |
? |
Gio-dot Z-Bee Duo with CC2652P | CC2652P (RFSTAR RF-BM-2652P2) |
CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | Yes | DIO_28: 2.4Ghz DIO_29: 20dBm PA |
DIO_7 (Green) DIO_6 (Red) |
? |
cyijun OpenZ3Gateway | CC2652P (RFSTAR RF-BM-2652P2 SMA Ant.) |
CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | No | DIO_28: 2.4Ghz DIO_29: 20dBm PA |
DIO_7 (Green) DIO_6 (Red) |
? |
SONOFF Zigbee 3.0 USB Dongle Plus by ITead | CC2652P | CC1352P2_CC2652P_launchpad_*.zip | DIO_15 | Yes | DIO_29: 20dBm PA | DIO_7(Not welded) Power LED(Red) |
DIO13: TX DIO12:RC DIO19: CTS(DIP switch ON) DIO18: RTS(DIP switch ON) |
@agners slightly off-topic but FYI, there is now an official experimental OTBR firmware available from dresden-elektronik for ConBee II and RaspBee II, see → https://github.com/dresden-elektronik/openthread-r21
Other independent developers are also using the $10 nRF52840-Dongle (nRF52) Dongle from Nordic Semiconductor to create an inexpensive compatible OpenThread RCP USB dongle for Thread. See -> https://golioth.github.io/golioth-openthread-demo-docs/docs/create-rcp
Has anyone successfully tested a compatible Texas Instruments OpenThread RCP firmware on a CC2652-based adapter as a TBR (Thread Border Router) with Home Assistant to create a Thread network that is used with Matter devices in official integration?
https://github.com/home-assistant/addons/tree/master/openthread_border_router
https://www.home-assistant.io/blog/2023/02/08/state-of-matter-and-thread/
https://www.home-assistant.io/blog/2023/03/01/release-20233/#thread--matter
Has anyone successfully tested a compatible Texas Instruments OpenThread RCP firmware on a CC2652-based adapter as a TBR (Thread Border Router) with Home Assistant to create a Thread network that is used with Matter devices in official integration?
https://github.com/home-assistant/addons-development/tree/master/openthread_border_router
https://www.home-assistant.io/blog/2023/02/08/state-of-matter-and-thread/
https://www.home-assistant.io/blog/2023/03/01/release-20233/#thread--matter
Following!
Since the add-on moved to the main repository at https://github.com/home-assistant/addons/tree/master/openthread_border_router now, this is the wrong place to discuss vanilla OTBR firmwares.
In any case, the issue tracker is probably the wrong place as well to discuss firmwares, unless there is a specific problem with a firmware which seems to be caused by the add-on itself. otherwise I'd suggest to discuss this elsewhere, maybe in the community forums.
FYI, Texas Instruments now provide an official TI OpenThread project here which has to be compiled for each specific adapter
https://github.com/TexasInstruments/ot-ti
slaesh posted links to new updated binaries for his cc2652 stick in this issue:
https://github.com/slaesh/cc2652-stick/issues/23
slaesh wrote that his latest build seems to work using the otbr docker container.
There is more discussion about CC2652/CC1352 as OpenThread Border Router in Home Assistant community forum here:
Im trying to set up a slae.shCC2652R stick with open thread firmware. I chosen the correct device and the correct baudrate. The error still happening.
When I start the web ui the page only says 502: Bad Gateway.
I didn't find any way to modify the front end port or something like zigbee2mqtt does.