iobroker.idm-multitalent_002 2.1.3 → 2.2.1

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; 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.
+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,15 @@ Example screenshots of objects:
 ![Status](resources/ioBrokerAdapter-Status.jpg)
 
 ## Changelog
+### 2.2.1 (2026-09-13)
+* (zloe) the per-sweep log line introduced in 2.2.0 (`sensor sweep done in ...`) is now logged at debug level instead of info - in normal operation a sensor sweep completes roughly every 10s, which was far too chatty for info level. In its place, a new info-level summary is logged once every 10 minutes with a small statistic (sweep count, min/avg/max duration) per group covering that window
+
+### 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
@@ -220,60 +229,74 @@ 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', '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.
+#### 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 at **debug** level, e.g. `sensor sweep done in 1400ms (avg of last 10: 1360ms)` - one line
+per group, logged the moment that group's sweep finishes. 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.
+
+Since a sensor sweep normally completes roughly every 10s, debug is the right level for that
+per-sweep detail - logging it at info would flood the log in normal operation. Instead, once every
+10 minutes (fixed), one small **info**-level summary line reports both groups' activity over that
+window, e.g. `last 10min - sensor: 58 sweep(s), 1360ms avg (min 1210ms, max 1890ms); settings: 9
+sweep(s), 640ms avg (min 600ms, max 720ms)` - or `0 sweeps` for a group that hasn't completed one
+in that window. This is the only sweep-related log at info level now; it replaces the earlier
+combined "full-coverage cycle" line, which no longer made sense once the two groups started running
+on independent schedules.
 
 #### 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 - 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 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.
+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
@@ -308,14 +331,9 @@ for the first time ever. This benefits every firmware equally, not just the ones
 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):
-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 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.

package/io-package.json

