That the Sonoff Zigbee temp sensor has no capability for FW upgrades is probably not a big issue. I would be more concerned if the Sonoff (mains) powered devices (like the S31 Zigbee Lite) which should all have the repeater functionality, have no capability to receive FW upgrades. Not sure if that is the case for all Sonoff Zigbee (mains) powered devices.
Does anyone knows that?
If only Sonoff’s Zigbee Bridge is able to receive FW updates, then that would be a big Con for their whole ZB platform
Btw, first time I heard about Terncy Hub, it looks like an impressive device, also Homekit compatible!
Do we know, is this Hub compatible as well with the Sonoff ZB sensors?
Do we need to buy a Sonoff Zigbee Bridge and leave it with stock firmware, for the purpose of OTA updates?
A better question would be if someone could convince ITead to make Sonoff Zigbee devices OTA firmware images download URLs public so that third-party Zigbee implementations can use them. IKEA and Ledvance/OSRAM already do so and that is why ZHA supports OTA for those by default. Read:
FYI, ITead has announced in a video that they will soon sell a Sonoff branded Zigbee 3.0 USB Dongle that is based the exact same Silicon Labs EFR32MG21 SoC as their Sonoff ZBBridge Zigbee Bridge
Note! Ember USB Zigbee adapters/dongles/sticks like these are highly recommended over using a remotely connected Ember module using a serial-to-ip bridge / serial forwarding server like ser2net.
https://github.com/zigpy/bellows#warning-about-zigbee-to-wifi-bridges
The reason Ember remote bridges over serial-to-IP proxy server is not recommended is that clients using the EZSP serial protocol requires a robust connection between the EmberZNet Zigbee stack running on EFR32 MCU and the serial port of the Zigbee radio. With solutions such as ITEAD Sonoff ZBBridge or a Ser2Net serial proxy connection over a WiFi network it is expected to see NCP entered failed state. Requesting APP controller restart in the logs. This is a normal part of the operation and indicates there was a drop in communication which caused packet loss to occurred between the zigpy radio library and the Zigbee radio. The use of serial network proxies/bridges/servers over WiFi is therefore not recommended when wanting a stable Zigbee environment with Silicon Labs Ember based Zigbee radios. The developers of the bellows radio library for the zigpy project has more information about this if needed.
1 Like
Ethernet will work fine. I’ve had my ebyte gateway up for over a month now with no disconnects/failures. @walt is stress testing an early version of my CC2652p2 based gateways and it has been rock solid. I will have CC2652p2 based serial over ethernet and some based on the SM-011 efr32 module as well as a higher end one based on the MGM12P32F1024GE-v4 module for sale shortly - all waiting on some shipments.
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.
@tube0013: would you have a few pics of what you are creating? Are you planning to bring it to market soon?
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.
this adventure started here: https://github.com/zigpy/zigpy/discussions/584
2 Likes
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.
2 Likes
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.
Again please read discussion in New Zigbee to Ethernet "DIY" Corrdinator · zigpy/zigpy · Discussion #584 · GitHub for more information.
when I wrote the above I was sort of thinking about the tuya hub in respect to the recent progress of rooting it and using it as a serial gateway.
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)?
By the way, are you creating your new Zigbee gateway such that it supports natively the Sonoff line of Zigbee devices?
@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.
OK Hedda, thanks for clarifying this to me. Very useful - I have a better understanding now how these concepts work 