iobroker.idm-multitalent_002 2.1.2 → 2.2.0

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; sensor is polled as fast as the protocol allows (throttled to at most once every 10s), while settings is polled only once every 60s, plus once right away after you change a value yourself - see the Architecture section below for the exact schedule. 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. 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,19 @@ Example screenshots of objects:
 ![Status](resources/ioBrokerAdapter-Status.jpg)
 
 ## Changelog
+### 2.2.0 (2026-09-11)
+* (zloe) sensor and settings are no longer polled in lockstep: sensor is read as fast as the protocol allows (throttled to at most once every 10s), settings only once every 60s plus once right away after any value is written to the heat pump - both intervals measured from the start of one full sweep to the start of the next, and neither configurable. This noticeably reduces how often the heat pump's own control gets polled for the slower-changing settings data, without making sensor data any less fresh
+* (zloe) a group's sweep (round-robin or multi-block alike) is never interrupted by the other group becoming due partway through - previously only a multi-block collection had this guarantee; the classic one-block-at-a-time round-robin now gets it too
+* (zloe) replaced the combined "full-coverage cycle" log line (which no longer makes sense once sensor and settings run on independent schedules) with one line per group, logged the moment that group's own sweep completes, showing its actual elapsed time and a rolling average over its last 10 sweeps - the old per-block delay breakdown is gone along with it
+* (zloe) docs: shortened and reworked the Architecture section's description of the sensor/settings polling cadence, with a small sequence diagram
+
+### 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)
 
@@ -213,55 +226,67 @@ correction instead of always jumping by the full coarse amount; only genuinely r
 escalate the step back up. See `contentDelayForCurrentBlock()`/`updateContentDelayEstimate()` and
 the "adaptive per-data-block content delay" tests in `lib/idm-session.test.js`.
 
