@Bogie11 Versuch es damit: https://forum.iobroker.net/topic/51869/installation-auf-raspi-einfacher-geht-s-nicht

@Qlink sagte: Kannst du mir sagen ob ich bei den Adapter Settings wo einen Fehler habe ? Kommt darauf an, was du erreichen willst. Wenn du zunächst nur den aktuellen Verbrauch im Portal sehen willst, müssen wir uns nur Status und aktuelle Leistung anschauen. In den meisten Fällen wird der Status (also an oder aus) nicht richtig übertagen. Das sieht man aber schön im debug-log. Ich würde die Tabell ganz unten speziell mit DeviceOIDCounter und DeviceOIDStatus ausfüllen... Wenn du später die wallbox auch vom Portal gesteuert haben willst, musst du DeviceOIDPlugConnected und DeviceOIDChargePower in der Tabelle ausfüllen.

Ah, Danke @feuersturm ! 🙈 Jetzt macht alles Sinn. Das habe ich einfach übersehen, tut mir leid. Jetzt sieht es besser aus und alle Knöpfe und Updates laufen! Spitze!

Also es scheint an der Admin-Version zu liegen. Ich habe jetzt auf die Admin v7.8.29 aktualisiert und dann nochmal denn MQTT-Client auf v4.0.0 und es funktioniert alles.

gelöscht, da gelöst…

Bei mir bleibt es zerschossen, auch wenn ich einen downgrade und reboot mache ... auch Browsercache löschen brachte gar nichts ...

@bommel_030 sagte: Mit dem Elektriker zusammen nachgerechnet ;-) und ja, der vertreibt KNX und kein Homematic... Ich habe selbst zig Beispiele hoch und runter gerechnet. KNX ist nicht teurer als Homematic. Außer, man kennt nur ABB, Schneider und Gira auf der KNX-Seite. Die meisten Elektriker verschaffen sich leider keinen Überblick. Wie @samson71 schon sagt, kenne ich auch einige Systemintegratoren, die kein Homematic mehr machen und jetzt komplett auf KNX umgestiegen sind. Ich wollte hier nur die falschen Thesen (welche oft wiederholt werden) widerlegen. Du kannst natürlich gerne Homematic einbauen. Ich verdiene da nirgendwo mit :)

top, danke

@Dr.-Bakterius Ist im anderen Thread schon geklärt

Neuvorstellung bitte im Bereich TESTER, ziemlich sicher im Bereich TESTER/...nicht im offiziellen Repo https://forum.iobroker.net/category/197/...nicht-in-offiziellem-repo Wenn du dort (noch) nicht schreiben kannst, dann schreib @homoran im Chat an, er schaltet dich frei.

@homoran Bitte an den generellen Shelly Support Topic anhängen: https://forum.iobroker.net/topic/81297/shelly-adapter-genereller-support @holger-etzel Im Log steht sonst nichts? Ich nehme an es werden dann auch keine Geräte im Objectbaum eingerichtet. Heißester Tipp mit den vorhandenen Infos wäre dass auf dem Shelly (dem Gerät) entweder die Adresse des ioBroker Host oder der Port falsch eingetragen ist. Beachte dass du deine Adapter Instanz auf Port 1895 konfiguriert hast und daher auch im Shelly diesen Port eingeben musst. Außerdem bitte beachten dass (nah meinem Kenntnisstand) das mqtt Passwort im Shelly bei JEDER Änderung an den mqtt Daten neu eingegeben werden muss und dass der Shelly nach dem Abspeichern der mqtt Daten neu getstartet werden muss. Wenn das nichts hilft, prüfe bitte um deine Netzwerkumgebung irgendwie blocken könnte. Falls du irgendeine Virtualisierung / Docker verwendest prüfe dass der Posrt durchgereicht wird.

@JoJo58 sagte: das nodejs über apt immer ein Downgrade machen wollte. Das sollte aber genau so sein. Die fragliche Version wurde zurückgezogen und durch eine vorherige Version ersetzt. Dein Paketamanager hat also genau das getan, was er tun soll.

