@Purecut ich kenne die pw11 nicht, aber ja, ein weiterer Bus = eine weitere Instanz Wenn du an dem Bus des Konverters mehrere SDM anschließen kannst, bleibt es bei einer Instanz Zur 2.Instanz siehe https://www.iobroker.net/#de/documentation/tutorial/adapter.md

@Purecut sagte: in der Jetzigen Form lässt es nicht mehr zu einen Client ID zu benennen Wie kommst du zu dieser Aussage? Wie gesagt kenne ich das gar nicht dass das jemals ging, schon gar nicht @Purecut sagte: wo ich sagen kann in welchen Unterordner der die Datenpunkte ablegt.

@OliverIO sagte: @backons Hast du einmal probiert, die Pins direkt über die Kommandozeile mit dem Programm raspi-gpio abzufragen? Ja in der Linux Console wird der korrekte Status angezeigt D.h. Am Pi selbst funktioniert alles wie es soll. Die Daten werden nur durch den Adapter nicht korrekt an den ioBroker weitergegeben. Deswegen die Frage nach einer alternativen Lösung

Dann muss ich mich wohl mit dem Gedanken anfreunden.... Trotzdem Danke für die Unterstützung @thomas-braun @homoran @haselchen

#gelöscht

@Kellerkind-86 sagte: ob du das hier meinst: Im Manu_Mode gibt's keine Beschattung! Das ist ei Feature, kein Bug! Die sonneneinstellungen lassen wir dann mal bis du sie gefunden hast

@rewenode sagte: Wird die Redis db bei der Umstellung zu Jsonl plattgemacht? jep, wenn ich mich recht erinnere, kommt auch eine entsprechende Warnmeldung. EDIT: also das "Plattmachen" erfolgt beim Zurückspielen in Richtung Redis Ich hatte mir seinerzeit auch die Zähne daran ausgebissen, herauszufinden, welche Objekte betroffen waren.

Wie setzte ich das dann OFF, also möchte den ausgelösten Alarm denn gern abschalten?!

Hmm, das ist ein kniffliges Problem, und auch MMN möglicherweise ein Bug im sql-Adapter. "Löschen eines Objektbaums löscht Datenbankverknüpfungen von enthaltenen Datenpunkten nicht" Jetzt ist die Frage, wie man so etwas wieder weggefummelt bekommt. Meine vage Idee: Adapter noch einmal installieren dann müssten die fraglichen DPs wieder angelegt werden Für die Datenpunkte sql aktivieren, und gleich wieder deaktivieren. Möglicherweise ist danach das Problem weg. Nutze aber selber den SQL Adapter nicht, sondern Influx

Laut GitHub ist es mit der 7.2.2 behoben

Ich habe es nochmal probiert: QOS auf 1 gestellt. Dann per mqtt beide Relais eingeschaltet und über die Weboberfäche wieder ausgeschaltet. Nach drei Minuten in der 24. Sekunde das gleiche Verhalten. [image: 1781790901084-1000083333.jpg] [image: 1781791071525-1000083335.jpg] Immer in der 24. Sekunde. [image: 1781791201944-1000083339-resized.jpg] [image: 1781791347548-1000083343-resized.jpg]

ich nochmal, der Motor läuft ja mit einem Akku, den Akku Status kann micht zufällig auslesen? Habe den momentan permanent am Strom, würde das jedoch gerne mit einer smarten Steckdose steuern

Danke, der Artikel hat mir geholfen. Aber eine Frage dazu habe ich auch noch. Ich kann nun Daten aus dem Solakon One auslesen. Hat es von euch jemand geschafft den Poweroutput über iobroker zu setzen oder zu ändern?

@Kusselin sagte: Warum der nicht mehr installiert war @Kusselin sagte: node 22.xx liegen??? habe nämlich das Update getsren gemacht...weil der aktuelle sonoff adapter das fordert! weil er nicht kompatibel zu deinem System war

