iobroker.laundrylens 0.4.37 → 0.4.39

package/README.md

@@ -132,6 +132,17 @@ This also works inside the conditional `[...]` blocks: `[🌡️ Outside: {state
 
 ### **WORK IN PROGRESS**
 
+### 0.4.39 (2026-10-06)
+- Fix: reported live - `elapsedTime` stayed frozen (often at a stale value left over from a previous cycle) for the entire "detecting..." period of a new cycle, only starting to update once a program was actually confirmed (observed: stuck at 11342 while only ~15 minutes into a new washer cycle; for a dryer, jumped from frozen to 1096 the moment the program was recognized). Root cause: `elapsedTime` is just `Date.now()` minus the cycle's start time, with no real dependency on program detection - but the `onTimeUpdate` callback that wrote it (via `_onTime()`) returned early, skipping the write entirely, whenever `WashDataManager._updateTimeEstimate()` reported no program/bestCandidate yet
+- Fixed by extracting the computation into a shared `_updateElapsedTime()` helper, now called unconditionally at the top of `onTimeUpdate` - before its "no program detected" early return - as well as from `_onTime()`'s normal path, so it updates from the moment a cycle starts running regardless of detection status
+- Covered by a new regression test (`tests/test_elapsed_time_before_detection.js`)
+
+### 0.4.38 (2026-10-04)
+- New: the Lernkontrolle (learning review/feedback) flow can now be driven from a VIS dashboard, not just the admin tab - previously only reachable via sendTo commands, invisible to VIS, which can only read/write data points
+- New read-only data points: `pendingFeedbackCount`, `pendingFeedback` (JSON array of all unconfirmed cycles, oldest first), and `feedbackCycleId`/`feedbackProgram`/`feedbackDuration`/`feedbackEnergy`/`feedbackConfidence` (convenience fields for the oldest pending cycle, so a simple VIS text widget doesn't need to parse JSON)
+- New writable actions, each acting on the oldest pending cycle: `feedbackConfirm` (button - same as the admin tab's "Correct – confirm"), `feedbackCorrectProgram` (dropdown of program names, kept in sync the same way `programOverride`'s own dropdown is - writing a name corrects and confirms, same as the admin tab's "Wrong program" flow), `feedbackDelete` (button - discards the cycle without confirming it)
+- Covered by a new test file (`tests/test_vis_feedback_actions.js`, 17 cases) plus an extension to `test_english_only.js`'s existing state/migration-coverage invariant check (the ten new state ids are brand new, so correctly added to the "nothing to migrate" allow-list rather than the migrations object)
+
 ### 0.4.37 (2026-10-03)
 - Fix: three test files added in recent releases (`test_show_probable_program.js`, `test_cycle_finish_exception_guard.js`, `test_cycle_boundary_reset.js`) called the bare global `setTimeout()`/`setInterval()` directly in their fake-adapter mocks - the same mistake made and fixed before in other test files, missed again when writing these new ones. Brought in line with the native-timer-alias pattern used everywhere else in this suite (review checker E5004/E5005)
 - Fix: `@iobroker/testing` devDependency bumped to `^6.3.0` (current; was `^6.2.2`)

package/io-package.json

@@ -1,8 +1,34 @@
 {
     "common": {
         "name": "laundrylens",
-        "version": "0.4.37",
+        "version": "0.4.39",
         "news": {
+            "0.4.39": {
+                "en": "Fix: elapsedTime stayed frozen (often at a stale value left over from a previous cycle) for the entire \"detecting...\" period of a new cycle, only starting to update once a program was actually confirmed. elapsedTime is just Date.now() minus the cycle's start time though, with no real dependency on program detection - the callback that writes it was simply skipped entirely whenever no program had been recognized yet. Now updates from the moment a cycle starts running, regardless of detection status.",
+                "de": "Fix: elapsedTime blieb waehrend der gesamten \"detecting...\"-Phase eines neuen Zyklus eingefroren (oft auf einem veralteten Wert vom vorherigen Zyklus) und aktualisierte sich erst, sobald ein Programm tatsaechlich bestaetigt war. elapsedTime ist aber nur Date.now() minus Zyklusstartzeit, ohne echte Abhaengigkeit von der Programmerkennung - der Callback, der es schreibt, wurde schlicht komplett uebersprungen, solange noch kein Programm erkannt war. Aktualisiert sich jetzt ab dem Moment, in dem ein Zyklus zu laufen beginnt, unabhaengig vom Erkennungsstatus.",
+                "ru": "Исправление: elapsedTime оставался замороженным (часто на устаревшем значении с предыдущего цикла) на протяжении всего периода \"detecting...\" нового цикла и начинал обновляться только после фактического подтверждения программы. Однако elapsedTime - это просто Date.now() минус время начала цикла, без реальной зависимости от распознавания программы - колбэк, который его записывал, просто полностью пропускался, пока программа ещё не была распознана. Теперь обновляется с момента начала работы цикла, независимо от статуса распознавания.",
+                "pt": "Correcao: elapsedTime permanecia congelado (muitas vezes num valor obsoleto deixado do ciclo anterior) durante todo o periodo \"detecting...\" de um novo ciclo, so comecando a atualizar quando um programa era realmente confirmado. No entanto, elapsedTime e apenas Date.now() menos o horario de inicio do ciclo, sem dependencia real da deteccao de programa - o callback que o escrevia era simplesmente ignorado por completo enquanto nenhum programa tivesse sido reconhecido ainda. Agora atualiza a partir do momento em que um ciclo comeca a rodar, independente do status de deteccao.",
+                "nl": "Fix: elapsedTime bleef bevroren (vaak op een verouderde waarde van een vorige cyclus) gedurende de hele \"detecting...\"-periode van een nieuwe cyclus en werd pas bijgewerkt zodra een programma daadwerkelijk bevestigd was. elapsedTime is echter gewoon Date.now() min de startijd van de cyclus, zonder echte afhankelijkheid van programmaherkenning - de callback die het schreef werd simpelweg volledig overgeslagen zolang nog geen programma herkend was. Wordt nu bijgewerkt vanaf het moment dat een cyclus begint te lopen, ongeacht de herkenningsstatus.",
+                "fr": "Correction : elapsedTime restait fige (souvent sur une valeur obsolete laissee par un cycle precedent) pendant toute la periode \"detecting...\" d'un nouveau cycle, ne commencant a se mettre a jour qu'une fois un programme reellement confirme. Pourtant, elapsedTime n'est que Date.now() moins l'heure de debut du cycle, sans veritable dependance a la detection du programme - le callback qui l'ecrivait etait simplement totalement ignore tant qu'aucun programme n'avait encore ete reconnu. Se met desormais a jour des l'instant ou un cycle commence a tourner, quel que soit l'etat de detection.",
+                "it": "Correzione: elapsedTime restava bloccato (spesso su un valore obsoleto lasciato da un ciclo precedente) per l'intero periodo \"detecting...\" di un nuovo ciclo, iniziando ad aggiornarsi solo una volta che un programma veniva effettivamente confermato. Tuttavia elapsedTime e solo Date.now() meno l'orario di inizio del ciclo, senza una reale dipendenza dal rilevamento del programma - il callback che lo scriveva veniva semplicemente saltato del tutto finche non era stato riconosciuto alcun programma. Ora si aggiorna dal momento in cui un ciclo inizia a funzionare, indipendentemente dallo stato di rilevamento.",
+                "es": "Correccion: elapsedTime permanecia congelado (a menudo en un valor obsoleto de un ciclo anterior) durante todo el periodo \"detecting...\" de un nuevo ciclo, y solo empezaba a actualizarse una vez que se confirmaba realmente un programa. Sin embargo, elapsedTime es solo Date.now() menos la hora de inicio del ciclo, sin una dependencia real de la deteccion del programa - el callback que lo escribia simplemente se saltaba por completo mientras no se hubiera reconocido ningun programa todavia. Ahora se actualiza desde el momento en que un ciclo empieza a ejecutarse, independientemente del estado de deteccion.",
+                "pl": "Poprawka: elapsedTime pozostawal zamrozony (czesto na nieaktualnej wartosci pozostalej z poprzedniego cyklu) przez caly okres \"detecting...\" nowego cyklu i zaczynal sie aktualizowac dopiero po faktycznym potwierdzeniu programu. Jednak elapsedTime to po prostu Date.now() minus czas rozpoczecia cyklu, bez rzeczywistej zaleznosci od wykrywania programu - wywolanie zwrotne, ktore je zapisywalo, bylo po prostu calkowicie pomijane, dopoki zaden program nie zostal jeszcze rozpoznany. Teraz aktualizuje sie od momentu rozpoczecia dzialania cyklu, niezaleznie od statusu wykrywania.",
+                "uk": "Виправлення: elapsedTime залишався замороженим (часто на застарілому значенні з попереднього циклу) протягом усього періоду \"detecting...\" нового циклу і починав оновлюватися лише після фактичного підтвердження програми. Проте elapsedTime - це просто Date.now() мінус час початку циклу, без реальної залежності від розпізнавання програми - зворотний виклик, який його записував, просто повністю пропускався, доки програму ще не було розпізнано. Тепер оновлюється з моменту початку роботи циклу, незалежно від статусу розпізнавання.",
+                "zh-cn": "修复：在新周期的整个「detecting...」（检测中）阶段，elapsedTime 会一直冻结（通常停留在上一个周期遗留的过期值上），只有在程序被真正确认后才开始更新。然而 elapsedTime 其实只是 Date.now() 减去周期开始时间，与程序检测并无真正关联——写入它的回调函数在尚未识别出程序时会被完全跳过。现在从周期开始运行的那一刻起就会更新，与检测状态无关。"
+            },
+            "0.4.38": {
+                "en": "New: the Lernkontrolle (learning review/feedback) flow can now be driven from VIS, not just the admin tab. New read-only data points: pendingFeedbackCount, pendingFeedback (JSON list of all unconfirmed cycles, oldest first), and feedbackCycleId/feedbackProgram/feedbackDuration/feedbackEnergy/feedbackConfidence (convenience fields for the oldest one). New writable actions, each acting on the oldest pending cycle: feedbackConfirm (button, confirms it), feedbackCorrectProgram (dropdown of program names - writing one corrects and confirms), feedbackDelete (button, discards it without confirming).",
+                "de": "Neu: Die Lernkontrolle kann jetzt auch aus VIS heraus bedient werden, nicht nur ueber den Admin-Tab. Neue schreibgeschuetzte Datenpunkte: pendingFeedbackCount, pendingFeedback (JSON-Liste aller unbestaetigten Zyklen, aelteste zuerst) sowie feedbackCycleId/feedbackProgram/feedbackDuration/feedbackEnergy/feedbackConfidence (Komfortfelder fuer den aeltesten). Neue schreibbare Aktionen, die jeweils auf den aeltesten offenen Zyklus wirken: feedbackConfirm (Button, bestaetigt ihn), feedbackCorrectProgram (Dropdown mit Programmnamen - Eintrag schreiben korrigiert und bestaetigt), feedbackDelete (Button, verwirft ihn ohne Bestaetigung).",
+                "ru": "Новое: процесс контроля обучения (Lernkontrolle) теперь можно выполнять из VIS, а не только через вкладку администратора. Новые датапоинты только для чтения: pendingFeedbackCount, pendingFeedback (JSON-список всех неподтверждённых циклов, сначала самые старые) и feedbackCycleId/feedbackProgram/feedbackDuration/feedbackEnergy/feedbackConfidence (удобные поля для самого старого). Новые доступные для записи действия, каждое воздействует на самый старый ожидающий цикл: feedbackConfirm (кнопка, подтверждает), feedbackCorrectProgram (выпадающий список названий программ - запись исправляет и подтверждает), feedbackDelete (кнопка, отклоняет без подтверждения).",
+                "pt": "Novo: o fluxo de revisao de aprendizado (Lernkontrolle) agora pode ser controlado pelo VIS, nao apenas pela aba de administracao. Novos data points somente leitura: pendingFeedbackCount, pendingFeedback (lista JSON de todos os ciclos nao confirmados, do mais antigo ao mais novo) e feedbackCycleId/feedbackProgram/feedbackDuration/feedbackEnergy/feedbackConfidence (campos de conveniencia para o mais antigo). Novas acoes graváveis, cada uma atuando no ciclo pendente mais antigo: feedbackConfirm (botao, confirma), feedbackCorrectProgram (lista suspensa de nomes de programas - escrever um corrige e confirma), feedbackDelete (botao, descarta sem confirmar).",
+                "nl": "Nieuw: de Lernkontrolle (leercontrole/feedback) kan nu ook vanuit VIS worden bediend, niet alleen via het admin-tabblad. Nieuwe alleen-lezen datapoints: pendingFeedbackCount, pendingFeedback (JSON-lijst van alle onbevestigde cycli, oudste eerst) en feedbackCycleId/feedbackProgram/feedbackDuration/feedbackEnergy/feedbackConfidence (gemaksvelden voor de oudste). Nieuwe schrijfbare acties, elk werkend op de oudste openstaande cyclus: feedbackConfirm (knop, bevestigt deze), feedbackCorrectProgram (dropdown met programmanamen - schrijven corrigeert en bevestigt), feedbackDelete (knop, verwerpt zonder te bevestigen).",
+                "fr": "Nouveau : le flux de controle d'apprentissage (Lernkontrolle) peut desormais etre pilote depuis VIS, pas seulement via l'onglet admin. Nouveaux points de donnees en lecture seule : pendingFeedbackCount, pendingFeedback (liste JSON de tous les cycles non confirmes, du plus ancien au plus recent) et feedbackCycleId/feedbackProgram/feedbackDuration/feedbackEnergy/feedbackConfidence (champs pratiques pour le plus ancien). Nouvelles actions inscriptibles, agissant chacune sur le cycle en attente le plus ancien : feedbackConfirm (bouton, le confirme), feedbackCorrectProgram (liste deroulante de noms de programmes - ecrire une valeur corrige et confirme), feedbackDelete (bouton, l'ecarte sans confirmer).",
+                "it": "Novita: il flusso di controllo dell'apprendimento (Lernkontrolle) puo ora essere gestito da VIS, non solo tramite la scheda admin. Nuovi data point di sola lettura: pendingFeedbackCount, pendingFeedback (elenco JSON di tutti i cicli non confermati, dal piu vecchio) e feedbackCycleId/feedbackProgram/feedbackDuration/feedbackEnergy/feedbackConfidence (campi comodi per il piu vecchio). Nuove azioni scrivibili, ciascuna agisce sul ciclo in sospeso piu vecchio: feedbackConfirm (pulsante, lo conferma), feedbackCorrectProgram (menu a tendina dei nomi dei programmi - scrivere un valore corregge e conferma), feedbackDelete (pulsante, lo scarta senza confermare).",
+                "es": "Novedad: el flujo de control de aprendizaje (Lernkontrolle) ahora se puede manejar desde VIS, no solo desde la pestana de administracion. Nuevos data points de solo lectura: pendingFeedbackCount, pendingFeedback (lista JSON de todos los ciclos no confirmados, el mas antiguo primero) y feedbackCycleId/feedbackProgram/feedbackDuration/feedbackEnergy/feedbackConfidence (campos de conveniencia para el mas antiguo). Nuevas acciones escribibles, cada una actuando sobre el ciclo pendiente mas antiguo: feedbackConfirm (boton, lo confirma), feedbackCorrectProgram (lista desplegable de nombres de programas - escribir uno corrige y confirma), feedbackDelete (boton, lo descarta sin confirmar).",
+                "pl": "Nowosc: proces kontroli uczenia (Lernkontrolle) mozna teraz obslugiwac z poziomu VIS, a nie tylko przez zakladke administratora. Nowe datapointy tylko do odczytu: pendingFeedbackCount, pendingFeedback (lista JSON wszystkich niepotwierdzonych cykli, od najstarszego) oraz feedbackCycleId/feedbackProgram/feedbackDuration/feedbackEnergy/feedbackConfidence (wygodne pola dla najstarszego). Nowe zapisywalne akcje, kazda dziala na najstarszym oczekujacym cyklu: feedbackConfirm (przycisk, potwierdza go), feedbackCorrectProgram (lista rozwijana nazw programow - wpisanie poprawia i potwierdza), feedbackDelete (przycisk, odrzuca bez potwierdzania).",
+                "uk": "Нове: процес контролю навчання (Lernkontrolle) тепер можна виконувати з VIS, а не лише через вкладку адміністратора. Нові датапоінти лише для читання: pendingFeedbackCount, pendingFeedback (JSON-список усіх непідтверджених циклів, спочатку найстаріші) та feedbackCycleId/feedbackProgram/feedbackDuration/feedbackEnergy/feedbackConfidence (зручні поля для найстарішого). Нові записувані дії, кожна діє на найстаріший очікуючий цикл: feedbackConfirm (кнопка, підтверджує його), feedbackCorrectProgram (випадний список назв програм - запис виправляє і підтверджує), feedbackDelete (кнопка, відхиляє без підтвердження).",
+                "zh-cn": "新增：学习检查（Lernkontrolle）流程现在也可以从 VIS 操作，而不仅限于管理标签页。新增只读数据点：pendingFeedbackCount、pendingFeedback（所有未确认周期的 JSON 列表，最旧的在前）以及 feedbackCycleId/feedbackProgram/feedbackDuration/feedbackEnergy/feedbackConfidence（针对最旧周期的便捷字段）。新增可写操作，均作用于最旧的待处理周期：feedbackConfirm（按钮，确认该周期）、feedbackCorrectProgram（程序名称下拉列表——写入即可更正并确认）、feedbackDelete（按钮，不确认直接丢弃该周期）。"
+            },
             "0.4.37": {
                 "en": "Fix: three test files added in recent releases (test_show_probable_program.js, test_cycle_finish_exception_guard.js, test_cycle_boundary_reset.js) called the bare global setTimeout()/setInterval() directly in their fake-adapter mocks, which the review checker's plain-timer-usage check flags - brought in line with the native-timer-alias pattern already used everywhere else in this test suite. Fix: bumped the @iobroker/testing devDependency to the current version (6.3.0).",
                 "de": "Fix: drei in juengeren Releases hinzugefuegte Testdateien (test_show_probable_program.js, test_cycle_finish_exception_guard.js, test_cycle_boundary_reset.js) riefen in ihren Fake-Adapter-Mocks das nackte globale setTimeout()/setInterval() direkt auf, was die Pruefung des Review-Checkers auf rohe Timer-Aufrufe meldet - an das in dieser Testsuite ueberall sonst verwendete native-Timer-Alias-Muster angeglichen. Fix: die devDependency @iobroker/testing auf die aktuelle Version (6.3.0) angehoben.",
@@ -67,32 +93,6 @@
                 "pl": "Poprawka: nowy cykl mógł przez kilka minut pokazywać pozostałość przypuszczenia programu z *poprzedniego*, już zakończonego cyklu (np. \"~30 Speed (76%)\" zaraz na starcie cyklu) - wewnętrzne pole najlepszego kandydata nie było czyszczone przy starcie nowego cyklu. Poprawka: cycleProgress pozostawał na ostatniej wartości (często 100%) po zakończeniu cyklu zamiast wrócić do 0. Poprawka: wyjątek podczas przetwarzania końcowego cyklu (zwłaszcza analiza post-hoc faz dla pralek/zmywarek) mógł po cichu blokować aktualizację datapointów statusu na żywo. Nowa opcja \"Pokaż prawdopodobny program przed potwierdzeniem\": opcjonalnie pokazuje bieżące przypuszczenie najlepszego kandydata w datapointach program/programText/confidence (z przedrostkiem \"≈\"), nie tylko we własnym podglądzie zakładki administratora. Nowa opcja \"Datapointy tekstowe bez emoji\": opcjonalnie pomija emoji w phaseText/stateText, na potrzeby dashboardów lub syntezy mowy.",
                 "uk": "Виправлення: новий цикл міг кілька хвилин показувати залишкове припущення ймовірної програми з *попереднього*, уже завершеного циклу (наприклад, \"~30 Speed (76%)\" одразу на старті циклу) - внутрішнє поле найкращого кандидата не скидалося під час старту нового циклу. Виправлення: cycleProgress залишався на останньому значенні (часто 100%) після завершення циклу замість скидання до 0. Виправлення: виняток під час постобробки наприкінці циклу (зокрема постфактум-аналіз фаз для пральних/посудомийних машин) міг непомітно блокувати оновлення датапоінтів живого статусу. Нова опція \"Показувати ймовірну програму до підтвердження\": опціонально виводить поточне припущення найкращого кандидата в датапоінти program/programText/confidence (з префіксом \"≈\"), а не лише у власному прев'ю вкладки адміністратора. Нова опція \"Текстові датапоінти без емодзі\": опціонально прибирає емодзі з phaseText/stateText для дашбордів або синтезу мовлення.",
                 "zh-cn": "修复：新周期可能会在最初几分钟内显示来自*上一个*已结束周期残留的可能程序猜测（例如周期刚开始就显示「~30 Speed (76%)」）——内部的最佳候选字段在新周期开始时未被清空。修复：周期结束后 cycleProgress 停留在最后的值（通常是 100%）而不会重置为 0。修复：周期结束后处理过程中的异常（尤其是洗衣机/洗碗机的事后阶段分析）可能会悄悄阻止实时状态数据点的更新。新增选项「确认前显示可能的程序」：可选择将实时最佳候选猜测显示到 program/programText/confidence 数据点中（带「≈」前缀），而不仅仅是管理标签页自身的预览。新增选项「文本数据点不含表情符号」：可选择在 phaseText/stateText 中省略表情符号，便于仪表盘或文本转语音使用。"
-            },
-            "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 数据点一直冻结在骤降前的最后一个值，尽管管理标签页读取的实时状态早已正确。修复方法是触发与正常周期结束转换相同的通知。如果你现在正遇到这个问题，重启适配器即可立即清除卡住的值，无需等待下一个周期。"
             }
         },
         "titleLang": {

package/main.js

@@ -347,6 +347,7 @@ class WashdataAdapter extends utils.Adapter {
           onProgramChange: (program, confidence) =>
             this._onProgram(deviceCfg.deviceId, program, confidence),
           onTimeUpdate: (remaining, total, pct) => {
+            this._updateElapsedTime(deviceCfg.deviceId);
             if (remaining === null) {
               // No program detected – reset remaining time and progress
               this.setState(`${deviceCfg.deviceId}.timeRemaining`, 0, true);
@@ -378,6 +379,11 @@ class WashdataAdapter extends utils.Adapter {
       // Subscribe to writable states
       await this.subscribeStatesAsync(`${deviceCfg.deviceId}.programOverride`);
       await this.subscribeStatesAsync(`${deviceCfg.deviceId}.forceFinish`);
+      await this.subscribeStatesAsync(`${deviceCfg.deviceId}.feedbackConfirm`);
+      await this.subscribeStatesAsync(
+        `${deviceCfg.deviceId}.feedbackCorrectProgram`,
+      );
+      await this.subscribeStatesAsync(`${deviceCfg.deviceId}.feedbackDelete`);
 
       // Disable ghost protection if the sensor is currently drawing power
       try {
@@ -664,6 +670,36 @@ class WashdataAdapter extends utils.Adapter {
           }
           return;
         }
+        if (id === `${this.namespace}.${deviceId}.feedbackConfirm`) {
+          if (state.val === true) {
+            this._handleFeedbackConfirm(deviceId, mgr).catch((err) =>
+              this.log.error(`${deviceId}: feedbackConfirm: ${err.message}`),
+            );
+            this.setState(`${deviceId}.feedbackConfirm`, false, true);
+          }
+          return;
+        }
+        if (id === `${this.namespace}.${deviceId}.feedbackCorrectProgram`) {
+          if (state.val) {
+            this._handleFeedbackCorrectProgram(deviceId, mgr, state.val).catch(
+              (err) =>
+                this.log.error(
+                  `${deviceId}: feedbackCorrectProgram: ${err.message}`,
+                ),
+            );
+          }
+          this.setState(`${deviceId}.feedbackCorrectProgram`, "", true);
+          return;
+        }
+        if (id === `${this.namespace}.${deviceId}.feedbackDelete`) {
+          if (state.val === true) {
+            this._handleFeedbackDelete(deviceId, mgr).catch((err) =>
+              this.log.error(`${deviceId}: feedbackDelete: ${err.message}`),
+            );
+            this.setState(`${deviceId}.feedbackDelete`, false, true);
+          }
+          return;
+        }
       }
     }
 
@@ -760,6 +796,84 @@ class WashdataAdapter extends utils.Adapter {
     mgr.detector.reset();
   }
 
+  // Returns the oldest cycle still needing feedback for this device, or
+  // null if there isn't one - the single target the three feedback*
+  // writable data points below act on, same cycle _updateNeedsFeedback()
+  // exposes via feedbackCycleId/feedbackProgram/etc.
+  _oldestPendingCycle(mgr) {
+    const open = mgr
+      .getCycleHistory()
+      .filter((c) => !c.confirmed)
+      .sort((a, b) => a.startTime - b.startTime);
+    return open[0] || null;
+  }
+
+  // VIS-friendly equivalent of the admin tab's confirmCycle sendTo
+  // handler (see onMessage() below), acting on the oldest pending cycle.
+  async _handleFeedbackConfirm(deviceId, mgr) {
+    const cycle = this._oldestPendingCycle(mgr);
+    if (!cycle) {
+      return;
+    }
+    cycle.confirmed = true;
+    if (cycle.profileId) {
+      mgr.profileStore.learnFromCycle(cycle.profileId, [], cycle.durationMs);
+      await mgr.profileStore.save();
+    }
+    await mgr._saveState();
+    await this._updateNeedsFeedback(deviceId, mgr);
+  }
+
+  // VIS-friendly equivalent of correctCycle, resolving the written
+  // program name back to a profile id the way programOverride's own
+  // handler (_handleProgramOverride) already does.
+  async _handleFeedbackCorrectProgram(deviceId, mgr, programName) {
+    const cycle = this._oldestPendingCycle(mgr);
+    if (!cycle) {
+      return;
+    }
+    const profile = mgr.profileStore
+      .getAllProfiles()
+      .find((p) => p.name === programName);
+    if (!profile) {
+      this.log.warn(
+        `${deviceId}: feedbackCorrectProgram: unknown program "${programName}"`,
+      );
+      return;
+    }
+    cycle.matchedProfile = profile.name;
+    cycle.profileId = profile.id;
+    cycle.confirmed = true;
+    cycle.corrected = true;
+    const traceForLearn = mgr.getTrace(cycle.id);
+    const tracePoints = traceForLearn
+      ? traceForLearn.points.map((p) => ({ ts: p.ts, watts: p.watts }))
+      : [];
+    mgr.profileStore.learnFromCycle(profile.id, tracePoints, cycle.durationMs);
+    await mgr.profileStore.save();
+    await mgr._saveState();
+    await this._updateNeedsFeedback(deviceId, mgr);
+    await this._updateOverrideStates(deviceId, mgr);
+  }
+
+  // VIS-friendly equivalent of deleteCycle, discarding the oldest
+  // pending cycle without confirming or correcting it.
+  async _handleFeedbackDelete(deviceId, mgr) {
+    const cycle = this._oldestPendingCycle(mgr);
+    if (!cycle) {
+      return;
+    }
+    const idx = mgr.cycleHistory.findIndex((c) => c.id === cycle.id);
+    if (idx === -1) {
+      return;
+    }
+    mgr.cycleHistory.splice(idx, 1);
+    mgr.traceStore.deleteTrace(cycle.id);
+    await mgr._saveState();
+    await mgr.traceStore.save();
+    await this._updateNeedsFeedback(deviceId, mgr);
+  }
+
   async onMessage(obj) {
     if (!obj || !obj.command) {
       return;
@@ -1419,16 +1533,76 @@ class WashdataAdapter extends utils.Adapter {
       JSON.stringify(profiles.map((p) => p.name)),
       true,
     );
+    // feedbackCorrectProgram's own dropdown - same program list, also
+    // without 'auto' (correcting a past, already-finished cycle to
+    // "automatic" makes no sense the way it does for programOverride)
+    await this.extendObjectAsync(`${deviceId}.feedbackCorrectProgram`, {
+      common: {
+        states: profiles.reduce((o, p) => {
+          o[p.name] = p.name;
+          return o;
+        }, {}),
+      },
+    });
   }
 
-  // ── Update "feedback needed" indicator ──────────────────
-  // Mirrors admin/tab_m.html's updateFeedbackBadge() exactly (cycles
-  // with !confirmed) - that is the only place this count was ever
-  // computed before, entirely client-side, which is why the
-  // needsFeedback data point itself was never actually written.
+  // ── Update "feedback needed" indicator + VIS-friendly pending-
+  // feedback data points ──────────────────────────────────
+  // Mirrors admin/tab_m.html's renderFeedback()/updateFeedbackBadge()
+  // exactly (cycles with !confirmed, oldest first) - that used to be
+  // the only place this was ever computed, entirely client-side via
+  // sendTo, which is why none of this was ever exposed as data points
+  // that a VIS dashboard (or any other automation) could read or act
+  // on directly.
   async _updateNeedsFeedback(deviceId, mgr) {
-    const needsFeedback = mgr.getCycleHistory().some((c) => !c.confirmed);
-    this.setState(`${deviceId}.needsFeedback`, needsFeedback, true);
+    const open = mgr
+      .getCycleHistory()
+      .filter((c) => !c.confirmed)
+      .sort((a, b) => a.startTime - b.startTime);
+
+    this.setState(`${deviceId}.needsFeedback`, open.length > 0, true);
+    this.setState(`${deviceId}.pendingFeedbackCount`, open.length, true);
+    this.setState(
+      `${deviceId}.pendingFeedback`,
+      JSON.stringify(
+        open.map((c) => ({
+          id: c.id,
+          startTime: c.startTime,
+          program: c.matchedProfile || "",
+          durationMin: Math.round((c.durationMs || 0) / 60000),
+          energyWh: Math.round((c.energyWh || 0) * 100) / 100,
+          confidencePct: Math.round((c.confidence || 0) * 100),
+        })),
+      ),
+      true,
+    );
+
+    // Convenience fields for the single oldest pending cycle - the one
+    // feedbackConfirm/feedbackCorrectProgram/feedbackDelete act on - so
+    // a simple VIS text/button widget doesn't need to parse the JSON
+    // array above just to show "what am I confirming right now".
+    const oldest = open[0];
+    this.setState(`${deviceId}.feedbackCycleId`, oldest ? oldest.id : "", true);
+    this.setState(
+      `${deviceId}.feedbackProgram`,
+      oldest ? oldest.matchedProfile || "" : "",
+      true,
+    );
+    this.setState(
+      `${deviceId}.feedbackDuration`,
+      oldest ? Math.round((oldest.durationMs || 0) / 60000) : 0,
+      true,
+    );
+    this.setState(
+      `${deviceId}.feedbackEnergy`,
+      oldest ? Math.round((oldest.energyWh || 0) * 100) / 100 : 0,
+      true,
+    );
+    this.setState(
+      `${deviceId}.feedbackConfidence`,
+      oldest ? Math.round((oldest.confidence || 0) * 100) : 0,
+      true,
+    );
   }
 
   // ── Callbacks ────────────────────────────────────────────────
@@ -1538,6 +1712,22 @@ class WashdataAdapter extends utils.Adapter {
     }
   }
 
+  // elapsedTime is purely Date.now() - cycleStartTime - meaningful and
+  // available from the moment RUNNING starts, with no actual dependency
+  // on whether a program has been detected yet. Called both from
+  // onTimeUpdate()'s "no program detected" early-return branch and from
+  // _onTime()'s normal path, so it keeps ticking up throughout the
+  // entire "detecting..." period instead of only once a program is
+  // confirmed - found live (reported stuck at a stale value, e.g. left
+  // over from a previous, longer cycle, until recognition caught up).
+  _updateElapsedTime(deviceId) {
+    const mgr = this.managers[deviceId];
+    if (mgr && mgr.cycleStartTime) {
+      const elapsedSec = Math.round((Date.now() - mgr.cycleStartTime) / 1000);
+      this.setState(`${deviceId}.elapsedTime`, elapsedSec, true);
+    }
+  }
+
   _onTime(
     deviceId,
     remainingSeconds,
@@ -1598,12 +1788,7 @@ class WashdataAdapter extends utils.Adapter {
       ).catch(() => {});
     }
     this.setState(`${deviceId}.timeRemaining`, remainingSeconds ?? 0, true);
-    // Elapsed time from the manager
-    const mgr2 = this.managers[deviceId];
-    if (mgr2 && mgr2.cycleStartTime) {
-      const elapsedSec = Math.round((Date.now() - mgr2.cycleStartTime) / 1000);
-      this.setState(`${deviceId}.elapsedTime`, elapsedSec, true);
-    }
+    this._updateElapsedTime(deviceId);
     this.setState(`${deviceId}.totalDuration`, totalSeconds ?? 0, true);
     // Only overwrite progress if > 0 (prevents a reset if the profile
     // briefly doesn't match) - UNLESS forceWrite is set, which is how
@@ -2240,6 +2425,67 @@ class WashdataAdapter extends utils.Adapter {
         def: false,
         write: false,
       },
+      // Lernkontrolle (feedback) - VIS-friendly data points so the
+      // confirm/correct/delete flow doesn't require the admin tab
+      {
+        id: "pendingFeedbackCount",
+        name: "Cycles needing feedback",
+        type: "number",
+        role: "value",
+        def: 0,
+        write: false,
+      },
+      {
+        id: "pendingFeedback",
+        name: "Cycles needing feedback (JSON)",
+        type: "string",
+        role: "json",
+        def: "[]",
+        write: false,
+      },
+      {
+        id: "feedbackCycleId",
+        name: "Oldest pending cycle ID",
+        type: "string",
+        role: "text",
+        def: "",
+        write: false,
+      },
+      {
+        id: "feedbackProgram",
+        name: "Oldest pending cycle: detected program",
+        type: "string",
+        role: "text",
+        def: "",
+        write: false,
+      },
+      {
+        id: "feedbackDuration",
+        name: "Oldest pending cycle: duration",
+        type: "number",
+        role: "value",
+        def: 0,
+        write: false,
+        unit: "min",
+      },
+      {
+        id: "feedbackEnergy",
+        name: "Oldest pending cycle: consumption",
+        type: "number",
+        role: "value",
+        def: 0,
+        write: false,
+        unit: "Wh",
+      },
+      {
+        id: "feedbackConfidence",
+        name: "Oldest pending cycle: confidence",
+        type: "number",
+        role: "value",
+        def: 0,
+        write: false,
+        unit: "%",
+      },
       // Zusatz-Info
       {
         id: "phase",
@@ -2315,6 +2561,32 @@ class WashdataAdapter extends utils.Adapter {
         write: true,
         read: false,
       },
+      {
+        id: "feedbackConfirm",
+        name: "Confirm oldest pending cycle",
+        type: "boolean",
+        role: "button",
+        def: false,
+        write: true,
+        read: false,
+      },
+      {
+        id: "feedbackCorrectProgram",
+        name: "Correct oldest pending cycle to this program, then confirm",
+        type: "string",
+        role: "text",
+        def: "",
+        write: true,
+      },
+      {
+        id: "feedbackDelete",
+        name: "Delete oldest pending cycle without confirming",
+        type: "boolean",
+        role: "button",
+        def: false,
+        write: true,
+        read: false,
+      },
     ];
 
     for (const s of states) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "iobroker.laundrylens",
-  "version": "0.4.37",
+  "version": "0.4.39",
   "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",