VT_VACATIONPROG: hard-coded enable_byte=6 rejected by Siemens RVS21 — should be 1

[remidebette]

Disclosure: done with the help of Claude Code
Relates to #811

Publishing as a draft because I am not sure this is the right fix, and anyways it does not fully work yet (active vacation mode works after this fix, but not inactive vacation mode)

Summary

BSB_LAN_defs.h declares enable_byte=6 for VT_VACATIONPROG. On a Siemens RVS21.831F/127 controller, this causes every SET attempt against vacation parameters (642/643 and CC2 equivalents 652/653) to be rejected by the heater — the BSB-LAN web UI / MQTT writes never propagate to the heater, even though the device reports the SET as successful (because the optimistic re-query path also misreads the response). Reading vacation values that were configured via the heater's hardware screen also fails to render correctly: BSB-LAN shows --- for active periods.

Changing the table entry from 6 to 1 fixes both reads and writes for the active path:

- {VT_VACATIONPROG,     1.0,    6, 8+32,     DT_DDMM, 0,  UNIT_NONE,         STR_VACATIONPROG     },
+ {VT_VACATIONPROG,     1.0,    1, 8+32,     DT_DDMM, 0,  UNIT_NONE,         STR_VACATIONPROG     },

The enable_byte field's own documentation in BSB_LAN_defs.h:596 notes both 1 and 6 are valid conventions across heaters; VT_VACATIONPROG is the only "date-shaped" type currently set to 6. All sibling types in the same block (VT_DATETIME, VT_YEAR, VT_DAYMONTH, VT_TIME) use 1, which is consistent with the validity-byte convention checked by printDateTime() in include/print_telegram.h.

Reproduction

• BSB-LAN 5.1.1 on ESP32 NodeMCU.
• Heater: Atlantic Alfea Extensa Duo A.I. 5 with Siemens RVS21.831F/127 controller (device family 211, variant 127).
• programWriteMode = 1 (Standard) — params 642/643 have DEFAULT_FLAG, so writable.

Symptoms before the fix

1. Set a vacation period from the heater hardware screen (e.g. 07.05 → 12.05).
2. Read 642 via BSB-LAN. Expected 07.05., got ---.
3. Attempt to set 642 from BSB-LAN: GET /S642!0=15.07.. BSB-LAN reports success and re-renders 15.07., but the heater hardware screen still shows the old date and the period is never engaged.

Bus traces

Reading a hardware-configured period (heater answers, BSB-LAN displays ---):

LAN->HEIZ QUR 642.0 - Début Congé:
  DC C2 00 0B 06 3D 05 09 C4 51 9A
HEIZ->LAN ANS 642.0 - Début Congé: ---
  DC 80 42 14 07 05 3D 09 C4 | 00 00 05 07 00 00 00 00 17 | E8 1B
                              ^^ enable=0 (valid value), date=07.05, date_flag=0x17

The heater returned a valid value (byte 0 = 0). printDateTime() correctly renders this as 07.05.. Earlier observations where this came back as 01 00 05 09 … were caused by prior failed SET attempts that left the heater in a transient state — see "Pre-fix corrupted-state observation" below.

Attempting an active SET before the fix (enable_byte=6):

LAN->HEIZ SET 642.0 - Début Congé: 15.07.
  DC C2 00 14 03 3D 05 09 C4 | 06 7D 07 0F 00 00 00 00 17 | ...
                              ^^ enable=6
HEIZ->LAN NACK ...

After the fix (enable_byte=1):

LAN->HEIZ SET 642.0 - Début Congé: 08.05.
  DC C2 00 14 03 3D 05 09 C4 | 01 00 05 08 00 00 00 00 17 | DC C1
                              ^^ enable=1
HEIZ->LAN ACK 642.0 - Début Congé:
  DC 80 42 0B 04 05 3D 09 C4 14 4E
LAN->HEIZ QUR 642.0 - Début Congé:
HEIZ->LAN ANS 642.0 - Début Congé: 08.05.
  DC 80 42 14 07 05 3D 09 C4 00 00 05 08 00 00 00 00 17 ...

Heater ACKs the SET; the subsequent QUR returns the new date with byte 0 = 0; printDateTime() renders 08.05. correctly.

Root cause

