gio-dot / z-bee-duo Goto Github PK

Will you consider making CC2674/CC2674P/CC2674R and/or CC1354/CC1354P Zigbee adapters for developers and early adopters?

Check out this developer discussion in Koenkk's Z-Stack firmware repository -> Koenkk/Z-Stack-firmware#476

There is no community firmware from Koenkk yet but that is probably partially because no one made a CC2674 or CC1354 adapter yet.

Chicken or the egg, what comes first, early prototype adapters that Koenkk can test or firmware built in the blind?

FYI, E72-2G4M20S1C (CC2674P10) radio module from Ebyte/Cdebyte is already available for prototyping and first-to-market devices:

https://www.cdebyte.com/products/E72-2G4M20S1C

According to LSagiroglu this new CC2674P10 based module is is pin to pin compatible with their CC2652P based module:

https://www.cdebyte.com/products/E72-2G4M20S1E

PS: No news so far from RFstar if they are working on CC2674P or CC1354P radio modules yet.

@gio-dot Can you please consider providing OpenThread Border Router (OTBR) "RCP mode" firmware images well as "NCP mode" firmware images (with support for the OpenThread spinel+hdlc+uart protocol) and preferably using the latest SDK for this Texas Instruments CC2652 based adapter so that it will be compatible with the "OpenThread Border Router Add-on" that Home Assistant developer agners (Nabu Casa employee Stefan Agner) is currently developing? Check out:

https://github.com/home-assistant/addons-development/tree/master/openthread_border_router

https://github.com/openthread/ot-br-posix/

https://github.com/agners

https://community.home-assistant.io/u/agners/summary

https://groups.google.com/g/openthread-users/

OTBR should be a "Thread Certified Component" Texas Instruments CC2652 based chips:

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

https://training.ti.com/thread-cc2652-cc1352

The main reason for this request is that an "RPC" firmware with OTBR (OpenThread Border Router) support will make your adapter will be compatible with upcoming Thread based "Matter" (Project CHIP / Connected Home over IP) devices if used in Home Assistant with their other add-ons for the that is also in development. This addon by agners requires that the radio hard a firmware in "RPC" mode instead of the no traditional "NCP" mode:

https://github.com/home-assistant/addons-development/tree/master/chip_controller_repl

https://github.com/home-assistant/addons-development/tree/master/chip_tool

https://github.com/project-chip/connectedhomeip

https://buildwithmatter.com

https://csa-iot.org/all-solutions/matter/

Also having optional OpenThread "NCP" border router firmware would allow users to alternatively use other existing OpenThread applications that use "NCP" mode instead of the newer "RPC" mode which require additional component running on the host. Ex:

https://github.com/openthread/wpantund

Note that so far agners has only worked with Silicon Labs based adapter with OpenThread "RPC" firmware for Thread based Matter (as well as ESP32-C3 based devkit for Matter over WiFi) and that is only because it is a Silabs EFR32MG21 chip based adapter that will ship inside the official Home Assistant Yellow (formerly Home Assistant Amber) hardware:

zigpy/zigpy#894

https://github.com/home-assistant/addons-development/tree/master/silabs-multiprotocol

https://www.home-assistant.io/blog/2021/09/13/home-assistant-yellow/

https://www.crowdsupply.com/nabu-casa/home-assistant-yellow

PS: By the way, you might be interested in the the "Matter" workshop that Home Assistant is holding on the 15th of June even if they are in that specific workshop will not use a Thread based controller or devices and instead use a WiFi (+ Bluetooth) based "Matter" devices:

https://www.home-assistant.io/blog/2022/05/29/matter-in-home-assistant-workshop-announcement/

https://www.youtube.com/watch?v=9fOHBl5w0_k

https://community.home-assistant.io/t/matter-in-home-assistant-workshop-announcement/426129/

We recently bought one of these devices on tindie (order 315091), and we cannot get it working. When we connect it to ethernet and power, it sometimes get's an IP address, and sometimes not. It does show up on our router (so I can see it's MAC address) - but it seems it stops working pretty fast cause most of the times it doesn't even complete DHCP. I've never been able to ping the device, and it does not listen on port 23. I've also not been able to flash the device - no matter which of the flashing instructions I try to follow, I get the following error:

