iobroker.idm-multitalent_002 2.1.2 → 2.1.3

package/README.md

@@ -30,7 +30,7 @@ Currently following versions are supported (if your version is not listed but yo
 
 You need a Ethernet to RS422 converter to connect to the multitalent control.
 **Note** that you have to connect ground/shield of your converter to the ground of the control/heatpump in order to prevent electric influences on the sensor readings.
-There are sensor values and settings values; sensor values are read about twice as often as settings values, so they stay more up to date. Depending on your control's firmware, the adapter either reads a whole group (all sensor values, or all settings values) together in one request, or - for firmwares where that isn't (yet) established - one settings block at a time, round-robin, so a complete refresh of every setting can take a few polling cycles either way (see the Architecture section below for the exact schedule).
+There are sensor values and settings values; the adapter alternates between the two groups turn by turn, so both stay about equally up to date. The adapter reads a whole group (all sensor values, or all settings values) together in one request once every block's exact reply length for that group has been CONFIRMED from real traffic - even for firmwares with hand-verified lengths built in, a short startup phase always re-confirms each one against the actual hardware first (one matching read is enough there; a firmware with no built-in lengths at all needs two consecutive matching reads instead, since it has nothing to start from), no dedicated measurement pass required either way, just the readings the adapter would be taking anyway. Every firmware ends up on the faster combined-request path this way; only how many polling cycles that startup phase takes depends on whether its lengths were already known in advance (see the Architecture section below for the exact schedule). If a combined reply is ever misread, the adapter forgets that group's confirmed lengths and re-confirms it from scratch rather than continuing to trust a value that just proved wrong.
 Values you change yourself are sent to the heat pump right away; the state's acknowledgment only follows once that value is actually read back from the heat pump on its next turn, so it can take a little while to show up.
 
 During bootup of the heatpump control (e.g. after a power loss) no values should be polled. This is currently **NOT** ensured by the adapter. So you **manually** need to **stop** it. If the control of the heatpump did not start due to the adapter then simply stop the adapter and power cycle the control. This should fix the problem. Afterwards you can start the adapter again. I implemented a delayed switch-on of the serial server. This also mitigates the problem.
@@ -56,6 +56,13 @@ Example screenshots of objects:
 ![Status](resources/ioBrokerAdapter-Status.jpg)
 
 ## Changelog
+### 2.1.3 (2026-09-11)
+* (zloe) every data block's wire length - even a hand-verified one built into a firmware's data block definition - now always needs at least one confirming read against the actual connected hardware before multi-block requests trust it, exactly like a value learned from scratch or restored from a previous run; previously a built-in value was trusted outright, forever, with no live check at all. This costs nothing extra in the normal case (that one confirming read happens as part of the startup phase every firmware already goes through) and means every firmware benefits equally from the same safety net: if a multi-block reply is ever misread (lost sync - an unrecognized block id, a block shorter than expected, or leftover trailing bytes), the adapter now forgets every wire length for that whole group and re-confirms it from scratch instead of continuing to (mis)use a length that just proved wrong
+* (zloe) sensor and settings turns now alternate strictly 1:1 (previously sensor got 2 turns for every 1 settings turn) - the 2:1 bias dated from when a settings turn could take much longer than a sensor turn to actually finish; since 2.1.2 a turn always collects its whole group before yielding either way, so the old bias no longer bought sensor anything and settings now gets its fair share of turns too
+* (zloe) the maximum frame length the adapter will buffer before giving up on a stuck/noisy connection is reduced from 2048 to 1024 hex characters (~512 bytes) - still more than double the largest real combined multi-block reply seen so far (S_H726100's 7-block settings group, ~442 hex characters), while catching runaway noise sooner
+* (zloe) new `info`-level log lines, once per connection: how many blocks in each of the sensor/settings groups still need a confirming measurement before that group can switch to multi-block requests (0 means it starts on multi-block requests right away)
+* (zloe) fix: the intro's description of sensor/settings polling still implied a firmware's built-in wire lengths were trusted immediately and that sensor was read twice as often as settings - both are addressed by the two changes above
+
 ### 2.1.2 (2026-09-10)
 * (zloe) fix: 2.1.0's interleaving made a multi-block group's turn give up after exactly one `0171`/`0172` attempt and yield to the other group, even if that attempt hadn't found every block yet - on real hardware, where settings typically needs several re-asks to fully arrive, this meant each of those re-asks now had to wait through two full sensor turns and a connection resync in between, so a full settings refresh actually got close to as slow as before 2.0.0 despite sensor freshness genuinely improving. A group's turn now again collects the whole group - re-asking with a bare `0172` at an adaptive backoff, exactly like the original (2.0.0) settings-only mechanism, just extended to sensor too - before yielding to the next turn in the poll pattern (see the Architecture section)
 
@@ -230,16 +237,21 @@ dropped as too noisy; only this line remains.)
 #### Poll pattern: sensor and settings
 
 Every call to `request_data()` is one "turn", and which of the two groups (sensor or settings) a
-turn is for comes from `IdmSession#pollPattern` (`['sensor', 'sensor', 'settings']`, cycled via
-`pollPatternIndex`): sensor gets two turns for every one settings turn, and always goes first -
-both after connecting and after every settings turn - so the freshest-changing data (sensor
-readings) is never left waiting behind a settings collection, however long that takes. Within a
-turn, each group independently uses either the classic one-block-at-a-time round-robin (unchanged
-since the very first version) or a multi-block request for the whole group at once, whichever it
-currently qualifies for - see the next two sections. Where a group is multi-block-capable, its turn
-collects that WHOLE group - every one of its blocks actually found - before the next turn in the
-pattern begins; it is not interrupted partway through (see the next section for why), so the
-pattern is what settles how *often* each group gets a turn, not how long any one turn takes.
+turn is for comes from `IdmSession#pollPattern` (`['sensor', 'settings']`, cycled via
+`pollPatternIndex`): simple 1:1 alternation, sensor first - both after connecting and after every
+settings turn - so the very first turn after connecting, and every settings turn, is bracketed by a
+fresh sensor read rather than opening the connection with the slower-changing settings data. An
+earlier version gave sensor two turns for every one settings turn, back when a settings turn could
+take several times longer than a sensor turn to actually finish (many re-asks against real
+hardware); now that a turn always collects its whole group before yielding either way (see below),
+that imbalance no longer buys sensor anything extra, so plain alternation is both simpler and gives
+settings its fair share too. Within a turn, each group independently uses either the classic
+one-block-at-a-time round-robin (unchanged since the very first version) or a multi-block request
+for the whole group at once, whichever it currently qualifies for - see the next two sections.
+Where a group is multi-block-capable, its turn collects that WHOLE group - every one of its blocks
+actually found - before the next turn in the pattern begins; it is not interrupted partway through
+(see the next section for why), so the pattern is what settles how *often* each group gets a turn,
+not how long any one turn takes.
 
 #### Multi-block requests, per group
 
@@ -255,13 +267,13 @@ requiring the request to be repeated until everything has actually come back. Be
 multi-block request path is strictly opt-in, gated independently for each of the two groups:
 `IdmProtocol#firmwareSupportsMultiBlockRequestsForBlocks()` (and its `firmwareSupportsMultiBlockRequests()`
 /`firmwareSupportsMultiBlockRequestsForSensors()` convenience wrappers for the settings/sensor
-groups) only returns true once every one of that group's blocks has a TRUSTED wire length - either
+groups) only returns true once every one of that group's blocks has a TRUSTED wire length - always
+CONFIRMED from real traffic (see "wireLength learning" below), whether it started from nothing, from
 an explicit, hand-verified `wireLength` in its data block definition (see
-[`lib/datablocks/README.md`](lib/datablocks/README.md)), or one confirmed from real traffic (see
-"wireLength learning" below). A firmware's two groups can be in different states (e.g. settings
-qualified from its JSON definition while sensor is still being learned, or vice versa); whichever
-group doesn't (yet) qualify keeps using the plain one-block-per-turn round-robin, completely
-unaffected.
+[`lib/datablocks/README.md`](lib/datablocks/README.md)), or from a value restored from a previous
+run. A firmware's two groups can be in different states (e.g. settings qualified while sensor is
+still being confirmed, or vice versa); whichever group doesn't (yet) qualify keeps using the plain
+one-block-per-turn round-robin, completely unaffected.
 
 Where a group is multi-block-capable, `IdmSession#beginGroupCollection()` requests every block in
 that group at once instead of just one - a single `0171` naming the whole group - reusing the very
@@ -282,6 +294,20 @@ stragglers for now (falling back to idle exactly as if it had completed) and sta
 fresh - asking for every one of that group's blocks again - next time that group's turn comes
 around, so nothing is permanently lost, only deferred.
 
+A reply that can't be fully parsed at all (`IdmProtocol#parse_multi_block_reply()`'s "lost sync" -
+an unrecognized block id, a block truncated shorter than its wire length, or trailing bytes left
+over after the last complete block) is treated differently from a routine partial reply: it means
+one of the group's wire lengths is no longer correct, though not which one, so
+`IdmSession#handleMultiBlockDataReply()` immediately abandons the collection and calls
+`IdmProtocol#forgetMeasuredWireLengths()` to discard EVERY one of that group's wire lengths - both
+confirmed values and unconfirmed seeds, deliberately not re-seeding from the same (possibly wrong)
+built-in value - before falling back to idle. `firmwareSupportsMultiBlockRequestsForBlocks()` then
+correctly returns false for the group, so its very next turn drops back to the classic
+one-block-at-a-time round-robin and re-confirms every block from scratch, exactly like a block seen
+for the first time ever. This benefits every firmware equally, not just the ones with hand-verified
+lengths: whatever the length's original source, a wrong assumption never lingers past the collection
+it broke.
+
 This deliberately mirrors how the very first (2.0.0) version of this feature worked, rather than
 resending a fresh `0171` on every re-ask and force-yielding to the other group after a single
 attempt regardless of whether the collection had finished (as a brief interim design in 2.1.0 did):
@@ -303,17 +329,35 @@ cost, for any block that doesn't already have a trusted length. A measurement al
 immediately, though - `IdmProtocol#recordMeasuredWireLength()` requires the SAME length twice in a
 row (a disagreement logs a warning and restarts the count from the new value, never averages)
 before treating it as confirmed, in case a firmware turns out to add a different number of