@Kusselin sagte: Hier die letzte Nachricht vom Shelly Support: die von Ihnen zitierte allgemeine Aussage des Adapter-Entwicklers ändert nichts an den im konkreten Fall vorliegenden Diagnosedaten. In den übermittelten Protokollen ist eindeutig erkennbar, dass der Shelly in sehr kurzen Abständen eingehende MQTT-Nachrichten aus Ihrem Netzwerk erhält. Der Adapter-Entwickler kennt weder Ihre vollständige ioBroker-Konfiguration noch Ihre Skripte, Instanzen, MQTT-Topics oder die konkreten Logdaten dieses Gerätes. Eine pauschale Aussage zum üblichen Verhalten des Adapters kann daher die tatsächlich protokollierte Kommunikation in Ihrer Installation nicht widerlegen. Ob diese Nachrichten durch den Adapter selbst, ein Skript, eine weitere Instanz, eine fehlerhafte Konfiguration oder ein anderes System erzeugt werden, können wir nicht beurteilen. Dies muss innerhalb Ihres Drittanbietersystems beziehungsweise anhand der Broker- und ioBroker-Protokolle geprüft werden. Der Shelly wird durch diese ungewöhnlich hohe Anzahl eingehender MQTT-Nachrichten, teilweise in Abständen im Millisekundenbereich, erheblich belastet. In den Protokollen wird dabei sogar eine überlaufende Warteschlange gemeldet. Dies führt dazu, dass das Gerät zeitweise nicht mehr reagiert und abstürzt. Ein Gerätefehler lässt sich aus den vorliegenden Diagnosedaten hingegen nicht ableiten. Bitte prüfen Sie daher in Ihrem MQTT-Broker beziehungsweise in ioBroker: welche Clients Nachrichten an die Topics des Shelly senden, welche Skripte oder Automationen diese Nachrichten auslösen, ob mehrere Adapter oder Instanzen gleichzeitig auf dasselbe Gerät zugreifen, welche Polling (Abfrage) Intervalle konfiguriert sind und ob sich die Nachrichtenrate nach dem Deaktivieren der MQTT-Integration normalisiert. Da die Ursache nach aktuellem Stand außerhalb des Shelly-Gerätes liegt und innerhalb des verwendeten Drittanbietersystems geprüft werden muss, werden wir den Vorgang an dieser Stelle schließen. Um das Rätselraten zu minimieren bitte - stell uns die Protokolle zur Verfügung auf Grund derer der Shelly SSupport zu seiner Aussage kommt. - stell wie schon früher angefragt ein vollständiges Logfile des Shelly Adapters mit level DEBUG zur Verfügung (vollständig = vom Start des Adapter bis zum Auftreten des Problems) Vielleicht sieht man dann mehr... Welche der Schritte die der Shelly Support empfohlen hat: Bitte prüfen Sie daher in Ihrem MQTT-Broker beziehungsweise in ioBroker: welche Clients Nachrichten an die Topics des Shelly senden, welche Skripte oder Automationen diese Nachrichten auslösen, ob mehrere Adapter oder Instanzen gleichzeitig auf dasselbe Gerät zugreifen, welche Polling (Abfrage) Intervalle konfiguriert sind und ob sich die Nachrichtenrate nach dem Deaktivieren der MQTT-Integration normalisiert. hast du schon mit welchem Ergebnis durchgeführt?

@BLRD Und den ford würde ich auch aus dem Fegefeuer nehmen: ford github: 1.2.0 latest: 1.1.5 for 5 months stable: 1.0.4 for 23 months Stuf den entweder auf die 1.0.4 aus stable zurück oder nimm die 1.1.5 aus dem Beta-Zweig. Alles besser als eine verwaiste räudige GitHub-Katze. Gleiches gilt für den homee: homee github: 1.2.0 latest: 1.2.0 for 59 months stable: 1.2.0 for 59 months GItHub ist NICHT die erste Adresse für Installationen, im Gegenteil. Edit: Gleiches für icons-ultimate-png: icons-ultimate-png github: 1.0.1 latest: 1.0.1 for 104 months stable: 1.0.1 for 104 months

Danke Männer, hat funktioniert

Verstanden, werde ich beizeiten anpassen (das PW ist natürlich nicht Standard). ✓ Your zigbee.0 COM-Port is matching 'by-id'. Very good! Das passt also nun auch. Danke Euch vielmals für die Hilfe!!!