Invoking bootloader by method 1 (default) // <- or method 3 if I use the --invoke-bootloader 3
Opening port COM3, baud 500000
Reading data from .\CC1352P2_CC2652P_launchpad_coordinator_20220219.hex
Your firmware looks like an Intel Hex file
Connecting to target...
ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)'

I'm kind of stuck at this point, and need some help to continue.

I have 2 zigbee coordinator in the same local network (one in home, one in the garage, but at a great distance from each other).
They are configured with static IP (.31 and .32) with 2 container in QNAP system (zigbee2mqtt-garage and zigbee2mqtt-soggiorno), I have HA Core installed on docker (2022.7 version).
Sometimes, randomly, one container crashes and fall off. So I must restart the container and it works properly, until it crashes again and so on. This fact happens about 1-2 times a day for the coordinator of the garage and 1 time every 2-3 days for the coordinator of the home. I tried to change channel (even if the two zb net are far), but the problem remains (now I have ch 11 for the garage and ch 15 for the home). The broker obviously is the same and the thing that change is the port of the frontend, so I can reach the page of the two z2m.
The firmware of the coordinator are these:

• revision coordinator soggiorno 20211217
• revision coordinator garage 20220219

I even tried to erase and redo the containers, with no results. I don't know what to do...
Thanks for the help.

Please consider adding Zeroconf support to Gio-dot Z-Bee-Duo Ser2net WiFi Adapter firmware for automatic ZHA network discovery.

Home Assistant OS (formerly HASSIO) support automatic network scanning and “Service Discovery” via Zeroconf and when a whitelisted Zigbee serial gateway is discovered it can pass along that to a domain like the ZHA integration component in Home Assistant.

For more details see:

https://community.home-assistant.io/t/zha-automatic-discovery-of-zigbee-coordinator-bridges-gateways-ethernet-wifi-network-devices-that-support-zeroconf-or-ssdp/293300

As a proof-of-concept this is now supported by Tube's Zigbee gateways (based on ESPHome firmware):

https://www.home-assistant.io/integrations/zha#discovery-via-usb-or-zeroconf

https://github.com/tube0013/tube_gateways

Once support for Zeroconf has been added to the firmware you also need the firmware to provide DNS TXT records for passing along setting parameters to integration config flows.

DNS TXT records could be used to pass along recommended settings parameters config flow to Home Assistant's ZHA integration:

radio_type=znp
baud_rate=value
data_flow_control=software
tcp_port_serial_gateway=value
Zeroconf DNS TXT records could also be used to pass along hostname, versions, location, MAC address, and more, etc..

http://www.zeroconf.org/Rendezvous/txtrecords.html

https://en.wikipedia.org/wiki/Zero-configuration_networking#DNS-based_service_discovery

https://en.wikipedia.org/wiki/TXT_record

More information about idea of using DNS TXT records for passing along setting parameters in https://github.com/thegroove/esphome-zbbridge#1 and https://github.com/thegroove/esphome-zha-ezsp-zeroconf

For a few weeks I have been recording random disconnections of the z-bee duo adapter. About 2/3 times a day after years of perfect operation.

puddly and agners have implemented a new zigpy packet API and native tcp:// protocol that the ZHA integration will not be able to use.

Their new tcp:// protocol will allow the ZHA integration and zigpy radio library/libraries to communicate with the radio using TCP/IP which should make for a much faster and more stable connection over a network in theory.

Could you maybe look into implementing this in your ESP firmware builds as an alternative to tunnelling via the ser2net style serial stream server with socket:// protocol (using pyserial)?

This has been implemented in upstream zigpy-znp and bellows radio libraries but does not think it is yet available in ZHA integration(?).

See puddly's and agners's related work in zigpy:

zigpy/bellows#489

zigpy/zigpy-znp#179

zigpy/zigpy-znp#171

zigpy/zigpy-deconz#206

zigpy/zigpy#1043

