Zigbee2MQTT Ember Helper 
Zigbee2MQTT Ember Helper
Version: 1.2.1Get a better understanding of your Zigbee network using Zigbee2MQTT with Ember driver (for EmberZNet-based adapter).
Enter your network details and provide the log file in the form above.
Compatible with Zigbee2MQTT version 1.37.0 or later.
Warning
The information given is only meant to be indicative and may not be entirely relevant depending on your specific network/environment.
Values for identifying potential issues remain arbitrary until improved with more feedback.
Processing is done locally in your browser. Your log file doesn't leave your computer.
Changelog
[1.2.x]
- Add counters average by hour.
- Add failed pings detection.
[1.1.x]
- Add ability to sort relevant tables. Improve Routing table 'by error' display.
- Improve Routing tab to more closely relate to the logic behind network/routing errors.
- Added messages for identified possible issues in NCP/ASH counters.
- "Ideal" NCP Counters are now based on a 720-hour sample (associated log file available for download in Help section).
Multi-devices Flasher
Nabu Casa Home Assistant
SMLight
Ember ZLI
Nabu Casa
Silicon Labs
Note
Current Recommended Firmware
- 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.
- 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.
- 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). You will need to rename/move/delete the backup file. An alternative is to upgrade your firmware to 7.3.1 and start `ezsp` once (which will create a more recent backup), then upgrade to 7.4.1 and switch to `ember`.
- 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.
Details on Network/Route errors
- A status of SOURCE_ROUTE_FAILURE indicates that a source-routed unicast sent from this node encountered a broken link. Note that this case occurs only if this node is a concentrator using many-to-one routing for inbound messages and source-routing for outbound messages. The node prior to the broken link generated the route error message and returned it to us along the many-to-one route.
- A status of MANY_TO_ONE_ROUTE_FAILURE also occurs only if the local device is a concentrator, and indicates that a unicast sent to the local device along a many-to-one route encountered a broken link. The node prior to the broken link generated the route error message and forwarded it to the local device via a randomly chosen neighbor, taking advantage of the many-to-one nature of the route.
- A status of MAC_INDIRECT_TIMEOUT indicates that a message sent to the target end device could not be delivered by the parent because the indirect transaction timer expired. Upon receipt of the route error, the stack sets the extended timeout for the target node in the address table, if present. It then calls this handler to indicate receipt of the error.
A new route error message is generated for each failed retry. Therefore, it is not unusual to receive three route error messages in succession for a single failed retried APS unicast. On the other hand, it is also not guaranteed that any route error messages will be delivered successfully at all.
Reference Network ("Ideal")
Software
Sample