@@ -1,8 +1,34 @@
 {
   "common": {
     "name": "idm-multitalent_002",
-    "version": "2.1.3",
+    "version": "2.2.1",
     "news": {
+      "2.2.1": {
+        "en": "the per-sweep log line introduced in 2.2.0 (\"sensor sweep done in ...\") is now logged at debug level instead of info - a sensor sweep normally completes roughly every 10s, which was too chatty for info level. In its place, a small info-level summary is now logged once every 10 minutes, with a statistic (sweep count, min/avg/max duration) per group covering that window",
+        "de": "die in 2.2.0 eingeführte Log-Zeile pro Durchlauf (\"sensor sweep done in ...\") wird jetzt auf Debug-Level statt Info protokolliert - ein Sensor-Durchlauf ist normalerweise etwa alle 10s abgeschlossen, was auf Info-Level zu viel Rauschen erzeugte. Stattdessen wird jetzt alle 10 Minuten eine kleine Info-Level-Zusammenfassung protokolliert, mit einer Statistik (Anzahl Durchläufe, min/durchschnittliche/max Dauer) pro Gruppe für dieses Zeitfenster",
+        "ru": "строка журнала для каждого прохода, добавленная в 2.2.0 (\"sensor sweep done in ...\"), теперь записывается на уровне debug вместо info - проход сенсоров обычно завершается примерно каждые 10с, что было слишком часто для уровня info. Вместо этого теперь раз в 10 минут записывается небольшая сводка на уровне info со статистикой (количество проходов, мин/среднее/макс длительность) по каждой группе за этот период",
+        "pt": "a linha de log por varredura introduzida na 2.2.0 (\"sensor sweep done in ...\") agora é registrada em nível debug em vez de info - uma varredura de sensores normalmente é concluída a cada 10s, o que era muito frequente para o nível info. Em seu lugar, agora é registrado um pequeno resumo em nível info a cada 10 minutos, com uma estatística (contagem de varreduras, duração mín/média/máx) por grupo naquele período",
+        "nl": "de per-ronde logregel die in 2.2.0 werd geïntroduceerd (\"sensor sweep done in ...\") wordt nu op debug-niveau gelogd in plaats van info - een sensorronde is normaal ongeveer elke 10s voltooid, wat te veel ruis gaf op info-niveau. In plaats daarvan wordt nu elke 10 minuten een kleine samenvatting op info-niveau gelogd, met een statistiek (aantal rondes, min/gemiddelde/max duur) per groep over die periode",
+        "fr": "la ligne de journal par tour introduite dans la 2.2.0 (\"sensor sweep done in ...\") est désormais enregistrée au niveau debug au lieu de info - un tour des capteurs se termine normalement environ toutes les 10s, ce qui était trop fréquent pour le niveau info. À la place, un petit résumé de niveau info est maintenant enregistré toutes les 10 minutes, avec une statistique (nombre de tours, durée min/moyenne/max) par groupe sur cette période",
+        "it": "la riga di log per giro introdotta nella 2.2.0 (\"sensor sweep done in ...\") viene ora registrata a livello debug invece che info - un giro dei sensori normalmente si completa circa ogni 10s, il che era troppo frequente per il livello info. Al suo posto, ora viene registrato un piccolo riepilogo a livello info ogni 10 minuti, con una statistica (numero di giri, durata min/media/max) per gruppo relativa a quel periodo",
+        "es": "la línea de registro por pasada introducida en la 2.2.0 (\"sensor sweep done in ...\") ahora se registra en nivel debug en lugar de info - una pasada de sensores normalmente se completa cada 10s aproximadamente, lo cual era demasiado frecuente para el nivel info. En su lugar, ahora se registra un pequeño resumen en nivel info cada 10 minutos, con una estadística (número de pasadas, duración mín/media/máx) por grupo durante ese periodo",
+        "pl": "linia dziennika dla każdego przebiegu wprowadzona w 2.2.0 (\"sensor sweep done in ...\") jest teraz zapisywana na poziomie debug zamiast info - przebieg czujników zwykle kończy się co około 10s, co było zbyt częste dla poziomu info. Zamiast tego co 10 minut zapisywane jest teraz małe podsumowanie na poziomie info, ze statystyką (liczba przebiegów, min/średni/maks czas trwania) dla każdej grupy w tym okresie",
+        "zh-cn": "2.2.0 中引入的每轮采集日志行(\"sensor sweep done in ...\")现在改为以 debug 级别记录,而不是 info 级别——传感器一轮采集通常约每10秒完成一次,这在 info 级别下过于频繁。取而代之的是,现在每10分钟记录一条小型 info 级别摘要,包含该分组在此期间的统计信息(采集次数、最小/平均/最大耗时)",
+        "uk": "рядок журналу для кожного проходу, доданий у 2.2.0 (\"sensor sweep done in ...\"), тепер записується на рівні debug замість info - прохід датчиків зазвичай завершується приблизно кожні 10с, що було занадто часто для рівня info. Натомість тепер раз на 10 хвилин записується невеликий підсумок на рівні info зі статистикою (кількість проходів, мін/середня/макс тривалість) для кожної групи за цей період"
+      },
+      "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",
@@ -67,32 +93,6 @@
         "pl": "dla S_H726100 wartości ustawień są teraz zbierane w jednym połączonym żądaniu zamiast jednego bloku na cykl odpytywania - pełne odświeżenie ustawień trwa teraz sekundy zamiast około minuty. Pozostałe obsługiwane firmware nie są tym dotknięte",
         "zh-cn": "对于 S_H726100,设置值现在通过一次合并请求一次性收集,而不再是每个轮询周期只读取一个区块——完整刷新一次设置现在只需几秒钟,而不是大约一分钟。其他所有受支持的固件均不受影响",
         "uk": "для S_H726100 значення налаштувань тепер збираються одним об'єднаним запитом замість одного блоку за цикл опитування - повне оновлення налаштувань тепер триває секунди замість приблизно хвилини. Усі інші підтримувані прошивки це не стосується"
-      },
-      "1.3.10": {
-        "en": "fix: a retry on an already finely-tuned data block no longer jumps the delay up by the full coarse step - it now corrects by the same small step the tuning had converged to, and only escalates back up if retries keep actually recurring",
-        "de": "fix: ein Retry auf einen bereits fein eingestellten Datenblock springt das Delay nicht mehr um den vollen groben Schritt hoch - er korrigiert jetzt um denselben kleinen Schritt, auf den die Feinabstimmung bereits konvergiert war, und eskaliert nur weiter, wenn Retries tatsächlich wiederholt auftreten",
-        "ru": "исправление: повтор для уже точно настроенного блока данных больше не увеличивает задержку сразу на весь грубый шаг - теперь коррекция происходит на тот же малый шаг, до которого сошлась точная настройка, и шаг увеличивается снова только при повторяющихся сбоях",
-        "pt": "correção: uma nova tentativa em um bloco de dados já ajustado finamente não aumenta mais o atraso pelo passo grosseiro completo - agora corrige pelo mesmo passo pequeno ao qual o ajuste havia convergido, e só aumenta novamente se as tentativas realmente se repetirem",
-        "nl": "fix: een retry op een al fijn afgesteld datablok verhoogt de vertraging niet meer met de volledige grove stap - er wordt nu gecorrigeerd met dezelfde kleine stap waarnaar de afstelling al was geconvergeerd, en de stap wordt alleen weer groter als retries daadwerkelijk blijven terugkomen",
-        "fr": "correctif : une nouvelle tentative sur un bloc de données déjà finement ajusté n'augmente plus le délai du pas grossier complet - elle corrige désormais du même petit pas vers lequel l'ajustement avait convergé, et n'escalade à nouveau que si les tentatives se répètent réellement",
-        "it": "correzione: un retry su un blocco dati già finemente calibrato non aumenta più il ritardo dell'intero passo grossolano - ora corregge con lo stesso piccolo passo a cui la calibrazione era convergente, e aumenta di nuovo solo se i retry continuano davvero a ripetersi",
-        "es": "corrección: un reintento en un bloque de datos ya ajustado finamente ya no aumenta el retardo en el paso grueso completo - ahora corrige con el mismo paso pequeño al que había convergido el ajuste, y solo vuelve a escalar si los reintentos realmente siguen repitiéndose",
-        "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мс"
       }
     },
     "titleLang": {