@Homoran sagte: Selbst mit massiven Schreibvorgängen in 72GB History mit 150-200DP tlw. im 5 Sekundentakt Wau! Interessant, dass deine SD-Karte trotz der vielen Schreibvorgänge so lange hält. Meine Endurance-Karte hat ca 2 Jahre durchgehalten, vermutlich lag das aber an den Daueraufnahmen der Kameras. Abgesehen von der Qualität dürfte auch die Größe eine Rolle spielen, da sich die vielen Schreibvorgänge auf alle verfügbaren Blöcke verteilen und so die Lebensdauer verlängern können (meine Meinung). Derzeit nutze ich für Kameras ein NAS mit HDDs, und mein ioBroker inkl Pi-hole läuft seit Jahren problemlos über USB3 an einer T5 (füher musste man noch von der SD-Karte booten). Ein Test an USB2 zeigt, dass ioBroker und Pi-hole sogar damit problemlos laufen. USB3 kann bei schlecht abgeschirmten Kabeln Störungen im 2,4‑GHz-Bereich verursachen. Das hatte ich auch einmal, konnte es inzwischen aber mit einem besseren und kürzeren Kabel beheben. Kann mich ja melden, wenn meine T5 den Geist aufgibt, hoffe natürlich nie ;-)

@joacableman Mit dem mageren Arbeitsspeicher musst du viel Geduld mitbringen. Und eine stabile Spannungsversorgung.

Letztlich habe ich das Soundcork-Projekt https://github.com/deborahgu/soundcork auf dem Rechner aufgesetzt, auf dem auch iobroker läuft. Meine Bose SoundTouch20 spielt jetzt wieder Internetradio ab und die Preset-Tasten sind auch wieder nutzbar. Vorteil für mich ist, dass die über den Bose-Adapter und JavaScript realisierte Multimediasteuerung in meiner JARVIS-Visualisierung auf meinem Tablet nach wie vor funktioniert und ich hier so gut wie nichts anpassen musste (lediglich die Aktualisierung des "key"-Datenobjekts in iobroker funktioniert jetzt nicht mehr bei jedem Tastendruck, warum auch immer, so dass ich hier mein Javascript anpassen musste). Wer also seine Bose SoundTouch 20 weiter wie gewohnt über den Bose-Adapter in iobroker weiternutzen möchte und seine Skriptlösungen und seine bereits mühsam aufgebauten GUI-Lösungen (VIS oder JARVIS etc.) nicht anpassen möchte, dem sei die soundcork-Lösung wärmstens empfohlen. Voraussetzung ist lediglich, dass man einen Linux-Server im Heimnetz zur Verfügung hat, der die ganze Zeit durchläuft (im Idealfall sowieso der Rechner, auf dem iobroker läuft). Dank der guten Schritt für Schritt Anleitung auf GitHub war die Implementierung des soundcork-Servers auch für versierte Laien nicht wirklich schwierig.

Ich habe den Speicher als Thermostat erfasst. Klappt, allerdings mit der Einheit ° statt %. Muss ich erstmal mit leben. Falls es ein besseres Workaround gibt, bin ich für Anregungen dankbar.

@tombox Vielen Dank für die Hilfe. Mail ist unterwegs, hoffe es kommt durch. Das Emailprogramm motzte dass es allenfalls zu gross sei, hat es aber verschickt. Melde dich wenn es hängen geblieben ist, dann schicke ich es in kleineren Teilen... @tombox sagte: UDP überlebt NAT-Aging schlechter als TCP. Wenn dein MDT KNX Secure unterstützt, schalte zurück auf TCP Eigentlich müsste es KNX Secure können, hab ich mich aber noch nicht wirklich damit befasst. Komisch ist das es nach dem FW-Upgrade angeblich automatisch mit TCP verbunden hat, obwohl das so wie ich verstehe gar nicht möglich sein dürfte da ich KNX secure gar nicht aktiviert habe...Aber wie geschrieben, das Thema ist für mich komplettes Neuland. Schaue ich wenn ich dazu komme morgen mal an... @tombox sagte: Setze in der WireGuard-Peer-Config (auf der Seite, die hinter LTE-NAT sitzt) folgendes: PersistentKeepalive = 25 Muss ich Morgen noch mal kontrollieren, wenn ich mich aber nicht täusche steht der schon auf 25s (wie all meine WG-Verbindungen). Aber ist es denn nicht so dass die Anzahl der Meldungen schon genug sein sollte um die Verbindung aufrecht zu erhalten? Etliche Meldungen vom KNX werden da im Sekunden-Takt verschickt. Aber vielleicht verstehe ich da auch was falsch. Was für mich auffällig ist, ist dass es mit den 0.x-Versionen die Abbrüche nicht gab. Seitdem hab ich am WG-Tunnel, KNX-Projekt und Menge der übermittelten Daten nichts bewusst verändert...was jetzt nicht heisst dass es da kein Verbesserungspotential seitens meines Systems gibt, im Gegenteil. Und ist auch kein Vorwurf an dich...soll nur als Info dienen um das Problem allenfalls weiter eingrenzen zu können... Vielen Dank und Gruss