@knopers1 Was heißt nicht rückgängig? Wenn du vis2 installierst versucht es einmalig deine vis1 views zu importieren. Ich schreibe extra versucht, da es meistens nicht richtig gut funktioniert. Einige Widgets lassen sich nicht importieren. Die ganzen Standard Widgets sollten aber funktionieren. Daher mein Rat: lösch die ganzen views wieder in vis2 und baue es Stück für Stück von Grund auf neu Ab dem Zeitpunkt gibt es keinerlei Austausch mehr zwischen vis1 und vis2 Du kannst beides separat aufrufen und bedienen. Änderungen in vis1 werden danach nicht mehr nach Vis2 gespiegelt und umgekehrt. Du hast alle Möglichkeiten Wenn vis1 keine Lizenz mehr benötigt, ist diese überflüssig. Also kannst du bedenkenlos konvertieren.

Erledigt, danke für den Hinweis!

@jan_xx Seit es den e3oncan Adapter gibt, gehören diese Probleme bei mir der Vergangenheit an. Ich war diese ständigen Störungen, Ausfälle, .. seitens Viessmann leid und bin auf diesen Adapter umgestiegen. Wenn du ein E3-System besitzt, solltest du über einen Umstieg nachdenken. Es lohnt sich. [image: 1780379700386-f7648be4-1a2c-4b5a-8384-3d99e45ccd7e-image.jpeg]

@Kanumouse ich kann da leider nicht weiter helfen da ich kein Fritz Box habe.

@da_Woody sagte: Multiple Scripts würden die Daten nur mehrfach zum Adapter senden. Das sollte aber - nach meiner Kenntnis - nicht schaden. genau da bin ich nicht sicher, ob der adapter da nicht ins schleudern kommt... Das ist kein Problem. Die ID der Nachricht ist ja dann identisch und es wird aufgelistet, welche Geräte die Nachricht alle empfangen haben. Siehe https://youtu.be/FubPHOsktbU?si=-45ISXV1Y3phF02e&t=449

@Thomas-Braun Mit dem Modul selbst bauen bin ich überfordert, da werde ich wohl vorläufige mit dem image8 leben müssen.

Dimstal hab ich auch hier mit dem esp32 Dongle.. bin zufrieden.

@JB_Sullivan sagte: Nachdem ich nun aus diesem View einen "ganzen Arsch voll" Geister Widgets gelöscht habe, ist auch die Reaktionszeit der Visualisierung gefühlt deutlich schneller geworden. dann erzähl .. wie das Magic funktioniert

Was haltet ihr von dem als neue Hardware https://www.ram-koenig.de/dell-optiplex-3000-tc-d15u-intel-n6005-16ddr4-256nvme-wifi-psu/10191

@Homoran Bin gerade unterwegs. Sobald ich wieder zuhause bin, melde ich mich.