The enable_byte field is used by the SET path at BSB_LAN.ino:3256-3258:

param[0]=decodedTelegram.enable_byte;       // active set: byte 0 = 6 (or 1 after fix)
param[0]=decodedTelegram.enable_byte-1;     // disable:    byte 0 = 5 (or 0 after fix)

Siemens RVS21 expects the SET telegram's first payload byte to be 0x01 to activate a vacation period. With enable_byte=6, BSB-LAN was sending 0x06, which the controller rejects (or silently mishandles in some firmware revisions).

The display path at include/print_telegram.h:532 checks if (msg[bus->getPl_start()]==0) for value validity. After a successful SET via the fixed path, the heater's QUR response contains 0x00 in byte 0 — so the display path correctly renders the date. No change is needed in print_telegram.h — the convention there is already correct; only the enable_byte table entry was inconsistent.

Caveat: clear-via-SET (--- payload) is unrelated and remains unsolved

Setting --- to disable a vacation period still NACKs on RVS21 with error code 0x06, regardless of payload shape. Tested:

Payload sent	Result
00 00 05 07 00 00 00 00 17 (enable=0, dates carried over — current set() behavior at BSB_LAN.ino:3351-3357)	NACK 0x06
00 00 00 00 00 00 00 00 17 (enable=0, dates zeroed, date_flag=0x17 preserved)	NACK 0x06
00 00 00 00 00 00 00 00 00 (everything zero)	NACK 0x06

The RVS21 appears not to support disabling a vacation period through the BSB write path — its hardware UI must use a separate "delete" mechanism. This is not an issue with BSB-LAN; the existing carry-over-and-flip-byte logic in set() is correct for controllers that accept disable-via-SET. Users on RVS21 who want to "clear" a vacation period via HA/MQTT can soft-clear by writing both 642 and 643 to a date in the past (e.g. 01.01.). I'm flagging this here only so anyone reading the PR doesn't expect --- to start working as a side-effect of the enable_byte change.

Pre-fix corrupted-state observation

Before fixing enable_byte, repeated failed SET attempts (sending enable=6 or enable=5) appear to leave the heater in a transient state where reads return 01 00 dd mm 00 00 00 00 17 rather than 00 00 dd mm 00 00 00 00 17. In that state printDateTime() correctly identifies the response as "invalid" (byte 0 ≠ 0) and renders ---, even though the heater's hardware screen continues to display the configured dates. After the enable_byte fix and a clean SET cycle from BSB-LAN, the byte-0 field returns to 0x00 and rendering works. This was a red herring during initial investigation but worth knowing about for anyone bisecting similar reports.

Risk to other controllers

enable_byte=6 was the upstream value on day one — anyone whose controller was actually accepting enable=6 for VT_VACATIONPROG would regress with this change. Mitigations:

• The enable_byte field is documented (BSB_LAN_defs.h:596) as taking either 1 or 6 for "regular commands", with the choice depending on the controller. We don't know the population split.
• All four other date-shaped types in the same block (VT_DATETIME, VT_YEAR, VT_DAYMONTH, VT_TIME) use 1 and are known to work across many controllers including Siemens RVS — strong evidence that 1 is the more common convention.
• If a regression on some controller surfaces, a per-device-family override would be the right structural fix; a flat global 1 is the minimal-risk first step.

I've been running with enable_byte=1 for several days on the RVS21.831F/127 with no observed regressions to other date-handling parameters.

Hardware / firmware tested

• Heater: Atlantic Alfea Extensa Duo A.I. 5
• Controller: Siemens RVS21.831F/127 (device family 211, variant 127, OV 4062)
• BSB-LAN: 5.1.1-20260316232429
• Microcontroller: Joy-It ESP32 NodeMCU

[fredlcore]

As mentioned in your other bug report, please do not use AI for anything BSB-LAN specific (other than general C++ coding issues). AI has absolutely no clue about the protocol and starts to hallucinate at some point.
Please send me your dump from your heater via e-mail, then I can check if there is a discrepancy between the dump and what your heater expects. If there is a discrepancy, this would be a first after many, many installations. If, despite your "fix" you still can't disable the setting (---), then the fix is wrong, because the flag is (among others) specifically for enabling/disabling a parameter that supports that.