iobroker.laundrylens 0.4.30 → 0.4.32

package/README.md

@@ -132,6 +132,16 @@ This also works inside the conditional `[...]` blocks: `[🌡️ Outside: {state
 
 ### **WORK IN PROGRESS**
 
+### 0.4.32 (2026-09-27)
+- Fix: follow-up to 0.4.31 - a restart alone did not clear an *already*-stale `state` data point (e.g. stuck on "Running"), even with 0.4.31 installed. `onReady()` only re-wrote the `state`/`stateText`/`running`/`program`/`phase` data points when a restore branch fired (sensor currently drawing power, or a saved cycle needs resuming/finishing) - with neither true (the common case: an idle device whose last cycle already finished cleanly), nothing touched them at all, so a stale leftover value would survive any number of restarts
+- Fixed by unconditionally re-syncing these data points with the manager's actual resolved state (`manager.currentState`/`manager.getStatus()`) at the end of every device's startup, regardless of which restore branch fired or didn't. Covered by a new source-inspection regression test (`tests/test_startup_state_sync.js`); also re-ran the full js-controller integration test since this touches `onReady()`
+- If you're still seeing a stuck status after installing 0.4.31: this release should finally clear it on the next restart
+
+### 0.4.31 (2026-09-27)
+- Fix: reported live - the admin tab showed the dryer as off while the `state` data point still read "Running". Root cause: the dryer's anti-crease "power drop" quick-finish path (`WashDataManager.processPowerReading()` - force-ends a cycle 45s after a sudden power drop, to react faster than waiting for the full off-delay) set the in-memory state to `off` directly and called the internal `_onCycleFinished()`, but - unlike the normal `_onDetectorState()` OFF transition - never invoked the `onStateChange` callback afterwards. That callback is what `main.js`'s `_onManagerState()` uses to write the `state`/`stateText`/`running`/`program`/`programText`/`phase`/`phaseText` data points, so they stayed frozen on their last value from before the drop even though the live status the admin tab reads (`WashDataManager._buildStatus()` via `getStatus`) was already correct. `lastCycle`/`lastCycleProgram`/etc. were unaffected (a separate callback), which is why cycle history looked fine while only the live status data points were stuck
+- Fixed by firing `onStateChange` after the quick-finish, exactly as the normal end-of-cycle transition already does. Covered by a new regression test (`tests/test_dryer_drop_finish_state_callback.js`)
+- If you're seeing the stuck-state symptom right now: restarting the adapter clears it immediately without waiting for the next cycle to start
+
 ### 0.4.30 (2026-09-27)
 - Fix: removed the `sinon` devDependency again - it's already provided transitively via `@iobroker/testing`, so listing it directly was flagged as redundant by the review checker (E0063)
 - Fix: `tests/test_elapsed_time_unit.js`'s fake-adapter object (added in 0.4.29) made the same bare-global-timer mistake `test_restart_resume_low_power.js` had in 0.4.28 - reworked to use this suite's established native-setTimeout/setInterval alias pattern (E5004/E5005)

package/io-package.json

@@ -1,8 +1,34 @@
 {
     "common": {
         "name": "laundrylens",
-        "version": "0.4.30",
+        "version": "0.4.32",
         "news": {
+            "0.4.32": {
+                "en": "Follow-up fix to 0.4.31: a restart alone did not clear an already-stale state data point (e.g. stuck on \"Running\"), even with 0.4.31 installed. onReady() only re-writes the state/stateText/running/program/phase data points when a restore branch fires (sensor currently active, or a saved cycle needs resuming/finishing) - with neither true, the common case, nothing touched them at all. Now every device's startup unconditionally re-syncs these data points with the manager's actual resolved state, so a restart always clears any stale value immediately, regardless of cause.",
+                "de": "Folgefix zu 0.4.31: ein reiner Neustart raeumte einen bereits haengengebliebenen Status-Datenpunkt (z.B. festgefahren auf \"Running\") nicht auf, selbst mit installiertem 0.4.31. onReady() schrieb die Datenpunkte state/stateText/running/program/phase bisher nur neu, wenn ein Restore-Zweig griff (Sensor aktuell aktiv, oder ein gespeicherter Zyklus muss fortgesetzt/beendet werden) - traf keins von beidem zu, der Normalfall, wurde nichts angefasst. Jetzt synchronisiert jeder Geraete-Start diese Datenpunkte bedingungslos mit dem tatsaechlichen, aufgeloesten Zustand des Managers, sodass ein Neustart jeden haengengebliebenen Wert sofort beseitigt, unabhaengig von der Ursache.",
+                "ru": "Дополнительное исправление к 0.4.31: одна лишь перезагрузка не устраняла уже зависший датапоинт состояния (например, застрявший на \"Running\"), даже при установленном 0.4.31. onReady() перезаписывал датапоинты state/stateText/running/program/phase только при срабатывании ветки восстановления (датчик сейчас активен либо сохранённый цикл нужно возобновить/завершить) - если ни то, ни другое не верно (обычный случай), ничего не менялось. Теперь при каждом запуске устройства эти датапоинты безусловно синхронизируются с фактическим состоянием менеджера, поэтому перезапуск всегда немедленно устраняет любое зависшее значение, независимо от причины.",
+                "pt": "Correcao de acompanhamento a 0.4.29: reiniciar sozinho nao limpava um data point de estado ja obsoleto (por exemplo, preso em \"Running\"), mesmo com a 0.4.31 instalada. O onReady() so reescrevia os data points state/stateText/running/program/phase quando um ramo de restauracao era acionado (sensor atualmente ativo, ou um ciclo salvo precisa ser retomado/finalizado) - sem nenhum dos dois, o caso comum, nada era alterado. Agora a inicializacao de cada dispositivo sincroniza incondicionalmente esses data points com o estado real resolvido do gerenciador, entao reiniciar sempre limpa qualquer valor obsoleto imediatamente, independente da causa.",
+                "nl": "Vervolgfix op 0.4.31: een herstart alleen wiste een reeds verouderd state-datapoint (bijv. vastgelopen op \"Running\") niet, zelfs met 0.4.31 geinstalleerd. onReady() herschreef de datapoints state/stateText/running/program/phase alleen wanneer een herstel-tak werd geactiveerd (sensor momenteel actief, of een opgeslagen cyclus moet worden hervat/afgerond) - was geen van beide waar, het normale geval, dan werd er niets aangepast. Nu synchroniseert elke apparaatstart deze datapoints onvoorwaardelijk met de daadwerkelijk vastgestelde status van de manager, zodat een herstart elke verouderde waarde altijd meteen opheldert, ongeacht de oorzaak.",
+                "fr": "Correction complementaire a 0.4.31 : un simple redemarrage ne nettoyait pas un data point d'etat deja obsolete (par ex. bloque sur \"Running\"), meme avec la 0.4.31 installee. onReady() ne reecrivait les data points state/stateText/running/program/phase que lorsqu'une branche de restauration se declenchait (capteur actuellement actif, ou un cycle enregistre doit etre repris/termine) - si aucun des deux n'etait vrai, le cas courant, rien n'etait modifie. Desormais, chaque demarrage d'appareil resynchronise inconditionnellement ces data points avec l'etat reel resolu du gestionnaire, de sorte qu'un redemarrage efface toujours immediatement toute valeur obsolete, quelle qu'en soit la cause.",
+                "it": "Correzione di follow-up alla 0.4.31: un semplice riavvio non ripuliva un data point di stato gia bloccato (ad es. fermo su \"Running\"), anche con la 0.4.31 installata. onReady() riscriveva i data point state/stateText/running/program/phase solo quando si attivava un ramo di ripristino (sensore attualmente attivo, oppure un ciclo salvato deve essere ripreso/terminato) - se nessuno dei due era vero, il caso comune, non veniva modificato nulla. Ora l'avvio di ogni dispositivo risincronizza incondizionatamente questi data point con lo stato effettivo risolto del manager, cosi un riavvio ripulisce sempre immediatamente qualsiasi valore bloccato, indipendentemente dalla causa.",
+                "es": "Correccion de seguimiento a 0.4.31: reiniciar por si solo no limpiaba un data point de estado ya obsoleto (por ejemplo, atascado en \"Running\"), incluso con 0.4.31 instalado. onReady() solo reescribia los data points state/stateText/running/program/phase cuando se activaba una rama de restauracion (sensor actualmente activo, o un ciclo guardado necesita reanudarse/finalizarse) - si ninguno de los dos era cierto, el caso comun, no se tocaba nada. Ahora el arranque de cada dispositivo resincroniza incondicionalmente estos data points con el estado real resuelto del gestor, por lo que reiniciar siempre limpia de inmediato cualquier valor atascado, sin importar la causa.",
+                "pl": "Poprawka uzupelniajaca do 0.4.31: samo ponowne uruchomienie nie czyscilo juz nieaktualnego datapointu stanu (np. utknietego na \"Running\"), nawet po zainstalowaniu 0.4.31. onReady() ponownie zapisywal datapointy state/stateText/running/program/phase tylko wtedy, gdy uruchamiala sie galaz przywracania (czujnik aktualnie aktywny lub zapisany cykl wymaga wznowienia/zakonczenia) - jesli zadne z tych warunkow nie bylo spelnione, czyli w typowym przypadku, nic nie bylo zmieniane. Teraz uruchomienie kazdego urzadzenia bezwarunkowo synchronizuje te datapointy z faktycznym, rozwiazanym stanem menedzera, dzieki czemu ponowne uruchomienie zawsze natychmiast czysci kazda utkniete wartosc, niezaleznie od przyczyny.",
+                "uk": "Додаткове виправлення до 0.4.31: сама лише перезагрузка не очищала вже застарілий датапоінт стану (наприклад, застряглий на \"Running\"), навіть із встановленим 0.4.31. onReady() перезаписував датапоінти state/stateText/running/program/phase лише коли спрацьовувала гілка відновлення (датчик наразі активний, або збережений цикл потрібно відновити/завершити) - якщо жодне з цього не було правдою, звичайний випадок, нічого не змінювалося. Тепер запуск кожного пристрою безумовно синхронізує ці датапоінти з фактичним, визначеним станом менеджера, тому перезапуск завжди негайно очищує будь-яке застарile значення, незалежно від причини.",
+                "zh-cn": "0.4.31 的后续修复：即使安装了 0.4.31，仅重启也无法清除已经过期的状态数据点（例如卡在「Running」）。此前 onReady() 只有在触发恢复分支时（传感器当前处于活动状态，或需要恢复/结束已保存的周期）才会重写 state/stateText/running/program/phase 数据点——如果两者都不成立（这是常见情况），则完全不做任何更改。现在每台设备启动时都会无条件将这些数据点与管理器实际解析出的状态同步，因此重启总能立即清除任何过期的值，无论原因是什么。"
+            },
+            "0.4.31": {
+                "en": "Fix: a real bug report - the admin tab showed the dryer as off while the state data point still read \"Running\". Root cause: the dryer's anti-crease \"power drop\" quick-finish path (which force-ends a cycle 45s after a sudden power drop, to react faster than waiting for the full off-delay) set the in-memory state to off directly but never notified the rest of the adapter about it - so the state/stateText/running/program/phase data points stayed frozen on their last value from before the drop, even though the live status the admin tab reads was already correct. Fixed by firing the same notification the normal end-of-cycle transition already fires. If you're seeing this right now, restarting the adapter clears the stuck values immediately without waiting for the next cycle.",
+                "de": "Fix: ein realer Fehlerbericht - der Admin-Tab zeigte den Trockner als aus an, waehrend der Status-Datenpunkt noch \"Running\" anzeigte. Ursache: der Anti-Knitter-Schnellabschluss des Trockners (der einen Zyklus 45 Sekunden nach einem ploetzlichen Leistungsabfall zwangsbeendet, um schneller zu reagieren als die volle Ausschaltverzoegerung abzuwarten) setzte den internen Status direkt auf aus, benachrichtigte aber nie den Rest des Adapters darueber - daher blieben die Datenpunkte state/stateText/running/program/phase auf ihrem letzten Wert vor dem Abfall eingefroren, obwohl der Live-Status, den der Admin-Tab liest, bereits korrekt war. Behoben, indem dieselbe Benachrichtigung ausgeloest wird, die der normale Zyklusende-Uebergang ohnehin schon ausloest. Wer das gerade sieht: ein Neustart des Adapters raeumt die haengengebliebenen Werte sofort auf, ohne auf den naechsten Zyklus warten zu muessen.",
+                "ru": "Исправление: реальный отчёт об ошибке - вкладка администратора показывала сушилку выключенной, тогда как датапоинт состояния всё ещё показывал \"Running\". Причина: путь быстрого завершения цикла сушилки при защите от сминания (\"power drop\" - принудительно завершает цикл через 45 секунд после резкого падения мощности, чтобы реагировать быстрее полной задержки отключения) устанавливал внутреннее состояние в off напрямую, но никогда не уведомлял остальную часть адаптера об этом - поэтому датапоинты state/stateText/running/program/phase оставались замороженными на последнем значении до падения, хотя живой статус, который читает вкладка администратора, уже был корректен. Исправлено вызовом того же уведомления, которое уже вызывает обычный переход в конце цикла. Если вы видите это прямо сейчас, перезапуск адаптера немедленно устраняет зависшие значения без ожидания следующего цикла.",
+                "pt": "Correcao: um relato real de bug - a aba de administracao mostrava a secadora como desligada enquanto o data point de estado ainda mostrava \"Running\". Causa raiz: o caminho de finalizacao rapida por queda de energia (anti-amarrotamento) da secadora (que forca o fim de um ciclo 45s apos uma queda subita de energia, para reagir mais rapido do que esperar o atraso total de desligamento) definia o estado interno como desligado diretamente, mas nunca notificava o restante do adaptador sobre isso - entao os data points state/stateText/running/program/phase ficavam congelados no ultimo valor antes da queda, mesmo que o status ao vivo lido pela aba de administracao ja estivesse correto. Corrigido disparando a mesma notificacao que a transicao normal de fim de ciclo ja dispara. Se voce esta vendo isso agora, reiniciar o adaptador limpa os valores presos imediatamente, sem esperar pelo proximo ciclo.",
+                "nl": "Fix: een echte bugmelding - het admin-tabblad toonde de droger als uit terwijl het state-datapoint nog \"Running\" liet zien. Oorzaak: het kreukbeschermings-\"stroomval\"-snelafsluitpad van de droger (dat een cyclus 45s na een plotselinge stroomval geforceerd beeindigt om sneller te reageren dan de volledige uitschakelvertraging) zette de interne status direct op uit, maar informeerde de rest van de adapter daar nooit over - waardoor de datapoints state/stateText/running/program/phase bevroren bleven op hun laatste waarde van voor de val, terwijl de live status die het admin-tabblad leest al correct was. Opgelost door dezelfde melding te versturen die de normale cyclus-einde-overgang al verstuurt. Zie je dit nu, dan lost een herstart van de adapter de vastzittende waarden meteen op, zonder op de volgende cyclus te hoeven wachten.",
+                "fr": "Correction : un vrai signalement de bug - l'onglet admin affichait le secheur comme eteint alors que le data point d'etat indiquait encore \"Running\". Cause : le chemin de fin rapide anti-froissage du secheur (qui force la fin d'un cycle 45s apres une chute soudaine de puissance, pour reagir plus vite que d'attendre le delai d'arret complet) mettait l'etat interne a off directement, mais ne notifiait jamais le reste de l'adaptateur - les data points state/stateText/running/program/phase restaient donc figes sur leur derniere valeur d'avant la chute, alors que le statut en direct lu par l'onglet admin etait deja correct. Corrige en declenchant la meme notification que la transition normale de fin de cycle declenche deja. Si vous voyez ce cas maintenant, redemarrer l'adaptateur efface immediatement les valeurs bloquees sans attendre le prochain cycle.",
+                "it": "Correzione: una segnalazione reale di bug - la scheda admin mostrava l'asciugatrice come spenta mentre il data point di stato mostrava ancora \"Running\". Causa: il percorso di chiusura rapida anti-piega dell'asciugatrice (che forza la fine di un ciclo 45s dopo un calo improvviso di potenza, per reagire piu velocemente rispetto ad attendere il ritardo di spegnimento completo) impostava lo stato interno su off direttamente, ma non notificava mai il resto dell'adattatore - quindi i data point state/stateText/running/program/phase restavano bloccati sull'ultimo valore prima del calo, anche se lo stato live letto dalla scheda admin era gia corretto. Risolto attivando la stessa notifica gia attivata dalla normale transizione di fine ciclo. Se lo state vedendo ora, riavviare l'adattatore risolve subito i valori bloccati senza attendere il ciclo successivo.",
+                "es": "Correccion: un informe real de error - la pestana de administracion mostraba la secadora como apagada mientras el data point de estado aun mostraba \"Running\". Causa raiz: el camino de finalizacion rapida anti-arrugas de la secadora (que fuerza el fin de un ciclo 45s despues de una caida repentina de potencia, para reaccionar mas rapido que esperar el retraso de apagado completo) establecia el estado interno en apagado directamente, pero nunca notificaba al resto del adaptador - por lo que los data points state/stateText/running/program/phase quedaban congelados en su ultimo valor antes de la caida, aunque el estado en vivo que lee la pestana de administracion ya era correcto. Corregido disparando la misma notificacion que ya dispara la transicion normal de fin de ciclo. Si esta viendo esto ahora mismo, reiniciar el adaptador limpia los valores atascados de inmediato, sin esperar al proximo ciclo.",
+                "pl": "Poprawka: prawdziwe zgloszenie bledu - zakladka administratora pokazywala suszarke jako wylaczona, podczas gdy datapoint stanu nadal pokazywal \"Running\". Przyczyna: sciezka szybkiego zakonczenia cyklu suszarki przy ochronie przed gnieceniem (\"power drop\" - wymusza zakonczenie cyklu 45s po nagłym spadku mocy, aby zareagowac szybciej niz czekajac na pelne opoznienie wylaczenia) ustawiala stan wewnetrzny na wylaczony bezposrednio, ale nigdy nie powiadamiala o tym reszty adaptera - dlatego datapointy state/stateText/running/program/phase pozostawaly zamrozone na ostatniej wartosci sprzed spadku, mimo ze status na zywo odczytywany przez zakladke administratora byl juz poprawny. Naprawiono, wywolujac to samo powiadomienie, ktore wywoluje juz normalne przejscie konca cyklu. Jesli widzisz to teraz, ponowne uruchomienie adaptera natychmiast czysci utkniete wartosci bez czekania na kolejny cykl.",
+                "uk": "Виправлення: реальне повідомлення про помилку - вкладка адміністратора показувала сушарку вимкненою, тоді як датапоінт стану все ще показував \"Running\". Причина: шлях швидкого завершення циклу сушарки при захисті від зминання (\"power drop\" - примусово завершує цикл через 45 секунд після різкого падіння потужності, щоб реагувати швидше за повне очікування затримки вимкнення) встановлював внутрішній стан на вимкнено напряму, але ніколи не повідомляв про це решту адаптера - тому датапоінти state/stateText/running/program/phase залишалися замороженими на останньому значенні до падіння, хоча живий статус, який читає вкладка адміністратора, вже був коректним. Виправлено викликом того самого сповіщення, яке вже викликає звичайний перехід у кінці циклу. Якщо ви бачите це зараз, перезапуск адаптера негайно очищує застряглі значення без очікування наступного циклу.",
+                "zh-cn": "修复：一个真实的问题反馈——管理标签页显示烘干机已关闭，但状态数据点仍显示「Running」。根本原因：烘干机的防皱「功率骤降」快速结束路径（在功率突然下降 45 秒后强制结束周期，以比等待完整关闭延迟更快地做出反应）直接将内存中的状态设为关闭，但从未通知适配器的其余部分——因此 state/stateText/running/program/phase 数据点一直冻结在骤降前的最后一个值，尽管管理标签页读取的实时状态早已正确。修复方法是触发与正常周期结束转换相同的通知。如果你现在正遇到这个问题，重启适配器即可立即清除卡住的值，无需等待下一个周期。"
+            },
             "0.4.30": {
                 "en": "Fix: elapsedTime declares role \"value.interval\", which requires its value in seconds, but it was computed and stored in minutes everywhere (the state definition's unit, the one-time migration for existing installs, main.js's periodic update, and the live snapshot the admin tab reads via getStatus). All four now consistently use seconds, matching timeRemaining/totalDuration. Fix: removed the sinon devDependency again - it's already provided transitively via @iobroker/testing, so listing it directly was redundant (review checker E0063). Fix: a second test file's fake-adapter timers reworked to use this suite's established native-setTimeout/setInterval alias pattern (review checker E5004/E5005).",
                 "de": "Fix: elapsedTime deklariert die Rolle \"value.interval\", die einen Wert in Sekunden erfordert, wurde aber ueberall in Minuten berechnet und gespeichert (die unit der State-Definition, die einmalige Migration fuer bestehende Installationen, das periodische Update in main.js sowie der Live-Snapshot, den der Admin-Tab ueber getStatus liest). Alle vier Stellen nutzen jetzt konsistent Sekunden, passend zu timeRemaining/totalDuration. Fix: die devDependency sinon wieder entfernt - sie wird bereits transitiv ueber @iobroker/testing bereitgestellt, die direkte Auflistung war daher ueberfluessig (Review-Checker E0063). Fix: die Fake-Adapter-Timer einer weiteren Testdatei auf das in dieser Suite etablierte native-setTimeout/setInterval-Alias-Muster umgestellt (Review-Checker E5004/E5005).",
@@ -67,32 +93,6 @@
                 "pl": "Nowość: pełny model uczenia się czasu trwania faz do szacowania pozostałego czasu. Każdy program uczy się teraz nie tylko całkowitego czasu trwania, ale także tego, jak długo zazwyczaj trwa każda pojedyncza faza i w jakiej kolejności. Gdy dostępnych jest wystarczająco dużo danych, pozostały czas jest szacowany jako \"czas pozostały w bieżącej fazie plus typowy czas trwania każdej fazy, która historycznie następuje po niej\" - znacznie dokładniejsze pod koniec cyklu niż pojedyncza średnia dla całego cyklu.",
                 "uk": "Новинка: повна модель навчання тривалості фаз для оцінки залишкового часу. Тепер кожна програма вивчає не лише загальну тривалість, а й те, скільки зазвичай триває кожна окрема фаза та в якому порядку. Щойно накопичиться достатньо даних, залишковий час оцінюється як «час, що залишився в поточній фазі, плюс типова тривалість кожної фази, яка історично йде після неї» - значно точніше наприкінці циклу, ніж єдине загальне середнє значення.",
                 "zh-cn": "新功能：用于剩余时间估算的完整分阶段时长学习模型。现在每个程序不仅学习总时长，还学习每个单独阶段（加热、洗涤、脱水、烘干、冷却等）通常需要多长时间，以及它们的先后顺序。一旦积累了足够的数据，剩余时间将被估算为\"当前阶段剩余时间，加上历史上在此之后各阶段的典型时长之和\"——这在周期接近结束时比单一的整体周期平均值准确得多，尤其适用于像烘干机主烘干阶段这种相对总时长位置波动很大的阶段。"
-            },
-            "0.4.24": {
-                "en": "Improved remaining-time/progress accuracy, especially for the dryer: each program now also learns how much its real duration actually varies cycle to cycle (e.g. a dryer's drying time depends heavily on load size/dampness, so it naturally varies much more than a fixed-temperature wash). The remaining-time estimate now leans more on the live energy-consumption pace for programs known to vary a lot, and more on the historical time average for consistent ones. The reported progress percentage is now derived from that same estimate, so it can no longer disagree with the predicted finish time. Added a remaining-time cap for the dryer's short \"cooling\" phase, matching the washer's existing \"spinning\" cap.",
-                "de": "Genauigkeit von Restzeit/Fortschritt verbessert, besonders beim Trockner: Jedes Programm lernt jetzt zusätzlich, wie stark seine tatsächliche Dauer von Zyklus zu Zyklus wirklich schwankt (z.B. hängt die Trockenzeit stark von Beladungsgröße/Feuchte ab und schwankt daher naturgemäß viel stärker als ein Waschgang mit fester Temperatur). Die Restzeit-Schätzung stützt sich jetzt bei Programmen mit bekannt hoher Schwankung stärker auf das aktuelle Verbrauchstempo, bei gleichbleibenden Programmen stärker auf den historischen Zeitdurchschnitt. Die angezeigte Fortschrittsprozentzahl wird jetzt aus derselben Schätzung abgeleitet, sodass sie nicht mehr im Widerspruch zur vorhergesagten Endzeit stehen kann. Eine Restzeit-Obergrenze für die kurze „Abkühlen\"-Phase des Trockners ergänzt, passend zur bereits bestehenden „Schleudern\"-Obergrenze der Waschmaschine.",
-                "ru": "Улучшена точность оставшегося времени/прогресса, особенно для сушильной машины: теперь каждая программа также учится тому, насколько сильно её реальная длительность варьируется от цикла к циклу. Оценка оставшегося времени теперь больше опирается на текущий темп потребления энергии для программ с известной высокой изменчивостью и больше на исторический средний показатель для стабильных программ. Отображаемый процент прогресса теперь рассчитывается на основе той же оценки. Добавлено ограничение оставшегося времени для короткой фазы охлаждения сушилки, аналогично существующему ограничению для фазы отжима стиральной машины.",
-                "pt": "Precisão do tempo restante/progresso melhorada, especialmente para a secadora: cada programa agora também aprende o quanto sua duração real varia de ciclo para ciclo. A estimativa de tempo restante agora se apoia mais no ritmo de consumo de energia ao vivo para programas conhecidos por variar muito, e mais na média histórica de tempo para os consistentes. A porcentagem de progresso exibida agora é derivada dessa mesma estimativa. Adicionado um limite de tempo restante para a fase curta de \"resfriamento\" da secadora, semelhante ao limite já existente de \"centrifugação\" da lavadora.",
-                "nl": "Nauwkeurigheid van resterende tijd/voortgang verbeterd, vooral voor de droger: elk programma leert nu ook hoezeer de werkelijke duur echt varieert per cyclus. De schatting van de resterende tijd leunt nu meer op het actuele energieverbruikstempo bij programma's met bekende grote variatie, en meer op het historische tijdgemiddelde bij consistente programma's. Het weergegeven voortgangspercentage wordt nu afgeleid van dezelfde schatting. Een limiet voor de resterende tijd toegevoegd voor de korte \"afkoel\"-fase van de droger, vergelijkbaar met de bestaande \"centrifugeren\"-limiet van de wasmachine.",
-                "fr": "Précision du temps restant/de la progression améliorée, en particulier pour le sèche-linge : chaque programme apprend désormais aussi à quel point sa durée réelle varie d'un cycle à l'autre. L'estimation du temps restant s'appuie désormais davantage sur le rythme de consommation d'énergie en direct pour les programmes connus pour beaucoup varier, et davantage sur la moyenne historique pour les programmes constants. Le pourcentage de progression affiché est désormais dérivé de cette même estimation. Ajout d'une limite de temps restant pour la courte phase de \"refroidissement\" du sèche-linge, à l'image de la limite \"essorage\" déjà existante du lave-linge.",
-                "it": "Precisione di tempo rimanente/progresso migliorata, specialmente per l'asciugatrice: ogni programma ora impara anche quanto la sua durata reale varia effettivamente da ciclo a ciclo. La stima del tempo rimanente ora si basa maggiormente sul ritmo di consumo energetico in tempo reale per i programmi noti per variare molto, e maggiormente sulla media storica per quelli costanti. La percentuale di progresso mostrata è ora derivata dalla stessa stima. Aggiunto un limite al tempo rimanente per la breve fase di \"raffreddamento\" dell'asciugatrice, come già avviene per la fase di \"centrifuga\" della lavatrice.",
-                "es": "Precisión del tiempo restante/progreso mejorada, especialmente para la secadora: cada programa ahora también aprende cuánto varía realmente su duración de un ciclo a otro. La estimación del tiempo restante ahora se apoya más en el ritmo de consumo de energía en vivo para programas con alta variabilidad conocida, y más en el promedio histórico de tiempo para los consistentes. El porcentaje de progreso mostrado ahora se deriva de esa misma estimación. Se añadió un límite de tiempo restante para la breve fase de \"enfriamiento\" de la secadora, similar al límite de \"centrifugado\" ya existente de la lavadora.",
-                "pl": "Poprawiono dokładność pozostałego czasu/postępu, zwłaszcza dla suszarki: każdy program uczy się teraz również, jak bardzo jego rzeczywisty czas trwania różni się między cyklami. Szacowanie pozostałego czasu opiera się teraz bardziej na bieżącym tempie zużycia energii dla programów o znanej dużej zmienności, a bardziej na historycznej średniej czasowej dla stabilnych programów. Wyświetlany procent postępu jest teraz wyprowadzany z tego samego oszacowania. Dodano limit pozostałego czasu dla krótkiej fazy \"chłodzenia\" suszarki, podobnie jak istniejący już limit dla fazy \"wirowania\" pralki.",
-                "uk": "Покращено точність залишкового часу/прогресу, особливо для сушарки: кожна програма тепер також вивчає, наскільки сильно її реальна тривалість насправді відрізняється від циклу до циклу. Оцінка залишкового часу тепер більше спирається на поточний темп споживання енергії для програм із відомою високою мінливістю та більше на історичне середнє значення для стабільних програм. Відображений відсоток прогресу тепер визначається на основі тієї самої оцінки. Додано обмеження залишкового часу для короткої фази \"охолодження\" сушарки, за аналогією з наявним обмеженням \"віджиму\" пральної машини.",
-                "zh-cn": "改进了剩余时间/进度的准确性，尤其是烘干机：现在每个程序还会学习其实际时长在各周期之间的真实波动程度（例如烘干时间在很大程度上取决于负载大小/湿度，因此天然比恒温洗涤波动更大）。对于已知波动较大的程序，剩余时间估算现在更多依赖实时能耗节奏；对于稳定的程序，则更多依赖历史平均时长。显示的进度百分比现在基于同一估算得出，因此不会再与预计完成时间相矛盾。新增了烘干机简短\"冷却\"阶段的剩余时间上限，与洗衣机现有的\"脱水\"阶段上限保持一致。"
-            },
-            "0.4.23": {
-                "en": "Fix: a cycle interrupted by an ioBroker restart while the device's power had already returned to idle was silently orphaned - it stayed stuck showing \"running\" (with stale pre-restart values) forever, since the on-startup restore logic only handled the case where power was still high at restart. Combined with the offDelayMin fix in 0.4.22, this should resolve \"cycle never ends\" reports after a mid/post-cycle adapter restart. If a cycle still gets stuck after this, please share the adapter log so any remaining cause can be found.",
-                "de": "Fix: Ein Zyklus, der durch einen ioBroker-Neustart unterbrochen wurde, während die Leistung des Geräts bereits wieder im Leerlauf war, wurde stillschweigend vergessen - er blieb für immer als „läuft\" hängen (mit veralteten Werten von vor dem Neustart), da die Wiederherstellungs-Logik beim Start nur den Fall behandelte, dass die Leistung beim Neustart noch hoch war. Zusammen mit dem offDelayMin-Fix aus 0.4.22 sollte das Meldungen von „Zyklus endet nie\" nach einem Adapter-Neustart mitten im oder nach einem Zyklus beheben. Falls ein Zyklus danach weiterhin hängen bleibt, bitte das Adapter-Log teilen.",
-                "ru": "Исправление: цикл, прерванный перезапуском ioBroker в момент, когда мощность устройства уже вернулась к простою, незаметно забывался - он навсегда оставался в состоянии «работает» (с устаревшими значениями до перезапуска), поскольку логика восстановления при запуске обрабатывала только случай, когда мощность при перезапуске всё ещё была высокой. В сочетании с исправлением offDelayMin из 0.4.22 это должно устранить сообщения о том, что «цикл никогда не завершается» после перезапуска адаптера.",
-                "pt": "Correção: um ciclo interrompido por uma reinicialização do ioBroker enquanto a energia do dispositivo já havia voltado ao repouso era silenciosamente esquecido - ficava preso mostrando \"em execução\" para sempre (com valores desatualizados de antes da reinicialização), já que a lógica de restauração na inicialização só tratava o caso em que a energia ainda estava alta na reinicialização. Combinado com a correção do offDelayMin na 0.4.22, isso deve resolver relatos de \"ciclo nunca termina\" após uma reinicialização do adaptador.",
-                "nl": "Fix: een cyclus die werd onderbroken door een herstart van ioBroker terwijl het vermogen van het apparaat al was teruggekeerd naar inactief, werd stilzwijgend vergeten - deze bleef voor altijd \"actief\" tonen (met verouderde waarden van vóór de herstart), omdat de herstellogica bij het opstarten alleen het geval afhandelde waarin het vermogen bij herstart nog hoog was. Samen met de offDelayMin-fix in 0.4.22 zou dit meldingen van \"cyclus eindigt nooit\" na een herstart van de adapter moeten oplossen.",
-                "fr": "Correction : un cycle interrompu par un redémarrage d'ioBroker alors que la puissance de l'appareil était déjà revenue au repos était silencieusement oublié - il restait bloqué indéfiniment sur « en cours » (avec des valeurs obsolètes d'avant le redémarrage), car la logique de restauration au démarrage ne traitait que le cas où la puissance était encore élevée au redémarrage. Combiné à la correction d'offDelayMin dans la 0.4.22, cela devrait résoudre les rapports de « cycle qui ne se termine jamais » après un redémarrage de l'adaptateur.",
-                "it": "Correzione: un ciclo interrotto da un riavvio di ioBroker mentre la potenza del dispositivo era già tornata inattiva veniva silenziosamente dimenticato - rimaneva bloccato mostrando \"in esecuzione\" per sempre (con valori obsoleti precedenti al riavvio), poiché la logica di ripristino all'avvio gestiva solo il caso in cui la potenza fosse ancora alta al riavvio. Combinato con la correzione di offDelayMin nella 0.4.22, questo dovrebbe risolvere le segnalazioni di \"il ciclo non termina mai\" dopo un riavvio dell'adattatore.",
-                "es": "Corrección: un ciclo interrumpido por un reinicio de ioBroker mientras la energía del dispositivo ya había vuelto al reposo se olvidaba silenciosamente - se quedaba atascado mostrando \"en ejecución\" para siempre (con valores obsoletos previos al reinicio), ya que la lógica de restauración al inicio solo manejaba el caso en que la energía seguía alta en el reinicio. Combinado con la corrección de offDelayMin en la 0.4.22, esto debería resolver los informes de \"el ciclo nunca termina\" tras un reinicio del adaptador.",
-                "pl": "Poprawka: cykl przerwany przez ponowne uruchomienie ioBroker, gdy moc urządzenia już wróciła do stanu bezczynności, był po cichu zapominany - pozostawał na zawsze zablokowany, pokazując \"działa\" (z nieaktualnymi wartościami sprzed ponownego uruchomienia), ponieważ logika przywracania przy starcie obsługiwała tylko przypadek, gdy moc była nadal wysoka przy restarcie. W połączeniu z poprawką offDelayMin w 0.4.22 powinno to rozwiązać zgłoszenia \"cykl nigdy się nie kończy\" po ponownym uruchomieniu adaptera.",
-                "uk": "Виправлення: цикл, перерваний перезапуском ioBroker, коли потужність пристрою вже повернулася до простою, непомітно забувався - він назавжди залишався у стані \"працює\" (із застарілими значеннями до перезапуску), оскільки логіка відновлення під час запуску обробляла лише випадок, коли потужність усе ще була високою під час перезапуску. У поєднанні з виправленням offDelayMin у 0.4.22 це має вирішити повідомлення про те, що \"цикл ніколи не завершується\" після перезапуску адаптера.",
-                "zh-cn": "修复：当设备功率已恢复到空闲状态时，因 ioBroker 重启而中断的周期会被静默遗忘——它会永远卡在\"运行中\"状态（显示重启前的过期数值），因为启动时的恢复逻辑此前只处理了重启时功率仍然较高的情况。结合 0.4.22 中的 offDelayMin 修复，这应该能解决适配器重启后\"周期永不结束\"的问题。"
             }
         },
         "titleLang": {

package/lib/washDataManager.js

@@ -442,6 +442,21 @@ class WashDataManager {
               this.detector.powerTrace = savedTrace;
               this._onCycleFinished(eventData);
               this.detector.powerTrace = [];
+              // This finish path bypasses the normal _onDetectorState()
+              // OFF transition entirely, so without this the
+              // onStateChange callback (which writes the state/
+              // stateText/running/program/phase data points in
+              // main.js's _onManagerState()) never fires here - the
+              // live in-memory state flips to "off" correctly (visible
+              // in the admin tab's real-time view), but the persisted
+              // state data point stays stuck on whatever it showed
+              // during the cycle ("running") until the next cycle
+              // starts. Found from a real report: admin tab showed the
+              // dryer as off while the state data point still read
+              // "Running".
+              if (typeof this.callbacks.onStateChange === "function") {
+                this.callbacks.onStateChange("off", this._buildStatus());
+              }
             }, 45000);
             return;
           }

package/main.js

@@ -583,6 +583,24 @@ class WashdataAdapter extends utils.Adapter {
       this.log.info(
         `${deviceCfg.name}: started – sensor: ${deviceCfg.powerId}`,
       );
+
+      // Always re-sync the persisted state/stateText/running/program/
+      // phase data points with the manager's actual resolved state at
+      // this point, regardless of which restore branch above fired (or
+      // none at all). Without this, a clean startup with no active
+      // cycle to restore never touches these data points at all - so
+      // any stale value left over from before the restart (the exact
+      // symptom fixed in 0.4.31: the state data point stuck on
+      // "Running" after a dryer anti-crease quick-finish that forgot
+      // to fire onStateChange) would stay stuck forever, surviving
+      // even a full adapter restart, until a brand new cycle happened
+      // to start. This call is idempotent - if the data points already
+      // match, it's a harmless no-op.
+      this._onManagerState(
+        deviceCfg.deviceId,
+        manager.currentState,
+        manager.getStatus(),
+      );
     }
 
     this.setState("info.connection", true, true);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "iobroker.laundrylens",
-  "version": "0.4.30",
+  "version": "0.4.32",
   "description": "ioBroker adapter that detects washing machine and dryer cycles via smart plug power measurement, matches them against learned programs and estimates remaining time",
   "author": {
     "name": "backfisch88",