Will you consider making CC2674/CC2674P/CC2674R and/or CC1354/CC1354P Zigbee adapters for developers and early adopters?

Check out this developer discussion in Koenkk's Z-Stack firmware repository -> Koenkk/Z-Stack-firmware#476

There is no community firmware from Koenkk yet but that is probably partially because no one made a CC2674 or CC1354 adapter yet.

Chicken or the egg, what comes first, early prototype adapters that Koenkk can test or firmware built in the blind?

FYI, E72-2G4M20S1C (CC2674P10) radio module from Ebyte/Cdebyte is already available for prototyping and first-to-market devices:

https://www.cdebyte.com/products/E72-2G4M20S1C

According to LSagiroglu this new CC2674P10 based module is is pin to pin compatible with their CC2652P based module:

https://www.cdebyte.com/products/E72-2G4M20S1E

PS: No news so far from RFstar if they are working on CC2674P or CC1354P radio modules yet.

Hello!
I am using a zbee duo with ESP wifi module.

I recently changed my ip class from 192.168.1.0/24 to 10.10.0.0/27 but the device is no longer connecting to the wifi nor getting an IP.

I tried to re-add the network using the fallback option but without luck.

Do you have any idea what is causing this issue?

thanks Mario

FYI, Koenkk has now uploaded an experimental firmware for CC2652P/CC1352P with a default set to 9 dBm (and a max of 20 dBm):

Koenkk/Z-Stack-firmware#323

He mentions in Koenkk/zigbee2mqtt#8885 that he does not have RF measurement equipment so cannot confirm RF output power.

Would be great if you can test and verify Koenkk experimental firmware for CC2652P configurable up to 20 dBm TX power output.

I've been having Wifi issues with a Pi Zero with a Z-Bee Duo attached to it. What I see is noticeable lags and drops when connecting over SSH. As well, the mqtt connection between my broker and zigbee2mqtt running on the zero will drop typically every hour or two. Unless the connection drops entirely, pings look fine. I ended up having to add a script that reboots the Pi when it can't ping the router, but that's a temporary fix at best.

At first, I figured it was an issue with my wifi network config (I have Unifi APs), but eventually I discovered that if I removed the hat that latency as measured by https://github.com/jacobsa/ssh_ping dropped significantly. I put it back on and the wifi issues came back. I was only able to test with it off for a few hours, so I'm not 100% sure I've identified the issue.

My next step is to connect the hat over USB instead, but I was short a USB OTG cable.

Has anyone else encountered issues like this? Any other ideas?

Greetings,
I had a CC2531 coordinator with 40+ devices and all used to work properly.
One day I decided to switch to a more powerful coordinator and I bought this Z-Bee-Duo from Tindie (a couple of weeks ago).

