Git Product home page Git Product logo

openz3gateway's Introduction

不建议不准备pr的朋友fork啦,我还在维护这个项目,未来会有新功能或者修复的,不要错过

OpenZ3Gateway

An open source Zstack3 gateway powered by ESP8266 and CC2652P modules. One costs less than 60 CNY in China.

image image image

This repository includes

  1. Altium Designer schematic and PCB files
  2. Schematic and PCB in PDF
  3. Gerber files
  4. A lite Arduino Ser2Net project for ESP8266 based on https://github.com/dparnell/esp8266-ser2net

Usage

  1. Send the Gerber file to PCB factory for production
  2. Buy the components you need
  3. Solder them
  4. Flash the CC2652P with the latest "CC1352P2_CC2652P_launchpad_coordinator" coordinator zstack firmware
  5. Compile and upload the Ser2Net project to ESP8266.

Note: Jumper caps are needed to choose the function of the board.

About The 2.54 Ports

  • The 2x7 IDC port will be used to connect to my MT7621 OpenWrt Gateway project.
  • The 2x10 IDC port can be directly connected to the XDS110 port, this board can be a cheap CC2652 multi protocol development board too.
  • The two 1x6 XH2.54 port are used to connect my CH340C auto-upload circuit board, which will be opened too.

Why Not USB?

  • Of course this board can be used as a USB "stick"! You can connect my CH340C auto-upload circuit board project to the XH2.54 port of CC2652 module and adjust the jumper caps. Then you can use it as a "stick" like ZZH.
  • The other reason is you need powerful ZigBee routers if your house is too large. An ESP8266 will help you manage the routers easier, you can reset the nodes by ESP8266 easily.

Boo

I'm too lazy to list a BOM, please check the schematic for components list.

openz3gateway's People

Contributors

cyijun avatar imgbotapp avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

openz3gateway's Issues

[REQUEST NEWER HARDWARE] CC2674 (CC2674P/CC2674R) and CC1354P (CC1354P) Zigbee Coordinator and Zigbee Router adapters?

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.

[REQUEST] OpenThread Border Router (OTBR) RCP and NCP firmware images for CC2652R based cyijun OpenZ3Gateway adapter?

@cyijun 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

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:

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/

[REQUEST] Zeroconf support to OpenZ3Gateway for Home Assistant ZHA network discovery

Please consider adding Zeroconf DNS TXT Reconds parameters in firmware for automatic ZHA network discovery but only enable it when running in "Zigbee Home Automation Mode".

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 context about this Zigbee gateway “Service Discovery” via Zeroconf for the ZHA integration in Home Assistant, please 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

and

https://developers.home-assistant.io/docs/creating_integration_manifest/#zeroconf

FYI, there is already a working 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.

You first need to add Zeroconf service and give it name and as well as adding information about protocol (tcp) and port (????), etc.

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

version=1.0
radio_type=znp
baud_rate=value
data_flow_control=software

I believe that is advertised for Zeroconf config in this format or similar (though is obviously for emberznet "ezsp" instead of zstack "znp"):

zha_ezsp_zeroconf  _ezsp._tcp  local
   hostname = [zha_ezsp_zeroconf.local]
   port = [8080]
   protocol = [tcp]
   service = tubes_zb_gw
   txt = ["version=1.0"]
   txt = ["radio_type=ezsp"]
   txt = ["baud_rate=value"]
   txt = ["data_flow_control=software"]

(use e.g. avahi-browse -r -a to see this)

As can see, you will need one DNS TXT Record for each attribute and value that is to be passed along to HA's ZHA integration.

Zeroconf DNS TXT records could also be used to pass along info about 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

In the end it is probably best to see actual example config for ESPHome as in Tube's Zigbee Gateway as that is the reference:

https://github.com/tube0013/tube_gateways/blob/main/V2_tube_zb_gw_cc2752p2/ESPHome/tube_zb_gw_cc2652p2v2.yml

zeroconf:
  - service: tubes_zb_gw
    protocol: tcp
    port: 6638
    txt:
      version: 1.0
      radio_type: znp
      baud_rate: 115200
      data_flow_control: software

Again, support for Tube's Zigbee Gateway was initially added to Home Aassistant core for ZHA support in home-assistant/core#48420

As I believe to then whitelist Zeroconf for more gateways and/or radio types in HA's zeroconf as well as for ZHA need to do PR for:

https://github.com/home-assistant/core/blob/dev/homeassistant/generated/zeroconf.py

 "_esphomelib._tcp.local.": [
        {
            "domain": "zha",
            "name": "tube*"
        }
    ],

and

https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/manifest.json

"zeroconf": [
    {
      "type": "_esphomelib._tcp.local.",
      "name": "tube*"
    }
  ],

and

https://github.com/home-assistant/core/blob/dev/homeassistant/components/zha/config_flow.py

async def async_step_zeroconf(self, discovery_info: DiscoveryInfoType):
        """Handle zeroconf discovery."""
        # Hostname is format: livingroom.local.
        local_name = discovery_info["hostname"][:-1]
        node_name = local_name[: -len(".local")]
        host = discovery_info[CONF_HOST]
        device_path = f"socket://{host}:6638"

        if current_entry := await self.async_set_unique_id(node_name):
            self._abort_if_unique_id_configured(
                updates={
                    CONF_DEVICE: {
                        **current_entry.data.get(CONF_DEVICE, {}),
                        CONF_DEVICE_PATH: device_path,
                    },
                }
            )

        # Check if already configured
        if self._async_current_entries():
            return self.async_abort(reason="single_instance_allowed")

        self.context["title_placeholders"] = {
            CONF_NAME: node_name,
        }

        self._device_path = device_path
        self._radio_type = (
            RadioType.ezsp.name if "efr32" in local_name else RadioType.znp.name
        )

SUGGESTION] Switch to USB-to-UART bridge chip with programmable EEPROM so can add custom "Product Description String" string as unique identifier

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.; "cyijun OpenZ3Gateway 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.

[REQUEST] Zeroconf support to cyijun OpenZ3Gateway for Home Assistant ZHA network discovery

Please consider adding Zeroconf support to cyijun OpenZ3Gateway 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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.