* Matter Zigbee bridge: route per-endpoint friendly names to correct endpoint
The Matter to Zigbee bridge mapped each Matter endpoint to a Zigbee
shortaddr only, losing endpoint information. For multi-endpoint
devices (e.g. 2-channel on/off relays), every Matter command routed
to Zigbee endpoint 1 and incoming reports updated all Matter plugins
targeting that device.
Changes in Matter_z_Zigbee.be:
* New "<device>:<N>" explicit syntax for per-endpoint targeting,
e.g. zigbee_device:"my_device:2" routes Matter to Zigbee endpoint 2.
* Per-endpoint friendly name auto-resolution as a fallback: when no
explicit ":N" is given and the config string is a non-hex name,
the mapper queries ZbName once at first resolve and walks the
response to find the source endpoint. Preserves the existing
Tasmota convention of per-endpoint friendly names set via
ZbName <dev>,<name>,<ep>.
* Outgoing: pass the original config string verbatim in the ZbSend
Device field. ZbSend's parseDeviceFromName resolves per-endpoint
friendly names natively. Adds explicit Endpoint field when known.
* Incoming: filter Matter_Zigbee.attributes_final by attr_list._src_ep
when the mapper has a known endpoint. The frame parameter is
always nil at this call site (caller passes nullptr), so the
filter relies on the attribute list's source endpoint instead.
* Boot probe (probe_zb_values) is now endpoint-aware: triggers a
ZbRead per attribute the plugin tracks for the specific endpoint.
Avoids the previous merged-state pollution where probe pushed the
same device.info() to all plugins targeting the same shortaddr.
Single-endpoint configs keep the cheap cached probe (no extra
Zigbee traffic).
Backwards compatibility preserved for shortaddr / integer / device-
level friendly name configs - default endpoint behavior is unchanged.
Tested on a 2-channel Zigbee on/off device paired to a Tasmota
Zigbee gateway, verified bidirectional in Apple Home.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Delet solidify file
---------
Co-authored-by: Paul de Monchy <paul.de.monchy@gmail.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: s-hadinger <49731213+s-hadinger@users.noreply.github.com>
On platforms without exceptions (-fno-exceptions, e.g. ESP8266),
new[] returns nullptr on allocation failure instead of throwing.
The missing NULL check caused a hard crash (load/store to address
derived from nullptr+offset) whenever the token buffer could not
be allocated.
Fix all four paths that dereference _tokens without a NULL guard,
and implement the existing TODO in parse() to ensure _token_len=0
invariant holds after OOM, consistent with the zero-error design.
* Replace old software-defined library arduino-vid6608 with hw-defined esp-32-vid6608
* VID6608: Rework integration to allow select RMT/SW method by using the `VID6608_RMT` option
* VID6608: Tune library inclusion for RMT version
* The RMT version is not supported on ESP32-C2, library excluded
* Add more clear error message, if RMT is requested, but not supported
