Replies: 9 comments 13 replies
-
|
Then Silabs have stop supporting software flow control its needed having hardware flow control for not getting suck in the future.
All is shaving the same hardware configurations and can being updated with standard bootloader (X-modem UART) or if implanting BT OTA. The soft and hardware can running Zigbee (EZSP), Thread (OTBR) and also BT like Zigbee-Direct or native BT if needed. I think its possible getting one very good platform for from simple application like NCP / EZSP and to one very potent Matter compatible controller. The problem in the end is the price for populating the components then if using to expensive its not possible selling it to your beloved customer. Best regards Mattias |
Beta Was this translation helpful? Give feedback.
-
FYI, WCH CH348 series are 8-port USB to serial chips with up to 48 GPIOs (it also has built-in writable EEPROM for product information ID). https://www.cnx-software.com/2022/03/04/wch-ch348-8-port-usb-to-serial-chip-with-up-to-48-gpios/ Btw, Silabs CP2104 USB to UART chip price has increased a lot which is why ITead/Sonoff went with WCH CH9102F in their new dongle. https://www.cnx-software.com/2021/09/14/ch9102f-a-replacement-for-cp2104-usb-to-uart-bridge/ The new WCH CH343 series (CH343G, CH343K, and CH343P) also offer similar minimum features as WCH CH9102F I think: |
Beta Was this translation helpful? Give feedback.
-
|
Also read there that ESP USB Bridge project can convert ESP32-S3 into a USB to JTAG bridge / debugger probe which could be another use case for developers: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @MattWestb :)
Concept design...
|
Beta Was this translation helpful? Give feedback.
-
Looks great !!And as normal very flexible :-)) About CH340: I have running 2 Billy RCP on 2 RK3228 / RK3318 boxed with OTR RCP firmware is using the same bootloader as NCP / EZSP so can doing it with comport but i think Silabs is doing more fixes for getting native thread OTA for there devices. Have you finding one good cheep ESP32 with good form-factor for the board ? |
Beta Was this translation helpful? Give feedback.
-
|
Ah, was thought that you where making a USB-adapter only and not a LAN/network-gateway style adapter |
Beta Was this translation helpful? Give feedback.
-
|
Is it one place for ESP8266 module for "budget" version on the under side or is it one BT module ? By the way nice placed RF modules in the under side in the corners and 90° angle between them = by the book :-))) I think you is getting most or all possible you is needing for new projects but i hope its not being too expensive for your customers then producing the device. |
Beta Was this translation helpful? Give feedback.
-
Do not the commonly used CH340E as it does not have built-in EEPROM for writing product information string for the USB which is needed for USB discovery, so instead look at CH340B, CH343, or CH9102F as all those have built-in writable EEPROM. USB discovery provides some needed user-friendly plug-and-play experience magic! https://www.home-assistant.io/integrations/zha#discovery-via-usb-or-zeroconf https://www.home-assistant.io/integrations/usb/ https://www.cnx-software.com/2021/09/14/ch9102f-a-replacement-for-cp2104-usb-to-uart-bridge/ Or as mentioned above, the WCH CH348 series are 8-port USB to serial chips with up to 48 GPIOs (it also has built-in writable EEPROM for product information ID) so could be used if want to offer developers direct USB-to-Serial access to all radio modules on the board: https://www.cnx-software.com/2022/03/04/wch-ch348-8-port-usb-to-serial-chip-with-up-to-48-gpios/ |
Beta Was this translation helpful? Give feedback.
-
|
hmm, I am assuming that you wish to make your product stand out a little to compete on different terms with existing Silicon Labs based Zigbee Coordinator adapters on the market today, like ITead’s “Sonoff Zigbee 3.0 USB Dongle Plus V2” (model “ZBDongle-E”) and Home Assistant SkyConnect USB Stick As far as marketing goes when selling to the home automation enthusiast userbase (e.g. Home Assistant, OpenHAB, Domoticz, Jeedom, Zigbee2MQTT, IoBroker, Tasmota2Zigbee/Tasmota) but still attractive looking so would also appeal to beginners then you might want to consider calling it something "Pro", such as the example "Brand-X Mesh Controller Pro" (e.g. "RobOz Mesh Controller Pro" or "Ozwiz Mesh Controller Pro"). First, consider making it a crowdfunding campaign on Indiegogo or Kickstarter, or alternatively on Crowd Supply (which is very niche so do not expect to get a large amount of pre-orders if you choose to go with Crowd Supply instead of Indiegogo or Kickstarter). Regardless, if you decide to do a crowdfunding campaign then you will still need to actively spread the news yourself if you also want a lot of pre-orders and not just technical ideas/feedback/input from geeks like us ;) Then I would think about what features would make it a "Pro" product compared to the existing and alternative products on the market. Ideas that I personally would like to see in a "Pro" adapter:
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the excellent feedback and ideas list. Much appreciated. I'll absorb it in the morning ;) I've been using an Ethernet based system here for a few months so happy with the stability. I have about 100 devices online, some 50-70m away, running commercial and my own firmware. So ready for some final design and a small production run of a 100 or so devices. |
Beta Was this translation helpful? Give feedback.
-
|
Oh, and enclosure has wall mount option... |
Beta Was this translation helpful? Give feedback.
-
|
I hope the mounting and screws is not blocking the RF from the chip. I think Gary is making one mounting that is not blocking RF (no metal shielding). And i think only 5V power supply is good enough only finding one good IC and making it delivering enough amps stable for your needs (some extra large caps with > 16 V rating). |
Beta Was this translation helpful? Give feedback.
-
|
Good point on power supply. Will look into that. Need at least 1A at 5V... big caps too! |
Beta Was this translation helpful? Give feedback.
-
|
What i remember for the school shall one 5V system heave elyte caps rated 100% = 10V but i think its better using 2 or more parallel and using 16V or higher but in the end is one question on place on the PCB and not so much the end cost of it. Was reading little more on the open thread and and ESP8266 and ESP8285 chip is not supported for matter then is using old SDK but all ESP32 can doing the WiFi and BT things for the matter part = OK only that newer ESP32 versions with 154 radios cant being used with Solabs software then Silabs have changing to its own cunurrent protocol so can using RCP and NCP on the same chip and tunneling all to the host system. Make routing of the PTI pins from the MG24 module to one hardware SIP port on the ESP32 so it can being used in the future for sniffing traffic then have "finding" how Silabs / Seggers have making it we can using it as one very advanced 154 network analyzer. What i have seen your proposal have all you can need for man years if you is getting all working together and getting one good price for producing it in scale for your lab and customers. POE i think its better using one cheep CE (not Certificate Europe but China Export) POE adapter with normal power plug or USB then its needed but if demand i think one enchanted version can being good but not as first generation and also POE have much problems if not the POE switch and cable is working OK and you is getting the problems in your system. If you can implanting analog reading for the system 5V and 3.3 V for detecting if getting problems with the power from the POE and / or USB / power plug (i think ESP32 have multiple Analogue input that can being used for it purposes but need correct resistors and caps for getting OK reading) and also is the sampling time very interesting (or one cheep power control chip that can flagging "dirty power"). If you need some Alpha or Beta tester you have my mail address ;-)) Edit: If you is having free pins on the ESP32 also routing the SWD pins for the Zigbee module so can using Seggers RTT for debugging and also console and if the hardware is supporting it flashing the EFR32 can being possible with the right implementation of hard and software and the cost routing them is not large then the design is not frozen but is expensive making it later and if not working it was not so bad. |
Beta Was this translation helpful? Give feedback.
-
|
FYI, Home Assistant 2022.9 and later in combination with the latest ESPHome firmware for ESP32 has now got Bluetooth Proxy (ESPHome Remote Adapter) support for Home Assistant's Bluetooth integration so might want to consider shipping it pre-installed with ESP32-S3 with WiFi disabled but Bluetooth enable and perhaps even with a dedicated external antenna for Bluetooth via ESP32-S3? That ESPHome Bluetooth proxies feature can in some cases make Bluetooth devices almost as easy to use as Zigbee devices: https://www.home-assistant.io/blog/2022/09/07/release-20229/#bluetooth-everywhere https://www.home-assistant.io/blog/2022/08/03/release-20228/#first-class-bluetooth-support https://www.home-assistant.io/integrations/bluetooth/#remote-adapters https://esphome.io/components/bluetooth_proxy.html https://esphome.github.io/bluetooth-proxies/ https://digiblur.com/2022/09/07/home-assistant-esphome-bluetooth-proxy-how-to/ |
Beta Was this translation helpful? Give feedback.
-
|
At this stage ESP32 is on board, cost is minimal for power and convenience! So excellent point on the HA Bluetooth integration, though I've not had much time to evaluate it. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
I believe that Zigbee-to-Matter bridges are going to be in high demand in the next few years before native Matter compatible Thread devices become commonly available at as low price that Zigbee devices are at today, and I think I'm not the only one who believes so. https://github.com/project-chip/connectedhomeip/tree/master/examples/dynamic-bridge-app Matter 1.0 standard has now been released and "IoT-protocol-XYZ to Matter bridges" will for the next upcoming years be much more important than Matter-native devices as it will then be easy for people to add their existing third-party non-Matter devices to for example Google Assistant, Amazon Alexa, and Apple HomeKit or other ecosystems via a common Matter fabric by using a bridge. https://csa-iot.org/newsroom/matter-arrives/ https://github.com/project-chip/connectedhomeip/releases/tag/v1.0.0 For example, Philips and IKEA have already announced that they will make their existing or future Zigbee hubs also act as a Matter bridges. Check out Silcon Labs notes on their bridge concept with "Unify SDK" from Silicon Labs as a reference for ideas as it also depends on MQTT: https://www.silabs.com/blog/matter-1-0-is-here-does-reality-meet-expectation The Important Role Bridging Plays in MatterThis simplicity and ease of adoption has been dominating Matter coverage – and with good reason. The catalyst for these brands coming together in the first place was the realization fragmentation meant that for a lot of consumers, the smart home just wasn’t working. However, if Matter succeeds in getting buyers comfortable purchasing and setting up new products but misses by making it difficult to adapt existing devices by customers with lots of devices already, it wouldn’t really fulfill its promise. With a large existing install base of Zigbee, Z-Wave, and other wireless IoT protocols, bridges will be a key aspect of connecting Matter to these devices to integrate the technologies and bridge existing sensor networks to interoperate with Matter networks. The vast majority of existing devices will not be moving to Matter. Instead, they will be able to communicate with the Matter network via a bridge. Many IoT manufacturers are already planning on being able to update existing gateways to support Matter bridging and will be introducing products to support both existing and deployed Zigbee/Z-Wave products, in addition to the newer Matter products. https://www.silabs.com/blog/bridging-non-matter-devices-to-a-matter-network Bridging Non-Matter Devices to a Matter NetworkThis is shaping up to be a big year for Matter, which aims to reduce fragmentation across different vendors and achieve interoperability among smart home devices and Internet of Things (IoT) platforms from different providers. It will do this by defining a common application layer using Internet Protocol (IP) that delivers interoperability among devices regardless of the underlying network protocol. A new Matter device can be controlled and be part of multiple ecosystems at the same time. For example, a light bulb can connect to both Amazon Alexa, Google Home, and Apple HomeKit. This means consumers will be able to add new products and brands to their smart homes without additional effort trying to figure out if X works with Y. With Matter, it just works. ... What is Bridging and Why is it Needed?With a large install base of non-IP based Zigbee, Z-Wave, and other wireless IoT protocols, bridges will be a key aspect of connecting Matter to these devices to integrate the technologies. Although some end devices could meet the requirements (such as sufficient flash and RAM) to be upgraded in-field, it will be simpler, more stable, and a better user experience to bridge existing sensor networks to interoperate with Matter networks. Many IoT companies, including Silicon Labs, will be introducing bridging products that will support both existing and deployed Zigbee/Z-Wave products, in addition to the newer Matter products. Matter uses Bluetooth Low Energy (LE) for commissioning and runs over Wi-Fi, Ethernet, and Thread protocols. Before understanding what a Matter bridge is, it’s important to have an understanding of Thread, an underlying network protocol to Matter. What is Unify™ SDK?Silicon Labs' Unify SDK simplifies IoT infrastructure development including gateways, access points, hubs, bridges, and application processor-based end products. Each Unify SDK component implements an MQTT interface to the unified language which is based on Dotdot. Its a modular, extendible, lightweight, and well-defined interface for system integration. Unify SDK natively runs on Linux but is architected for portability. The Unify-Matter bridge application, which is part of Unify SDK, is based on the Matter Bridge Application software from CSA. The application receives the ZCL commands on the Matter protocol interface and translates to Unify Controller Language data model and publishes to an MQTT interface. How Does the Matter Bridge Work?A Matter bridge device extends connectivity to non-Matter IoT devices in a Matter fabric. It enables the consumer to keep using existing non-Matter devices such as Zigbee and Z-Wave devices together with new Matter devices. These non-Matter devices appear as bridged devices to the Matter fabric. The Matter bridge performs the protocol translation between Matter and Zigbee / Z-Wave network devices using Unify SDK. The diagram below shows both connectivity between Thread network and Matter fabric as well as Matter to non-Matter networks like Z-Wave / Zigbee using a bridge device. The illustration below shows the Matter network as a unified solution for a Smart Home:
https://www.silabs.com/developers/unify-sdk Unify Software Development Kit (SDK)Unify SDK simplifies IoT infrastructure development including gateways, access points, hubs, bridges, and application processor-based end products. Unify SDK is a software framework that simplifies the developer experience, removing difficult parts of network control and network management as it relates to gateway and hub development in IoT applications. It can also provide Matter bridge functionality to other protocols that do not natively run matter. Unify SDK is developed as an open, modular, and portable architecture based on ubiquitous lightweight MQTT technology. The software framework is designed and developed on the application processors running POSIX compliant OS, such as Linux. It provides an extensible set of software features to enable IoT wireless connectivity in gateways, multiprotocol scalability and application processor-based end products. Unify SDK simplifies development and ongoing software maintenance for IoT gateways and application processor-based end devices. The Unify SDK provides software source and binary packages for Raspberry Pi 4. It facilitates the easy development of an IoT gateway based on the Unify SDK architecture. Unify SDK provides common building blocks that ease connectivity across IoT ecosystems.
Unify SDK Features and Benefits
Espressif (who makes ESP32) is also going all in on this concept and has presented Matter-Zigbee and Matter-BLE Mesh bridge solutions: https://medium.com/the-esp-journal/matter-bridge-for-non-matter-devices-d3b7f003a004 https://blog.espressif.com/matter-thread-border-router-in-matter-240838dc4779 https://docs.espressif.com/projects/esp-matter/en/main/esp32/index.html https://docs.espressif.com/projects/esp-matter/en/main/esp32/ https://github.com/espressif/esp-matter/tree/main/examples/zigbee_bridge https://github.com/project-chip/connectedhomeip/tree/master/examples/lighting-app/esp32 https://www.espressif.com/en/news/ESP_Matter_Solution https://www.espressif.com/en/solutions/device-connectivity/esp-matter-solution https://github.com/espressif/esp-matter "We offer both Matter-Zigbee and Matter-BLE Mesh bridge solutions with full functional software SDK support. A Matter-Zigbee Bridge uses two SoCs (Wi-Fi + 802.15.4), they are connected via a serial interface like UART or SPI, while a Matter-BLE Mesh Bridge can be done on single SoC with both Wi-Fi and BLE interfaces."
It seems like Espressif are currently focusing on embedded Zigbee gateway and Zigbee/Thread to Matter bridge implementation (with an all-in-one two-SoC gateway/bridge solution combining a ESP32-H2 for Zigbee/Thread with an ESP32-S3 for Wi-Fi): https://github.com/espressif/esp-thread-br#hardware-platforms https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_br https://openthread.io/guides/border-router/espressif-esp32 Hardware PlatformsThe ESP Thread Border Router consists of two SoCs:
ESP Thread Border Router BoardThe ESP Thread border router board provides an integrated module of an ESP32-S3 SoC and an ESP32-H2 RCP.
The two SoCs are connected with following interfaces:
Standalone ModulesThe SDK also supports manually connecting an ESP32-H2 RCP to an ESP32 series Wi-Fi SoC.
The following image shows an example connection betwe Add a package diagram. ES32-H2 and ESP32:
In this setup, only UART interface is connected, so it doesn't support RCP Update or RF Coexistence features. You can refer to ot_br example in esp-idf as a quick start. https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_br https://openthread.io/guides/border-router/espressif-esp32 Provided FeaturesThese features are currently provided by the SDK:
In the future releases, the following features will be added:
|
Beta Was this translation helpful? Give feedback.
-
|
I bet a few people would also suggest an optional model with PoE (Power over Ethernet) but I know that drives cost and EMF for FCC testing. https://en.wikipedia.org/wiki/Power_over_Ethernet That is why a few mnakers build products based on Olimex ESP32-POE-ISO or the LILYGO TTGO T-Internet-POE boards. Tubeszb has for examle has an PoE model based on Olimex ESP32-POE-ISO https://twitter.com/TubesZb/status/1394478007730020352 https://twitter.com/TubesZb/status/1394845581823074308 ZigStar has ZigStar LilyZig POE based on LILYGO TTGO T-Internet-PO https://zig-star.com/projects/zigstar-lilyzig/ Electrolama has Zoe2 which is not a stand-alone product but instead a HAT/Shield for Raspberry Pi: |
Beta Was this translation helpful? Give feedback.
-
|
Another suggestion for this product would be to also add a Z-Wave 800 radio module or Z-Wave 700 radio module from Silicon Labs too: https://www.silabs.com/wireless/z-wave/800-series-modules https://www.silabs.com/wireless/z-wave/700-series-modules Z-Wave can for example be used with the official Z-Wave JS integration for Home Assistant: https://www.home-assistant.io/integrations/zwave_js/ And I believe more Z-Wave JS users use the stand-alone implementation "Z-Wave JS UI" (full-featured Z-Wave Control Panel and MQTT Gateway) with other DIY setups such as Node-RED, IoBroker, Domoticz, Jeedom, etc. https://github.com/zwave-js/zwave-js-ui I think there could be a market for it as there are no other network-attached Z-Wave Controller adapters available and the Z-Wave JS integration for just Home Assistant is for example used by more than 10% of the Home Assistant user base: |
Beta Was this translation helpful? Give feedback.
-
|
@Hedda - There is provision for an add-on module with a serial interface. So Z-Wave can be added if required. |
Beta Was this translation helpful? Give feedback.
-
Byw, liked the DIY solution by tube0013 solved the missing Z-Wave Controller problem by offering a Raspberry Pi GPIO converter adapter: https://tubeszb.com/product/z-wave-poe-kit/ https://tubeszb.com/product/raspberry-pi-gpio-to-olimex-uext-for-z-wave-adaptors/ TubesZW??? Almost, but not quiteThis kit does not contain a Z-Wave radio! This product is a kit, it contains a pre-flashed Olimex ESP32-PoE with ESPHome firmware to use as a TCP serial port, a 3d printer enclosure and Raspberry Pi GPIO to Olimex UEXT adapter, which allows the the Z-Wave modules made for the Pi’s gpio pins to work with the ESP32-PoE. Tested and confirmed working with the zwave.me Razzbery Pro 7 and the Zooz Long Range 800 (ZAC93-93-Module). Unfortunately due to the complications of different radio frequencies globally I do not plan to sell the z-wave radios myself. Purchase Links: (Affiliate Links) Other modules built for the Raspberry Pi’s gpio pins will likely work but may not be compatible with the enclosure. Requites use of the Z-Wave JS UI or the Z-Wave JS UI Home Assistant Addon Set up is as simple as entering the IP address of the ESP32-PoE and port as the serial port in the Z-Wave settings – tcp://IP_ADDRESS:6638 |
Beta Was this translation helpful? Give feedback.
-
I am designing a new Zigbee Coordinator for a customer and wanted to take the opportunity to add extra functionality for the Home Automation users - so I can make more to reduce the costs.
What would be a "wish list" or "nice-to-have" for a Mesh Device Controller?
In repository comments I see requests for USB C, Ethernet, NCP, RCP, Multiprotocol, etc...
Beta Was this translation helpful? Give feedback.
All reactions