@mcm1957 Keine Ahnung ob ich auf GIT den Adapter mal irgendwann beobachtet habe, denn vom Programmieren an dem Adapter selber habe ich keine Ahnung. Heute Morgen kamen erst wieder drei neue Meldungen von dem BOT. Spoiler German description can be found below | Deutsche Beschreibung weiter unten General information This PR has been created by iobroker-bot. Please review the changes carefully and merge the PR if review is ok. Feel free to contact me (@ioBroker-Bot) if you have any questions or feel that a PR is faulty. Please open an issue at repository https://github.com/ioBroker/ioBroker.repochecker to report a faulty PR. And THANKS A LOT for maintaining this adapter from me and all users. Let's work together for the best user experience. your ioBroker Check and Service Bot @mcm1957 for evidence Changes provided by this PR This PR resolves warning W8917 logged by the ioBroker repository checker. What this PR does This PR adds an ignore rule to the Dependabot configuration in .github/dependabot.yml to prevent Dependabot from automatically proposing major version bumps for the @types/node package. The following change is applied to every updates: block that specifies package-ecosystem: npm and directory: / or directories: ['**/*']: ignore: dependency-name: "@types/node" update-types: "version-update:semver-major" Why this change is needed The @types/node package provides TypeScript type definitions for the Node.js runtime API. The major version of @types/node that an adapter should use is determined by the lowest major Node.js version the adapter supports. The lowest supported Node.js version is specified in the engines.node field of package.json. Allowing Dependabot to automatically bump @types/node to a newer major version would introduce type definitions for Node.js APIs that are not available in the minimum supported Node.js version. This can lead to incorrect type checking and potential runtime errors on older Node.js installations. Therefore, major version updates of @types/node must always be reviewed manually and aligned with any intentional change to the minimum supported Node.js version. Reference ioBroker Repository Checker – Warning W8917 Dependabot ignore configuration Deutsche Beschreibung Dieser PR behebt die Warnung W8917, die vom ioBroker-Repository-Checker gemeldet wird. Was dieser PR macht Dieser PR fügt der Dependabot-Konfiguration in .github/dependabot.yml eine Ignore-Regel hinzu, die verhindert, dass Dependabot automatisch Major-Version-Bumps für das Paket @types/node vorschlägt. Die folgende Änderung wird auf jeden updates:-Block angewendet, der package-ecosystem: npm und directory: / oder directories: ['**/*'] enthält: ignore: dependency-name: "@types/node" update-types: "version-update:semver-major" Warum diese Änderung notwendig ist Das Paket @types/node stellt TypeScript-Typdefinitionen für die Node.js-Laufzeit-API bereit. Die Major-Version von @types/node, die ein Adapter verwenden sollte, wird durch die niedrigste unterstützte Node.js-Hauptversion des Adapters bestimmt. Die niedrigste unterstützte Node.js-Version wird im Feld engines.node in package.json angegeben. Würde Dependabot @types/node automatisch auf eine neuere Major-Version aktualisieren, würden Typdefinitionen für Node.js-APIs eingeführt, die in der minimal unterstützten Node.js-Version nicht verfügbar sind. Dies kann zu fehlerhafter Typprüfung und potenziellen Laufzeitfehlern auf älteren Node.js-Installationen führen. Daher müssen Major-Version-Updates von @types/node immer manuell geprüft und mit einer bewussten Änderung der minimal unterstützten Node.js-Version abgestimmt werden. Referenzen ioBroker Repository Checker – Warnung W8917 Dependabot Ignore-Konfiguration You my recreate this PR by adding the following comment: @ioBroker-Bot recreate Template: W8917-dependabot-addIgnoreTypesNode You can view, comment on, or merge this pull request online at: https://github.com/PArns/ioBroker.innogy-smarthome/pull/150 Commit Summary 77ced0b Update from template: W8917-dependabot-addIgnoreTypesNode File Changes (1 file) M .github/dependabot.yml (36) Patch Links: https://github.com/PArns/ioBroker.innogy-smarthome/pull/150.patch https://github.com/PArns/ioBroker.innogy-smarthome/pull/150.diff — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you are subscribed to this thread.Message ID: PArns/ioBroker.innogy-smarthome/pull/150@github.com Es wäre auf jeden Fall toll, wenn der Adapter in den Community Bereich verschoben werden könnte, das ggf. notwendige System Anpassungen den Adapter am Leben halten. Nicht das eines Tages wegen neuer Nodes Versionen der Adapter stirbt. Änderungen am Adapter selber oder neue Funktionen wird es nicht geben, denn wie ich oben schon geschrieben hatte, gibt es die Firma LIVISI nicht mehr. Man muss es den ehemaligen Mitarbeitern von LIVISI aber hoch anrechnen, das sie das Smarthome System so umgeschrieben haben, das es so lange LOKAL weiter laufen kann, solange die Hardware funktioniert und man alle Schritte für die Lokale Migration unternommen hatte. Es hat sich quasi ein Post-Livisi (Innogy) Forum nach deren Abschaltung gegründet. Dort wird immer noch fleißig zu dem System auf Homeassist Basis und ioBroker diskutiert. https://lsh.community/search/?q=iobroker&sortField=time&sortOrder=DESC

