Yes, I’ve been running the wired CC2652P2 gateway on my 120 node network and it has been great!
I migrated seamlessly from a ZZH and so far the network statistics have been slightly better on the wired gateway. Though to be fair, the wired gateway is farther away from the server so less RF interference and the ZZH is now also online in the network as a router (supports 50 children!) instead of as the coordinator.
Zero watchdog rests on the CC2652 gateway after the install. (The watchdog is a process in zigpy that will reinitialize the network on loss of connectivity with the stick or gateway). I’m running the gateway off a $29 Unifi Flex Mini switch though any Ethernet switch or your home router should work.
I’m waiting on some components, I only have one remaining for testing the board builds. Shipment has arrived in the US so it’s close. hoping to have a small quantity available for sale within the next few weeks. The picture above is of the CC2652p2 variant.
Looking great! Thanks for sharing.
Will it work with the Sonoff Zigbee devices?
What are the main specs of this custom gateway which stand out versus the standard Zigbee gateways currently available on the market from the likes of Sonoff, Tuya, etc?
It will be based on open source hardware, the ESP32 runs ESPHome and the PCB has headers for full debug access. to the zigbee modules. I plan to post the pcb schematics, gerbers, case .STLs and the ESPHome config to my github.
Wired ethernet is the number one feature for stability when compared to the Sonoff.
The esp is an ESP32 variant vs an ESP8266 in the Sonoff. The ESP32 has 2 hardware UART serial interfaces so there is good performance for both the ethernet and serial connection with the zigbee module. It is using ESPHome for the Serial to ethernet. being open source and open hardware one could add sensors or other things supported by ESPHome.
On the zigbee side, for the EFR32 SM-011 modules - they will be flashed with non locked down firmware allowing for firmware upgrades when new/bug releases come from Silicon Labs. - without having to wait on signed firmware like in the sonoff bridge (unless you SWD flash the non locked bootloader).
Vs the Tuya gateway. this is built specifically for ZHA (ether variant) or Zigbee2mqtt (the cc2652p2 variant). The tuya also has a relatively low powered zigbee radio when compared to these. it’s a EFR32 but only has 32k of ram available. The SM-011 has 64k of ram. The other EFR32 module I will use in the higher end “Pro” model has 256K ram. these affect the number of children/routes supported by the coordinator.
The “Pro” EFR32 gateway will also have an onboard USB-to-serial converter so you could run it as a coordinator over USB if wanted, you would just need to change 2 jumpers.
You should not compare a Zigbee serial-to-network like that with other “Zigbee gateways/bridges” which run their own hub/controller software which abstracts away the fact that devices are using Zigbee.
When installing Tasmota or ESPHome and configured it to act as a serial server-bridge then the only thing that will matter to ZHA and Zigbee2MQTT is which SoC and antenna of the Zigbee coordinator.
You need to understand that is that when simply connecting to a remote Zigbee coordinator to ZHA or Zigbee2MQTT they will act just as a Zigbee coordinator that locally connected directly via USB or serial.
Know that when flashed with standard Zigbee coordinator firmware and Tasmota or ESPHome is configured to act as a serial server-bridge you don’t use any third-party gateway/hub software on them. The serial server-bridge only facilitate a transparent pass-though tunnel that blindly transfers the serial communication between both sides without modifying the data stream in any way.
This is the same as setting up a Ser2net connection between two computers to allow one computer to connect to another computer’s serial-port. The remote computer will only act as serial-to-network bridge.
The application that actually utilizes the Zigbee coordinator will not know that is not a local device.
That means that other than the connection is relying on the stability of your network the Zigbee coordinator will otherwise not function any differently from a locally connected Zigbee coordinator.
I fully understand that you go for a wired ethernet connection, also definitely my preference. But have you considered also to add WiFi for the LAN connction?
In certain cases WiFi connectivity can come in handy as well if at the location where you prefer to place the Zigbee Hub it is not that simple to get a LAN cable available (without opening ceilings/walls).
This is what attracted me to the sonoff bridge last summer. But having watched discord and GitHub and seen various issues where the common factor is the bridge, and to me it’s either the WiFi and/or the unknown settings of the signed firmware provided. I’m not going to ship gateways with WiFi enabled as I don’t think it is ideal.
Saying that, the board will run on ESPHome the config will be in my GitHub so anyone who want to enable WiFi can do so on their own.
I am not testing or evaluating my designs to be utilized for WiFi, I oriented the radio modules at 90 degrees to the ESP/WiFi to try and reduce 2.4ghz interference but cannot guarantee there won’t be interference with WiFi running.
OK, I understand your considerations and agree that the WiFi connectivity of many home automation hubs is a source of trouble, bcs of its instability every now and then/interference issues in the 2.4 ghz band.
That’s probably also the main reason the Hubitat Zigbee/Z-wave hubs are having hard-wired LAN port and no Wifi.
Do you have any experience with the Hubitat hubs and their latest version (C-7)?
@Marc_Sway Please read my explaination above again as you are asking the wrong question and I tried there to explain there that the bridge hardware by tube0013 is not a stand-alone hub/controller when using ESPHome with serial server. It will simply act as a proxy for the Zigbee module and replays its serial-port to a other software via socket like ZHA or Zigbee2MQTT, and what Zigbee devices those applications in turn nativly support in entirly up to them, (both does however support Sonoff Zigbee devices). Again you can not compare this to stand-alone hubs/controllers like example Hubitat.
I do know that Aqara Zigbee water detection sensors work with Sonoff Zigbee Bridge.
Has anybody tried to use a Sonoff Zigbee Door Switch, by opening that device and instead of the reed contact in there, solding 2 wires to the connection points and use those 2 connected wire leads to detect water?
I really would like to know if modifying a standard Sonoff Zigbee door switch can be used then as a water sensor.
Based on all the available information, the Sonoff Zigbee Bridge appears to be a lost cause.
Zigbee devices repeatedly come unpaired because data packets get lost or missed in the wifi-to-zigbee link, inside the Sonoff Zigbee Bridge. It sounds like a fundamental architecture flaw, which likely means it’s not fixable without a new version of the Sonoff Zigbee Bridge hardware being created.
I note the warning in the brown box on this page:
This week, I removed the Sonoff Zigbee Bridge and moved on to using a CC2531 USB stick coordinator.
Thus far, there have been zero instances of Zigbee devices coming unpaired.