I flashed it to work with z2m based on the information provided here and on z2m website.
After two three times of restarting z2m, rebooting host etc, it started working without any need to re-pair my devices.
But then I noticed the network doesn't work properly (even main powered devices).
On top of the general occasional issues, a few Aqara devices started to act stranagely. Even after re-pairing, they work for half an hour, and then they stop refreshing and never get connected back to the network.
I had recently added 6 smart plugs (and thought they might be the problem), so on my latest debugging, I turned them all off and even removed then from my network (on z2m ui). Then re-paired the problematic devices and verified their Lqi and they were all good (as always). They got connected directly to the coordinator (I got this information by looking at z2m Map in ui). But again after 20-30 minutes they don't work any more. I am a bit tired of the amount of time I am spending on this. Can you guys give me a help how to debug or find a way to fix the issue?
By the way, there is no wifi-zigbee interference issue (as wifi is forced to use another band; also checked neighbours' wifi with wifi-analyzer). Also I already used a cable to attenuate potentially usb3 inteference.

Home Assistant: 2021.9.5 on Rpi4
Zigbee2Mqtt: 1.21.2-1
Coordinator: Z-Bee-Duo
Repeaters: Sonoff zbmini x12 pcs around the house (they are actually wall switch with repeater capability)
End points: Aqara sensors, Sonoff sensors and buttons, Ikea remote

Any help would be appreciated.

Please consider switching the design to a other USB-to-Serial converter chip with its own writable EEPROM as a hardware feature.

This would allow you to add your own custom "Product Description String" as a unique identifier for it via the USB interface, and the reason for wanting a unique identifier via the USB interface is in order to enable the possibility for it to support automatic USB discovery of Zigbee USB adapters.

The whole point of this is to make it possible for developers to make the initial installation of Zigbee solution plug-and-play friendly and easier for different home automation software to automatically USB discover and initiate a setup without end-user interactions.

Support for USB discovery was recently added to Home Assistant OS (formerly HASSIO) and the ZHA integration for it, see here:

https://community.home-assistant.io/t/unique-friendly-name-description-for-automatic-zigbee-usb-adapter-discovery-in-home-assistant-zha-using-dongle-vendor-product-ids/337077

That unique customized USB description string could be something like ex.; "Gio-dot Z-Bee-Duo CC2652P Zigbee Stick v2 hardware revision 2.0.0"

The unique "description" string for each USB adapter can then be added to HA via a PR like this -> home-assistant/core#56201

As I understand it, cheaper CH340 series (example CH340C and CH340E) by WCH which unfortunately does not support this feature.

I understand that more expensive chips like FT231 chips by FTDI and CP210x chips by Silicon Labs / Silabs do support this feature:

https://ftdichip.com/products/ft231xs/
https://ftdichip.com/products/ft231xq/

FT231X/FT231XS: "Key Hardware Features" "Fully integrated 2048 byte EEPROM for storing device descriptors and CBUS I/O configuration."

https://www.silabs.com/interface/usb-bridges/classic/device.cp2102
https://www.silabs.com/interface/usb-bridges/classic/device.cp2104
https://www.silabs.com/developers/usb-to-uart-bridge-vcp-drivers
https://www.silabs.com/documents/public/data-sheets/cp2102n-datasheet.pdf
https://www.silabs.com/documents/public/application-notes/an197.pdf
https://www.silabs.com/documents/public/application-notes/an978-cp210x-usb-to-uart-api-specification.pdf
https://www.silabs.com/documents/public/application-notes/AN571.pdf

"The CP2102N devices have the following features" "Internal 960-byte programmable ROM for vendor ID, product ID, serial number, power descriptor, release number, and product description strings"

"The CP2102N includes an internal electrically erasable programmable read-only memory (EEPROM). This memory may be used to customize the USB Vendor ID (VID), Product ID (PID), Product Description String, Power Descriptor, Device Release Number and Device Serial Number as desired for OEM applications. If the EEPROM is not programmed with OEM data, the default configuration data shown in the table below is used."

"Product String The Product String is an optional string that describes the product. It is limited to 126 characters."

PS: I understand that a bonus feature in of chips like FT231 and CP210x is to add the ability to allow users to auto-reset and put the device in bootloader mode via the DTR/RTS pins exposed will enable much easier firmware upgrades for the end-users as they will no longer need to press any buttons to enter bootloader mode, and then bootloader mode could be activated via software from the firmware flasher program software which could make the OTW (Over-The-Wire) firmware upgrade procedure more user-friendly.

Can this device be flashed with router firmware? It would be nice if it's flashed as router and connected to PI Zero and plugged anywhere in the house.

I have a Z-Bee Duo Ser2net wifi adapter. how do i change the wifi configuration. I have to connect to a new wifi line. I tried the "reset" and "flash" buttons but nothing

can you make the enclosure files available?

i had ordered one with an enclosure for the Raspberry PI Zero but now i upgraded to a pi 4 and have the device usb connected.

Hi,
I was using this great little thing (on wifi) for about a year now, without any issue.
It was advised to update zigbee controller firmware to use a new device I've added to my network, so did I.
I followed the instructions (rev C, ebyte), and it seemed to work fine: no error message and command ending with "Verified (match 0x....)".

Unfortunately, after rebooting, my zigbee network is down, it seems like no new state can be published.
Is there something I need to re-configure, maybe on the esplink side?

Hello,

Is it possible to have the esphome yaml configuration file for the little wifi - ser2net module, in order to update it if needed?

thanks a lot