EmberZNet adapters (Silicon Labs)

Currently supported firmware version: 7.4.x, 8.0.x

ATTENTION

Use of 8.0.0 and 8.0.1 is not recommended due to firmware issues that have been resolved in 8.0.2.

Firmware release notes: https://www.silabs.com/developers/zigbee-emberznet?tab=documentation

Multiprotocol is not currently supported due to the various issues associated with it. The recommended alternative to establish multiple networks is to use one adapter per protocol.

Configuration

serial:
    adapter: ember

Other supported settings are: adapter_concurrent and transmit_power (docs).

TIP

If you are experiencing issues with your adapter and it has hardware flow control support (check list below), try to flash a firmware with hardware flow control disabled and use the following setting instead:

serial:
    rtscts: false

TIP

The use of adapter: ezsp is now deprecated. See https://github.com/Koenkk/zigbee2mqtt/discussions/21462

Firmware flashing

USB

Sonoff ZBDongle-E (V2 model, EFR32MG21)

With external antenna. Only supports software flow control (make sure not to set rtscts: true).

This section is about the "ZBDongle-E", for "ZBDongle-P" see zStack.

Nabu Casa Home Assistant SkyConnect (EFR32MG21)

With integrated antenna and hardware flow control support.

serial:
    rtscts: true
SMLIGHT SLZB-07 (EFR32MG21)

With external antenna and hardware flow control support.

serial:
    rtscts: true
Z-WAVE>ME Z-Station (EFR32MG21P)

With external antenna.

Requires Z-Station firmware 2024.04.22 or later.

serial:
    rtscts: false

Network (TCP)

TubeZB EFR32 MGM24 POE (MGM240PB32VNN)

With external antenna.

Hybrid (USB + Network)

SMLIGHT SLZB-06M (EFR32MG21)

With external antenna.

For optimal performance, ensure your firmware is at least version 20240510 (requires Core firmware version 2.2.0 or higher). Not suitable for WiFi or other high latency connections.

SMLIGHT SLZB-06mg24 (EFR32MG24)

With external antenna.

Hub

Nabu Casa Home Assistant Yellow (MGM210P)

With integrated antenna and hardware flow control support.

serial:
    rtscts: true

Custom

All Series 0/1 based-devices

Older hardware.

See Silicon Labs announcement.

Easyiot ZB-GW04 (v1.1, v1.2)

Low-resources hardware.

Logging specific to this stack

info level

The start and stop sequences describe the steps taken to get Zigbee2MQTT running with ember in more details. This should help to locate potential start and stop problems.

Stack/Network status changes (up/down, channel change, open/close from Permit Join, etc).

Network/Route error: The error indicates that there was a problem sending/receiving messages from the target node (see below for more details). A few of these over time is expected (or on Zigbee2MQTT start), too many, too often, is indicative of a problem in your network.

warning level

Node descriptor reports device is only compliant to revision: Device identified as having an older Zigbee revision. These can be the source of problems, especially if pre-21.

[EzspConfigId] Failed to SET: Usually when the coordinator has lower memory than others. In-firmware value will be used instead.

An ID conflict was detected: Two devices cannot have the same ID on the same network. The involved devices are kicked off the network then should rejoin (may need to re-pair them if not).

NOT READY - Signaling NCP: ember driver is temporarily overloaded. The coordinator is made aware and processing is deferred for a short period.

error level

NCP EZSP protocol version of XX does not match Host version 13: ember currently requires a firmware with EZSP v13 (EmberZNet firmware 7.4.x). You will need to upgrade your adapter's firmware. Check the first two posts here.

[BACKUP] Current backup file is from an unsupported EZSP version: ember currently only supports EZSP v12 and above backups (can be identified by opening the coordinator_backup.json file). The file has been renamed automatically. A new one will be created by ember upon successful start.

Failed delivery of a message. The target device could not be reached. There can be several causes for this, the rest of the logs should help identify which.

Failed request. Message should be self-explanatory, and give a status indicating the reason of the failure.

