iobroker.idm-multitalent_002 2.1.3 → 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; 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,12 @@ 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
@@ -220,60 +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', '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, 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 - 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 +321,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,21 @@
 {
   "common": {
     "name": "idm-multitalent_002",
-    "version": "2.1.3",
+    "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",
@@ -80,19 +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мс"
       }
     },
     "titleLang": {