-undocumented bytes on different occasions. Every outcome is logged (routine progress at `info`, a
-disagreement at `warn`), and the moment a group's every block becomes trusted this way, that's
-logged too and multi-block requests for it start from its very next turn. Each newly CONFIRMED
-length is also persisted to the `info.measuredWireLengths` ioBroker state (`onWireLengthLearned`
-hook, wired up in `main.js`) as `{"<firmware version>": {"<block id>": <byte length>}}`, and
-restored on the next adapter start (`loadMeasuredWireLengths()`, before the session starts) via
-`IdmProtocol#seedMeasuredWireLength()` - but only as a CANDIDATE, not as already-trusted: every
-restart still re-confirms it with one fresh matching measurement before relying on it again, in
-case some heat pump setting turns out to affect a block's length after all. See the "wireLength
-learning" tests in `lib/idm-session.test.js` (and `idm-protocol.test.js` for the underlying
-confirm/mismatch/seed mechanics).
+undocumented bytes on different occasions.
+
+That two-in-a-row rule has exactly one shortcut, applied uniformly regardless of where a starting
+value came from: `IdmProtocol#seedMeasuredWireLength()` seeds a length as an unconfirmed CANDIDATE
+rather than an already-trusted value, and a candidate counts as the FIRST of the two required
+measurements, so only one further fresh, matching read is needed to confirm it - never an instant
+grant. Two things get seeded this way: a value restored from a previous adapter run (see below), and
+- as of this release - an explicit, hand-verified `wireLength` in a firmware's data block definition
+(see [`lib/datablocks/README.md`](lib/datablocks/README.md)), seeded by `IdmProtocol#initialize()`
+for every block that declares one. Previously a declared `wireLength` was trusted outright and
+forever, with no live check at all; now it still costs nothing extra in the normal case (the one
+confirming read happens as part of the startup phase every firmware already goes through), but every
+firmware - built-in lengths or not - gets the same live safety net, and a firmware update or
+undocumented quirk that changes a block's actual length no longer goes undetected forever.
+
+Every outcome is logged (routine progress at `info`, a disagreement at `warn`), and the moment a
+group's every block becomes trusted this way, that's logged too and multi-block requests for it
+start from its very next turn. Each newly CONFIRMED length is also persisted to the
+`info.measuredWireLengths` ioBroker state (`onWireLengthLearned` hook, wired up in `main.js`) as
+`{"<firmware version>": {"<block id>": <byte length>}}`, and restored on the next adapter start
+(`loadMeasuredWireLengths()`, before the session starts) via `seedMeasuredWireLength()` - the same
+seed-then-confirm path described above, so it too needs one fresh matching measurement before
+relying on it again, in case some heat pump setting turns out to affect a block's length after all.
+
+A length - seeded or fully confirmed - can also be forgotten outright: see the "lost sync" handling
+in the "Multi-block requests, per group" section above (`IdmProtocol#forgetMeasuredWireLengths()`),
+which forces a whole group back through this same measurement path from scratch after a multi-block
+reply couldn't be parsed. See the "wireLength learning" tests in `lib/idm-session.test.js` (and
+`idm-protocol.test.js` for the underlying confirm/mismatch/seed/forget mechanics).
 
 ### Overriding the data blocks without an adapter update
 The instance setting **"Custom data blocks directory"** (`native.dataBlocksDir`) can point at a directory of your own such files. Each file's `"version"` field is matched against the version string the heat pump reports after connecting - a match REPLACES that version's bundled definition entirely (it is not merged field-by-field), useful for adding min/max limits you have verified for your own installation, fixing a field, or adding a not-yet-supported control version, all without reinstalling or upgrading the adapter. Versions with no matching (and valid) custom file keep using their bundled definition. A file that fails validation, or two files claiming the same version, are both rejected with a warning in the adapter's log - the bundled definition (if any) is kept in that case.

package/io-package.json

