- Rework of the eQ-3 TRV device view to show a compact status row
- Use shared signal-strength indicator styling and remove duplicate CSS from Zigbee and MI BLE pages.
- Extend the MQTT payload with `BattVolt` field
The driver could already enable CH2 (ot_flags CH2, master status bit 4)
but never sent the CH2 control setpoint (data-id 8) nor read the CH2 flow
temperature (data-id 31).
- ot_tboiler2: CH2 setpoint, written only while CH2 is enabled and on
change (same tolerance as ot_tboiler); runtime value, starts with the
saved CH setpoint after a restart (no Settings change)
- ot_ch2: runtime CH2 enable, counterpart of ot_ch (no flash write)
- telemetry BTMP2 and TB2, web lines for CH2
Both commands reuse the tboiler/ch handlers via the command index.
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
* HLK-LD2402 Fix bitwise operation precedence
* Fixed issue with code not running because of a mistake in
the order of some bitwise operations
* Adjusted logic to better conform with HiLink documentation
* HLK-LD2402 increased resilience to uart issues
* Driver is more relaxed with uart communications this allows it to
continue working where perviously it would become confused.
* Tested on ESP32 and ESP8266 device.
IRSend has two shapes: a JSON one, which reads Channel and picks the emitter,
and a plain "IRSend <freq>,<rawdata>" one, which has no channel at all and
always uses the first emitter. A remote whose protocol IRremoteESP8266 does not
recognise is stored as raw by anything that learns codes, so on a board with
several emitters those remotes could only ever be replayed through emitter 1,
silently.
IRSend now also takes raw data as JSON, in the same shape the receiver
publishes it:
IRSend {"RawData":"+8570-4240+550-1580C-510","Frequency":38000,"Channel":3}
RawData accepts the compact format and a comma separated list, as the plain
form does. Frequency defaults to 38 kHz and Channel to the first emitter, so
the two forms behave the same when nothing is given.
IrRemoteSendRawStandard takes the channel as a parameter rather than a default
argument, because the Arduino builder generates a prototype for a function used
before its definition and a default in both places does not compile.
* Matter: add Electrical Power Measurement cluster to On/Off Plug-in Unit
Adds a new "relay_power" plugin type (Matter_Plugin_OnOff_Power) that extends
the existing relay/OnOff Plug-in Unit (0x010A) with the Electrical Power
Measurement cluster (0x0090), reporting Voltage, Current, ActivePower,
ApparentPower, ReactivePower, Frequency and PowerFactor from Tasmota's ENERGY
sensor JSON, so Matter controllers can display live power usage for smart
plugs with energy monitoring.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* Matter: add v_relay_power virtual variant for Electrical Power Measurement
Adds Matter_Plugin_Virt_OnOff_Power ("v_relay_power") so the new
ElectricalPowerMeasurement-enabled plug can be exercised without physical
hardware, driven entirely via `MtrUpdate` (e.g. Voltage/Current/ActivePower/
ApparentPower/ReactivePower/Factor/Frequency).
Also guards Matter_Plugin_OnOff_Power.parse_sensors() against VIRTUAL
instances (it must not read the local ENERGY sensor) and declares
UPDATE_COMMANDS so MtrUpdate accepts the new measurement keys. The wattage
key is named `ActivePower` rather than `Power` since `Power` is already the
inherited On/Off boolean command.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
* Matter: register new plugin headers in be_matter_module.c
be_matter_module.c maintains an explicit, hand-written list of solidified
Berry header includes (no auto-discovery). The new OnOff_Power and
Virt_OnOff_Power plugin files were missing from that list, so their classes
were never defined, causing the "undeclared" build failures reported by CI
(be_class_Matter_Plugin_OnOff_Power / be_class_Matter_Plugin_Virt_OnOff_Power)
even though matter.plugins_classes referenced them by name.
* Matter: add http_relay_power bridge variant for Electrical Power Measurement
Adds Matter_Plugin_Bridge_OnOff_Power ("http_relay_power") so the
ElectricalPowerMeasurement-enabled plug can also be bridged from a remote
Tasmota device over HTTP (polling `Status 10`), completing the local/virtual/
bridge trio already used by other plugins (relay, relay_power now included).
Refactors the ENERGY-object parsing in Matter_Plugin_OnOff_Power into a
shared `_parse_energy()` helper used by both `parse_sensors()` (local device)
and the new `parse_status()` override (bridge, index 10 / Status 10), and
guards `parse_sensors()` against BRIDGE instances so a bridge endpoint never
reads the local gateway's own ENERGY sensor by mistake.
Registers the new solidified header in be_matter_module.c (missed this for
the previous two plugin files, which broke CI) and adds http_relay_power to
the bridge type dropdown in Matter_UI.be.
Verified with a full PlatformIO build for tasmota32s3 (SUCCESS).
* Matter: auto-detect relay_power on remote bridge devices with an ENERGY sensor
The "Add Remote sensor or device" auto-detection always suggested plain
light0/relay for every detected relay channel, even when the remote device
reports an ENERGY sensor (e.g. a NOUS A5T 4-outlet power strip with a single
shared CSE7766 meter) - so relay+power devices showed up as plain "Light 0
OnOff" with no way to pick relay_power from that screen (the type column is
static text for already-detected rows, only editable for a brand new blank
row).
generate_config_from_status() now tags the first detected relay as
relay_power when ENERGY is present, leaving the rest as plain relays: most
Tasmota energy-monitoring boards have a single meter for the whole device,
not one per relay, so duplicating the cluster across every channel would
misleadingly show the same aggregate reading on each endpoint.
* Matter: compose Electrical Sensor device type onto the power-monitoring plug
Adds device type 0x0510 (Electrical Sensor) alongside 0x010A (On/Off
Plug-in Unit) on the same endpoint for relay_power/v_relay_power/
http_relay_power, plus the mandatory Power Topology cluster (0x009C) with
the NODE feature (this single ENERGY sensor meters the whole device, not a
subset of endpoints - matches Tasmota's non-indexed ENERGY object).
Matches the Matter 1.4.1 Device Library requirement that Electrical Power
Measurement lives on an Electrical Sensor device type, while keeping the
cluster on the plug's own endpoint (composed DeviceTypeList) rather than a
separate endpoint, since controllers only recognize the measurement
capability when the Electrical Sensor device type is actually declared.
Verified on real ESP32-S3 hardware via chip-tool: endpoint 2 now reports
DeviceTypeList = [266 (On/Off Plug-in Unit), 1296/0x0510 (Electrical
Sensor), 19 (Bridged Node)], and Power Topology FeatureMap = 1 (NODE).
---------
Co-authored-by: Ludovic BOUÉ <938089+lboue@users.noreply.github.com>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
* DALI: bind DALI-2 push button events to control gear targets
Add command DaliBind<1..8> <device>,<instance>,<target>,<mode> to link
push button events (IEC 62386-301) from an input device instance to a
control gear target. Modes are Toggle, On, Off, Up and Down; Up and Down
start a fade on button press and stop it on release. The first matching
binding is executed. DaliBind<x> 0 removes a binding and DaliBind alone
lists them all.
Bindings are stored in the DALI settings file, packed as one uint32 per
slot, so they survive a restart.
* Describe how start-up brightness stored differently per short addres vs dali groups
Two independent reliability fixes for the MFRC522 driver, found while
debugging a real device:
- LoadAvg climbing toward its ceiling: idle polling every 250ms was
hitting the reader's own ~25ms internal REQA timeout every time
(PCD_CommunicateWithPICC busy-waits synchronously with no yield()
until TReloadReg's on-chip timer fires), i.e. a permanent ~10% duty
cycle from polling alone. Throttles idle polling to roughly once a
second and shortens the on-chip poll timeout via TReloadReg
(RC522ShortenPollTimeout, ~2.5ms instead of 25ms - still well above
a real tag's few-hundred-microsecond ISO14443A response time), an
order of magnitude cheaper without hurting detection reliability.
Also added exponential backoff as a safety net if a poll is ever
genuinely slow (e.g. RF noise triggering the anticollision path).
- Reader silently stopping card detection after a few reads, only
recoverable with a manual reset: traced to MIFARE_Authenticate
(used by USE_RC522_DATA_FUNCTION) occasionally leaving the crypto1
cipher engine stuck engaged, which garbles all further card
communication even though simple register reads keep succeeding.
Added a 1s watchdog that checks two registers that reveal this
broken-but-alive state - Status2Reg's MFCrypto1On bit and
TxControlReg's antenna-field bits - and does a full PCD_Reset()+
PCD_Init() the moment either looks wrong, rather than waiting for a
user to notice and run RC522Reset. Toggle with RC522Watchdog 0/1
(on by default); new RC522Status field, "Healthy", reports the same
check on demand.
Also stopped calling PCD_PerformSelfTest() at init - it resets the
chip and writes test patterns into several registers, needing a full
re-init to undo (the library's own docs note "self-test blows init").
A plain VersionReg read is already a reliable presence check without
that risk.
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
SteWers
s-hadinger
Theo Arends
pebl-hankandClaude Opus 5.5
protectivedad
SoWizardands-hadinger
Ludovic BOUÉ
Gustavo Cateim
John Murfett
Jason2866
Erin of Yukis
Bogdan ShatikandClaude Sonnet 5