iobroker.e3oncan 1.0.0 → 1.0.2

package/README.de.md

@@ -210,11 +210,11 @@ Die **e3oncan Datenpunkte**-Seite ist die zentrale Stelle zum Durchsuchen von Da
 
 Alle Geräte und erkannte Energiezähler werden als aufklappbare Karten angezeigt, standardmäßig zugeklappt für einen schnellen Überblick über das gesamte System. Ein Klick auf den Karten-Header klappt die Karte auf. Das Suchfeld filtert nach Name oder ID, passende Karten werden automatisch ausgeklappt.
 
-Wenn für ein Gerät noch kein Datenpunktscan durchgeführt wurde, erscheint oben auf der Seite ein Warnbanner als Erinnerung.
+Wenn für ein Gerät noch kein Datenpunktscan durchgeführt wurde, erscheint oben auf der Seite ein Warnbanner als Erinnerung. Wenn ein Scan vorhanden ist, die in v1.x eingeführte Collect-Auto-Erkennung aber noch nicht ausgeführt wurde, empfiehlt ein Info-Banner einen erneuten Scan. Dieser Hinweis kann per Instanz dauerhaft ausgeblendet werden (Schaltfläche **Nicht mehr anzeigen**).
 
 **Gerätekarten**
 
-Jede Gerätekarte listet ihre Datenpunkte mit ID, Name, Codec und Zeitplaneinstellungen auf. Der Collect-Schalter und die minimale Aktualisierungszeit erscheinen im Karten-Header. Wenn während des Datenpunktscans Collect-Traffic vom Gerät erkannt wurde, wird im Karten-Header ein grünes Pin-Symbol als Bestätigung angezeigt.
+Jede Gerätekarte listet ihre Datenpunkte mit ID, Name, Codec und Zeitplaneinstellungen auf. Der Collect-Schalter und die minimale Aktualisierungszeit erscheinen im Karten-Header. Wenn während des Datenpunktscans Collect-Traffic vom Gerät erkannt wurde, wird im Karten-Header ein grünes Pin-Symbol als Bestätigung angezeigt. Sind Datenpunkte eingeplant, erscheint ein grünes **N scheduled**-Badge — ein Klick darauf klappt die Karte auf und zeigt nur die eingeplanten Datenpunkte. Nochmaliger Klick auf das Badge hebt den Filter auf; ein Klick auf den Karten-Header hebt den Filter auf und klappt die Karte ein oder vollständig auf, je nachdem, ob das Badge sie geöffnet hatte.
 
 **Energiezähler-Karten**
 
@@ -376,51 +376,10 @@ Ja. Den State `e3oncan.0.<GERÄT>.cmnd.udsReadByDid` bearbeiten und eine Liste v
 Wenn Ihnen dieses Projekt gefällt — oder Sie einfach großzügig sind — würde ich mich über ein Bier freuen. Prost! :beers:
 
 ## Changelog