NCP Fatal Error. The coordinator failed (the reason should be given in the message). Zigbee2MQTT will attempt to reset it and resume communication. If unsuccessful, Zigbee2MQTT will be stopped completely and the system's watchdog (if any) will attempt to restart it.

Tools

Ember ZLI

https://github.com/Nerivec/ember-zli/

NodeJS command line tool that allows firmware flashing, interacting with the adapter's stack, sniffing, etc. using zigbee-herdsman. Check out the Wiki for more details.

Bellows CLI

https://github.com/zigpy/bellows

Python command line tool that allows interacting with the adapter's stack.

Zigbee2MQTT Ember Helper

https://nerivec.github.io/z2m-ember-helper/

Analyze log files in your browser and get an automated review of your network.

[EXPERT] Customizing stack configuration

ATTENTION

This feature modifies the behavior of your adapter, and the network. Using improper values for your network can completely break it. Only modify any of these values if you are absolutely sure your network will benefit from it. Most networks will be just fine with the defaults.

ATTENTION

Do not open a new issue in Zigbee2MQTT before confirming the problem is present with the default configuration.

You can modify the EmberZNet default stack configuration by creating a file stack_config.json in the same folder as your coordinator_backup.json. This configuration can only be done manually.

Format, available and default values are as below:

{
    "CONCENTRATOR_RAM_TYPE": "high",
    "CONCENTRATOR_MIN_TIME": 5,
    "CONCENTRATOR_MAX_TIME": 60,
    "CONCENTRATOR_ROUTE_ERROR_THRESHOLD": 3,
    "CONCENTRATOR_DELIVERY_FAILURE_THRESHOLD": 1,
    "CONCENTRATOR_MAX_HOPS": 0,
    "MAX_END_DEVICE_CHILDREN": 32,
    "TRANSIENT_DEVICE_TIMEOUT": 10000,
    "END_DEVICE_POLL_TIMEOUT": 8,
    "TRANSIENT_KEY_TIMEOUT_S": 300,
    "CCA_MODE": null
}

Any value that is omitted from the JSON file, invalid or out of range, will use the default instead.

Documentation on these values and their behavior can be found in SiLabs UG100 - 2.3.1 PDF and concentrator article.

The driver further restricts values to the below:

  • CONCENTRATOR_RAM_TYPE: "high" or "low"
  • CONCENTRATOR_MIN_TIME: min 1, max 60
  • CONCENTRATOR_MAX_TIME: min 30, max 300
  • CONCENTRATOR_ROUTE_ERROR_THRESHOLD: min 1, max 100
  • CONCENTRATOR_DELIVERY_FAILURE_THRESHOLD: min 1, max 100
  • CONCENTRATOR_MAX_HOPS: min 0, max 30
  • MAX_END_DEVICE_CHILDREN: min 6, max 64
  • TRANSIENT_DEVICE_TIMEOUT: min 0, max 65535
  • END_DEVICE_POLL_TIMEOUT: min 0, max 14
  • TRANSIENT_KEY_TIMEOUT_S: min 0, max 65535
  • CCA_MODE: defaults to undefined (i.e. left to firmware default), possible values:
    • "RSSI": RSSI-based CCA. CCA reports a busy medium upon detecting any energy above -75 (default).
    • "SIGNAL": Signal Identifier-based CCA. CCA reports a busy medium only upon the detection of a signal compliant with this standard with the same modulation and spreading characteristics of the PHY that is currently in use.
    • "SIGNAL_OR_RSSI": RSSI or signal identifier-based CCA. CCA reports a busy medium on either detecting any energy above -75 (default) or detection of a signal compliant with this standard with the same modulation and spreading characteristics of the PHY that is currently in use.
    • "SIGNAL_AND_RSSI": RSSI and signal identifier-based CCA. CCA reports a busy medium only on detecting any energy above -75 (default) of a signal compliant with this standard with the same modulation and spreading characteristics of the PHY that is currently in use.
    • "ALWAYS_TRANSMIT": ALOHA. Always transmit CCA=1. CCA always reports an idle medium.

Note that some values are not only restricted by these ranges, but also by the memory available in your adapter. If any value (or combination) is too great for your adapter to handle, it will default to the firmware value(s) instead.