-`IdmSession` also logs how long a full-coverage cycle actually took, once the next one completes
-(there is nothing to compare the very first cycle against yet) - every sensor block *and* every
-settings block actually read at least once. This is driven by data actually being *received*
-(`recordBlockRead()`, called from `receive_data()`'s successful-data branch), not merely requested
-- a block that was requested but never got a reply back (a retry, a response-watchdog reset, the
-periodic resync) does not count, so the log only ever fires once every block has genuinely been
-read. It also carries a running total of how many full-coverage cycles have completed since the
-adapter started (not persisted across restarts) and a breakdown of the delay currently in use per
-block, grouped by shared value (e.g. `(07,08) 650ms, (09,04,05) 2300ms`) - together with the
-elapsed time, that's the overall effect of all the delays and polling behavior below added
-together, so it's what actually shows whether a change to any of it made polling faster or slower.
-(An earlier, more frequent "one full poll cycle" line - logged every single sensor sweep - was
-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.
+#### Sensor and settings: independent polling cadence
+
+Every call to `request_data()` is one "turn" - a request for either the sensor or the settings
+group, decided by `chooseNextGroup()`. The two groups are no longer polled in lockstep: each has
+its own minimum interval between the *start* of one full sweep (every block in that group actually
+read at least once) and the start of its next - sensor as fast as the protocol allows, but never
+sooner than **10s** apart; settings only every **60s**, plus once right after any value is written
+to the heat pump, so a change you make shows up promptly instead of waiting out the rest of that
+window. Both numbers are fixed (not configurable) - the point is purely to spare the heat pump's
+own control, since settings rarely change and doesn't need reading nearly as often as sensor data.
+
+Once a sweep for a group has started, it keeps getting that group's turns - regardless of whether
+the other group is also due - until every one of its blocks has actually been read; only then does
+the interval rule decide when that group may sweep again. This is the same "never interrupted
+partway through" rule a multi-block collection already followed (see below), now applied to the
+classic one-block-at-a-time round-robin too. A batch of writes is never interrupted by a settings
+read either: `request_data()` is only reached once the whole write queue has drained, so several
+values submitted together always finish, uninterrupted, before the one settings refresh they
+trigger.
+
+```mermaid
+sequenceDiagram
+    participant HP as Heat pump
+    participant S as IdmSession
+    Note over S: sensor due (≥10s since its last sweep started)
+    S->>HP: request sensor blocks
+    HP-->>S: sensor data
+    Note over S: sensor sweep complete
+    Note over S: settings not due yet - parks, nothing sent
+    Note over S: a value gets written
+    S->>HP: write value
+    HP-->>S: ack
+    Note over S: write queue drained - settings refresh forced
+    S->>HP: request settings blocks
+    HP-->>S: settings data
+    Note over S: settings sweep complete
+```
+
+Each completed sweep logs its own actual elapsed time plus a rolling average over the last 10
+sweeps, e.g. `sensor sweep done in 1400ms (avg of last 10: 1360ms)` - one line per group, logged
+the moment that group's sweep finishes. This replaces the earlier combined "full-coverage cycle"
+line: now that the two groups run on independent schedules there is no single shared interval left
+to time them together, so each gets its own line instead. As before, this is driven by data
+actually being *received* (`recordBlockRead()`), not merely requested - a block that was asked for
+but never got a reply (a retry, a response-watchdog reset, the periodic resync) does not count.
 
 #### Multi-block requests, per group
 
-The serial protocol actually allows requesting several data blocks in one `0171` message, which
-come back combined in a single `01F2`/`0172` reply - but the control's replies turned out to be
-genuinely different from single-block requests in two ways, both confirmed against a real
-S_H726100 control before this was implemented: a block's reply can be a few bytes LONGER than the
-documented fields account for (harmless for a single-block request, since the frame's own SOH/
-ETX/checksum framing finds the boundary regardless - but fatal for parsing several blocks out of
-one reply, where the exact length of each block is the only way to find where the next one
-starts), and a single `0172` typically only returns a PARTIAL subset of the requested blocks,
-requiring the request to be repeated until everything has actually come back. Because of this, the
-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
-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.
+The serial protocol allows requesting several data blocks in one `0171` message, combined in a
+single `01F2`/`0172` reply - but real control traffic (confirmed against S_H726100) showed two
+quirks: a block's reply can be a few bytes LONGER than its documented fields (harmless alone, but
+fatal for splitting several blocks out of one reply unless each one's exact length is known), and a
+single `0172` typically only returns a PARTIAL subset of what was asked for. Because of this, the
+multi-block path is strictly opt-in, gated independently per group:
+`IdmProtocol#firmwareSupportsMultiBlockRequestsForBlocks()` (and its `...ForSensors()`/plain
+`...Requests()` wrappers for sensor/settings) only returns true once every block in that group has
+a TRUSTED wire length - confirmed from real traffic (see "wireLength learning" below), whether it
+started from an explicit `wireLength` in the data block definition (see
+[`lib/datablocks/README.md`](lib/datablocks/README.md)), a value restored from a previous run, or
+nothing at all. The two groups can be in different states; whichever hasn't (yet) qualified just
+keeps using the plain one-block-per-turn round-robin.
 
 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,14 +307,23 @@ 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.
 
-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):
-a collection's own re-asks are never interleaved with an unrelated request from the other group in
-between, so there is no uncertainty here about whether the control could resume a partial reply
-across such an interruption - that situation simply never arises - and settings, which on real
-hardware often needs several re-asks to fully arrive, no longer has to wait through two full sensor
-turns and a connection resync between every one of them. See the "multi-block collection, sensor
+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.
+
+A collection's own re-asks are never interleaved with an unrelated request from the other group in
+between, so there is no uncertainty about whether the control could resume a partial reply across
+such an interruption - that situation simply never arises. See the "multi-block collection, sensor
 and settings" tests in `lib/idm-session.test.js`, which drive this against a small simulated
 control (`MultiBlockControllerSim`) modeling the partial-reply/stale-repeat/not-ready behavior
 actually observed on real hardware.
@@ -303,17 +337,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,34 @@
 {
   "common": {
     "name": "idm-multitalent_002",
-    "version": "2.1.2",
+    "version": "2.2.0",
     "news": {
+      "2.2.0": {
+        "en": "sensor and settings are no longer polled in lockstep: sensor is read as fast as the protocol allows (throttled to at most once every 10s), while settings is only read once every 60s, plus once right away after any value is written to the heat pump - reducing how often the heat pump's own control gets polled for the slower-changing settings data, without making sensor data any less fresh. A group's sweep - round-robin or multi-block alike - is never interrupted by the other group becoming due partway through. The combined \"full-coverage cycle\" log line is replaced by one line per group, logged the moment that group's own sweep completes, showing its actual elapsed time and a rolling average over its last 10 sweeps",
+        "de": "Sensor- und Settings-Abfragen laufen nicht mehr im Gleichschritt: Sensor wird so schnell wie das Protokoll es erlaubt gelesen (gedrosselt auf höchstens einmal alle 10s), während Settings nur alle 60s gelesen wird, plus einmal sofort nachdem ein Wert zur Wärmepumpe geschrieben wurde - das reduziert, wie oft die Steuerung der Wärmepumpe für die sich selten ändernden Settings-Daten abgefragt wird, ohne dass Sensordaten dadurch weniger aktuell werden. Ein Durchlauf einer Gruppe - egal ob round-robin oder multi-block - wird nie unterbrochen, nur weil die andere Gruppe währenddessen fällig wird. Die kombinierte \"full-coverage cycle\"-Logzeile wird durch eine Zeile pro Gruppe ersetzt, die genau dann protokolliert wird, wenn der Durchlauf dieser Gruppe abgeschlossen ist, und die tatsächliche verstrichene Zeit sowie einen gleitenden Durchschnitt der letzten 10 Durchläufe zeigt",
+        "ru": "Опрос сенсоров и настроек больше не выполняется в едином ритме: сенсоры читаются настолько быстро, насколько позволяет протокол (но не чаще одного раза в 10 секунд), а настройки читаются только раз в 60 секунд, плюс сразу после любой записи значения в тепловой насос - это снижает частоту опроса самого контроллера теплового насоса для редко меняющихся данных настроек, не делая при этом данные сенсоров менее актуальными. Проход группы - будь то round-robin или multi-block - никогда не прерывается, если тем временем наступает срок опроса другой группы. Объединённая строка журнала \"full-coverage cycle\" заменена на отдельную строку для каждой группы, которая записывается сразу по завершении прохода этой группы и показывает фактическое затраченное время, а также скользящее среднее по последним 10 проходам",
+        "pt": "a leitura de sensores e configurações não é mais feita em sincronia: os sensores são lidos o mais rápido que o protocolo permite (limitado a no máximo uma vez a cada 10s), enquanto as configurações só são lidas a cada 60s, mais uma vez logo após qualquer valor ser escrito no aquecedor - isso reduz a frequência com que o próprio controlador do aquecedor é consultado para os dados de configuração, que mudam raramente, sem tornar os dados dos sensores menos atuais. A varredura de um grupo - round-robin ou multi-block - nunca é interrompida por causa do outro grupo ficar pendente no meio do caminho. A linha de log combinada \"full-coverage cycle\" foi substituída por uma linha por grupo, registrada no momento em que a varredura daquele grupo é concluída, mostrando o tempo decorrido real e uma média móvel das últimas 10 varreduras",
+        "nl": "sensor- en instellingenuitlezingen lopen niet langer synchroon: sensor wordt zo snel als het protocol toelaat gelezen (beperkt tot hoogstens eens per 10s), terwijl instellingen slechts elke 60s wordt gelezen, plus één keer direct nadat een waarde naar de warmtepomp is geschreven - dit vermindert hoe vaak de besturing van de warmtepomp wordt bevraagd voor de traag veranderende instellingengegevens, zonder de sensorgegevens minder actueel te maken. Een ronde van een groep - round-robin of multi-block - wordt nooit onderbroken doordat de andere groep tussentijds aan de beurt komt. De gecombineerde \"full-coverage cycle\"-logregel is vervangen door één regel per groep, gelogd zodra de ronde van die groep is voltooid, met de werkelijk verstreken tijd en een voortschrijdend gemiddelde over de laatste 10 rondes",
+        "fr": "la lecture des capteurs et des réglages ne se fait plus en cadence commune : les capteurs sont lus aussi vite que le protocole le permet (limité à une fois toutes les 10s maximum), tandis que les réglages ne sont lus que toutes les 60s, plus une fois juste après qu'une valeur a été écrite vers la pompe à chaleur - cela réduit la fréquence à laquelle le contrôleur de la pompe à chaleur est sollicité pour les données de réglage, qui changent rarement, sans rendre les données des capteurs moins fraîches. Un tour d'un groupe - round-robin ou multi-block - n'est jamais interrompu parce que l'autre groupe devient dû entre-temps. La ligne de journal combinée \"full-coverage cycle\" est remplacée par une ligne par groupe, enregistrée dès que le tour de ce groupe est terminé, indiquant le temps réellement écoulé ainsi qu'une moyenne glissante sur les 10 derniers tours",
+        "it": "la lettura di sensori e impostazioni non avviene più in sincronia: i sensori vengono letti il più velocemente possibile consentito dal protocollo (limitato a al massimo una volta ogni 10s), mentre le impostazioni vengono lette solo ogni 60s, più una volta subito dopo che un valore è stato scritto sulla pompa di calore - questo riduce la frequenza con cui il controllo stesso della pompa di calore viene interrogato per i dati di impostazione, che cambiano raramente, senza rendere i dati dei sensori meno aggiornati. Un giro di un gruppo - round-robin o multi-block - non viene mai interrotto perché l'altro gruppo diventa dovuto nel frattempo. La riga di log combinata \"full-coverage cycle\" è sostituita da una riga per gruppo, registrata nel momento in cui il giro di quel gruppo si completa, che mostra il tempo effettivamente trascorso e una media mobile sugli ultimi 10 giri",
+        "es": "la lectura de sensores y ajustes ya no se realiza al mismo ritmo: los sensores se leen tan rápido como lo permite el protocolo (limitado a como máximo una vez cada 10s), mientras que los ajustes solo se leen cada 60s, más una vez justo después de escribir cualquier valor en la bomba de calor - esto reduce la frecuencia con la que se consulta el propio control de la bomba de calor para los datos de ajustes, que cambian con poca frecuencia, sin hacer que los datos de los sensores sean menos actuales. Una pasada de un grupo - round-robin o multi-block - nunca se interrumpe porque el otro grupo pase a estar pendiente mientras tanto. La línea de registro combinada \"full-coverage cycle\" se sustituye por una línea por grupo, registrada en el momento en que la pasada de ese grupo se completa, mostrando el tiempo real transcurrido y una media móvil de las últimas 10 pasadas",
+        "pl": "odczyt czujników i ustawień nie odbywa się już w jednym rytmie: czujniki są odczytywane tak szybko, jak pozwala protokół (ograniczone do maksymalnie raz na 10s), natomiast ustawienia są odczytywane tylko raz na 60s, plus raz zaraz po zapisaniu jakiejkolwiek wartości do pompy ciepła - to zmniejsza częstotliwość odpytywania samego sterownika pompy ciepła o rzadko zmieniające się dane ustawień, bez pogarszania aktualności danych czujników. Przebieg grupy - round-robin czy multi-block - nigdy nie jest przerywany przez to, że druga grupa staje się w międzyczasie należna. Połączona linia dziennika \"full-coverage cycle\" została zastąpiona jedną linią na grupę, zapisywaną w chwili zakończenia przebiegu danej grupy, pokazującą rzeczywisty upływający czas oraz średnią kroczącą z ostatnich 10 przebiegów",
+        "zh-cn": "传感器和设置的轮询不再同步进行:传感器会以协议允许的最快速度读取(限制为最多每10秒一次),而设置每60秒才读取一次,并且在每次向热泵写入数值后会立即额外读取一次——这减少了对热泵控制器本身、针对变化较少的设置数据的轮询频率,同时不会降低传感器数据的实时性。一个分组的一轮采集——无论是逐个轮询还是多区块请求——都不会因为另一个分组中途到期而被打断。合并的\"full-coverage cycle\"日志行已被替换为每个分组各一行,在该分组本轮采集完成时记录,显示实际耗时以及最近10轮的滚动平均值",
+        "uk": "опитування датчиків і налаштувань більше не виконується в єдиному ритмі: датчики читаються настільки швидко, наскільки дозволяє протокол (але не частіше одного разу на 10с), а налаштування читаються лише раз на 60с, плюс одразу після будь-якого запису значення в тепловий насос - це зменшує частоту опитування самого контролера теплового насоса для рідко змінюваних даних налаштувань, не роблячи при цьому дані датчиків менш актуальними. Прохід групи - round-robin чи multi-block - ніколи не переривається через те, що інша група тим часом стає готовою до опитування. Об'єднаний рядок журналу \"full-coverage cycle\" замінено на окремий рядок для кожної групи, який записується одразу після завершення проходу цієї групи і показує фактичний витрачений час та ковзне середнє за останні 10 проходів"
+      },
+      "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",
@@ -67,32 +93,6 @@
         "pl": "poprawka: ponowna próba dla już precyzyjnie dostrojonego bloku danych nie zwiększa już opóźnienia o pełny, zgrubny krok - teraz koryguje o ten sam mały krok, do którego zbiegło dostrajanie, i eskaluje ponownie tylko wtedy, gdy próby faktycznie się powtarzają",
         "zh-cn": "修复:对已经精细调优的数据块进行重试时,不再将延迟直接跳增整个粗略步长——现在会按照调优已收敛到的相同小步长进行修正,只有在重试确实反复发生时才会重新升级步长",
         "uk": "виправлення: повторна спроба для вже точно налаштованого блока даних більше не збільшує затримку одразу на весь грубий крок - тепер вона коригується тим самим малим кроком, до якого зійшло налаштування, і знову зростає лише якщо повтори справді повторюються"
-      },
-      "1.3.9": {
-        "en": "the full-coverage cycle log line now lists every block's current content delay, and the adaptive per-block delay now eases down in progressively finer steps (down to 1ms) instead of always by a flat 100ms",
-        "de": "die Vollzyklus-Log-Zeile listet jetzt den aktuellen Content-Delay jedes Blocks auf, und der adaptive Delay pro Block wird jetzt in immer feineren Schritten (bis auf 1ms) statt immer um pauschal 100ms abgebaut",
-        "ru": "строка журнала о полном цикле теперь содержит текущую задержку содержимого каждого блока, а адаптивная задержка по блокам теперь снижается всё более мелкими шагами (вплоть до 1 мс) вместо фиксированных 100 мс",
-        "pt": "a linha de log do ciclo completo agora lista o atraso de conteúdo atual de cada bloco, e o atraso adaptativo por bloco agora diminui em passos cada vez mais finos (até 1ms) em vez de sempre 100ms fixos",
-        "nl": "de full-coverage-cyclusregel toont nu de huidige content-vertraging van elk blok, en de adaptieve vertraging per blok wordt nu in steeds fijnere stappen (tot 1ms) afgebouwd in plaats van steeds met vaste 100ms",
-        "fr": "la ligne de log du cycle complet liste désormais le délai de contenu actuel de chaque bloc, et le délai adaptatif par bloc diminue maintenant par paliers de plus en plus fins (jusqu'à 1ms) au lieu de toujours 100ms fixes",
-        "it": "la riga di log del ciclo completo ora elenca il ritardo di contenuto attuale di ogni blocco, e il ritardo adattivo per blocco ora si riduce con passi sempre più fini (fino a 1ms) anziché sempre di 100ms fissi",
-        "es": "la línea de registro del ciclo completo ahora lista el retardo de contenido actual de cada bloque, y el retardo adaptativo por bloque ahora se reduce en pasos cada vez más finos (hasta 1ms) en lugar de siempre 100ms fijos",
-        "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)