iobroker.laundrylens 0.4.33 → 0.4.34

package/README.md

@@ -132,6 +132,11 @@ This also works inside the conditional `[...]` blocks: `[🌡️ Outside: {state
 
 ### **WORK IN PROGRESS**
 
+### 0.4.34 (2026-10-02)
+- Fix: reported live with screenshots - `availablePrograms` could show `[]` for a device that clearly had saved programs visible in the admin tab's own "Programme" list, while a second device correctly showed all of its programs. Root cause: the data point (and `programOverride`'s dropdown states) was only ever written from five specific admin-tab actions (create/delete/rename a program, "clear all data") - never at startup, and never after a program got auto-learned from a confirmed cycle. A device whose programs were all auto-learned, with none of those five actions performed since the last restart, kept showing an empty list indefinitely even though `profileStore` had loaded the real programs from disk
+- Fix: `needsFeedback` stayed `false` even with a cycle visibly pending confirmation in the admin tab's "Lernkontrolle" tab (complete with its own "1" badge). Root cause: the data point was declared in `io-package.json` but never actually written anywhere - the admin tab computes its own pending-cycle count entirely client-side (`updateFeedbackBadge()` in `tab_m.html`, counting cycles with `!confirmed`), so the data point itself never reflected it
+- Both are now re-synced (a) unconditionally at the end of every device's startup, (b) after every finished cycle, and (c) - for `needsFeedback` - after a cycle is confirmed or corrected via the admin tab, mirroring the admin tab's own counting logic exactly
+
 ### 0.4.33 (2026-10-02)
 - Fix: reported live with logs + a screenshot - a brand new cycle could show a leftover best-candidate guess from the *previous*, already-finished cycle for several minutes (e.g. "~30 Speed (76%)" right at the start of a new washing-machine cycle, matching exactly what the previous cycle had matched), before that new cycle's own matching had run even once. Root cause: `_onDetectorState()`'s `STARTING` case reset about a dozen per-cycle fields but not `_bestCandidate`, the field driving both the admin tab's live preview and, at the next confirmed transition, the persisted `program`/`programText`/`confidence` data points. The `STARTING` transition is now the single, authoritative reset point for every per-cycle field (also added the phase-tracking fields as defensive redundancy) - a new cycle can no longer show anything left over from the one before it
 - Fix: `cycleProgress` stayed stuck at its last value (often 100%) after a cycle finished, instead of resetting to 0. The reset call reused `_onTime()`, which has a guard that only writes `cycleProgress` when `progressPct > 0` (meant to ignore a brief non-match mid-cycle) - the deliberate reset-to-0 call was silently swallowed by that same guard. `_onTime()` now takes a `forceWrite` parameter that the reset call uses to bypass the guard

package/io-package.json

@@ -1,8 +1,21 @@
 {
     "common": {
         "name": "laundrylens",
-        "version": "0.4.33",
+        "version": "0.4.34",
         "news": {
+            "0.4.34": {
+                "en": "Fix: availablePrograms could show [] for a device that clearly had saved programs (visible in the admin tab's own Programme list) - it was only ever written from specific admin-tab actions (create/delete/rename a program, clear all data), never at startup or after a program got auto-learned from a confirmed cycle. Fix: needsFeedback stayed false even with a cycle visibly pending confirmation in the admin tab's Lernkontrolle tab - the data point was declared but never actually written anywhere; the admin tab computed its own pending-count entirely client-side. Both are now kept in sync at adapter startup, after every finished cycle, and (for needsFeedback) after a cycle is confirmed or corrected.",
+                "de": "Fix: availablePrograms konnte [] anzeigen, obwohl ein Gerät eindeutig gespeicherte Programme hatte (sichtbar in der Admin-Tab-eigenen Programme-Liste) - der Datenpunkt wurde nur von bestimmten Admin-Tab-Aktionen geschrieben (Programm anlegen/löschen/umbenennen, alle Daten löschen), nie beim Start oder nachdem ein Programm aus einem bestätigten Zyklus automatisch gelernt wurde. Fix: needsFeedback blieb auf false, obwohl im Lernkontrolle-Tab des Admin-Tabs sichtbar ein Zyklus auf Bestätigung wartete - der Datenpunkt war deklariert, wurde aber nirgends tatsächlich beschrieben; der Admin-Tab berechnete seine eigene Anzahl offener Zyklen komplett clientseitig. Beide werden jetzt beim Adapterstart, nach jedem beendeten Zyklus und (bei needsFeedback) nach einer Bestätigung/Korrektur eines Zyklus synchron gehalten.",
+                "ru": "Исправление: availablePrograms мог показывать [], хотя у устройства явно были сохранённые программы (видимые в собственном списке «Программы» админ-вкладки) - датапоинт записывался только при определённых действиях в админ-вкладке (создание/удаление/переименование программы, очистка всех данных), но никогда при запуске или после автоматического обучения программе из подтверждённого цикла. Исправление: needsFeedback оставался false, хотя на вкладке «Контроль обучения» админ-панели был явно виден цикл, ожидающий подтверждения - датапоинт был объявлен, но нигде фактически не записывался; админ-вкладка вычисляла своё количество ожидающих циклов полностью на стороне клиента. Теперь оба синхронизируются при запуске адаптера, после каждого завершённого цикла и (для needsFeedback) после подтверждения или исправления цикла.",
+                "pt": "Correção: availablePrograms podia mostrar [] mesmo com um dispositivo claramente com programas salvos (visíveis na própria lista de Programas da aba de administração) - o data point só era escrito a partir de ações específicas da aba de administração (criar/excluir/renomear um programa, limpar todos os dados), nunca na inicialização ou após um programa ser aprendido automaticamente a partir de um ciclo confirmado. Correção: needsFeedback permanecia false mesmo com um ciclo visivelmente pendente de confirmação na aba Lernkontrolle da administração - o data point estava declarado, mas nunca era realmente escrito em lugar nenhum; a aba de administração calculava sua própria contagem pendente inteiramente no lado do cliente. Ambos agora são sincronizados na inicialização do adaptador, após cada ciclo finalizado e (para needsFeedback) após um ciclo ser confirmado ou corrigido.",
+                "nl": "Fix: availablePrograms kon [] tonen voor een apparaat dat duidelijk opgeslagen programma's had (zichtbaar in de eigen Programma's-lijst van het admin-tabblad) - het datapoint werd alleen geschreven vanuit specifieke admin-tabbladacties (programma aanmaken/verwijderen/hernoemen, alle data wissen), nooit bij opstarten of nadat een programma automatisch was geleerd uit een bevestigde cyclus. Fix: needsFeedback bleef false terwijl er zichtbaar een cyclus wachtte op bevestiging in het Lernkontrolle-tabblad van de admin - het datapoint was gedeclareerd maar werd nergens daadwerkelijk geschreven; het admin-tabblad berekende zijn eigen aantal openstaande cycli volledig client-side. Beide worden nu gesynchroniseerd bij het opstarten van de adapter, na elke afgeronde cyclus en (voor needsFeedback) na het bevestigen of corrigeren van een cyclus.",
+                "fr": "Correction : availablePrograms pouvait afficher [] pour un appareil ayant clairement des programmes enregistrés (visibles dans la propre liste Programmes de l'onglet admin) - le point de données n'était écrit que depuis des actions spécifiques de l'onglet admin (créer/supprimer/renommer un programme, effacer toutes les données), jamais au démarrage ni après qu'un programme ait été appris automatiquement à partir d'un cycle confirmé. Correction : needsFeedback restait à false alors qu'un cycle était visiblement en attente de confirmation dans l'onglet Lernkontrolle de l'admin - le point de données était déclaré mais jamais réellement écrit nulle part ; l'onglet admin calculait son propre nombre de cycles en attente entièrement côté client. Les deux sont désormais resynchronisés au démarrage de l'adaptateur, après chaque cycle terminé et (pour needsFeedback) après la confirmation ou la correction d'un cycle.",
+                "it": "Correzione: availablePrograms poteva mostrare [] per un dispositivo che aveva chiaramente programmi salvati (visibili nella lista Programmi della scheda admin stessa) - il data point veniva scritto solo da azioni specifiche della scheda admin (creare/eliminare/rinominare un programma, cancellare tutti i dati), mai all'avvio o dopo che un programma veniva appreso automaticamente da un ciclo confermato. Correzione: needsFeedback restava false anche con un ciclo visibilmente in attesa di conferma nella scheda Lernkontrolle dell'admin - il data point era dichiarato ma non veniva mai effettivamente scritto da nessuna parte; la scheda admin calcolava il proprio conteggio in sospeso interamente lato client. Entrambi vengono ora sincronizzati all'avvio dell'adattatore, dopo ogni ciclo terminato e (per needsFeedback) dopo la conferma o correzione di un ciclo.",
+                "es": "Corrección: availablePrograms podía mostrar [] para un dispositivo que claramente tenía programas guardados (visibles en la propia lista de Programas de la pestaña de administración) - el data point solo se escribía desde acciones específicas de la pestaña de administración (crear/eliminar/renombrar un programa, borrar todos los datos), nunca al iniciar ni después de que un programa se aprendiera automáticamente a partir de un ciclo confirmado. Corrección: needsFeedback permanecía en false aunque había visiblemente un ciclo pendiente de confirmación en la pestaña Lernkontrolle de administración - el data point estaba declarado pero nunca se escribía realmente en ningún sitio; la pestaña de administración calculaba su propio recuento pendiente completamente del lado del cliente. Ambos se sincronizan ahora al iniciar el adaptador, tras cada ciclo finalizado y (para needsFeedback) tras confirmar o corregir un ciclo.",
+                "pl": "Poprawka: availablePrograms mógł pokazywać [], mimo że urządzenie wyraźnie miało zapisane programy (widoczne we własnej liście Programy zakładki administratora) - datapoint był zapisywany tylko przy określonych akcjach w zakładce administratora (utworzenie/usunięcie/zmiana nazwy programu, wyczyszczenie wszystkich danych), nigdy przy starcie ani po automatycznym nauczeniu się programu z potwierdzonego cyklu. Poprawka: needsFeedback pozostawał false, mimo że w zakładce Lernkontrolle administratora widoczny był cykl oczekujący na potwierdzenie - datapoint był zadeklarowany, ale nigdzie faktycznie nie był zapisywany; zakładka administratora obliczała własną liczbę oczekujących cykli całkowicie po stronie klienta. Oba są teraz synchronizowane przy starcie adaptera, po każdym zakończonym cyklu oraz (dla needsFeedback) po potwierdzeniu lub poprawieniu cyklu.",
+                "uk": "Виправлення: availablePrograms міг показувати [], хоча пристрій явно мав збережені програми (видимі у власному списку «Програми» вкладки адміністратора) - датапоінт записувався лише при певних діях у вкладці адміністратора (створення/видалення/перейменування програми, очищення всіх даних), ніколи під час запуску або після автоматичного навчання програми з підтвердженого циклу. Виправлення: needsFeedback залишався false, хоча на вкладці «Контроль навчання» адміністратора було явно видно цикл, що очікує підтвердження - датапоінт був оголошений, але ніде фактично не записувався; вкладка адміністратора обчислювала власну кількість очікуючих циклів повністю на стороні клієнта. Обидва тепер синхронізуються під час запуску адаптера, після кожного завершеного циклу та (для needsFeedback) після підтвердження чи виправлення циклу.",
+                "zh-cn": "修复：即使设备明显已保存程序（在管理标签页自己的「程序」列表中可见），availablePrograms 仍可能显示为 []——该数据点此前只在特定的管理标签页操作中写入（创建/删除/重命名程序、清除所有数据），从不在启动时或某个程序通过已确认的周期自动学习后写入。修复：即使管理标签页的「学习检查」标签页中明显有一个周期待确认，needsFeedback 仍保持 false——该数据点已声明但从未在任何地方真正写入过；管理标签页完全在客户端自行计算待处理数量。现在两者都会在适配器启动时、每次周期结束后，以及（对于 needsFeedback）在确认或更正某个周期后保持同步。"
+            },
             "0.4.33": {
                 "en": "Fix: a new cycle could show a leftover probable-program guess from the *previous*, already-finished cycle for several minutes (e.g. \"~30 Speed (76%)\" right at cycle start) - the internal best-candidate field wasn't cleared when a new cycle started. Fix: cycleProgress stayed stuck at its last value (often 100%) after a cycle finished instead of resetting to 0. Fix: an exception during cycle-finish post-processing (notably the post-hoc phase analysis for washing machines/dishwashers) could silently block the live status data points from updating. New option \"Show probable program before confirmation\": optionally surfaces the live best-candidate guess into the program/programText/confidence data points (prefixed with \"≈\"), not just in the admin tab's own preview. New option \"Text data points without emoji\": optionally omits the emoji from phaseText/stateText, for dashboards or text-to-speech.",
                 "de": "Fix: ein neuer Zyklus konnte minutenlang eine Restvermutung des *vorherigen*, bereits beendeten Zyklus anzeigen (z. B. \"~30 Speed (76%)\" direkt beim Start) - das interne Bestkandidat-Feld wurde beim Start eines neuen Zyklus nicht zurückgesetzt. Fix: cycleProgress blieb nach Zyklusende auf dem letzten Wert (oft 100%) hängen, statt auf 0 zurückgesetzt zu werden. Fix: eine Exception bei der Nachbearbeitung am Zyklusende (insbesondere die Post-hoc-Phasenanalyse für Waschmaschine/Spülmaschine) konnte die Aktualisierung der Live-Status-Datenpunkte stillschweigend blockieren. Neue Option \"Wahrscheinliches Programm vor Bestätigung anzeigen\": zeigt optional die Live-Bestkandidat-Vermutung in den Datenpunkten program/programText/confidence an (mit \"≈\"-Präfix), nicht nur in der Admin-Tab-eigenen Vorschau. Neue Option \"Text-Datenpunkte ohne Emoji\": lässt optional das Emoji in phaseText/stateText weg, für Dashboards oder Sprachausgabe.",
@@ -80,19 +93,6 @@
                 "pl": "Poprawka: rozwijana lista celu powiadomienia pokazywała na sztywno zakodowany niemiecki tekst zastępczy (\"Alle (broadcast)\") dla każdego adaptera powiadomień poza Telegram/e-mail, niezależnie od skonfigurowanego języka systemu - teraz wszędzie używa istniejącego tłumaczenia. Poprawka: wyświetlana nazwa użytkownika Telegram (którą może dowolnie ustawić każdy użytkownik piszący do skonfigurowanego bota) była zapisywana w opcjach rozwijanej listy zakładki administratora bez ucieczki HTML - teraz jest escapowana przed wstawieniem.",
                 "uk": "Виправлення: спадний список цілі сповіщення показував жорстко закодований німецький текст-заповнювач (\"Alle (broadcast)\") для будь-якого адаптера сповіщень, крім Telegram/email, незалежно від налаштованої системної мови - тепер скрізь використовується наявний переклад. Виправлення: відображуване ім'я користувача Telegram (яке може довільно встановити будь-який користувач, що пише налаштованому боту) записувалося в опції спадного списку вкладки адміністратора без екранування HTML - тепер екранується перед вставкою.",
                 "zh-cn": "修复：通知目标下拉菜单在除 Telegram/邮件之外的所有通知适配器中都显示硬编码的德语占位文本（\"Alle (broadcast)\"），与所配置的系统语言无关——现在统一使用现有的翻译。修复：Telegram 用户的显示名称（任何给已配置的机器人发消息的用户都可以任意设置）此前未经 HTML 转义就被写入管理标签页的下拉选项——现在会在插入前进行转义处理。"
-            },
-            "0.4.26": {
-                "en": "Fix: a program correctly detected early in a cycle could later revert to \"detecting...\" near the end, if it had been confirmed at a moderate confidence (60-74%) rather than a very high one. The protection against this (locking a confirmed program so a later run of unmatched readings can't wipe it) used to only activate if some individual reading happened to also reach 75% confidence on its own - now it activates immediately on every confirmation, regardless of the confirming confidence. A high-confidence, persistent override to a genuinely different program is still possible and unaffected.",
-                "de": "Fix: Ein früh im Zyklus korrekt erkanntes Programm konnte gegen Ende wieder auf „erkenne...\" zurückfallen, wenn es mit moderater statt sehr hoher Konfidenz (60-74%) bestätigt worden war. Der Schutz davor (ein bestätigtes Programm sperren, damit es eine spätere Serie von Nicht-Treffern nicht löschen kann) griff bisher nur, wenn zufällig auch eine einzelne Messung 75% Konfidenz erreichte - jetzt greift er sofort bei jeder Bestätigung, unabhängig von der bestätigenden Konfidenz. Ein hochsicherer, dauerhafter Wechsel zu einem tatsächlich anderen Programm bleibt weiterhin möglich und unverändert.",
-                "ru": "Исправление: программа, правильно определённая в начале цикла, могла позже снова показать «определение...» ближе к концу, если она была подтверждена с умеренной, а не очень высокой уверенностью (60-74%). Защита от этого (блокировка подтверждённой программы, чтобы более поздняя серия несовпадений не могла её стереть) раньше активировалась только если какое-то отдельное измерение случайно достигало 75% уверенности - теперь она активируется сразу при каждом подтверждении, независимо от подтверждающей уверенности.",
-                "pt": "Correção: um programa corretamente detectado no início de um ciclo podia voltar a mostrar \"detectando...\" perto do fim, se tivesse sido confirmado com confiança moderada (60-74%) em vez de muito alta. A proteção contra isso (bloquear um programa confirmado para que uma série posterior de leituras sem correspondência não o apague) antes só era ativada se alguma leitura individual também atingisse 75% de confiança - agora é ativada imediatamente em cada confirmação, independentemente da confiança confirmadora.",
-                "nl": "Fix: een programma dat vroeg in een cyclus correct werd gedetecteerd, kon later tegen het einde weer \"detecteren...\" tonen, als het was bevestigd met een gematigde in plaats van zeer hoge betrouwbaarheid (60-74%). De bescherming hiertegen (een bevestigd programma vergrendelen zodat een latere reeks niet-overeenkomende metingen het niet kan wissen) werd voorheen alleen geactiveerd als een individuele meting toevallig ook 75% betrouwbaarheid haalde - nu wordt deze direct geactiveerd bij elke bevestiging, ongeacht de bevestigende betrouwbaarheid.",
-                "fr": "Correction : un programme correctement détecté tôt dans un cycle pouvait revenir à « détection... » vers la fin, s'il avait été confirmé avec une confiance modérée (60-74 %) plutôt que très élevée. La protection contre cela (verrouiller un programme confirmé pour qu'une série ultérieure de lectures non concordantes ne puisse pas l'effacer) ne s'activait auparavant que si une lecture individuelle atteignait aussi 75 % de confiance par hasard - elle s'active désormais immédiatement à chaque confirmation, quelle que soit la confiance de confirmation.",
-                "it": "Correzione: un programma rilevato correttamente all'inizio di un ciclo poteva tornare a \"rilevamento...\" verso la fine, se era stato confermato con una confidenza moderata (60-74%) anziché molto alta. La protezione contro questo (bloccare un programma confermato affinché una successiva serie di letture non corrispondenti non possa cancellarlo) prima si attivava solo se una singola lettura raggiungeva casualmente anche il 75% di confidenza - ora si attiva immediatamente ad ogni conferma, indipendentemente dalla confidenza di conferma.",
-                "es": "Corrección: un programa correctamente detectado al principio de un ciclo podía volver a mostrar \"detectando...\" cerca del final, si se había confirmado con una confianza moderada (60-74%) en lugar de muy alta. La protección contra esto (bloquear un programa confirmado para que una serie posterior de lecturas sin coincidencia no pueda borrarlo) antes solo se activaba si alguna lectura individual también alcanzaba el 75% de confianza por sí sola - ahora se activa inmediatamente en cada confirmación, sin importar la confianza confirmante.",
-                "pl": "Poprawka: program poprawnie wykryty na początku cyklu mógł później, bliżej końca, ponownie pokazać \"wykrywanie...\", jeśli został potwierdzony z umiarkowaną, a nie bardzo wysoką pewnością (60-74%). Zabezpieczenie przed tym (blokowanie potwierdzonego programu, aby późniejsza seria niedopasowanych odczytów nie mogła go skasować) wcześniej aktywowało się tylko wtedy, gdy pojedynczy odczyt przypadkowo osiągnął też 75% pewności - teraz aktywuje się natychmiast przy każdym potwierdzeniu, niezależnie od potwierdzającej pewności.",
-                "uk": "Виправлення: програма, правильно визначена на початку циклу, могла пізніше знову показати «визначення...» ближче до кінця, якщо вона була підтверджена з помірною, а не дуже високою впевненістю (60-74%). Захист від цього (блокування підтвердженої програми, щоб пізніша серія невідповідних показань не могла її стерти) раніше активувався лише якщо якесь окреме показання випадково також досягало 75% впевненості - тепер він активується одразу під час кожного підтвердження, незалежно від підтверджувальної впевненості.",
-                "zh-cn": "修复：一个在周期早期被正确检测到的程序，如果是以中等置信度（60-74%）而非非常高的置信度被确认的，后期可能会重新显示为\"检测中...\"。此前，防止这种情况的保护机制（锁定已确认的程序，使后续一连串不匹配的读数无法将其清除）只有在某次单独读数恰好也达到 75% 置信度时才会启用——现在无论确认时的置信度如何，每次确认都会立即启用该保护。切换到确实不同程序的高置信度、持续性覆盖机制不受影响，仍然可用。"
             }
         },
         "titleLang": {

package/main.js

@@ -608,6 +608,22 @@ class WashdataAdapter extends utils.Adapter {
         manager.currentState,
         manager.getStatus(),
       );
+
+      // Same reasoning as above, for two more data points found live to
+      // have the same "only updated from specific admin-tab actions"
+      // gap: availablePrograms/programOverride's states (only ever
+      // written from the createProfile/deleteProfile/renameProfile/
+      // clearAllData sendTo handlers - never at startup, so a device
+      // with profiles already on disk showed an empty [] until one of
+      // those actions happened to run) and needsFeedback (declared as a
+      // data point but never written anywhere at all - the admin tab's
+      // own "Lernkontrolle" badge computes its pending-cycle count
+      // entirely client-side from getCycles(), so the data point never
+      // reflected it). Both are now also re-synced after every finished
+      // cycle and (for needsFeedback) after a cycle is confirmed/
+      // corrected - see _onCycleFinished()/confirmCycle/correctCycle.
+      await this._updateOverrideStates(deviceCfg.deviceId, manager);
+      await this._updateNeedsFeedback(deviceCfg.deviceId, manager);
     }
 
     this.setState("info.connection", true, true);
@@ -851,6 +867,7 @@ class WashdataAdapter extends utils.Adapter {
             );
             await mgr.profileStore.save();
           }
+          await this._updateNeedsFeedback(obj.message.deviceId, mgr);
           respond({ ok: true });
           break;
         }
@@ -885,6 +902,8 @@ class WashdataAdapter extends utils.Adapter {
           );
           await mgr.profileStore.save();
           await mgr._saveState(); // Persist the cycle change
+          await this._updateNeedsFeedback(obj.message.deviceId, mgr);
+          await this._updateOverrideStates(obj.message.deviceId, mgr);
           respond({ ok: true });
           break;
         }
@@ -1392,6 +1411,16 @@ class WashdataAdapter extends utils.Adapter {
     );
   }
 
+  // ── 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.
+  async _updateNeedsFeedback(deviceId, mgr) {
+    const needsFeedback = mgr.getCycleHistory().some((c) => !c.confirmed);
+    this.setState(`${deviceId}.needsFeedback`, needsFeedback, true);
+  }
+
   // ── Callbacks ────────────────────────────────────────────────
   _onManagerState(deviceId, state, status) {
     const prevState = this._lastState && this._lastState[deviceId];
@@ -1592,6 +1621,15 @@ class WashdataAdapter extends utils.Adapter {
     // Reset the program override
     this.setState(`${deviceId}.programOverride`, "auto", true);
 
+    if (mgrPh) {
+      // A freshly finished cycle may be unconfirmed (needs feedback) and/or
+      // may have caused profileStore.learnFromCycle() to auto-learn a brand
+      // new program - both found live to otherwise only ever update from
+      // specific admin-tab actions, never automatically here.
+      await this._updateNeedsFeedback(deviceId, mgrPh);
+      await this._updateOverrideStates(deviceId, mgrPh);
+    }
+
     // Send notification
     await this._sendNotification(deviceId, cycle);
   }

package/package.json

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