* 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>
* 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
* set no wait on connect
* removed incremental draw; reduced data moving; reduced touch events
* added set_nowait method to set TCP_NODELAY socket option
* added last chunk indicator for the stream callback
* writebytes optimizations
* Add an independent MQTT client for use by Berry applications and extensions
- Introduce `mqttclient` Berry class (ESP32) for connecting to MQTT brokers with own credentials, TLS, LWT, and auto-reconnect separate from global MQTT client
- Berry `mqttclient` aims to match functionality of global MQTT client including backoff logic using Settings->mqtt_retry, mqtt_keepalive, and mqtt_socket_timeout
- Rename `retry_counter_delay` to `retry_counter_multiplier` in xdrv_02_9_mqtt for clarity and avoid redundant multiplication.
* Added `USE_BERRY_MQTTCLIENT` flag for conditional compilation of the standalone Berry MQTT client
* Tasmota - Berry ASYNC Webclient integration
Add library.json for Async HttpClient Light
Update readme.txt for AsyncHttpClientLight
Clarified the integration of AsyncHttpClientLight with Berry webclient and improved formatting for example URLs.
AsyncHttpClientLight.cpp
Add AsyncHttpClientLight header file
Integrate ASYNC Webclient functionality
Add USE_BERRY_WEBCLIENT_ASYNC feature
USE_BERRY_WEBCLIENT_ASYNC definition for async webclient mode.
Refactor webclient to use AsyncHttpClientLight
* Revise readme for AsyncHttpClientLight updates
Updated readme.txt to reflect changes in AsyncHttpClientLight, including new core client details and operational notes.
* Update README for AsyncHttpClientLight integration