-<!--
-    Placeholder for the next version (at the beginning of the line):
-    ### **WORK IN PROGRESS**
--->
-### **WORK IN PROGRESS**
-* (MyHomeMyData) Behoben: Beim Speichern von Schedules in der Datenpunkte-Seite konnten unter bestimmten Umständen veraltete Einträge verbleiben
-* (MyHomeMyData) Topology-Schaltfläche in der Datenpunkte-Seite ergänzt; öffnet das Bus-Topologie-Diagramm in einem modalen Dialog
-* (MyHomeMyData) Scan-Status-Erkennung verbessert: nutzt `udsDidsWritable` statt `didsMetaDict`, um zuverlässig zu erkennen, ob ein Datenpunktscan durchgeführt wurde
-* (MyHomeMyData) Hinweis auf erneuten Scan in der Datenpunkte-Seite ergänzt, wenn ein Scan vorhanden, aber die Collect-Erkennung noch nicht durchgeführt wurde
-
-### 1.0.0-beta.1 (2026-04-30)
-* (MyHomeMyData) Bus-Topologie-Analyse wird jetzt automatisch nach dem Datenpunktscan erstellt; Ergebnisse werden in `info.topology` (JSON) und `info.topologyHtml` (HTML) gespeichert; Details im Readme
-* (MyHomeMyData) Eingabevalidierung für Intervall- und Verzögerungsfelder in der Datenpunkte-Seite ergänzt — nur positive ganze Zahlen werden akzeptiert
-
-### 1.0.0-beta.0 (2026-04-26)
-* (MyHomeMyData) Neue e3oncan Datenpunkte-Webseite, direkt in der Adapterinstanzzeile verankert
-* (MyHomeMyData) Energiezähler (E380, E3100CB) werden jetzt während des Gerätescans durch passives CAN-Lauschen auf beiden Kanälen automatisch erkannt
-* (MyHomeMyData) State-Namen für Energiezähler werden automatisch anhand von CAN-Adresse und Kanal vergeben; Details im Readme
-* (MyHomeMyData) Collect-Schalter und Verzögerung für Energiezähler werden ausschließlich in der e3oncan Datenpunkte-Seite konfiguriert; Änderungen werden nach Adapter-Neustart wirksam
-* (MyHomeMyData) Beim ersten Start nach einem Upgrade wird die Aktiv-Einstellung automatisch aus der bisherigen Adapterkonfiguration migriert
-* (MyHomeMyData) Collect-fähige Geräte werden jetzt während des Datenpunktscans durch passives CAN-Lauschen automatisch erkannt; ein Pin-Symbol wird im Gerätekarten-Header für jedes erkannte Gerät angezeigt
-* (MyHomeMyData) Option hinzugefügt, das Speichern von Datenpunktwerten während des Datenpunktscans zu unterdrücken
-
-### 0.11.1 (2026-04-23)
-* (MyHomeMyData) Robustheit verbessert: Ein Datenpunkt der Länge null wird als „negative response" behandelt
-* (MyHomeMyData) Metadaten werden jetzt auch nach dem Löschen eines Datenpunkts wiederhergestellt
-* (MyHomeMyData) Testfälle für deutsche Systemsprache angepasst
-
-### 0.11.0 (2026-04-14)
-* (MyHomeMyData) Für volle Unterstützung von Varianten-Datenpunkten und Metadaten bitte einen Gerätescan gefolgt von einem Datenpunktscan durchführen
-* (MyHomeMyData) Unterstützung für Varianten-Datenpunkte und Geräte-Datenformatkonfiguration hinzugefügt; Details unter https://github.com/MyHomeMyData/ioBroker.e3oncan/lib/data-points.md
-* (MyHomeMyData) Metadaten zu mehreren Datenpunkten hinzugefügt, z. B. Beschreibung, Einheit, Link zu weiteren Infos
-* (MyHomeMyData) Beim Datenpunktscan werden jetzt Metadaten zu den Datenpunkt-Objekten hinzugefügt
-* (MyHomeMyData) Handhabung schreibbarer Datenpunkte geändert; diese Information ist jetzt auch in der Datenpunktdefinition verfügbar; die Handhabung der Whitelist für Schreibzugriffe ist unverändert
-* (MyHomeMyData) Beim Gerätescan werden die verwendeten Datenformate (Datenpunkt 382) ausgewertet
-* (MyHomeMyData) Struktur vieler Datenpunkte aktualisiert; Details im [Changelog](lib/data-points.md#changelog-of-data-point-definitions)
-
-### 0.10.14 (2025-11-03)
-* (MyHomeMyData) Elemente zu enums.js basierend auf PR Nr. 182 von open3e hinzugefügt
-* (MyHomeMyData) Konfiguration der Dids-Scan-Grenzen im Quellcode vereinfacht
-* (MyHomeMyData) Scan bis Did 3338 erweitert
-* (MyHomeMyData) Hinweis zum Scanbereich im Readme ergänzt
-* (MyHomeMyData) Korrekturen für Issue #169 (Repository Checker)
-* (MyHomeMyData) Bugfix: Manuelle Änderung gerätespezifischer Dids wurde für Collect-Worker nicht ausgewertet
-* (MyHomeMyData) Liste der Datenpunkte für E3-Geräte auf Version 20251102 aktualisiert
+
+### Historie der Änderungen
+
+Die Changelog-Einträge sind in der englischen Verison der (README.MD)[README.MD#changelog] verfügbar.
 
 ### Ältere Versionen
 

package/README.md

@@ -229,11 +229,11 @@ The **e3oncan datapoints** page is the primary place for browsing data points an
 
 All devices and any detected energy meters are shown as expandable cards, starting collapsed so you get an overview of your whole system at a glance. Click a card header to expand it. The search box filters by name or ID, and matching cards are expanded automatically.
 
-If a data point scan has not been performed yet for a device, a warning banner is shown at the top of the page as a reminder.
+If a data point scan has not been performed yet for a device, a warning banner is shown at the top of the page as a reminder. If a scan has been done but the Collect auto-detection introduced in v1.x has not yet run, an info banner recommends running a new data point scan. This hint can be permanently dismissed per instance with the **Don't show again** button.
 
 **Device cards**
 
-Each device card lists its data points with ID, name, codec, and schedule settings. The Collect toggle and min. update time appear in the card header. If Collect traffic from the device was detected during the data point scan, a green pin icon is shown in the card header as a confirmation.
+Each device card lists its data points with ID, name, codec, and schedule settings. The Collect toggle and min. update time appear in the card header. If Collect traffic from the device was detected during the data point scan, a green pin icon is shown in the card header as a confirmation. If any data points are scheduled, a green **N scheduled** badge appears — click it to expand the card and show only the scheduled data points. Click the badge again to remove the filter; clicking the card header removes the filter and collapses or fully expands the card, depending on whether the badge had opened it.
 
 **Energy meter cards**
 
@@ -399,6 +399,13 @@ If you enjoyed this project — or just feeling generous, consider buying me a b
     Placeholder for the next version (at the beginning of the line):
     ### **WORK IN PROGRESS**
 -->
+### 1.0.2 (2026-05-17)
+* (MyHomeMyData) Improved error message when native module socketcan fails to load after a Node.js version upgrade — adapter now logs a clear hint to run `iob rebuild`
+
+### 1.0.1 (2026-05-11)
+* (MyHomeMyData) Clicking the green scheduled badge on a device card filters the view to show only its scheduled data points; clicking the badge again or the card header restores the full view
+* (MyHomeMyData) Fixed: saving from the datapoints tab now preserves inactive schedules (disabled in the old config UI) for full backward compatibility
+
 ### 1.0.0 (2026-05-06)
 * (MyHomeMyData) Adapter requires node.js >= 22 now
 * (MyHomeMyData) Improved scan status detection: uses `udsDidsWritable` instead of `didsMetaDict` to reliably detect whether a data point scan has been performed

package/admin/tab.html

@@ -125,6 +125,8 @@
         let sock = null;
         let loadedEnergyMeters = {};
         let topologyHtml = '';
+        let scheduledFilter = null;
+        let filterWasCollapsed = false;
 
         document.getElementById('btn-dismiss-rescan-hint').addEventListener('click', function() {
             localStorage.setItem('rescanHintDismissed_' + namespace, '1');
@@ -317,7 +319,7 @@
                     '<div class="dev-name-col"><strong>' + dev.devStateName + '</strong>' +
                     '<code class="ms-2 small">' + dev.devAddr + '</code>' +
                     '<span class="badge bg-secondary ms-2">' + dev.dids.length + ' DIDs</span>' +
-                    (activeCount > 0 ? '<span class="badge bg-success ms-1 scheduled-badge">' + activeCount + ' scheduled</span>' : '') +
+                    (activeCount > 0 ? '<span class="badge ' + (scheduledFilter === dev.devStateName ? 'bg-primary' : 'bg-success') + ' ms-1 scheduled-badge" style="cursor:pointer" onclick="event.stopPropagation();toggleScheduledFilter(\'' + dev.devStateName.replace(/\\/g, '\\\\').replace(/'/g, "\\'") + '\')">' + activeCount + ' scheduled</span>' : '') +
                     '</div>' +
                     collectHtml +
                     '</div>' +
@@ -338,7 +340,17 @@
                 const chevron = card.querySelector('.bi-chevron-down');
                 card.querySelector('.card-header').addEventListener('click', function(e) {
                     if (e.target.closest('.collect-area')) return;
-                    bootstrap.Collapse.getOrCreateInstance(collapseEl).toggle();
+                    if (scheduledFilter === dev.devStateName) {
+                        scheduledFilter = null;
+                        const badge = card.querySelector('.scheduled-badge');
+                        if (badge) { badge.classList.remove('bg-primary'); badge.classList.add('bg-success'); }
+                        if (!filterWasCollapsed) {
+                            bootstrap.Collapse.getOrCreateInstance(collapseEl).hide();
+                        }
+                        filterRows();
+                    } else {
+                        bootstrap.Collapse.getOrCreateInstance(collapseEl).toggle();
+                    }
                 });
                 chevron.style.transform = 'rotate(-90deg)';
                 collapseEl.addEventListener('hide.bs.collapse', function() { chevron.style.transform = 'rotate(-90deg)'; });
@@ -398,9 +410,13 @@
             const schedMode = document.querySelector('input[name="schedFilter"]:checked').value;
             const ivStr = document.getElementById('filter-interval-val').value.trim();
             const ivFilter = (schedMode === 'interval' && ivStr) ? parseInt(ivStr, 10) : null;
-            const hasActiveFilter = search || schedMode !== 'all';
+            const hasActiveFilter = search || schedMode !== 'all' || scheduledFilter;
 
             document.querySelectorAll('.ecu-group').forEach(function(group) {
+                if (scheduledFilter && group.dataset.devStateName !== scheduledFilter) {
+                    group.style.display = 'none';
+                    return;
+                }
                 let visibleCount = 0;
                 group.querySelectorAll('tbody tr').forEach(function(row) {
                     const textOk = !search ||
@@ -408,7 +424,11 @@
                         (row.dataset.name || '').includes(search) ||
                         (row.dataset.desc || '').includes(search);
                     let schedOk = true;
-                    if (schedMode === 'onstart') {
+                    if (scheduledFilter) {
+                        const onstart = row.querySelector('.onstart-check').checked;
+                        const iv = row.querySelector('.interval-input').value.trim();
+                        schedOk = onstart || iv !== '';
+                    } else if (schedMode === 'onstart') {
                         schedOk = row.querySelector('.onstart-check').checked;
                     } else if (schedMode === 'interval') {
                         const iv = row.querySelector('.interval-input').value.trim();
@@ -439,6 +459,34 @@
             });
         }
 
+        function toggleScheduledFilter(devStateName) {
+            let group = null;
+            document.querySelectorAll('.ecu-group').forEach(function(g) {
+                if (g.dataset.devStateName === devStateName) group = g;
+            });
+            const collapseEl = group ? group.querySelector('.collapse') : null;
+
+            if (scheduledFilter === devStateName) {
+                scheduledFilter = null;
+                if (filterWasCollapsed && collapseEl) {
+                    bootstrap.Collapse.getOrCreateInstance(collapseEl).hide();
+                }
+            } else {
+                filterWasCollapsed = collapseEl ? !collapseEl.classList.contains('show') : false;
+                scheduledFilter = devStateName;
+                if (collapseEl) bootstrap.Collapse.getOrCreateInstance(collapseEl).show();
+            }
+
+            document.querySelectorAll('.ecu-group').forEach(function(g) {
+                const badge = g.querySelector('.scheduled-badge');
+                if (!badge) return;
+                const isActive = scheduledFilter && g.dataset.devStateName === scheduledFilter;
+                badge.classList.toggle('bg-success', !isActive);
+                badge.classList.toggle('bg-primary', !!isActive);
+            });
+            filterRows();
+        }
+
         function markChanged() {
             hasChanges = true;
             document.getElementById('btn-save').disabled = false;
@@ -462,6 +510,8 @@
                 if (!badge) {
                     badge = document.createElement('span');
                     badge.className = 'badge bg-success ms-1 scheduled-badge';
+                    badge.style.cursor = 'pointer';
+                    badge.onclick = (function(name) { return function(e) { e.stopPropagation(); toggleScheduledFilter(name); }; })(card.dataset.devStateName);
                     nameCol.appendChild(badge);
                 }
                 badge.textContent = count + ' scheduled';
@@ -509,7 +559,10 @@
 
             const tabDevAddrs = new Set(allDevices.map(function(d) { return Number(d.devAddr); }));
             const newSchedules = (adapterNative.tableUdsSchedules || []).filter(function(s) {
-                return !tabDevAddrs.has(Number(s.udsSelectDevAddr));
+                // Keep schedules for devices not managed by this tab, and keep
+                // inactive schedules for tab devices (backward compatibility with
+                // the old config UI that allows disabling a schedule without deleting it).
+                return !tabDevAddrs.has(Number(s.udsSelectDevAddr)) || !s.udsScheduleActive;
             });
             const newCollectExt = JSON.parse(JSON.stringify(adapterNative.tableCollectCanExt || []));
             const newCollectInt = JSON.parse(JSON.stringify(adapterNative.tableCollectCanInt || []));

package/io-package.json

@@ -1,8 +1,34 @@
 {
   "common": {
     "name": "e3oncan",
-    "version": "1.0.0",
+    "version": "1.0.2",
     "news": {
+      "1.0.2": {
+        "en": "Improved error message when native module socketcan fails to load after a Node.js version upgrade — adapter now logs a clear hint to run `iob rebuild`",
+        "de": "Verbesserte Fehlermeldung, wenn das native Modul socketcan nach einem Node.js-Versions-Upgrade nicht geladen werden kann — Adapter protokolliert jetzt einen klaren Hinweis: `iob rebuild` ausführen",
+        "ru": "Улучшенное сообщение об ошибке, когда встроенный модуль socketcan не загружается после обновления версии Node.js — адаптер теперь регистрирует четкий намек на запуск «перестроения iob»",
+        "pt": "Mensagem de erro melhorada quando socketcan módulo nativo não consegue carregar após uma atualização de versão Node.js — adaptador agora registra uma dica clara para executar `iob reconstruction`",
+        "nl": "Verbeterde foutmelding wanneer native module socketcan niet kan worden geladen na een Node.js versie upgrade-adapter logt nu een duidelijke hint uit om te starten",
+        "fr": "Message d'erreur amélioré lorsque le module natif socketcan ne parvient pas à se charger après une mise à jour de la version Node.js — adaptateur enregistre maintenant un indice clair pour exécuter `iob rebuild`",
+        "it": "Messaggio di errore migliorato quando socket del modulo nativo può non caricare dopo un aggiornamento della versione Node.js — l'adattatore ora registra un chiaro suggerimento per eseguire `iob rebuild`",
+        "es": "Mensaje de error mejorado cuando el módulo nativo socketcan no se carga después de una actualización de la versión Node.js — el adaptador ahora registra una clara pista para ejecutar `iob reconstrucción`",
+        "pl": "Ulepszony komunikat błędu, gdy natywny moduł socketcan nie wczyta po aktualizacji wersji Node.js - adapter teraz loguje wyraźną wskazówkę do uruchomienia 'iob rebuild'",
+        "uk": "Удосконалено повідомлення про помилку, коли рідний модуль розетки може не навантажувати після оновлення версії Node.js — адаптер тепер записує чіткий підказок для запуску `iob rebuild`",
+        "zh-cn": "当本地模块套接字在节点.js版本升级后无法加载时改进错误信息——适配器现在登录一个运行“ iob 重建” 的明确提示"
+      },
+      "1.0.1": {
+        "en": "Clicking the green scheduled badge on a device card filters the view to show only its scheduled data points; clicking the badge again or the card header restores the full view\nFixed: saving from the datapoints tab now preserves inactive schedules (disabled in the old config UI) for full backward compatibility",
+        "de": "Ein Klick auf das grüne Badge auf einer Gerätekarte filtert die Ansicht für die aktivierten Datenpunkte; erneutes Klicken hebt den Filter wieder auf\nBehoben: Speichern von der Registerkarte Datenpunkte bewahrt nun inaktive Zeitpläne (in der alten config UI) für volle Rückwärtskompatibilität",
+        "ru": "Нажатие зеленого значка на карте устройства фильтрует вид, чтобы показать только его запланированные точки данных; нажатие снова на значок или заголовок карты восстанавливает полный вид\nИсправлено: сохранение со вкладки «Точки данных» теперь сохраняет неактивные графики (отключены в старом интерфейсе конфигурирования) для полной обратной совместимости",
+        "pt": "Clicar no crachá agendado verde num cartão de dispositivo filtra a vista para mostrar apenas os seus pontos de dados agendados; clicar novamente no crachá ou o cabeçalho do cartão restaura a visão completa\nCorrigido: salvar da aba pontos de dados agora preserva agendas inativas (desativadas na interface de configuração antiga) para compatibilidade com o backward completo",
+        "nl": "Klik op de groene geplande badge op een apparaatkaart filtert het uitzicht om alleen de geplande datapunten te tonen; opnieuw op de badge klikken of de kaartkop herstelt de volledige weergave\nFixed: opslaan vanaf het tabblad datapoints bewaart nu inactieve schema's (uitgeschakeld in de oude configuratie-UI) voor volledige compatibiliteit achterwaarts",
+        "fr": "Cliquer sur l'insigne programmé vert sur une carte de périphérique filtre la vue pour afficher seulement ses points de données programmés; cliquer de nouveau sur l'insigne ou l'en-tête de la carte restaure la vue complète\nCorrection : l'enregistrement depuis l'onglet datapoints préserve désormais les horaires inactifs (désactivés dans l'ancienne interface de configuration) pour une compatibilité arrière complète",
+        "it": "Fare clic sul badge verde programmato su una scheda di dispositivo filtra la vista per mostrare solo i suoi punti di dati programmati; fare clic sul badge di nuovo o l'intestazione della carta ripristina la vista completa\nRisolto: salvare dalla scheda datapoint ora conserva i programmi inattivi (disabilitati nella vecchia configurazione UI) per la piena compatibilità all'indietro",
+        "es": "Hacer clic en la placa verde programada en una tarjeta de dispositivo filtra la vista para mostrar sólo sus puntos de datos programados; hacer clic en la placa de nuevo o el encabezado de la tarjeta restaura la vista completa\nFijado: el ahorro de la ficha datapoints ahora preserva los horarios inactivos (desactivados en la antigua interfaz de usuario) para la compatibilidad atrasada completa",
+        "pl": "Kliknięcie zielonej planowej odznaki na karcie urządzenia filtruje widok, aby wyświetlić tylko swoje zaplanowane punkty danych; kliknięcie ponownie na odznakę lub nagłówek karty przywraca pełny widok\nNaprawiono: zapisywanie z zakładki datapoints teraz zachowuje nieaktywne harmonogramy (wyłączone w starym konfigu interfejsu) dla pełnej kompatybilności wstecznej",
+        "uk": "Натискання зеленої запланованої значки на картці пристрою фільтрує вигляд, щоб показати лише свої заплановані дані; натискання значка знову або заголовок картки відновлює повне подання\nВиправлено: збереження з вкладки даних тепер зберігає неактивні графіки (здатні у старій конфігурації UI) для повної сумісності з резервними сторонами",
+        "zh-cn": "在设备卡片上单击绿色的预定徽章过滤视图,只显示其预定的数据点;再次点击徽章或卡片头恢复全视图\n固定: 现在从数据点标签中保存不活动调度表( 在旧配置 UI 中已失效) , 完全向后兼容"
+      },
       "1.0.0": {
         "en": "Adapter requires node.js >= 22 now\nImproved scan status detection: uses `udsDidsWritable` instead of `didsMetaDict` to reliably detect whether a data point scan has been performed\nAdded re-scan recommendation hint in datapoints tab when a scan exists but Collect auto-detection has not yet been run",
         "de": "Adapter benötigt node.js >= 22\nVerbesserte Scan-Status-Erkennung: verwendet `udsDidsWritable` anstelle von `didsMetaDict`, um sicher zu erkennen, ob ein Datenpunkt-Scan durchgeführt wurde\nZusätzlicher re-scan Hinweis in Datenpunkte Tab, wenn ein Scan existiert, aber Collect Auto-Detektion noch nicht ausgeführt wurde",
@@ -67,32 +93,6 @@
         "pl": "Przypadkowo wymienione punkty danych 1415- 1418 zostały usunięte z changelog wersji 0.11.0",
         "uk": "У випадково зазначених пунктах даних 1415-1418 було вилучено з зміни версії 0.11.0",
         "zh-cn": "无意中提到的1415-1418数据点已经从0.110"
-      },
-      "0.11.2": {
-        "en": "Added \"What's new in v0.11.x\" section to Readme with upgrade notes for data point structure changes",
-        "de": "Hinzugefügt \"Was ist neu in v0.11.x\" Abschnitt zu Readme mit Upgrade-Notizen für Datenpunkt Strukturänderungen",
-        "ru": "Добавлен раздел «Что нового в v0.11.x» в Readme с примечаниями об обновлении для изменения структуры точек данных",
-        "pt": "Adicionado \"O que há de novo na seção v0.11.x\" para Readme com notas de atualização para mudanças na estrutura de pontos de dados",
-        "nl": "Toegevoegd \"Wat is nieuw in v0.11.x\" sectie aan Readme met upgrade notities voor gegevenspunt structuur wijzigingen",
-        "fr": "Ajout de la section « Quoi de neuf dans v0.11.x » à Readme avec des notes de mise à jour pour les changements de structure des points de données",
-        "it": "Aggiunto \"What's new in v0.11.x\" sezione a Readme con le note di aggiornamento per le modifiche della struttura del punto di dati",
-        "es": "Añadido \"Lo nuevo en v0.11.x\" sección a Readme con notas de actualización para cambios de estructura de puntos de datos",
-        "pl": "Dodano \"Co nowego w sekcji v0.11.x\" do Readme z notatkami aktualizacji zmian struktury punktów danych",
-        "uk": "Додано розділ \"Що нового в v0.11.x\" для читання з оновленнями нот для змін структури даних",
-        "zh-cn": "添加「 v0. 11. x. 中的新内容」 部分至 Readme, 并附有数据点结构变化的升级注释"
-      },
-      "0.11.1": {
-        "en": "Improved robustness: Receiving a data point of length zero is treated as a \"negative response\"\nThe metadata is now also restored after a data point is deleted \nAligned test cases for German system language",
-        "de": "Verbesserte Robustheit: Der Empfang eines Datenpunktes der Länge Null wird als \"negative Antwort\" behandelt\nDie Metadaten werden nun auch wiederhergestellt, nachdem ein Datenpunkt gelöscht wurde\nTestfälle für deutsche Systemsprache angepasst",
-        "ru": "Повышение надежности: получение нулевой точки данных рассматривается как «отрицательный ответ»\nМетаданные также восстанавливаются после удаления точки данных\nВыровненные тесты для немецкого системного языка",
-        "pt": "Maior robustez: Receber um ponto de dados de comprimento zero é tratado como uma \"resposta negativa\"\nOs metadados também são restaurados depois de um ponto de dados ser apagado\nCasos de teste alinhados para a língua do sistema alemão",
-        "nl": "Verbeterde robuustheid: Het ontvangen van een datapunt van lengte nul wordt behandeld als een \"negatieve respons\"\nDe metagegevens worden nu ook hersteld nadat een datapunt is verwijderd\nUitgelijnde testcases voor de Duitse systeemtaal",
-        "fr": "Amélioration de la robustesse : la réception d'un point de données de longueur zéro est traitée comme une \"réponse négative\"\nLes métadonnées sont maintenant également restaurées après la suppression d'un point de données\nCas d'essai alignés pour la langue du système allemand",
-        "it": "Maggiore robustezza: la ricezione di un data point di lunghezza zero viene trattata come una \"risposta negativa\"\nI metadati vengono ora ripristinati anche dopo la cancellazione di un data point\nCasi di prova allineati per la lingua del sistema tedesco",
-        "es": "Mayor robustez: Recibir un punto de datos de la longitud cero es tratado como una \"respuesta negativa\"\nLos metadatos ahora también se restauran después de que se elimina un punto de datos\nCasos de prueba de los Alineados para el lenguaje del sistema alemán",
-        "pl": "Lepsza odporność: Otrzymanie punktu danych o długości zero jest traktowane jako \"odpowiedź negatywna\"\nMetadane są teraz również przywrócone po usunięciu punktu danych\nDopasowanie przypadków testowych dla języka niemieckiego",
-        "uk": "Покращена надійність: Отримання точки даних довжини нульового обробляється як \"негативна відповідь\"\nМетадані також відновлюються після видалення даних\nВизначені тестові випадки для німецької мови системи",
-        "zh-cn": "增强强性:接收长度为0的数据点作为\"负反应\"处理\n在删除一个数据点后, 元数据现在也被恢复\n德语系统语言的对齐测试例"
       }
     },
     "titleLang": {

package/lib/protocols.md

@@ -1,165 +1,11 @@
 # Description of used protocols
 
-## Unsolicited sequences (mode "collect" of clients)
-
-Viessmann E3 devices broadcast data point values on the CAN bus unsolicited,
-whenever a value changes, without any prior request.
-The format is similar to the response of a UDS ReadDataByIdentifier service,
-but uses a different length encoding and does not require a flow-control
-handshake.
-
----
-
-### CAN-ID
-
-Each E3 device transmits on a fixed CAN-ID:
-
-| Device | CAN-ID |
-|---|---|
-| Vitocharge VX3 | `0x451` |
-| Vitocal 250 (internal bus and connected systems) | `0x693` |
-
----
-
-### Frame types
-
-Every CAN frame is exactly 8 bytes.
-
-**First Frame (FF)** — marks the start of a new data point transmission:
-
-```
-Byte 0:    0x21          (always, identifies the start of a sequence)
-Byte 1:    DID_LOW       (low byte of the Data Identifier)
-Byte 2:    DID_HIGH      (high byte of the Data Identifier)
-Byte 3:    length code   (see length encoding below)
-Byte 4+:   payload       (start position depends on length code)
-```
-
-**Continuation Frame (CF)** — carries the remaining payload bytes:
-
-```
-Byte 0:    sequence byte  (starts at 0x22, increments with each frame,
-                           wraps 0x2F → 0x20)
-Byte 1–7:  payload continuation
-```
-
-The last frame is padded to 8 bytes.
-
----
-
-### Length encoding
-
-The length code in byte 3 of the First Frame encodes both payload length and
-frame type:
-
-| Byte 3 (`v3`) | Byte 4 (`v4`) | Type | Payload length | Payload starts at |
-|---|---|---|---|---|
-| `0xB1`–`0xB4` | any | Single Frame | `v3 − 0xB0` (1–4 bytes) | Byte 4 |
-| `0xB5`–`0xBF` | any | Multi Frame | `v3 − 0xB0` (5–15 bytes) | Byte 4 |
-| `0xB0` | ≠ `0xC1` | Multi Frame | `v4` (16–255 bytes) | Byte 5 |
-| `0xB0` | `0xC1` | Multi Frame | Byte 5 (`v5`) | Byte 6 |
-
-The `0xC1` escape in the last row is used when the payload length value itself
-would equal `0xB5` or `0xC1`, to avoid ambiguity with those special byte
-values. In practice this has been observed for a payload length of `0xB5`
-(181 bytes).
-
----
-
-### Multi-frame sequence
-
-No flow control is required. The device sends all frames back-to-back:
-
-```
-Device                          Listener
-  |                               |
-  |── First Frame ───────────────>|
-  |── Continuation Frame 1 ──────>|
-  |── Continuation Frame 2 ──────>|
-  |           …                   |
-  |── Continuation Frame n ──────>|   ← last frame, padded to 8 bytes
-```
-
----
-
-### Complete examples
-
-**Single Frame** — DID `0x09BE`, payload length 4:
-
-```
-#        seq  DID       len  payload
-can0  693 [8]  21  BE 09  B4  95 0E 00 00
-```
-`v3 = 0xB4` → length = `0xB4 − 0xB0` = 4. Payload: `95 0E 00 00`.
-
----
-
-**Multi Frame** — DID `0x011A`, payload length 9:
-
-```
-#             seq  DID len payload ...
-can0  693 [8]  21 1A 01 B9 90 01 D4 00
-can0  693 [8]  22 E5 01 82 01 00 55 55
-```
-`v3 = 0xB9` → length = 9. Payload bytes 1–4 start at byte 4 of frame 1,
-bytes 5–9 follow in frame 2 (last 2 bytes are padding).
-
----
-
-**Multi Frame** — DID `0x0224`, payload length 24 (`0x18`):
-
-```
-#             seq  DID len v4 payload ...
-can0  693 [8]  21 24 02 B0 18 55 00 00
-can0  693 [8]  22 00 1A 03 00 00 5F 0A
-can0  693 [8]  23 00 00 38 0F 00 00 9B
-can0  693 [8]  24 32 00 00 57 5E 00 00
-```
-`v3 = 0xB0`, `v4 = 0x18` (≠ `0xC1`) → length = 24. Payload starts at byte 5
-of frame 1.
-
----
-
-**Multi Frame** — DID `0x0509`, payload length 181 (`0xB5`), using `0xC1` escape:
-
-```
-#             seq  DID len esc len2 payload ...
-can0  693 [8]  21 09 05 B0 C1  B5   00 00
-can0  693 [8]  22 00 00 00 00 00 00 00
-can0  693 [8]  23 00 00 00 00 00 00 00
-  ... (26 frames total) ...
-can0  693 [8]  2B 00 00 00 00 55 55 55
-```
-`v3 = 0xB0`, `v4 = 0xC1` (escape) → length = `v5 = 0xB5` = 181. Payload
-starts at byte 6 of frame 1. Last frame padded with `0x55`.
-
----
-
-### Receiver implementation checklist
-
-1. Listen on the device's CAN-ID for frames with byte 0 = `0x21` — this
-   marks the start of a new data point.
-2. Extract the DID from bytes 1–2: `DID = byte1 + 256 × byte2` (little-endian).
-3. Decode the length code in byte 3 using the table above to determine payload
-   length and start position.
-4. **Single Frame:** extract the payload directly and decode the data point.
-5. **Multi Frame:** record the expected next sequence byte (`0x22`), then
-   collect Continuation Frames until the full payload has been received.
-   - With each frame, verify byte 0 matches the expected sequence value.
-     If not, a frame was lost — discard the incomplete message.
-   - Increment the expected sequence byte after each frame; wrap `0x2F → 0x20`.
-6. Discard padding bytes beyond the declared payload length in the last frame.
-
----
-
 # UDS – ReadDataByIdentifier and WriteDataByIdentifier
 
 UDS (Unified Diagnostic Services, ISO 14229) is a diagnostic protocol used in
 automotive ECUs.  This document covers the two services relevant for reading
 and writing data points on Viessmann E3 devices.
 
-UDS is **not** used by E3onCAN but by open3e.
-
 ---
 
 ## Transport layer – ISO-TP (ISO 15765-2)
@@ -390,6 +236,503 @@ The wrap is at 15 → 0, not 15 → 1.
 **Timeout:** If no Flow Control arrives within ~1 s after a First Frame, abort
 the transmission.
 
+---
+## Unsolicited sequences (mode "collect" of clients)
+
+Viessmann E3 devices broadcast data point values on the CAN bus unsolicited,
+whenever a value changes, without any prior request.
+The format is similar to the response of a UDS ReadDataByIdentifier service,
+but uses a different length encoding and does not require a flow-control
+handshake.
+
+---
+
+### CAN-ID
+
+Each E3 device transmits on a fixed CAN-ID:
+
+| Device | CAN-ID |
+|---|---|
+| Vitocharge VX3 | `0x451` |
+| Vitocal 250 (internal bus and connected systems) | `0x693` |
+
+---
+
+### Frame types
+
+Every CAN frame is exactly 8 bytes.
+
+**First Frame (FF)** — marks the start of a new data point transmission:
+
+```
+Byte 0:    0x21          (always, identifies the start of a sequence)
+Byte 1:    DID_LOW       (low byte of the Data Identifier)
+Byte 2:    DID_HIGH      (high byte of the Data Identifier)
+Byte 3:    length code   (see length encoding below)
+Byte 4+:   payload       (start position depends on length code)
+```
+
+**Continuation Frame (CF)** — carries the remaining payload bytes:
+
+```
+Byte 0:    sequence byte  (starts at 0x22, increments with each frame,
+                           wraps 0x2F → 0x20)
+Byte 1–7:  payload continuation
+```
+
+The last frame is padded to 8 bytes.
+
+---
+
+### Length encoding
+
+The length code in byte 3 of the First Frame encodes both payload length and
+frame type:
+
+| Byte 3 (`v3`) | Byte 4 (`v4`) | Type | Payload length | Payload starts at |
+|---|---|---|---|---|
+| low nibble 1–4 | any | Single Frame | low nibble of `v3` (1–4 bytes) | Byte 4 |
+| low nibble 5–F | any | Multi Frame | low nibble of `v3` (5–15 bytes) | Byte 4 |
+| low nibble 0 | ≠ `0xC1` | Multi Frame | `v4` (16–255 bytes) | Byte 5 |
+| low nibble 0 | `0xC1` | Multi Frame | Byte 5 (`v5`) | Byte 6 |
+
+**Length encoding rule:** the payload length is always the **low nibble** of
+byte 3 (`v3 & 0x0F`). The high nibble is irrelevant for length purposes;
+byte 3 at this position is always a length code.
+Observed high-nibble values include `0x8` and `0xB`; both encode the same
+lengths (e.g. `0x82` and `0xB2` both mean 2 bytes).
+
+Low nibble = 0 signals a two-byte length field: the actual length is in
+byte 4 (`v4`), except when `v4 = 0xC1`, which is an escape byte — the true
+length is then in byte 5 (`v5`). The `0xC1` escape avoids ambiguity when the
+payload length value itself would equal `0xB5` or `0xC1`. In practice this
+has been observed for a payload length of `0xB5` (181 bytes).
+
+---
+
+### Multi-frame sequence
+
+No flow control is required. The device sends all frames back-to-back:
+
+```
+Device                          Listener
+  |                               |
+  |── First Frame ───────────────>|
+  |── Continuation Frame 1 ──────>|
+  |── Continuation Frame 2 ──────>|
+  |           …                   |
+  |── Continuation Frame n ──────>|   ← last frame, padded to 8 bytes
+```
+
+---
+
+### Complete examples
+
+**Single Frame** — DID `0x09BE`, payload length 4:
+
+```
+#        seq  DID       len  payload
+can0  693 [8]  21  BE 09  B4  95 0E 00 00
+```
+`v3 = 0xB4` → low nibble = 4 → length = 4. Payload: `95 0E 00 00`.
+
+---
+
+**Multi Frame** — DID `0x011A`, payload length 9:
+
+```
+#             seq  DID len payload ...
+can0  693 [8]  21 1A 01 B9 90 01 D4 00
+can0  693 [8]  22 E5 01 82 01 00 55 55
+```
+`v3 = 0xB9` → low nibble = 9 → length = 9. Payload bytes 1–4 start at byte 4
+of frame 1, bytes 5–9 follow in frame 2 (last 2 bytes are padding).
+
+---
+
+**Multi Frame** — DID `0x0224`, payload length 24 (`0x18`):
+
+```
+#             seq  DID len v4 payload ...
+can0  693 [8]  21 24 02 B0 18 55 00 00
+can0  693 [8]  22 00 1A 03 00 00 5F 0A
+can0  693 [8]  23 00 00 38 0F 00 00 9B
+can0  693 [8]  24 32 00 00 57 5E 00 00
+```
+`v3 = 0xB0`, `v4 = 0x18` (≠ `0xC1`) → length = 24. Payload starts at byte 5
+of frame 1.
+
+---
+
+**Multi Frame** — DID `0x0509`, payload length 181 (`0xB5`), using `0xC1` escape:
+
+```
+#             seq  DID len esc len2 payload ...
+can0  693 [8]  21 09 05 B0 C1  B5   00 00
+can0  693 [8]  22 00 00 00 00 00 00 00
+can0  693 [8]  23 00 00 00 00 00 00 00
+  ... (26 frames total) ...
+can0  693 [8]  2B 00 00 00 00 55 55 55
+```
+`v3 = 0xB0`, `v4 = 0xC1` (escape) → length = `v5 = 0xB5` = 181. Payload
+starts at byte 6 of frame 1. Last frame padded with `0x55`.
+
+---
+
+### Receiver implementation checklist
+
+1. Listen on the device's CAN-ID for frames with byte 0 = `0x21` — this
+   marks the start of a new data point.
+2. Extract the DID from bytes 1–2: `DID = byte1 + 256 × byte2` (little-endian).
+3. Decode the length code in byte 3 using the table above to determine payload
+   length and start position.
+4. **Single Frame:** extract the payload directly and decode the data point.
+5. **Multi Frame:** record the expected next sequence byte (`0x22`), then
+   collect Continuation Frames until the full payload has been received.
+   - With each frame, verify byte 0 matches the expected sequence value.
+     If not, a frame was lost — discard the incomplete message.
+   - Increment the expected sequence byte after each frame; wrap `0x2F → 0x20`.
+6. Discard padding bytes beyond the declared payload length in the last frame.
+
+---
+
+## Service 77 (proprietary write protocol)
+
+### Background
+
+Service 77 is a Viessmann-proprietary write protocol discovered via reverse engineering. It operates in parallel with UDS on a dedicated CAN-ID pair and allows writing of data points that are protected against normal `WriteDataByIdentifier` (UDS service 0x2E).
+
+Viessmann uses this mechanism to protect certain data points from accidental or unauthorised modification. When a client receives NRC `0x22` (conditionsNotCorrect) in response to a normal UDS write, it can retry the same write using Service 77 on the dedicated CAN-ID.
+
+Both protocols share the same data store: a value written via Service 77 is immediately readable via UDS `ReadDataByIdentifier`.
+
+### CAN-ID mapping
+
+The Service 77 CAN-IDs are derived from the device's UDS address:
+
+| | CAN-ID |
+|---|---|
+| Service 77 request  | `device_tx + 0x02`  (e.g. `0x682` for main device at `0x680`) |
+| Service 77 response | `device_tx + 0x12`  (= request + `0x10`) |
+
+### Transport layer
+
+Service 77 uses the same ISO 15765-2 (ISO-TP) framing as UDS. The reassembled payload is described below.
+
+### Request frame format
+
+After ISO-TP reassembly the payload has this structure:
+
+```
+Byte 0:     0x77
+Bytes 1–2:  [CTR_L] [CTR_H]
+Bytes 3–5:  0x43 0x01 0x82
+Bytes 6–7:  [DID_L] [DID_H]
+Byte  8:    0xB0 + n
+Bytes 9+:   [DATA ...]
+```
+
+| Field | Bytes | Description |
+|---|---|---|
+| Service ID | 1 | Always `0x77` |
+| Session counter | 2 | 16-bit little-endian counter; monotonically increasing across all writes in a session (~0.35 increments/s), wraps at 0xFFFF |
+| Client ID | 3 | Fixed bytes `43 01 82`; constant across all observed frames |
+| DID | 2 | Data identifier, **little-endian** (low byte first) |
+| Length code | 1 | Present only when the high nibble is ≥ `0x8` (observed: `0x8x` and `0xBx`). Low nibble = data length in bytes (e.g. `0x82` and `0xB2` both mean 2 bytes). Low nibble 0 means the next byte carries the length (≥ 16 bytes). **If the byte at this position has high nibble < `0x8`, it is not a length code — the remaining payload bytes including that byte are raw data** (observed for small data points, e.g. a 1-byte value of `0x2B`). |
+| Data | n | New value for the data point, little-endian |
+
+### Response frame format
+
+Positive response:
+
+```
+[0x77] [CTR_L] [CTR_H] [0x44]
+```
+
+| Field | Bytes | Description |
+|---|---|---|
+| Service ID | 1 | Always `0x77` |
+| Session counter | 2 | 16-bit LE counter **echoed from the request** (not the DID) |
+| Confirmation byte | 1 | Always `0x44` (Viessmann-specific, no UDS equivalent) |
+
+Negative response (reuses UDS encoding):
+
+```
+[0x7F] [0x77] [NRC]
+```
+
+| NRC | Meaning |
+|---|---|
+| `0x12` | Payload too short (subFunctionNotSupported) |
+| `0x31` | DID not present in data store (requestOutOfRange) |
+
+### Interaction with UDS WriteDataByIdentifier
+
+The `service77` key in `devices.json` specifies a list of DIDs that are protected against normal UDS writes:
+
+* A `WriteDataByIdentifier` (0x2E) request targeting a protected DID returns NRC `0x22` (conditionsNotCorrect) without modifying the data store.
+* A Service 77 request targeting the same DID is accepted and the value is written normally.
+* Service 77 accepts writes to **all** known DIDs, including unprotected ones.
+
+### Example exchange
+
+Write DID `0x044C` (decimal 1100) with 2-byte value `0x012C` on the main device (`tx = 0x680`).
+Session counter at this point: `0x0042`.
+
+The reassembled UDS payload is 11 bytes, so ISO-TP multi-frame is used:
+
+```
+# Client request on 0x682 (= 0x680 + 0x02):
+#                   ISO-TP FF (len=11)
+682  [8]  10 0B  77  42 00  43 01 82
+#                ↑   ↑───↑  ↑──────↑
+#                SID CTR   Client ID
+
+#                   ISO-TP CF1
+682  [8]  21  4C 04  B2  2C 01  CC CC
+#             ↑────↑ ↑   ↑────↑
+#             DID LE len  data LE
+
+# Device sends Flow Control first (standard ISO-TP):
+692  [8]  30 00 00 00 00 00 00 00
+
+# Server response on 0x692 (= 0x682 + 0x10):
+692  [8]  04  77  42 00  44  CC CC CC
+#             ↑   ↑────↑  ↑
+#             SID CTR     confirm=0x44
+```
+
+Notes:
+- DID `0x044C` is transmitted as `4C 04` (LE), not `04 4C` (BE).
+- The response echoes the session counter `42 00`, not the DID.
+- `0xB2` indicates 2 data bytes (low nibble = 2). `0x82` is equally valid and observed on real hardware.
+
+### Service 77 read
+
+In addition to writes, a **read** variant has been observed on the Vitocharge
+VX3 external CAN bus. The client requests the current value of a specific DID;
+the device responds with the full data payload. The framing is standard ISO-TP
+with Flow Control, identical to a write exchange.
+
+#### Read request
+
+After ISO-TP reassembly (always 8 bytes):
+
+```
+Byte 0:    0x77
+Bytes 1–2: [CTR_L] [CTR_H]
+Bytes 3–5: 0x41 0x01 0x82   (read-request marker)
+Bytes 6–7: [DID_L] [DID_H]
+```
+
+No length code and no data follow — the request carries only the DID.
+
+#### Read response
+
+After ISO-TP reassembly:
+
+```
+Byte 0:    0x77
+Bytes 1–2: [CTR_L] [CTR_H]   (echoed from request)
+Bytes 3–5: 0x42 0x01 0x82   (read-response marker)
+Bytes 6–7: [DID_L] [DID_H]  (echoed from request)
+Byte  8:   length code       (same encoding as write request, see above)
+Bytes 9+:  data
+```
+
+#### Example
+
+Read DID `0x0509` (1289) from Vitocharge VX3 (`tx = 0x43F`, request channel
+`0x441`, response channel `0x451`). The value is 181 bytes (0xB5), requiring
+the `0xC1` length-code escape. CTR = `0x3634`.
+
+```
+# Client read request on 0x441 — ISO-TP total = 8 bytes
+441  [8]  10 08  77  34 36  41 01 82
+451  [8]  30 00 05 00 00 00 00 00       ← Flow Control from device
+441  [8]  21  09 05  00 00 00 00 00
+#         ↑─────↑
+#         DID = 0x0509 LE
+
+# Device read response on 0x451 — ISO-TP total = 192 bytes
+451  [8]  10 C0  77  34 36  42 01 82
+441  [8]  30 00 05 00 00 00 00 00       ← Flow Control from client
+451  [8]  21  09 05  B0 C1 B5  00 00
+#         ↑─────↑  ↑────────↑
+#         DID echo  len=181 (0xC1 escape)
+451  [8]  22 ... (26 frames total, SN wraps 0x2F → 0x20, padded with 0x55)
+```
+
+---
+
+### Device-initiated Service 77 (CTR = 0x0000)
+
+The device can initiate Service 77 frames toward the client, always with
+session counter `0x0000`. Two distinct patterns have been observed:
+
+**Pattern A — Cross-device synchronization (echo)**
+
+When a client writes a value, the device immediately propagates that write to
+all other known devices using the same CAN-ID offset. The payload (DID + data)
+is identical to the client's write; only the counter is reset to zero.
+Confirmed across multiple traces and DIDs (e.g. `0x01F8`, `0x044D`).
+
+Example: client `0x682` writes DID `0x01F8`. Immediately after confirming,
+device `0x692` pushes the same DID/data back to `0x682`, and simultaneously
+`0x693` pushes the identical frame to `0x683`:
+
+```
+# Client write
+682  10 17 77 0D 00 43 01 82   ← FF, CTR=0x000D
+...
+692  04 77 0D 00 44 55 55 55   ← confirm, CTR=0x000D ✓
+
+# Immediate cross-device sync (CTR=0x0000 in both)
+692  10 17 77 00 00 43 01 82   ← device pushes same DID back to 682
+693  10 17 77 00 00 43 01 82   ← sibling device pushes to 683 simultaneously
+```
+
+**Pattern B — Related-value notification**
+
+After processing a write, the device pushes back a set of related DIDs whose
+values were affected by (or are logically associated with) the write. These
+pushed DIDs are different from the written DID.
+
+Example: client `0x441` writes DID `0x08B2` (2226). Before sending the
+confirmation, device `0x451` pushes back four related DIDs:
+
+| Pushed DID | Decimal | Data bytes |
+|---|---|---|
+| `0x0643` | 1603 | 4 |
+| `0x069A` | 1690 | 17 |
+| `0x0720` | 1824 | 16 |
+| `0x072C` | 1836 | 4 |
+
+The confirmation (`0x44`) for the original write arrives *after* all the
+device-initiated pushes have been sent. This pattern is reproducible: the same
+four DIDs are pushed on every write cycle to DID `0x08B2`, with data values
+that reflect the current device state at the time of the push.
+
+For large pushed payloads the ISO-TP sequence number wraps normally
+(`0x2F → 0x20`). Payloads up to 123 bytes (19 CFs) have been observed for
+device-initiated pushes on some DID/channel combinations.
+
+**Short pushes (1-byte data, no length code prefix):** For data points with a
+1-byte value whose byte representation has high nibble < `0x8`, the reassembled
+S77 payload is exactly 9 bytes (8-byte header + 1 data byte) and the data byte
+sits at position 8 without a preceding length code. Example:
+
+```
+# ISO-TP FF (total = 9 bytes)
+692  [8]  10 09  77 00 00 43 01 82
+# ISO-TP CF1 (need 3 more bytes: EF 06 2B)
+692  [8]  21  EF 06  2B  55 55 55 55
+#              ↑────↑  ↑
+#              DID LE  data = 0x2B (43 decimal)
+```
+
+Reassembled: `77 00 00 43 01 82 EF 06 2B` — DID `0x06EF`, 1-byte value `0x2B`.
+There is no length code byte; `0x2B` (high nibble `2` < `0x8`) is the value itself.
+
+**Summary: how to identify device-initiated frames**
+
+| Field | Client write | Device push |
+|---|---|---|
+| CTR | Running counter (≠ 0) | Always `0x0000` |
+| Direction | REQUEST_CH → RESPONSE_CH | RESPONSE_CH → REQUEST_CH |
+| DID | What the client wants to write | Echo of client's DID (Pattern A) or related DID (Pattern B) |
+
+### Anomaly: 4-byte Service 77 frames
+
+On multiple CAN-ID pairs, 4-byte Service 77 frames have been observed that
+are too short to carry a DID or data:
+
+```
+681  04 77 C9 11 21 00 00 00   ← client-side (00 padding)
+691  04 77 C9 11 22 55 55 55   ← device-side (55 padding), ~3 ms later
+
+682  04 77 41 75 21 55 55 55   ← client-side (55 padding)
+692  04 77 41 75 22 55 55 55   ← device-side (55 padding), 1 ms later
+
+683  04 77 D4 11 21 00 00 00   ← client-side (00 padding)
+693  04 77 D4 11 22 55 55 55   ← device-side (55 padding), 14 ms later
+
+686  04 77 08 6F 21 CC CC CC   ← client-side (CC padding)
+696  04 77 08 6F 22 55 55 55   ← device-side (55 padding), 1 ms later
+```
+
+Payload: `[0x77] [CTR_L] [CTR_H] [0x21]` (client) / `[0x77] [CTR_L] [CTR_H] [0x22]` (device)
+
+Observations:
+
+- `0x21` / `0x22` are consistent across all four channel pairs.
+- The CTR in each pair is always the global session counter incremented by
+  exactly 1 after the preceding write on that same channel (e.g. CTR=0x7540
+  for a write, CTR=0x7541 for the 4-byte frame immediately after).
+- The CAN padding byte on the **client** side is inconsistent: `0x00` on
+  channels 681 and 683, `0x55` on 682, `0xCC` on 686. The device side always
+  pads with `0x55`. This suggests the frames originate from different software
+  components or firmware generations.
+- These frames appear between write batches on all active channels, not only
+  after specific writes.
+
+**Hypothesis:** byte 3 = `0x21` / `0x22` is a session-level keepalive or
+commit signal, sent by the client after each write (or write batch) to confirm
+that no further writes are pending in this slot, with the device acknowledging.
+The CTR+1 spacing supports this: the client "spends" one CTR value on the
+keepalive before moving to the next write cycle.
+
+### CAN-ID sharing and protocol disambiguation
+
+CAN-IDs `0x451` (Vitocharge VX3) and `0x693` (Vitocal 250) are shared between
+the Collect protocol and the Service 77 response channel. Both protocols produce
+frames with sequence byte `0x21` as byte 0, making raw inspection ambiguous.
+
+**Disambiguation rule (ISO-TP state tracking):**
+
+A frame with byte 0 = `0x21` on `0x451` or `0x693` is:
+
+- **Service 77 CF1** — if a First Frame (`0x1x`) from the same CAN-ID has
+  been seen without a matching `0x21` CF1 consuming it yet.
+- **Collect start frame (FF)** — if no ISO-TP FF is currently open for that
+  CAN-ID.
+
+An implementation must maintain one boolean flag per CAN-ID: "FF open".
+Set it on `0x1x`; clear it on `0x21` (CF1 consumed) or `0x2x` for x > 1.
+
+**Operational modes:**
+
+In practice the two protocols appear to be functionally exclusive by mode:
+
+| Mode | Dominant protocol |
+|---|---|
+| Normal operation (passive/read-only) | Collect autonomous broadcasts |
+| Active service session (writes in progress) | Service 77 device-initiated pushes |
+
+Both distribute the same underlying data-point values. Service 77 device pushes
+are addressed to specific client channels (with ISO-TP ACK); Collect broadcasts
+are unaddressed and require no flow control. A receiver handling both protocols
+on the same CAN-ID will typically observe one or the other depending on whether
+a write session is active on the bus.
+
+---
+
+### Service 77 opcode summary
+
+All Service 77 frames start with SID `0x77`. The byte or bytes immediately
+following the session counter (bytes 3–5 of the reassembled payload) identify
+the frame type:
+
+| Bytes 3–5 | Total payload | Direction | Meaning |
+|---|---|---|---|
+| `43 01 82` | ≥ 10 bytes | Client → Device | **Write request** (data follows) |
+| `0x44` (byte 3 only) | 4 bytes | Device → Client | **Write confirmation** (echoes CTR) |
+| `43 01 82`, CTR = `0x0000` | ≥ 10 bytes | Device → Client | **Push / sync** (device-initiated) |
+| `0x21` (byte 3 only) | 4 bytes | Client → Device | **Session keepalive** request |
+| `0x22` (byte 3 only) | 4 bytes | Device → Client | **Session keepalive** response |
+| `41 01 82` | 8 bytes | Client → Device | **Read request** (DID only, no data) |
+| `42 01 82` | ≥ 10 bytes | Device → Client | **Read response** (echoes CTR + DID, data follows) |
+
 ---
 
 # Energy Meters – E380 CA and E3100CB
@@ -546,3 +889,33 @@ can0  569   [8]  XX XX XX  04  D0 07  00 00
 ```
 
 Decoded (signed Int16, scale 1): `0x07D0` = 2000 W.
+
+---
+
+# External CAN bus — observed CAN-IDs
+
+The external CAN bus connects the Vitocal 250 indoor unit to the Vitocharge VX3
+and the E380 energy meter. The table below summarises all CAN-IDs observed in a
+one-minute passive capture; it serves as a reference for tools that need to
+filter or ignore non-Viessmann traffic.
+
+| CAN-ID(s) | Protocol | Meaning |
+|---|---|---|
+| `0x441` ↔ `0x451` | Service 77 | S77 request/response for Vitocharge VX3 (`tx = 0x43F`); also carries Collect broadcasts from VX3 on `0x451` |
+| `0x250`–`0x25D` | E380 CA | Energy meter broadcasts (see E380 section above) |
+| `0x761`, `0x747`, `0x701` | CANopen Heartbeat | Node 97 (E380 CA), Node 71 (VX3), Node 1 |
+| `0x271` | CANopen NMT/PDO | Node 0x71 (VX3) |
+| `0x647` ↔ `0x5C7` | CANopen SDO | Client/Server, Node 71 (VX3) |
+| `0x661` ↔ `0x5E1` | CANopen SDO | Client/Server, Node 97 (E380) |
+| `0x6A1` ↔ `0x6B1` | UDS ReadDataByIdentifier | Periodic read of DID `0x2707` approximately every 15 s |
+| `0x541` ↔ `0x531` | Proprietary (SDO-like) | Unknown device; exact protocol not identified |
+| `0x1FF`, `0x190` | Periodic counter | Incrementing timestamp/counter frames |
+
+**Notes:**
+
+- Only `0x441`/`0x451` carries Service 77 traffic on the external bus. No
+  additional S77 pairs were found.
+- S77-READ transactions (Client-ID `41 01 82`) have been observed on `0x441`
+  reading DID `0x0509` (181 bytes, `0xC1` escape) approximately every 5 s.
+- CANopen node IDs follow the standard formula: heartbeat CAN-ID = `0x700 +
+  node`, SDO client = `0x600 + node`, SDO server = `0x580 + node`.

package/main.js

@@ -16,7 +16,13 @@
 const utils = require('@iobroker/adapter-core');
 
 // Loading modules:
-const can = require('socketcan');
+let can = null;
+let canLoadError = null;
+try {
+    can = require('socketcan');
+} catch (e) {
+    canLoadError = e;
+}
 const storage = require('./lib/storage');
 const E3DidsDict = require('./lib/didsE3.json');
 const E3DidsVarDict = require('./lib/didsE3var.json');
@@ -100,6 +106,23 @@ class E3oncan extends utils.Adapter {
     async onReady() {
         // Initialize your adapter here
 
+        if (!can) {
+            if (
+                canLoadError &&
+                /compiled against a different Node\.js version|did not self-register/i.test(canLoadError.message)
+            ) {
+                this.log.error('Native module socketcan was compiled for a different Node.js version.');
+                this.log.error(
+                    'Fix: stop the adapter, run  iob rebuild  on the command line, then restart the adapter.',
+                );
+            } else {
+                this.log.error(
+                    `Failed to load native module socketcan: ${canLoadError ? canLoadError.message : 'unknown error'}`,
+                );
+            }
+            return;
+        }
+
         await this.log.info(`Startup of instance ${this.namespace}: Starting.`);
         //await this.log.debug('this.config:');
         //await this.log.debug(JSON.stringify(this.config));

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "iobroker.e3oncan",
-  "version": "1.0.0",
+  "version": "1.0.2",
   "description": "Collect data on CAN bus for Viessmann E3 devices, e.g. Vitocal, Vitocharge, Energy Meters E380CA and E3100CB",
   "author": {
     "name": "Juergen",