search

Koenkk / zigbee2mqtt

Zigbee 🐝 to MQTT bridge 🌉, get rid of your proprietary Zigbee bridges 🔨
https://www.zigbee2mqtt.io
GNU General Public License v3.0
11.73k stars 1.64k forks source link

Using Itead ZBDongle-E last firmware with the ember adapter cause Warning #23344

Closed yoch closed 1 month ago

yoch commented 1 month ago

What happened?

After upgrading Z2M and flashing my ZBDongle-E with Itead's latest firmware (v7.4.3) to use the ember adapter, the following warning appears:

zh:ember: [EzspConfigId] Failed to SET "MULTICAST_TABLE_SIZE" TO "16" with status=ERROR_OUT_OF_MEMORY. Firmware value will be used instead.

Investigation

Comparison of configuration parameters between Itead and Darkxst firmware versions:

Parameter Itead Darkxst
CONFIG_PACKET_BUFFER_COUNT 250 255
CONFIG_ADDRESS_TABLE_SIZE 32 16
CONFIG_MULTICAST_TABLE_SIZE 8 16

Questions

  1. Why does Z2M rely on CONFIG_ADDRESS_TABLE_SIZE=16?
  2. Is there a risk of system malfunction due to this parameter mismatch?
  3. What are the reasons for these configuration differences between Itead and Darkxst firmware versions?

Zigbee2MQTT version

1.39.0

Adapter firmware version

7.4.3 [GA]

Adapter

EmberZNet

Setup

Plain install on RPi4

Debug Log

[2024-07-15 18:40:50] info:     z2m: Starting Zigbee2MQTT version 1.39.0 (commit #03269267)
[2024-07-15 18:40:50] info:     z2m: Starting zigbee-herdsman (0.50.1)
[2024-07-15 18:40:50] info:     zh:ember: Using default stack config.
[2024-07-15 18:40:50] info:     zh:ember: ======== Ember Adapter Starting ========
[2024-07-15 18:40:50] info:     zh:ember:ezsp: ======== EZSP starting ========
[2024-07-15 18:40:50] info:     zh:ember:uart:ash: ======== ASH NCP reset ========
[2024-07-15 18:40:50] info:     zh:ember:uart:ash: RTS/CTS config is off, enabling software flow control.
[2024-07-15 18:40:50] info:     zh:ember:uart:ash: Serial port opened
[2024-07-15 18:40:50] info:     zh:ember:uart:ash: ======== ASH starting ========
[2024-07-15 18:40:51] info:     zh:ember:uart:ash: ======== ASH connected ========
[2024-07-15 18:40:51] info:     zh:ember:uart:ash: ======== ASH started ========
[2024-07-15 18:40:51] info:     zh:ember:ezsp: ======== EZSP started ========
[2024-07-15 18:40:52] warning:  zh:ember: [EzspConfigId] Failed to SET "MULTICAST_TABLE_SIZE" TO "16" with status=ERROR_OUT_OF_MEMORY. Firmware value will be used instead.
[2024-07-15 18:40:52] info:     zh:ember: [STACK STATUS] Network up.
[2024-07-15 18:40:52] info:     zh:ember: [INIT TC] NCP network matches config.
[2024-07-15 18:40:52] info:     zh:ember: [CONCENTRATOR] Started source route discovery. 1248ms until next broadcast.
[2024-07-15 18:40:52] info:     zh:ember:queue: Request dispatching started.
[2024-07-15 18:40:52] info:     z2m: zigbee-herdsman started (resumed)
[2024-07-15 18:40:52] info:     z2m: Coordinator firmware version: '{"meta":{"build":0,"ezsp":13,"major":7,"minor":4,"patch":3,"revision":"7.4.3 [GA]","special":0,"type":170},"type":"EmberZNet"}'
baspax1 commented 1 month ago

I have the exact same adapter and performed the exact same upgrade with the intention of improving the potential connection issues I had with my devices. However, after the upgrade and the switch to ember, things are worse, as shown in the logs here:

Zigbee2MQTT version: 1.39.0

Log:

[12:49:12] INFO: Preparing to start...
[12:49:12] INFO: Socat not enabled
[12:49:14] INFO: Starting Zigbee2MQTT...
Starting Zigbee2MQTT without watchdog.
[12:50:00] INFO: Preparing to start...
[12:50:01] INFO: Socat not enabled
[12:50:03] INFO: Starting Zigbee2MQTT...
Starting Zigbee2MQTT without watchdog.
[12:51:32] INFO: Preparing to start...
[12:51:33] INFO: Socat not enabled
[12:51:35] INFO: Starting Zigbee2MQTT...
Starting Zigbee2MQTT without watchdog.

Configuration: https://prnt.sc/nOC-7ELnDYL7

Here are the devices I have: https://prnt.sc/GO97YqLaTuXu

I am facing many issues related to data updates; they are not stable at all. Even the sensor that is close to the Zigbee adapter does not receive data every 3 minutes as I want it to.

yoch commented 1 month ago

NOTE

I saw here that I could set non-default values ​​with a stack_config.json file :

{
  "ADDRESS_TABLE_SIZE": 32,
  "MULTICAST_TABLE_SIZE": 8
}

By doing so, the warning can be avoided, but I'm still curious to know why these specific values ​​are applied by Z2M? Maybe I better use the Darkxst firmware?

Nerivec commented 1 month ago

A config failing to set means the adapter will use in-firmware value instead, as the message says. Z2M adapts to the effective value when necessary, so it should not be a problem. Different values means different "priorities" though, see below.

Most of these values (in-firmware ones) were picked a while back (NabuCasa, darkxst, etc.) to optimize the general use case for ZHA/Z2M based on the available adapters. It's all about optimizing memory allocation on the adapter to what's of better use for most users. Since Silabs changed several areas regarding these values a while back, runtime modification was restricted a bit further. As such, a lot of these configs will no longer be explicitly set by Z2M (after next release), and instead in-firmware values will be used. Also new adapters (like MG24-based ones) can handle much larger values than previous.

The new firmware building system allows easy customization of firmware per adapter (even easy enough for anyone to clone the repo, change the values, and trigger the GitHub workflow to get a firmware built for themselves if they want to try something else).

I would say, better to use a darkxst firmware; haven't checked what values Itead put in all their new builds...