@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

@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.

Bin ich bei dir. Aber genaugenommen muss nur ein Layer dazwischen. Finde das in Python von Home Assistant gerade nicht. Aber es gibt schon Grundlagen. Tasmota macht das über MQTT... da wandert aber die komplette Hostapplikation auf den ESP. Unser CZC wird dort auch schon untertstützt. Damit hat man das Problem, falls man es denn hat, auch gelöst aber eben weniger ZigBee Hardware, die unterstützt wird. Und ja... dass Leute sagen: "Geht doch schon viel günstiger" sehe ich oft genug im WLED Umfeld. Bin ich auch hier (https://forum.iobroker.net/topic/84526/wled-grundlagen-von-smarterkram-olli-erklärt-von-mir) drauf eingengangen.

@Codierknecht Danke immer wieder für das Bild mit den Einstellungen in Post #2. Ich vergesse das immer wieder, wie es richtig eingestellt wird und welche Haken zu setzen sind - und komm dann wieder auf das Bild zurück. Und schon läuft's wieder

Da stehjt nix vom Gästezimmer drin

Ok, ich habe in einem anderen Forum die Lösung gefunden. Hier zur Doku :-) Es ist bei mir ein kabelgebundener Schalter verbaut, der Zigbee spricht und mit der Zigbee Funkfernbedienung gekoppelt ist. Man kann diesen kabelgebundenen Schalter zusätzlich mit einer Zigbee Zentrale koppeln. Dafür drückt man 10 Sekunden beide Knöpfe am Schalter, bis die LED rot zu blinken beginnt. DANACH muss man den oberen Knopf nochmal 10 Sekunden lang drücken, dann erscheint das Gerät auch im Zigbee2MSQTT.

@Asgothian Danke, dann bleibt es so, wie es jetzt ist.

@thomas-braun Guten Morgen, das Update wurde erfolgreich durchgeführt. Danke. Unter ioBroker kann ich das ESPHome-Dashboard allerdings weiterhin nicht direkt öffnen. Über http://IP:6052 funktioniert es jedoch problemlos. Warum der direkte Aufruf über ioBroker auf einmal nicht mehr funktioniert, kann ich aktuell leider auch nicht sagen.

Vielen Dank JoJo58. Jetzt funktioniert alles richtig.