Subject: ecoMAX 850P2 (+ Module B) - garbage temperature readings after bad SET_PARAM (0x33) writes to out-of-range indices - looking for Module A firmware / recovery advice
Hi everyone,
First off, thanks to this thread and everyone who's contributed to it over
the years - the protocol reverse-engineering here has been incredibly
useful. I've gotten myself into a bit of trouble with my own controller
and would really appreciate any pointers.
SETUP
Plum ecoMAX 850P2-C, Module A + Module B (2 mixer circuits), standard
monochrome control panel (3 buttons, one rotary/encoder - not the touch
panel variant, no SD card slot - just a mini-USB port on the board).
Direct USB-serial connection (bypassing the ecoNET300 WiFi module), 115200 8N1,
standard ecoNET frame protocol (0x68/0x16, XOR CRC).
Versions: Panel 6.30.44.K0, Module A 6.10.37.K1, Module B 1.31.16.
Hydraulics: 3 circulation pumps - boiler/buffer circuit pump, radiator
circuit pump (mixer 1), floor heating circuit pump (mixer 2).
WHAT HAPPENED
While experimenting with the protocol myself, I sent SET_PARAM (frame 0x33)
writes to raw indices 144, 147, 148, 160 - my mistake, I hadn't verified
these against the actual parameter table first. Both my own reconstructed
editable-params table and PyPlumIO independently confirm this controller's
editable-params table only goes up to index 138, so these writes targeted
something outside the documented parameter space.
SYMPTOMS
- Entering the manual control menu now starts the boiler unexpectedly
(shouldn't happen on this controller).
- Active alarm: "max boiler temp exceeded [50C]".
- Panel Info screen + live data show impossible readings.
CONFIRMED DIAGNOSTIC DATA (cross-checked two independent ways: my own
protocol reimplementation reading FRAME_GET_CURRPARAMSCONSTR/REGDATA, and
separately via PyPlumIO - both agree):
- heating_temp = ~2102 C (garbage)
- feeder_temp = -1.76e+38 (raw float garbage, not the normal NaN
"sensor absent" pattern)
- outside_temp = -inf (garbage)
- Everything else looks normal: mixer 1/2 current temps (~19C), buffer
temps (~19C), all relay/output booleans, all 139 editable params (only
2 minor out-of-own-range values, unrelated to the above, likely
pre-existing).
Notably, the corruption is NOT in the 4 indices I wrote to (144/147/148/160)
- it shows up in a completely different part of the protocol (the 0x04xx
regdata sensor block). The write sequence itself was also sloppy on my end
(serial port closed/reopened between each of the 4 writes, no ack/response
ever checked), so I can't even be fully sure all 4 writes landed cleanly.
WHAT I'M HOPING TO FIND
1. Since my panel has no SD card slot (just a mini-USB port on the board),
I believe the update path for this variant is via an ecoLINK2 cable +
PC-side update software rather than the SD-card method. Can anyone
confirm this, and point me to the PC software and a genuine/official
Module A firmware image for v6.10.37.K1 (or a safe version to reflash
with)? Assuming a reflash re-initializes calibration/EEPROM data
cleanly.
2. Whether temperature sensor calibration data is universal per
model/firmware version, or trimmed per physical unit at the factory -
this would tell me whether a straight reflash should fully fix this.
3. Whether anyone recognizes this exact garbage-float pattern (2102C /
-1.76e38 / -inf across 3 sensor channels simultaneously) from a bad
write - i.e. does an out-of-range SET_PARAM on this platform corrupt
adjacent calibration memory?
Happy to share my Python decode scripts (frame protocol + PyPlumIO-based)
if useful to anyone else working on this. Thanks in advance for any help!