Hier nun der Thread: https://forum.iobroker.net/topic/84650/test-adapter-sunseeker

@oFbEQnpoLKKl6mbY5e13 Mit Internet ist alles Okay. Die letzten 2 Tage geht es wieder (keine einzigen Fehler), aber davor war extrem viele Fehler. Ich habe im homematic-forum gelesen, dass zurzeit viele Nutzer sich wegen Ausfälle beschweren.

@Chaot hast du die Startwert entsprechend angepasst? Edit: SourceAnalytix – Neuer Zähler / Negative Verbrauchswerte korrigieren SA-Instanz stoppen (Instanzen → sourceanalytix.0 → Stop) In Objekte wechseln → Expertenmodus aktivieren (Schraubenschlüssel oben rechts) Den originalen Zähler-Datenpunkt suchen → rechts auf Bearbeiten (Bleistift) klicken Tab Benutzerdefiniert → sourceanalytix öffnen und folgende Felder anpassen: valueAtDeviceReset → 0 valueAtDeviceInit → 0 cumulativeValue → aktuellen realen Stand des neuen Zählers eintragen Startwerte anpassen: start_day → Zählerstand des neuen Zählers zu Beginn des heutigen Tages start_week, start_month, start_year → jeweils den Zählerstand des neuen Zählers zum Beginn des jeweiligen Zeitraums Speichern SA-Instanz wieder starten Hinweis: Falls SA nach dem Neustart einen Fehler wie valueAtDeviceReset > cumulativeValue cannot proceed meldet → SA nochmal stoppen und valueAtDeviceReset erneut auf 0 setzen, dann wieder starten Nochmal edit Lösung: Den alten Endstand als Offset addieren Du trägst in cumulativeValue nicht den realen Wert des neuen Zählers ein, sondern alter Endstand + aktueller Stand des neuen Zählers, damit es Nahtlos weiterläuft

@Hans_M sagte: Da muss ich mir mal in Ruhe Zeit nehmen dafür. Aber nicht zu lange, dein derzeitiges Ding ist überfällig.

der Adapter erstellt unter tr-064.0.devices deine Geräte, denen du einen Namen gibst. Darunter werden anschließend die Datenpunkte (DPs) erstellt, wie auf dem Bild zu sehen ist: [image: 1779888747674-tr064.jpg] Für den DP "active" habe ich einen Alias erstellt und verwende diesen in meinen Scripts. Update: Ich habe den Text lesbarer gemacht, hoffe ich 😄

Ist halt ein fehlerhaftes Repository. Sei froh dass da kein rm -r / drinnen stand :-)

@BernyR Wenn es der Buanet Container ist, dann ist das keine gute Idee. Ein Update erfolgt einfach durch die Aktualisierung der Container Version, herunterladen Container durchstarten fertig. Das ist auch identisch zur Aktualisierung des Container Betriebssystems. Das Problem deines Vorgehens ist, dass die Bereiche, in denen Node im Container Dateisystem gespeichert ist, nicht persistent ist beim nächsten neu erzeugen des Containers hast du dann einen Inkonsistenzen Stand. Also nicht machen

Wenn du die README.md von rpi2 liest sollte dir folgender Absatz auffallen: [image: 1779811927964-6da63821-db5d-4285-8a2d-3f01944102a9-image.jpeg] Also Trixie -> rpi 3.x.x Älteres OS -> rpi 2.x.x Oder rpi 3.x.x -> trixie (oder neuer) rpi 2.x.x -> älteres OS vor trixie

OK - da hat sich was am admin / jsonConfig geändert. Mit der aktellsten BETA des Admin gehts bei mir auch nicht mehr. Ich such mal ob das ein Fehler im Adapter oder im Admin ist. Edit: Wenn du magst kannst du schaun ob es mit STABLE Admin funtkioniert.