@@ -1,8 +1,21 @@
 {
   "common": {
     "name": "idm-multitalent_002",
-    "version": "2.1.2",
+    "version": "2.1.3",
     "news": {
+      "2.1.3": {
+        "en": "every data block's wire length now always needs a fresh confirming read from the actual connected hardware before multi-block requests trust it - even a hand-verified value built into a firmware's data block definition, which used to be trusted outright and forever with no live check at all. This costs nothing extra in the normal case (the confirming read happens during the startup phase every firmware already goes through), and means that if a multi-block reply is ever misread (an unrecognized block id, a block shorter than expected, or leftover trailing bytes), the adapter now forgets that whole group's wire lengths and re-confirms them from scratch instead of continuing to trust a value that just proved wrong. Also: sensor and settings turns now alternate strictly 1:1 instead of 2:1 (a turn has collected its whole group before yielding since 2.1.2, so the old sensor bias no longer bought it anything, and settings now gets its fair share); the frame-length safety cap is reduced from 2048 to 1024 hex characters (still more than double the largest real combined reply seen so far); and new info-level log lines report, once per connection, how many blocks in each group still need a confirming measurement",
+        "de": "die Leitungslänge jedes Datenblocks benötigt jetzt immer eine erneute Bestätigung durch einen frischen Messwert von der tatsächlich angeschlossenen Hardware, bevor multi-block-Anfragen ihr vertrauen - selbst ein händisch verifizierter Wert in der Datenblock-Definition einer Firmware, der bisher sofort und dauerhaft ohne jede Live-Prüfung vertraut wurde. Im Normalfall kostet das nichts zusätzlich (die Bestätigung erfolgt während der Startphase, die jede Firmware ohnehin durchläuft), und es bedeutet: wird eine multi-block-Antwort einmal falsch gelesen (eine unbekannte Blockkennung, ein kürzerer Block als erwartet, oder übrig gebliebene Bytes am Ende), vergisst der Adapter jetzt alle Leitungslängen dieser ganzen Gruppe und bestätigt sie von Grund auf neu, statt weiter einem Wert zu vertrauen, der sich gerade als falsch erwiesen hat. Außerdem: Sensor- und Settings-Durchläufe wechseln sich jetzt strikt im Verhältnis 1:1 ab statt 2:1 (ein Durchlauf sammelt seit 2.1.2 immer die ganze Gruppe, bevor er abgibt, sodass die alte Sensor-Bevorzugung nichts mehr brachte und Settings jetzt seinen fairen Anteil bekommt); die Sicherheitsgrenze für die Rahmenlänge wurde von 2048 auf 1024 Hex-Zeichen reduziert (immer noch mehr als doppelt so viel wie die bisher größte real beobachtete kombinierte Antwort); und neue Log-Zeilen auf Info-Ebene melden einmal pro Verbindung, wie viele Blöcke in jeder Gruppe noch eine bestätigende Messung benötigen",
+        "ru": "теперь длина блока данных на линии всегда требует свежего подтверждающего измерения от реально подключённого оборудования, прежде чем multi-block-запросы начнут ей доверять - даже вручную проверенное значение, встроенное в описание блоков данных прошивки, которое раньше доверялось сразу и навсегда без какой-либо живой проверки. В обычном случае это не стоит ничего лишнего (подтверждающее чтение происходит во время начальной фазы, которую и так проходит каждая прошивка), и означает, что если multi-block-ответ когда-либо будет прочитан неверно (нераспознанный идентификатор блока, блок короче ожидаемого или оставшиеся лишние байты), адаптер теперь забывает все длины блоков этой группы и подтверждает их заново с нуля, вместо того чтобы продолжать доверять значению, которое только что оказалось неверным. Также: такты сенсоров и настроек теперь строго чередуются 1:1 вместо 2:1 (начиная с 2.1.2 такт всегда собирает всю группу целиком, прежде чем передать управление, поэтому старое преимущество сенсоров больше ничего не давало, и настройки теперь получают свою справедливую долю тактов); защитный предел длины кадра снижен с 2048 до 1024 шестнадцатеричных символов (всё ещё более чем вдвое больше самого крупного реального объединённого ответа, встреченного до сих пор); и новые строки журнала уровня info сообщают, один раз за соединение, сколько блоков в каждой группе всё ещё нуждаются в подтверждающем измерении",
+        "pt": "o comprimento de cada bloco de dados agora sempre precisa de uma nova leitura de confirmação a partir do hardware realmente conectado antes que as requisições multi-block confiem nele - mesmo um valor verificado manualmente e embutido na definição de blocos de dados de um firmware, que antes era confiado de imediato e para sempre, sem qualquer verificação ao vivo. Isso não custa nada extra no caso normal (a leitura de confirmação ocorre durante a fase inicial que todo firmware já passa), e significa que, se uma resposta multi-block for lida incorretamente (um id de bloco não reconhecido, um bloco mais curto que o esperado, ou bytes sobrando no final), o adaptador agora esquece os comprimentos de todo aquele grupo e os reconfirma do zero, em vez de continuar confiando em um valor que acabou de se mostrar errado. Além disso: os turnos de sensores e configurações agora se alternam estritamente 1:1 em vez de 2:1 (desde a 2.1.2 um turno sempre coleta o grupo inteiro antes de passar adiante, então o antigo favorecimento dos sensores deixou de trazer vantagem, e as configurações agora recebem sua parte justa); o limite de segurança do comprimento do quadro foi reduzido de 2048 para 1024 caracteres hexadecimais (ainda mais que o dobro da maior resposta combinada real já observada); e novas linhas de log de nível info relatam, uma vez por conexão, quantos blocos em cada grupo ainda precisam de uma medição de confirmação",
+        "nl": "de lengte van elk datablok heeft nu altijd een nieuwe bevestigende meting van de daadwerkelijk aangesloten hardware nodig voordat multi-block-verzoeken deze vertrouwen - zelfs een handmatig geverifieerde waarde die in de datablok-definitie van een firmware is ingebouwd, die voorheen meteen en voorgoed werd vertrouwd zonder enige live controle. In het normale geval kost dit niets extra (de bevestigende meting vindt plaats tijdens de opstartfase die elke firmware toch al doorloopt), en het betekent dat als een multi-block-antwoord ooit verkeerd wordt gelezen (een onbekende blok-id, een blok korter dan verwacht, of overgebleven bytes aan het eind), de adapter nu alle lengtes van die hele groep vergeet en ze opnieuw vanaf nul bevestigt, in plaats van te blijven vertrouwen op een waarde die net onjuist bleek. Ook: sensor- en instellingenbeurten wisselen elkaar nu strikt 1:1 af in plaats van 2:1 (sinds 2.1.2 verzamelt een beurt altijd de hele groep voordat hij wordt doorgegeven, dus de oude sensor-voorkeur leverde niets meer op, en instellingen krijgen nu hun eerlijke aandeel); de veiligheidsgrens voor de framelengte is verlaagd van 2048 naar 1024 hex-tekens (nog steeds meer dan het dubbele van het grootste echte gecombineerde antwoord dat tot nu toe is gezien); en nieuwe logregels op info-niveau melden, eenmaal per verbinding, hoeveel blokken in elke groep nog een bevestigende meting nodig hebben",
+        "fr": "la longueur de chaque bloc de données nécessite désormais toujours une nouvelle lecture de confirmation depuis le matériel réellement connecté avant que les requêtes multi-block ne lui fassent confiance - même une valeur vérifiée manuellement et intégrée à la définition des blocs de données d'un firmware, qui était auparavant approuvée d'emblée et pour toujours, sans aucune vérification en direct. Cela ne coûte rien de plus dans le cas normal (la lecture de confirmation a lieu pendant la phase de démarrage que chaque firmware traverse de toute façon), et cela signifie que si une réponse multi-block est un jour mal lue (un identifiant de bloc non reconnu, un bloc plus court que prévu, ou des octets restants à la fin), l'adaptateur oublie désormais toutes les longueurs de ce groupe entier et les reconfirme depuis le début, au lieu de continuer à faire confiance à une valeur qui vient de se révéler fausse. Par ailleurs : les tours des capteurs et des réglages alternent désormais strictement 1:1 au lieu de 2:1 (depuis la 2.1.2, un tour collecte toujours le groupe entier avant de céder la main, si bien que l'ancien avantage des capteurs n'apportait plus rien, et les réglages reçoivent désormais leur juste part) ; la limite de sécurité de longueur de trame est réduite de 2048 à 1024 caractères hexadécimaux (toujours plus du double de la plus grande réponse combinée réelle observée jusqu'ici) ; et de nouvelles lignes de journal de niveau info indiquent, une fois par connexion, combien de blocs de chaque groupe ont encore besoin d'une mesure de confirmation",
+        "it": "la lunghezza di ogni blocco di dati richiede ora sempre una nuova lettura di conferma dall'hardware effettivamente collegato prima che le richieste multi-block se ne fidino - anche un valore verificato manualmente e integrato nella definizione dei blocchi di dati di un firmware, che prima veniva considerato attendibile subito e per sempre, senza alcun controllo dal vivo. Nel caso normale questo non costa nulla in più (la lettura di conferma avviene durante la fase di avvio che ogni firmware attraversa comunque), e significa che se una risposta multi-block viene letta male (un id di blocco non riconosciuto, un blocco più corto del previsto, o byte residui alla fine), l'adattatore ora dimentica tutte le lunghezze di quell'intero gruppo e le riconferma da zero, invece di continuare a fidarsi di un valore che si è appena rivelato sbagliato. Inoltre: i turni di sensori e impostazioni ora si alternano rigorosamente 1:1 invece che 2:1 (dalla 2.1.2 un turno raccoglie sempre l'intero gruppo prima di cedere il turno, quindi il vecchio vantaggio dei sensori non portava più nulla, e le impostazioni ora ricevono la loro giusta quota); il limite di sicurezza sulla lunghezza del frame è ridotto da 2048 a 1024 caratteri esadecimali (ancora più del doppio della più grande risposta combinata reale osservata finora); e nuove righe di log a livello info riportano, una volta per connessione, quanti blocchi in ciascun gruppo necessitano ancora di una misurazione di conferma",
+        "es": "la longitud de cada bloque de datos ahora siempre necesita una nueva lectura de confirmación desde el hardware realmente conectado antes de que las solicitudes multi-block confíen en ella - incluso un valor verificado manualmente e incorporado en la definición de bloques de datos de un firmware, que antes se confiaba de inmediato y para siempre, sin ninguna comprobación en vivo. Esto no cuesta nada extra en el caso normal (la lectura de confirmación ocurre durante la fase de inicio por la que ya pasa cada firmware), y significa que si una respuesta multi-block se lee mal alguna vez (un id de bloque no reconocido, un bloque más corto de lo esperado, o bytes sobrantes al final), el adaptador ahora olvida todas las longitudes de ese grupo completo y las reconfirma desde cero, en lugar de seguir confiando en un valor que acaba de demostrar ser incorrecto. Además: los turnos de sensores y configuración ahora se alternan estrictamente 1:1 en lugar de 2:1 (desde la 2.1.2 un turno siempre recopila todo el grupo antes de ceder el turno, por lo que el antiguo favoritismo hacia los sensores ya no aportaba nada, y la configuración ahora recibe su parte justa); el límite de seguridad de longitud de trama se reduce de 2048 a 1024 caracteres hexadecimales (todavía más del doble de la mayor respuesta combinada real vista hasta ahora); y nuevas líneas de registro de nivel info informan, una vez por conexión, cuántos bloques de cada grupo aún necesitan una medición de confirmación",
+        "pl": "długość każdego bloku danych zawsze wymaga teraz świeżego potwierdzającego odczytu z faktycznie podłączonego sprzętu, zanim zaufają jej żądania multi-block - nawet ręcznie zweryfikowana wartość wbudowana w definicję bloków danych danej wersji firmware, której wcześniej ufano od razu i na zawsze, bez żadnej weryfikacji na żywo. W normalnym przypadku nie kosztuje to nic dodatkowego (potwierdzający odczyt następuje podczas fazy startowej, którą i tak przechodzi każdy firmware), i oznacza to, że jeśli odpowiedź multi-block zostanie kiedyś błędnie odczytana (nierozpoznany identyfikator bloku, blok krótszy niż oczekiwano lub pozostałe bajty na końcu), adapter teraz zapomina wszystkie długości całej tej grupy i potwierdza je od nowa, zamiast dalej ufać wartości, która właśnie okazała się błędna. Ponadto: tury czujników i ustawień na przemian ściśle 1:1 zamiast 2:1 (od wersji 2.1.2 tura zawsze zbiera całą grupę przed oddaniem tury, więc stare uprzywilejowanie czujników nic już nie dawało, a ustawienia dostają teraz swoją sprawiedliwą część); limit bezpieczeństwa długości ramki zmniejszono z 2048 do 1024 znaków szesnastkowych (nadal ponad dwukrotnie więcej niż największa dotychczas zaobserwowana rzeczywista połączona odpowiedź); a nowe wpisy dziennika na poziomie info raportują, raz na połączenie, ile bloków w każdej grupie wciąż wymaga potwierdzającego pomiaru",
+        "zh-cn": "现在,每个数据区块的线路长度在多区块请求信任它之前,始终需要来自实际连接硬件的一次新的确认读取——即使是固件数据区块定义中内置的、经过人工验证的数值,以前也是被立即且永久信任、完全没有任何实时校验的。在正常情况下这不会带来额外开销(确认读取发生在每个固件本来就会经历的启动阶段),并且这意味着:如果某次多区块应答被误读(出现无法识别的区块标识、区块比预期短,或末尾残留多余字节),适配器现在会忘记整个分组的所有线路长度,并从头重新确认,而不是继续信任一个刚刚被证明错误的数值。此外:传感器与设置的轮询回合现在严格按 1:1 交替,而不再是 2:1(自 2.1.2 起,一个回合总会先采集完整个分组再让出,因此旧有的传感器优先已不再带来任何好处,设置现在也能获得公平的回合份额);帧长度安全上限从 2048 个十六进制字符降低到 1024 个(仍是迄今观察到的最大实际合并应答的两倍多);新增的 info 级别日志会在每次连接时报告每个分组中还有多少区块需要确认测量",
+        "uk": "довжина кожного блоку даних тепер завжди потребує свіжого підтверджувального читання з реально підключеного обладнання, перш ніж multi-block-запити почнуть їй довіряти - навіть вручну перевіреному значенню, вбудованому в опис блоків даних прошивки, якому раніше довіряли одразу й назавжди без жодної живої перевірки. У звичайному випадку це не коштує нічого додаткового (підтверджувальне читання відбувається під час стартової фази, яку й так проходить кожна прошивка), і означає, що якщо multi-block-відповідь колись буде прочитано неправильно (нерозпізнаний ідентифікатор блоку, блок коротший за очікуваний, або зайві байти в кінці), адаптер тепер забуває всі довжини цієї цілої групи і підтверджує їх заново з нуля, замість того щоб і далі довіряти значенню, яке щойно виявилося хибним. Також: такти датчиків і налаштувань тепер строго чергуються 1:1 замість 2:1 (від версії 2.1.2 такт завжди збирає всю групу цілком, перш ніж передати чергу, тому стара перевага датчиків більше нічого не давала, і налаштування тепер отримують свою справедливу частку); захисну межу довжини кадру знижено з 2048 до 1024 шістнадцяткових символів (усе ще більш ніж удвічі більше за найбільшу реальну об'єднану відповідь, яка траплялася досі); а нові рядки журналу рівня info повідомляють, один раз на з'єднання, скільки блоків у кожній групі ще потребують підтверджувального вимірювання"
+      },
       "2.1.2": {
         "en": "fix: a multi-block group's turn (sensor or settings) used to give up after exactly one request/reply attempt and hand off to the other group even if it hadn't found every block yet - on real hardware, where settings often needs several re-asks to fully arrive, this made settings collection nearly as slow as before 2.0.0 despite sensor freshness having improved. A turn now collects the whole group - re-asking with an adaptive backoff, exactly like the original 2.0.0 mechanism - before handing off, extended to sensor too",
         "de": "Fehlerbehebung: der Durchlauf einer multi-block-fähigen Gruppe (Sensor oder Settings) brach bisher nach genau einem Anfrage-/Antwortversuch ab und übergab an die andere Gruppe, selbst wenn noch nicht alle Blöcke gefunden waren - auf echter Hardware, wo Settings oft mehrere Nachfragen benötigen, bis alles vollständig da ist, machte das die Settings-Sammlung fast so langsam wie vor 2.0.0, obwohl sich die Aktualität der Sensordaten verbessert hatte. Ein Durchlauf sammelt jetzt die ganze Gruppe - mit adaptivem Backoff nachfragend, genau wie beim ursprünglichen 2.0.0-Mechanismus, jetzt auch für Sensor - bevor übergeben wird",
@@ -80,19 +93,6 @@
         "pl": "wiersz logu pełnego cyklu wypisuje teraz aktualne opóźnienie treści każdego bloku, a adaptacyjne opóźnienie na blok jest teraz zmniejszane coraz drobniejszymi krokami (aż do 1ms) zamiast zawsze o stałe 100ms",
         "zh-cn": "完整周期日志行现在会列出每个数据块当前的内容延迟,自适应的按块延迟现在以越来越精细的步长(最低至1毫秒)递减,而不再总是固定的100毫秒",
         "uk": "рядок журналу повного циклу тепер показує поточну затримку вмісту кожного блока, а адаптивна затримка на блок тепер зменшується дедалі дрібнішими кроками (аж до 1мс) замість фіксованих 100мс"
-      },
-      "1.3.8": {
-        "en": "remove the frequent per-sweep 'completed one full poll cycle' log line entirely (fired every ~14s) - only the much less frequent full-coverage cycle line remains, confirmed correct against real production logs",
-        "de": "die häufige Log-Zeile 'completed one full poll cycle' (feuerte alle ~14s) komplett entfernt - nur die deutlich seltenere Vollzyklus-Zeile bleibt, deren Korrektheit anhand echter Produktions-Logs bestätigt wurde",
-        "ru": "часто встречающаяся строка журнала 'completed one full poll cycle' (срабатывала каждые ~14 с) полностью удалена - осталась только гораздо более редкая строка полного цикла, корректность которой подтверждена по реальным журналам",
-        "pt": "removida por completo a linha de log frequente 'completed one full poll cycle' (disparava a cada ~14s) - resta apenas a linha do ciclo completo, bem mais rara, cuja correção foi confirmada em logs reais de produção",
-        "nl": "de veelvoorkomende logregel 'completed one full poll cycle' (vuurde elke ~14s af) volledig verwijderd - alleen de veel minder frequente full-coverage-cyclusregel blijft over, waarvan de juistheid is bevestigd aan de hand van echte productielogs",
-        "fr": "suppression complète de la ligne de log fréquente 'completed one full poll cycle' (se déclenchait toutes les ~14s) - seule la ligne de cycle complet, bien plus rare, reste, sa justesse ayant été confirmée sur de vrais logs de production",
-        "it": "rimossa completamente la frequente riga di log 'completed one full poll cycle' (scattava ogni ~14s) - resta solo la riga del ciclo completo, molto meno frequente, la cui correttezza è stata confermata su log di produzione reali",
-        "es": "eliminada por completo la línea de registro frecuente 'completed one full poll cycle' (se disparaba cada ~14s) - solo queda la línea del ciclo completo, mucho menos frecuente, cuya corrección se confirmó con registros reales de producción",
-        "pl": "całkowicie usunięto częsty wiersz logu 'completed one full poll cycle' (uruchamiał się co ~14s) - pozostał tylko znacznie rzadszy wiersz pełnego cyklu, którego poprawność potwierdzono na rzeczywistych logach produkcyjnych",
-        "zh-cn": "彻底移除了频繁出现的 'completed one full poll cycle' 日志行(约每 14 秒触发一次)- 仅保留频率低得多的完整周期日志行,其正确性已通过真实生产日志验证",
-        "uk": "повністю видалено частий рядок журналу 'completed one full poll cycle' (спрацьовував що ~14с) - залишився лише значно рідший рядок повного циклу, коректність якого підтверджено на реальних лог-файлах"
       }
     },
     "titleLang": {

package/lib/datablocks/README.md

@@ -46,12 +46,18 @@ definition (if any) is kept in that case rather than guessing which one to use.
     wire (which can be a few bytes longer than its documented fields account for - the extra
     bytes are simply ignored, they just have to be skipped correctly). **Only add this once you
     have verified it against real hardware traffic.** An explicit, hand-verified `wireLength`
-    here is trusted immediately; without one, the adapter measures and confirms it for itself
-    from ordinary traffic at runtime instead (see the main README's "wireLength learning"
-    section) - either way, once every block in a firmware's sensor or settings group has a
-    trusted length, that whole group is requested together in one combined multi-block request
-    instead of one block at a time. Leaving this out just means it takes a little longer to kick
-    in after every restart, not that it never will.
+    here still isn't trusted outright, though - the adapter always confirms it once against the
+    actual connected hardware before relying on it (one matching live read is enough, since a
+    verified value already starts a step ahead of a block with none); without one, the adapter
+    measures and confirms it for itself entirely from ordinary traffic at runtime instead, needing
+    two consecutive matching reads since it has nothing to start from (see the main README's
+    "wireLength learning" section) - either way, once every block in a firmware's sensor or
+    settings group has a confirmed length, that whole group is requested together in one combined
+    multi-block request instead of one block at a time, and if a combined reply ever turns out to
+    be misread, the whole group's confirmed lengths (this one included) are forgotten and
+    re-confirmed from scratch rather than continuing to trust a value that just proved wrong.
+    Leaving this out just means it takes one extra confirming read to kick in after every restart,
+    not that it never will.
   * `definition` - array of fields:
     * `statename` - the ioBroker state created for this field (empty for padding/unused positions)
     * `field` - internal field name (only used for debugging/comments)

package/lib/idm-protocol.js

@@ -5,12 +5,15 @@ const idm_datablocks = require('./idm_datablocks');
 const idm_utils = require('./idm-utils');
 
 // Generous upper bound on how many characters add_to_packet() will accumulate between a SOH
-// and the next ETX/EOT before giving up on the frame. The largest real data block payload is a
-// few hundred hex characters, so this is purely defensive: without it, a stream that never
-// sends a terminating ETX (line noise on the RS422/TCP path, a misbehaving serial-to-TCP
-// converter, ...) would grow received_data_packet/receive_chksum forever, since only a
-// genuine SOH/ETX/EOT byte - never plain length - used to trigger a state change or error.
-const MAX_FRAME_LENGTH = 2048;
+// and the next ETX/EOT before giving up on the frame. This is purely defensive: without it, a
+// stream that never sends a terminating ETX (line noise on the RS422/TCP path, a misbehaving
+// serial-to-TCP converter, ...) would grow received_data_packet/receive_chksum forever, since
+// only a genuine SOH/ETX/EOT byte - never plain length - is used to trigger a state change or
+// error. 1024 hex characters (~512 bytes) comfortably covers the largest real combined
+// multi-block reply seen so far (S_H726100's 7-block settings group, ~442 hex characters) with
+// more than double headroom, while still catching runaway noise well before it could be mistaken
+// for a plausible heat-pump-control reply.
+const MAX_FRAME_LENGTH = 1024;
 
 /**
  * Protocol/data-block state for ONE heat pump connection.
@@ -43,17 +46,24 @@ class IdmProtocol {
         this.remaining_data = '';
 
         // version -> Map(block -> {length, confirmed}) - see recordMeasuredWireLength() and
-        // getVerifiedBlockWireLength(). Learned passively from real single-block traffic for a
-        // block that has no JSON-declared "wireLength" yet, so that firmware EVENTUALLY qualifies
-        // for multi-block requests too (see firmwareSupportsMultiBlockRequestsForBlocks())
-        // without a maintainer having to hand-verify it against a traffic capture first - see
-        // IdmSession's wireLength-learning hook in receive_data().
+        // getVerifiedBlockWireLength(). Every block goes through this, one way or another, before
+        // it's trusted for multi-block requests (see firmwareSupportsMultiBlockRequestsForBlocks()):
+        // seeded with a starting candidate - a JSON-declared "wireLength" (initialize()) or a
+        // value restored from a previous run (main.js, via seedMeasuredWireLength()) - or, with
+        // no seed at all, learned entirely from scratch via two consecutive live measurements.
+        // Either way it's real traffic (see IdmSession's wireLength-learning hook in
+        // receive_data()) that ultimately confirms a length, never a maintainer's or a previous
+        // run's say-so alone.
         this.measuredWireLengths = new Map();
     }
 
     /**
      * Loads the hardware data block definitions (see idm_datablocks.js) and populates the
-     * lookup Maps used by the rest of this class, one entry per firmware version.
+     * lookup Maps used by the rest of this class, one entry per firmware version. Also seeds an
+     * unconfirmed measuredWireLengths CANDIDATE (see seedMeasuredWireLength()) for every block
+     * that has a JSON-declared "wireLength" - a hand-verified starting guess, not an instant
+     * grant (see getVerifiedBlockWireLength()'s comment for why every block, JSON-declared or
+     * not, needs at least one live confirming measurement before multi-block requests trust it).
      * @param {string} [customDir] absolute path to a directory of custom per-version data
      *   blocks files, e.g. from the adapter's "dataBlocksDir" setting - a version with no
      *   matching (and valid) file there keeps using its bundled definition
@@ -71,10 +81,13 @@ class IdmProtocol {
         this.speed.clear();
         // Also reset here: main.js always calls initialize() (constructor, then again in
         // onReady() with the configured customDir) BEFORE ever seeding a measurement persisted
-        // from a previous run (see seedMeasuredWireLength()), so this is a no-op for real
-        // operation - but it keeps a test suite that reuses one IdmProtocol instance across
-        // several initialize() calls (e.g. one per `it`, via a shared beforeEach) from leaking
-        // measurements learned in one test into the next.
+        // from a previous run (see seedMeasuredWireLength()), so the JSON seeding below is always
+        // what a real run starts from, with main.js's persisted-state seeding layered on top of
+        // it afterwards (overwriting a block's candidate where a persisted one exists - both are
+        // just unconfirmed candidates either way, so it makes no difference which one a block
+        // happens to start from). This clear() also keeps a test suite that reuses one
+        // IdmProtocol instance across several initialize() calls (e.g. one per `it`, via a shared
+        // beforeEach) from leaking measurements learned in one test into the next.
         this.measuredWireLengths.clear();
 
         for (const [version, data] of byVersion) {
@@ -83,6 +96,11 @@ class IdmProtocol {
             this.sensorDataBlocks.set(version, data.sensorBlocks);
             this.settingsDataBlocks.set(version, data.settingsBlocks);
             this.speed.set(version, data.speed);
+            for (const block of data.data_blocks) {
+                if (typeof block.wireLength === 'number') {
+                    this.seedMeasuredWireLength(version, block.block_number, block.wireLength);
+                }
+            }
         }
     }
 
@@ -195,10 +213,14 @@ class IdmProtocol {
     /**
      * The TRUSTED wire length for `block`/`version`, for anything that needs to walk a
      * multi-block reply's byte boundaries (see parse_multi_block_reply()) rather than just
-     * tolerate extra trailing bytes the way a single-block reply's own framing already does:
-     * either a JSON-declared "wireLength" (hand-verified by a maintainer against a real traffic
-     * capture), or a length CONFIRMED from two consecutive live measurements (see
-     * recordMeasuredWireLength()/seedMeasuredWireLength()). Deliberately never falls back to the
+     * tolerate extra trailing bytes the way a single-block reply's own framing already does: a
+     * length CONFIRMED via recordMeasuredWireLength() - either from two consecutive live
+     * measurements, or from just one live measurement matching a SEEDED candidate (a
+     * JSON-declared "wireLength", seeded by initialize(); or a value restored from a previous
+     * adapter run, seeded by main.js via seedMeasuredWireLength()). A JSON-declared "wireLength"
+     * is deliberately NOT trusted outright here, hand-verified or not: it's still only a
+     * candidate until this run's own traffic confirms it once, exactly like a restored value -
+     * see seedMeasuredWireLength()'s comment for why. Deliberately never falls back to the
      * documented field-sum getBlockWireLength() does for everything else - that fallback is a
      * plausible guess (blocks are known to carry undocumented trailing bytes beyond their listed
      * fields), and a wrong guess here wouldn't just mis-parse one block's own fields, it would
@@ -208,9 +230,6 @@ class IdmProtocol {
      * @returns {number | null}
      */
     getVerifiedBlockWireLength(version, block) {
-        const definitions = this.dataDefinitions.get(version);
-        const entry = definitions ? definitions.data_blocks.find((b) => b.block_number === block) : undefined;
-        if (entry && typeof entry.wireLength === 'number') return entry.wireLength;
         const measured = version ? this.measuredWireLengths.get(version)?.get(block) : undefined;
         if (measured && measured.confirmed) return measured.length;
         return null;
@@ -219,21 +238,22 @@ class IdmProtocol {
     /**
      * Records one single-block reply's ACTUAL wire length for `block`/`version`, learned
      * passively from real traffic (see IdmSession's wireLength-learning hook in receive_data(),
-     * the only caller) for a block that has no JSON-declared "wireLength" yet - a no-op once the
-     * block already has a trusted length (see getVerifiedBlockWireLength()), whether from the
-     * data blocks file or an earlier confirmed measurement.
+     * the only caller) - a no-op once the block already has a trusted length (see
+     * getVerifiedBlockWireLength()).
      *
      * A single-block reply is fully checksum-verified before this is ever called (see
      * add_to_packet()), so a CORRUPTED length can't slip in that way - what this guards against
      * instead is something we simply don't know either way, never having tested it: whether a
      * given firmware could append a different number of undocumented reserved/padding bytes on
-     * different occasions. Two CONSECUTIVE matching measurements are required before a length is
-     * trusted enough to unlock multi-block requests for its group (see
-     * firmwareSupportsMultiBlockRequestsForBlocks()) - a disagreement simply restarts the count
-     * from the new value rather than ever averaging or guessing which one was right. A value
-     * restored from a previous run (see seedMeasuredWireLength()) counts as the FIRST of those
-     * two measurements, not a free pass - every restart re-confirms once before its group is
-     * trusted for multi-block again, exactly like a block seen for the very first time.
+     * different occasions, or even change its wire format between installations or over time
+     * (e.g. a firmware update) despite reporting the same version string. Two CONSECUTIVE
+     * matching measurements are required before a length is trusted enough to unlock multi-block
+     * requests for its group (see firmwareSupportsMultiBlockRequestsForBlocks()) - a disagreement
+     * simply restarts the count from the new value rather than ever averaging or guessing which
+     * one was right. A SEEDED candidate (see seedMeasuredWireLength() - a value restored from a
+     * previous run, or a JSON-declared "wireLength") counts as the FIRST of those two
+     * measurements, not a free pass - every restart re-confirms once before its group is trusted
+     * for multi-block again, exactly like a block seen for the very first time ever.
      * @param {string | undefined} version
      * @param {string} block
      * @param {number} length byte length of this reply's payload (after the 01F200+block header)
@@ -256,18 +276,27 @@ class IdmProtocol {
     }
 
     /**
-     * Seeds `length` as a CANDIDATE measured wireLength for `block`/`version`, restored from a
-     * PREVIOUS adapter run (see main.js, which persists confirmed measurements to an ioBroker
-     * state and replays them here via this method on startup, before the connection is started).
+     * Seeds `length` as a CANDIDATE measured wireLength for `block`/`version`. Two sources call
+     * this, both feeding the SAME "needs one fresh confirming measurement" pipeline:
+     *   - main.js, restoring a value persisted from a PREVIOUS adapter run (an ioBroker state),
+     *     before the connection is started;
+     *   - initialize(), for every block with a JSON-declared "wireLength" in its data blocks
+     *     file - a hand-verified starting guess, not an instant grant (see
+     *     getVerifiedBlockWireLength()'s comment for why).
      *
      * Deliberately does NOT mark it confirmed outright - every restart re-measures once before
      * trusting it again (see recordMeasuredWireLength(), whose normal "two consecutive matching
      * measurements" rule this feeds into as if the seeded value were the first of those two): we
-     * have no hard evidence a control's wire length is fixed forever rather than depending on
-     * some heat pump setting, so treating a restored value as an unconfirmed candidate - needing
-     * exactly one fresh matching measurement THIS run, same as any other block - costs one extra
-     * request per block per restart but means every block, freshly seen or previously learned,
-     * is held to the same standard rather than a persisted value being trusted blindly forever.
+     * have no hard evidence a control's wire length is fixed forever - whether because it depends
+     * on some heat pump setting, or because a JSON value was estimated/wrong, or a firmware
+     * update silently changed it - so treating ANY seed as an unconfirmed candidate, needing
+     * exactly one fresh matching measurement THIS run, costs one extra request per block per
+     * restart but means every block - freshly seen, previously learned, or hand-verified in the
+     * data blocks file - is held to the same standard rather than any one source being trusted
+     * blindly forever. Calling this again for a block that already has an entry (confirmed or
+     * not) simply replaces it with a fresh unconfirmed candidate - used by
+     * forgetMeasuredWireLengths() to force a clean re-measurement after a multi-block parse error
+     * suggests a trusted length has gone wrong.
      * @param {string} version
      * @param {string} block
      * @param {number} length
@@ -277,6 +306,29 @@ class IdmProtocol {
         this.measuredWireLengths.get(version).set(block, { length, confirmed: false });
     }
 
+    /**
+     * Discards any measured/seeded wireLength state for `blockIds`/`version` - used when a
+     * multi-block reply couldn't be parsed (see IdmSession#handleMultiBlockDataReply()'s `error`
+     * branch, the only caller): losing sync mid-reply means one of the group's wireLengths is no
+     * longer correct, but not which one, so the whole group is dropped back to square one rather
+     * than guessing. This also intentionally discards a JSON-declared "wireLength" seed, not just
+     * a live measurement - if the JSON value itself turned out to be wrong (or a firmware update
+     * changed it), re-seeding from the very same value on the next connection would just recreate
+     * the mismatch, so the affected block(s) instead start completely fresh:
+     * firmwareSupportsMultiBlockRequestsForBlocks() now returns false for the group
+     * (getVerifiedBlockWireLength() has nothing left to return), so its next turn automatically
+     * falls back to the classic one-block-at-a-time round-robin, which re-learns each block from
+     * two fresh consecutive measurements like a block seen for the very first time.
+     * @param {string | undefined} version
+     * @param {string[]} blockIds
+     */
+    forgetMeasuredWireLengths(version, blockIds) {
+        if (!version) return;
+        const perVersion = this.measuredWireLengths.get(version);
+        if (!perVersion) return;
+        for (const block of blockIds) perVersion.delete(block);
+    }
+
     /**
      * Whether MULTI-block requests (asking for several data blocks in one 0171 message - see
      * IdmSession's multi-block collector) are safe to use for `blockIds` under `version`: every
@@ -296,8 +348,10 @@ class IdmProtocol {
 
     /**
      * Settings-blocks convenience wrapper - see firmwareSupportsMultiBlockRequestsForBlocks().
-     * Currently true for every version whose settings blocks all have a JSON-declared
-     * "wireLength" (S_H726100) OR have since been fully learned via recordMeasuredWireLength().
+     * True once every settings block's wireLength has been confirmed via
+     * recordMeasuredWireLength() - whether that took one confirming measurement (a JSON-declared
+     * "wireLength", e.g. S_H726100, or a value restored from a previous run) or two independent
+     * ones from scratch.
      * @param {string | undefined} version
      * @returns {boolean}
      */

package/lib/idm-protocol.test.js

@@ -346,8 +346,35 @@ describe('idm-protocol', () => {
         const b09 = '0000D80E'; // 4 bytes, exactly matches its documented fields
         const b0A = '000000002D00'; // 6 bytes, exactly matches its documented fields
 
+        // S_H726100.json's declared wireLength for every one of its data blocks - see
+        // confirmAllS_H726100WireLengths() below.
+        const S_H726100_WIRE_LENGTHS = { '03': 28, '04': 87, '05': 30, '06': 23, '07': 36, '08': 36, '09': 4, '0A': 6, '0B': 11, '0C': 42, '0D': 14 };
+
+        /**
+         * A JSON-declared "wireLength" is only a SEEDED CANDIDATE now (see
+         * getVerifiedBlockWireLength()'s comment), not an instant grant - most of the tests below
+         * are about the multi-block REQUEST/REPLY mechanics, not about the seed-then-confirm
+         * transition itself (that has its own dedicated tests, in the next describe block), so
+         * this confirms every one of idm_p's S_H726100 blocks with a single matching measurement
+         * each - exactly what one real confirming read per block would do - to bring it to the
+         * same "fully multi-block-capable" state the old, JSON-was-an-instant-bypass design had
+         * from the start.
+         */
+        function confirmAllS_H726100WireLengths() {
+            for (const [block, length] of Object.entries(S_H726100_WIRE_LENGTHS)) {
+                idm_p.recordMeasuredWireLength('S_H726100', block, length);
+            }
+        }
+
         describe('firmwareSupportsMultiBlockRequests / getBlockWireLength', () => {
+            it('a JSON-declared wireLength is a seeded candidate, not an instant grant - the group only qualifies once every block is confirmed', () => {
+                expect(idm_p.firmwareSupportsMultiBlockRequests('S_H726100'), 'not yet - nothing confirmed').to.be.false;
+                confirmAllS_H726100WireLengths();
+                expect(idm_p.firmwareSupportsMultiBlockRequests('S_H726100'), 'now - every settings block confirmed').to.be.true;
+            });
+
             it('is true only for S_H726100 - the only firmware with a verified wireLength for every settings block', () => {
+                confirmAllS_H726100WireLengths();
                 expect(idm_p.firmwareSupportsMultiBlockRequests('S_H726100')).to.be.true;
                 for (const version of versions.filter((v) => v !== 'S_H726100')) {
                     expect(idm_p.firmwareSupportsMultiBlockRequests(version), version).to.be.false;
@@ -383,9 +410,17 @@ describe('idm-protocol', () => {
                 learning.initialize();
             });
 
-            it('returns the JSON-declared wireLength when present, without ever touching measuredWireLengths', () => {
+            it('a JSON-declared wireLength is only a seeded candidate after initialize() - needs one fresh confirming measurement, like any other seed', () => {
+                // initialize() (in the outer beforeEach) already seeded '03' from S_H726100.json's
+                // declared wireLength (28) - but seeding alone is never enough, see
+                // getVerifiedBlockWireLength()'s comment.
+                expect(learning.getVerifiedBlockWireLength('S_H726100', '03')).to.be.null;
+                // one fresh measurement matching the seed is enough to confirm it (same rule as
+                // seedMeasuredWireLength() restoring a persisted value - see the dedicated test below).
+                expect(learning.recordMeasuredWireLength('S_H726100', '03', 28)).to.deep.equal({ status: 'confirmed', length: 28 });
                 expect(learning.getVerifiedBlockWireLength('S_H726100', '03')).to.equal(28);
-                // a block that already has a verified length is a no-op for recordMeasuredWireLength
+                // now that it's confirmed, a further call is a no-op - it doesn't touch the stored
+                // length (still 28 below) even though it echoes back whatever was passed in (999)
                 expect(learning.recordMeasuredWireLength('S_H726100', '03', 999)).to.deep.equal({ status: 'already-verified', length: 999 });
                 expect(learning.getVerifiedBlockWireLength('S_H726100', '03')).to.equal(28); // unchanged
             });
@@ -447,6 +482,61 @@ describe('idm-protocol', () => {
                 expect(learning.recordMeasuredWireLength('idm701100', '03', 41)).to.deep.equal({ status: 'confirmed', length: 41 });
                 expect(learning.getVerifiedBlockWireLength('idm701100', '03')).to.equal(41);
             });
+
+            describe('forgetMeasuredWireLengths (see IdmSession#handleMultiBlockDataReply()\'s parse-error branch, the only caller)', () => {
+                it('discards a CONFIRMED length, forcing it all the way back through fresh measurement next time', () => {
+                    learning.recordMeasuredWireLength('idm701100', '03', 41);
+                    learning.recordMeasuredWireLength('idm701100', '03', 41); // confirmed
+                    expect(learning.getVerifiedBlockWireLength('idm701100', '03')).to.equal(41);
+
+                    learning.forgetMeasuredWireLengths('idm701100', ['03']);
+
+                    expect(learning.getVerifiedBlockWireLength('idm701100', '03')).to.be.null;
+                    // back to square one: a single fresh measurement is not enough by itself anymore -
+                    // it needs two consecutive ones again, exactly like a block never seen before
+                    expect(learning.recordMeasuredWireLength('idm701100', '03', 41)).to.deep.equal({ status: 'first-measurement', length: 41 });
+                    expect(learning.getVerifiedBlockWireLength('idm701100', '03')).to.be.null;
+                });
+
+                it('also discards a JSON-declared seed, not just a live measurement - re-seeding from the same value would just recreate the mismatch', () => {
+                    // A fresh instance, never confirmed - S_H726100's block '03' is seeded
+                    // (unconfirmed) straight from initialize(), untouched by recordMeasuredWireLength().
+                    const fresh = new IdmProtocol();
+                    fresh.initialize();
+                    expect(fresh.firmwareSupportsMultiBlockRequestsForBlocks('S_H726100', ['03'])).to.be.false;
+
+                    fresh.forgetMeasuredWireLengths('S_H726100', ['03']);
+
+                    // Still nothing trusted - and confirming it now takes a fresh MATCHING
+                    // measurement, not an instant grant from the (discarded) JSON seed.
+                    expect(fresh.getVerifiedBlockWireLength('S_H726100', '03')).to.be.null;
+                    expect(fresh.recordMeasuredWireLength('S_H726100', '03', 28)).to.deep.equal({ status: 'first-measurement', length: 28 });
+                    expect(fresh.getVerifiedBlockWireLength('S_H726100', '03')).to.be.null;
+                });
+
+                it('forgets only the listed blocks, leaving every other block (same or different group) untouched', () => {
+                    learning.recordMeasuredWireLength('idm701100', '03', 41);
+                    learning.recordMeasuredWireLength('idm701100', '03', 41);
+                    learning.recordMeasuredWireLength('idm701100', '04', 20);
+                    learning.recordMeasuredWireLength('idm701100', '04', 20);
+
+                    learning.forgetMeasuredWireLengths('idm701100', ['03']);
+
+                    expect(learning.getVerifiedBlockWireLength('idm701100', '03')).to.be.null;
+                    expect(learning.getVerifiedBlockWireLength('idm701100', '04'), 'an untouched block must be unaffected').to.equal(20);
+                });
+
+                it('is a no-op for an unknown version or an empty/missing block list - never throws', () => {
+                    learning.recordMeasuredWireLength('idm701100', '03', 41);
+                    learning.recordMeasuredWireLength('idm701100', '03', 41);
+
+                    expect(() => learning.forgetMeasuredWireLengths(undefined, ['03'])).to.not.throw();
+                    expect(() => learning.forgetMeasuredWireLengths('no-such-version', ['03'])).to.not.throw();
+                    expect(() => learning.forgetMeasuredWireLengths('idm701100', [])).to.not.throw();
+
+                    expect(learning.getVerifiedBlockWireLength('idm701100', '03'), 'none of the above should have touched the real entry').to.equal(41);
+                });
+            });
         });
 
         describe('firmwareSupportsMultiBlockRequestsForBlocks / firmwareSupportsMultiBlockRequestsForSensors', () => {

package/lib/idm-session.js

@@ -158,10 +158,15 @@ class IdmSession {
         // giving the next turn to whichever group the pattern names next (see
         // beginGroupCollection()) - it does not get interrupted partway through, so the pattern
         // is what settles how often each group gets a turn, not how long any one turn takes.
-        // Sensor comes first in the pattern (not just proportionally more often) so the very
-        // first turn after connecting - and every settings turn - is bracketed by fresh sensor
-        // reads rather than opening the connection with the slower-changing settings data.
-        this.pollPattern = ['sensor', 'sensor', 'settings'];
+        // Simple 1:1 alternation, sensor first (not just tied, but first) so the very first turn
+        // after connecting - and every settings turn - is bracketed by a fresh sensor read rather
+        // than opening the connection with the slower-changing settings data. An earlier version
+        // gave sensor 2 turns for every 1 settings turn, back when a settings turn could take
+        // several times longer than a sensor turn to actually finish (many re-asks against real
+        // hardware) - now that a turn always collects its whole group before yielding either way
+        // (see above), that imbalance no longer buys sensor anything extra, so plain alternation
+        // is both simpler and gives settings its fair share too.
+        this.pollPattern = ['sensor', 'settings'];
         this.pollPatternIndex = 0;
 
         // When the current full-coverage cycle started - every sensor block AND every settings
@@ -320,6 +325,34 @@ class IdmSession {
         this.sendQueue.enqueue(message);
     }
 
+    /**
+     * Logs, once per connection (called right after onVersion(), see receive_data()'s 'V'
+     * branch), how many of each group's blocks still need a confirming live measurement before
+     * that group can switch to multi-block requests (see
+     * idm.firmwareSupportsMultiBlockRequestsForBlocks() / getVerifiedBlockWireLength()) - 0 means
+     * the group starts on multi-block requests right away (every block's wireLength was already
+     * confirmed - either a JSON-declared one confirmed earlier, or one restored and reconfirmed
+     * from a previous run's persisted state); anything more means the classic one-block-at-a-time
+     * round-robin runs for a little while first, passively confirming each one from real traffic
+     * (see learnWireLengthFrom()) before this group's turns switch over.
+     */
+    logWireLengthMeasurementStatus() {
+        const groups = [
+            ['sensor', this.idm.getSensorDataBlocks(this.version)],
+            ['settings', this.idm.getSettingsDataBlocks(this.version)],
+        ];
+        for (const [group, dataBlocks] of groups) {
+            if (!dataBlocks || dataBlocks.length === 0) continue;
+            const unconfirmed = dataBlocks.filter((b) => this.idm.getVerifiedBlockWireLength(this.version, b) === null);
+            if (unconfirmed.length === 0) {
+                this.log.info(group + ': every block\'s wireLength is already confirmed - starting on multi-block requests right away');
+            } else {
+                this.log.info(group + ': ' + unconfirmed.length + ' of ' + dataBlocks.length + ' block(s) (' + unconfirmed.join(',') +
+                    ') still need a confirming measurement before switching to multi-block requests - reading them one at a time for now');
+            }
+        }
+    }
+
     // ---- connecting / reconnecting -----------------------------------------------------
 
     /** Starts (or restarts) the connection process. Call once the adapter is ready. */
@@ -1012,6 +1045,7 @@ class IdmSession {
                     this.setConnected(true);
                     this.AdjustSpeed();
                     this.hooks.onVersion(version);
+                    this.logWireLengthMeasurementStatus();
                 }
                 if (this.needToSendData) {
                     this.needToSendData = this.write_data_to_heatpump(false);
@@ -1060,6 +1094,13 @@ class IdmSession {
      * adaptive backoff, WITHOUT sending another 0171 - the control already knows what was
      * requested from the initial one. Mirrors the single-block 'Data' branch's end-of-cycle
      * bookkeeping (recordBlockRead) as each block is found, not just at the end.
+     *
+     * A reply that couldn't be fully parsed (idm.parse_multi_block_reply()'s `error`) is treated
+     * as a sign that one of the group's wireLengths is no longer correct - not a routine partial
+     * reply - so on top of recording whatever blocks WERE successfully parsed before the error,
+     * this immediately abandons the collection and forgets every one of the group's wireLengths
+     * (see idm.forgetMeasuredWireLengths()), forcing a clean re-measurement rather than
+     * continuing to (mis)use an assumption that just proved wrong.
      * @param {string} received_data
      */
     handleMultiBlockDataReply(received_data) {
@@ -1072,9 +1113,6 @@ class IdmSession {
             return;
         }
         const { blocks, error } = this.idm.parse_multi_block_reply(this.version, received_data, this.hooks.onFieldUpdate);
-        if (error) {
-            this.log.warn('multi-block reply could not be fully parsed (' + error + '), ' + blocks.length + ' block(s) from it are still usable');
-        }
 
         let foundNew = false;
         for (const { block, text } of blocks) {
@@ -1088,6 +1126,15 @@ class IdmSession {
             this.hooks.onDataBlockText('Data_block_' + Number.parseInt(block, 16), text);
             this.recordBlockRead(block);
         }
+
+        if (error) {
+            this.log.warn('multi-block reply for ' + group + ' could not be fully parsed (' + error + ') - a wireLength for one of its ' +
+                'blocks is probably no longer correct; forcing re-measurement of every ' + group + ' block');
+            this.idm.forgetMeasuredWireLengths(this.version, this.groupDataBlocks(group));
+            this.finishGroupCollection();
+            return;
+        }
+
         this.log.debug('multi-block reply (' + group + '): found ' + blocks.map((b) => b.block).join(',') +
             ', still missing ' + [...collector.missing].join(',') + ' after ' + collector.reaskCount + ' re-ask(s)');
 

package/lib/idm-session.test.js

@@ -263,28 +263,26 @@ describe('idm-session (connection + request/response state machine)', () => {
         it('logs the elapsed time and a running total only once every distinct data block has actually been read, each time the lap completes', () => {
             const socket = connect();
             // idm701100 has 4 sensor blocks and 5 settings blocks - 9 distinct block ids total.
-            // pollPattern reads sensor twice for every one settings read (see its own comment),
-            // so a full-coverage cycle needs exactly 15 turns: 10 sensor turns (easily enough to
-            // cycle its 4-block round robin more than twice over) and exactly 5 settings turns -
-            // one full round trip of its 5-block round robin, which is what actually gates it.
+            // pollPattern alternates sensor/settings 1:1 (see its own comment), so a full-coverage
+            // cycle needs exactly 10 turns: 5 sensor turns (easily enough to cycle its 4-block
+            // round robin more than once over) and exactly 5 settings turns - one full round trip
+            // of its 5-block round robin, which is what actually gates it (sensor's smaller group
+            // always finishes its own round robin first and just keeps re-cycling).
             const fullCoverageLogs = () => log.info.getCalls().filter(c => /^full-coverage cycle #/.test(c.args[0]));
 
             socket.emit('data', versionResponse('idm701100')); // sensor block 07 in flight (turn 1)
 
-            for (let i = 0; i < 5; i++) completeCurrentBlockAndAdvance(socket); // turns 1-5: settings 03 (turn 3)
-            expect(fullCoverageLogs(), 'only 1 of 5 settings blocks read so far').to.have.lengthOf(0);
-
-            for (let i = 0; i < 7; i++) completeCurrentBlockAndAdvance(socket); // turns 6-12: settings 04, 05, 06
+            for (let i = 0; i < 8; i++) completeCurrentBlockAndAdvance(socket); // turns 1-8: settings 03, 04, 05, 06
             expect(fullCoverageLogs(), 'only 4 of 5 settings blocks read so far').to.have.lengthOf(0);
 
-            for (let i = 0; i < 3; i++) completeCurrentBlockAndAdvance(socket); // turns 13-15: settings 08 - the last one
+            for (let i = 0; i < 2; i++) completeCurrentBlockAndAdvance(socket); // turns 9-10: settings 08 - the last one
 
             // All 9 distinct ids have now been read once, completing the very first lap - but there's
             // no predecessor to time yet, so this isn't logged until the *next* lap completes.
             expect(fullCoverageLogs(), 'the very first lap has no predecessor to time yet').to.have.lengthOf(0);
 
-            // Second lap (15 more turns) - now there's a predecessor, so this one does get logged.
-            for (let i = 0; i < 15; i++) completeCurrentBlockAndAdvance(socket);
+            // Second lap (10 more turns) - now there's a predecessor, so this one does get logged.
+            for (let i = 0; i < 10; i++) completeCurrentBlockAndAdvance(socket);
             let logs = fullCoverageLogs();
             expect(logs, 'expected a log call once the second lap completes').to.have.lengthOf(1);
             // idm701100's 4 sensor + 5 settings blocks, all still at the normalDataContentDelay
@@ -293,7 +291,7 @@ describe('idm-session (connection + request/response state machine)', () => {
             expect(logs[0].args[0]).to.match(/^full-coverage cycle #1 done in \d+ms, delays: \(07,09,0A,0B,03,04,05,06,08\) 650ms$/);
 
             // A third lap - the running total should go up, not reset.
-            for (let i = 0; i < 15; i++) completeCurrentBlockAndAdvance(socket);
+            for (let i = 0; i < 10; i++) completeCurrentBlockAndAdvance(socket);
             logs = fullCoverageLogs();
             expect(logs, 'expected a second log call once the next lap completes').to.have.lengthOf(2);
             expect(logs[1].args[0]).to.match(/^full-coverage cycle #2 done in \d+ms, delays: /);
@@ -649,6 +647,24 @@ describe('idm-session (connection + request/response state machine)', () => {
         const ALL_SENSOR_BLOCKS = ['07', '0B', '0C', '0D']; // must match S_H726100.json's sensorBlocks
         const ALL_SETTINGS_BLOCKS = ['03', '04', '05', '06', '08', '09', '0A']; // must match S_H726100.json's settingsBlocks
 
+        // A JSON-declared "wireLength" is only a seeded CANDIDATE now (see
+        // getVerifiedBlockWireLength()'s comment), not an instant grant - it still needs one fresh
+        // confirming measurement before its group qualifies for multi-block requests. Every test in
+        // this describe block is about the multi-block REQUEST/REPLY mechanics themselves (that
+        // transition has its own dedicated tests, in the "wireLength learning" describe block below),
+        // and assumes S_H726100 is ALREADY fully multi-block-capable for both groups from turn 1 - so
+        // this confirms every one of its blocks directly via recordMeasuredWireLength(), bypassing the
+        // learnWireLengthFrom() stub the outer beforeEach installs (recordMeasuredWireLength is called
+        // straight on `idm`, not through the stubbed session method), exactly what one real confirming
+        // read per block would do. PAYLOADS' lengths are exactly S_H726100.json's declared wireLengths
+        // (see the comment above), so the first (and only) call for each block always matches its seed
+        // and confirms immediately.
+        beforeEach(() => {
+            for (const [block, payload] of Object.entries(PAYLOADS)) {
+                idm.recordMeasuredWireLength('S_H726100', block, payload.length / 2);
+            }
+        });
+
         /**
          * A small test double for the REAL S_H726100 control's observed multi-block behavior,
          * built directly from this feature's own captured real traffic: acks a 0171 multi-block
@@ -770,22 +786,20 @@ describe('idm-session (connection + request/response state machine)', () => {
             expect(session.activeMultiBlockGroup).to.equal('sensor');
         });
 
-        it('happy path: one full pattern cycle (sensor, sensor, settings), each group completing on its first content reply', () => {
+        it('happy path: one full pattern cycle (sensor, settings), each group completing on its first content reply', () => {
             const socket = connectAsH726100();
             new MultiBlockControllerSim(socket, session, {}); // both groups use their default (complete) reply
 
             completeGroupTurn(socket); // turn 1: sensor
-            completeGroupTurn(socket); // turn 2: sensor (a fresh collection - see pollPattern's comment)
-            // Turn 3 (settings) is driven WITHOUT the trailing version reply, so the state can be
-            // inspected right at the end of this pattern cycle, before turn 4 (the version reply
+            // Turn 2 (settings) is driven WITHOUT the trailing version reply, so the state can be
+            // inspected right at the end of this pattern cycle, before turn 3 (the version reply
             // completeGroupTurn() would otherwise supply immediately begins the next cycle's
             // sensor collection and reassigns activeMultiBlockGroup again).
-            clock.tick(10000); // turn 3: settings
+            clock.tick(10000); // turn 2: settings
 
-            // Sensor is collected TWICE per pattern cycle (2 sensor turns for every 1 settings
-            // turn - each turn starts a brand new collection since the previous one already
-            // completed) and settings once: 4 + 4 + 7 = 15, not just 11.
-            expect(hooks.onDataBlockText.callCount).to.equal(15);
+            // One full pattern cycle is exactly one sensor turn and one settings turn now (1:1
+            // alternation - see pollPattern's comment): 4 + 7 = 11, one read of every distinct block.
+            expect(hooks.onDataBlockText.callCount).to.equal(11);
             for (const id of [...ALL_SENSOR_BLOCKS, ...ALL_SETTINGS_BLOCKS]) {
                 expect(hooks.onDataBlockText.calledWith('Data_block_' + Number.parseInt(id, 16)),
                     'expected a call for block ' + id).to.be.true;
@@ -802,8 +816,7 @@ describe('idm-session (connection + request/response state machine)', () => {
             const socket = connectAsH726100();
             new MultiBlockControllerSim(socket, session, { settings: [['03', '04'], ['05', '06', '08', '09', '0A']] });
 
-            completeGroupTurn(socket); // turn 1: sensor
-            completeGroupTurn(socket); // turn 2: sensor
+            completeGroupTurn(socket); // turn 1: sensor - turn 2 (settings) is about to begin
 
             const writesBeforeSettingsTurn = socket.written.length;
             // A little slack (+50ms) beyond the exact sum of delays: sinon's fake timers don't
@@ -838,8 +851,9 @@ describe('idm-session (connection + request/response state machine)', () => {
                 ],
             });
 
-            completeGroupTurn(socket); // sensor
-            completeGroupTurn(socket); // sensor
+            completeGroupTurn(socket); // turn 1: sensor - turn 2 (settings) is about to begin
+            // Driven without the trailing version reply (unlike completeGroupTurn), so this stays
+            // on turn 2's own collection rather than also kicking off turn 3.
             clock.tick(20000); // settings: both content requests happen within this one collection
 
             expect(hooks.onDataBlockText.withArgs('Data_block_3').callCount, 'block 03 must only be reported once').to.equal(1);
@@ -857,10 +871,11 @@ describe('idm-session (connection + request/response state machine)', () => {
                 ],
             });
 
-            completeGroupTurn(socket); // sensor
-            completeGroupTurn(socket); // sensor
+            completeGroupTurn(socket); // turn 1: sensor - turn 2 (settings) is about to begin
             // All 4 content requests (03+04, REPEAT, REPEAT, the rest) happen within this ONE
             // settings collection - the backoff between them (900, 1800, 3600ms) comfortably fits.
+            // Driven without the trailing version reply (unlike completeGroupTurn), so this stays
+            // on turn 2's own collection rather than also kicking off turn 3.
             clock.tick(20000); // settings
 
             expect(session.multiBlockCollector).to.be.null;
@@ -873,8 +888,7 @@ describe('idm-session (connection + request/response state machine)', () => {
             const socket = connectAsH726100();
             new MultiBlockControllerSim(socket, session, { settings: [['03', '04'], ['05', '06', '08', '09', '0A']] });
 
-            completeGroupTurn(socket); // sensor
-            completeGroupTurn(socket); // sensor
+            completeGroupTurn(socket); // turn 1: sensor - turn 2 (settings) is about to begin
             clock.tick(session.requestDataBlockDelay + session.multiBlockContentDelay + 50); // settings: 0171 + first (partial) 0172 reply
 
             expect(session.activeMultiBlockGroup, 'settings collection has not finished yet').to.equal('settings');
@@ -896,8 +910,7 @@ describe('idm-session (connection + request/response state machine)', () => {
             const socket = connectAsH726100();
             new MultiBlockControllerSim(socket, session, { settings: ['NR', 'NR', [...ALL_SETTINGS_BLOCKS]] });
 
-            completeGroupTurn(socket); // sensor
-            completeGroupTurn(socket); // sensor
+            completeGroupTurn(socket); // turn 1: sensor - turn 2 (settings) is about to begin
             // Driven without the trailing version reply (unlike completeGroupTurn), so the state
             // can be inspected right as this collection completes, before the next one begins.
             clock.tick(10000); // settings - two NRs then the full reply, all within this one collection
@@ -916,8 +929,7 @@ describe('idm-session (connection + request/response state machine)', () => {
             // makes some progress but (for whatever reason) never completes the rest.
             new MultiBlockControllerSim(socket, session, { settings: [['03']] });
 
-            completeGroupTurn(socket); // sensor
-            completeGroupTurn(socket); // sensor
+            completeGroupTurn(socket); // turn 1: sensor - turn 2 (settings) is about to begin
             // All multiBlockMaxReasks (20) re-asks happen inside this single settings collection:
             // the adaptive backoff grows to multiBlockReaskMaxDelay (4000ms) after a few repeats,
             // so the worst case (900+1800+3600+17*4000ms, plus the initial request delays) is
@@ -950,6 +962,60 @@ describe('idm-session (connection + request/response state machine)', () => {
             expect(session.currentDataBlock, 'the plain single-block path should be in use instead').to.equal('07');
             expect(socket.written.length).to.equal(2); // init + exactly one single-block request, not a batch
         });
+
+        it('a reply that cannot be fully parsed (lost sync) abandons the collection and forgets the whole group\'s wireLengths, falling back to round-robin', () => {
+            // Driven entirely by hand (no MultiBlockControllerSim) - this needs to inject one
+            // deliberately malformed reply at an exact point, which the sim (real block ids/NR/
+            // REPEAT scripts only) cannot produce.
+            const socket = connectAsH726100();
+            expect(idm.firmwareSupportsMultiBlockRequests('S_H726100'), 'settings starts out multi-block-capable').to.be.true;
+
+            // Turn 1 (sensor) - completes normally, using a real full reply.
+            clock.tick(session.requestDataBlockDelay); // sends the sensor 0171
+            socket.emit('data', idm.create_message('01F10000')); // R1 ack
+            clock.tick(session.multiBlockContentDelay); // sends the sensor 0172
+            socket.emit('data', idm.create_message('01F200' + ALL_SENSOR_BLOCKS.map((id) => id + SENSOR_PAYLOADS[id]).join('')));
+            clock.tick(session.requestInitDelay); // re-init roundtrip -> turn 2 (settings) begins
+            socket.emit('data', versionResponse('S_H726100'));
+
+            // Turn 2 (settings) - a lost-sync reply.
+            clock.tick(session.requestDataBlockDelay); // sends the settings 0171
+            expect(session.activeMultiBlockGroup).to.equal('settings');
+            socket.emit('data', idm.create_message('01F10000')); // R1 ack
+            clock.tick(session.multiBlockContentDelay); // sends the settings 0172
+
+            // A reply idm.parse_multi_block_reply() can't make sense of (an unknown block id,
+            // 'ZZ', after a real block 09) - lost sync, exactly like the dedicated
+            // idm-protocol.test.js regression for this same payload shape.
+            socket.emit('data', idm.create_message('01F200' + '09' + SETTINGS_PAYLOADS['09'] + 'ZZ' + '00'));
+
+            expect(log.warn.calledWithMatch(/multi-block reply for settings could not be fully parsed/)).to.be.true;
+            // The collection is abandoned outright (not left waiting for more re-asks that could
+            // never resolve the mismatch), and every one of settings' wireLengths is gone - not
+            // just block 09's - since a lost-sync error doesn't say which one was actually wrong.
+            expect(session.activeMultiBlockGroup).to.be.null;
+            expect(session.multiBlockCollector).to.be.null;
+            expect(idm.firmwareSupportsMultiBlockRequests('S_H726100'), 'every settings wireLength was forgotten').to.be.false;
+            // Block 09 itself WAS parsed cleanly before the error, so it's still reported once.
+            expect(hooks.onDataBlockText.calledWith('Data_block_9')).to.be.true;
+
+            // Turn 3 (sensor again) - unaffected, still multi-block-capable, completes normally.
+            clock.tick(session.requestInitDelay); // re-init roundtrip -> turn 3 begins
+            socket.emit('data', versionResponse('S_H726100'));
+            expect(session.activeMultiBlockGroup, 'sensor is untouched by settings\' forgotten wireLengths').to.equal('sensor');
+            clock.tick(session.requestDataBlockDelay);
+            socket.emit('data', idm.create_message('01F10000'));
+            clock.tick(session.multiBlockContentDelay);
+            socket.emit('data', idm.create_message('01F200' + ALL_SENSOR_BLOCKS.map((id) => id + SENSOR_PAYLOADS[id]).join('')));
+            clock.tick(session.requestInitDelay); // re-init roundtrip -> turn 4 (settings) begins
+            socket.emit('data', versionResponse('S_H726100'));
+
+            // Turn 4 (settings) - falls back to the classic one-block-at-a-time path instead of
+            // trying (and failing) to send another multi-block request.
+            expect(session.activeMultiBlockGroup, 'settings must not attempt multi-block again until re-confirmed').to.be.null;
+            clock.tick(session.requestDataBlockDelay);
+            expect(ALL_SETTINGS_BLOCKS, 'a plain single-block request for one of settings\' own blocks').to.include(session.currentDataBlock);
+        });
     });
 
     describe('wireLength learning (see IdmSession#learnWireLengthFrom / IdmProtocol#recordMeasuredWireLength)', () => {
@@ -1061,9 +1127,21 @@ describe('idm-session (connection + request/response state machine)', () => {
             clock.tick(session.contentDelayForCurrentBlock());
             socket.emit('data', idm.create_message('01F20007' + '00'.repeat(10)));
             clock.tick(session.requestInitDelay);
-            socket.emit('data', versionResponse('idm701100')); // -> turn 2 (sensor again) begins
+            socket.emit('data', versionResponse('idm701100')); // -> turn 2 (settings - pollPattern alternates 1:1) begins
+
+            // idm701100's settings blocks were never touched above, so turn 2 is still the classic
+            // single-block path - sensor's own graduation must not affect the OTHER group, and
+            // pollPattern's next sensor turn isn't until turn 3.
+            expect(session.activeMultiBlockGroup, 'turn 2 (settings) has not graduated - still classic single-block').to.be.null;
+
+            clock.tick(session.requestDataBlockDelay);
+            socket.emit('data', idm.create_message('01F10000'));
+            clock.tick(session.contentDelayForCurrentBlock());
+            socket.emit('data', idm.create_message('01F20007' + '00'.repeat(10)));
+            clock.tick(session.requestInitDelay);
+            socket.emit('data', versionResponse('idm701100')); // -> turn 3 (sensor again) begins
 
-            expect(session.activeMultiBlockGroup, 'turn 2 should go straight to a multi-block collection').to.equal('sensor');
+            expect(session.activeMultiBlockGroup, 'turn 3 should go straight to a multi-block collection').to.equal('sensor');
             const writesBefore = socket.written.length;
             clock.tick(session.requestDataBlockDelay);
             expect(idm_u.get_string_uint8array(socket.written[writesBefore])).to.equal(

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "iobroker.idm-multitalent_002",
-  "version": "2.1.2",
+  "version": "2.1.3",
   "description": "Read and write values of a iDM heatpump with multitalent.002 control.",
   "author": {
     "name": "zloe",