Tested with a heatpump (0x08) and MP100 pool module (0x11), custom entities
compared against RC300 operation and a power meter on the circulation pump.
- boiler `poolon` (0x48A offset 0), writable, RC300 writes 01/00
- boiler `hppoolon` (0x488 offset 0 bit 6), pool heating actually active
- pool `poolshuntset` (0x5C4 offset 0, heatpump -> MP100), shunt setpoint;
`poolshunt` follows within ~2 min
- pool `poolpump` (0x5BA offset 4), 0 = running, 2 = off. This byte is only
in MP100 -> heatpump telegrams, so the pool module now also handles
telegrams it sends to other devices
- simulator: `test pool`
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013YrkDbvxEv3ZMS7SPSKCGd
The heat limit registers on heat pumps using EMS_DEVICE_FLAG_HEATPUMP
(product 172/173) are bytes 2/3/4 of telegram 0x0492, read as a direct
index into enum_maxHeat. That table has only six entries, so any unit
whose auxiliary electric heater goes above 9 kW reports an index the
table cannot resolve.
Nothing bounds-checks the raw byte on the way in, and every render path
guards on `value < options_size`, so an out-of-range index is dropped
silently: no value is published to MQTT, the API omits the field, Home
Assistant shows `unknown`, and nothing appears in the log. Helpers::
value2enum stops at the same boundary, so the value cannot be written
back from EMS-ESP either, leaving the entity permanently stuck.
Measured on a Bosch Compress 7000i AW (CS7000iAW 13 OR-T, product 172)
with a 15 kW auxiliary heater, by setting each limit from the unit's own
display and reading telegram 0x0492 back:
display 12 / 9 / 6 kW -> 0x0492 data: 03 00 06 05 04
raw kW note
0 0 agrees with the existing table
1 2 not offered by this heater
2 3 not offered by this heater
3 4 not offered by this heater
4 6 agrees with the existing table
5 9 agrees with the existing table
6 12 new
7 15 new
Indices 0, 4 and 5 match what EMS-ESP already decodes, which confirms the
existing entries and their ordering; the table was correct, just short.
The 2 kW and 4 kW entries belong to the 4-stufig (2/4/6/9 kW) heater
variant described in the HPC 410 service manual section 4.2.2, so a
3 kW-stepped heater simply skips them and walks 0, 3, 6, 9, 12, 15 kW,
i.e. raw 0, 2, 4, 5, 6, 7. The same sparse pattern is already encoded for
CS6800 devices in Boiler::process_HpHeaterConfig, which maps raw
{0, 2, 4, 5} onto {0, 3, 6, 9} kW.
Only devices carrying EMS_DEVICE_FLAG_HEATPUMP are affected; CS6800
devices use enum_maxHeat1/enum_maxHeat2 and are unchanged. Verified with
the standalone build: `test entity_dump` differs from the committed
docs/dump_entities.csv in exactly the six maxheat rows of products 172
and 173, and nowhere else.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
WebLogService::operator<< trims with `log_messages_.size() >= limit_log_messages_`.
size() is unsigned, so with limit_log_messages_ == 0 the condition holds even for an
empty deque and pop_front() runs on it - undefined behaviour, in practice heap
corruption. On a PSRAM board the stored value survives a reboot, so the device crashes
again as soon as the first log message is written.
Nothing clamps the value on the way in: start() copies settings.weblog_buffer with no
lower bound, the PSRAM branch of operator<< passes it straight into
limit_log_messages_, and ArduinoJson's | in WebSettings::update() only substitutes the
default for a missing or type-incompatible key - a stored 0 is a valid uint16_t.
- operator<<: skip the trim loop on an empty deque
- start(): keep the existing default when the stored value is 0
- getSetValues(): a missing or zero max_messages keeps the current size instead of
storing 0
- WebSettings::update(): repair a stored 0, and derive the psram/no-psram default once
instead of twice
Refs #3237
proddy