@Slowman

hi, mit 2 Elementen...

LG Sven

@mickym Shit, Asche auf mein Haupt. Da war ich aber schon lange nicht mehr dran. Habe ich jetzt entsprechend nachgetragen und werde das beobachten. Soweit erst mal danke.

@mickym laut Log (höchste Detail-Stufe) bekomme ich auch keine Nachricht zurück, die zuvor gesendet wurde

@mickym wenn du mir jetzt noch sagst, wie ich da machen soll... der Adapter läuft als Client. Unter "Subscribe Pattern" kann ich zwar was eintragen aber nichts speichern. Der Speicher-Button bleibt ausgegraut. Wenn ich noch eine andere Option ändere und den Button damit aktiviere, ist der Eintrag unter Subscribe Pattern wech... Wenn ich dann wieder was eintrage und auf Speichern klicke, ist nix gepeichert....

@bananajoe das ist die Konfig des sendenden Servers:

@lakelounge ich habe die zu übermittelnden Daten schon sehr genau definiert. Trotzdem, zur Kontrolle habe ich mal den Test am Mqtt-Server gemacht mit folgendem Ergebnis:

Da passiert auch nicht so viel. Das System läuft in dieser Konfig bereits 2 Jahre und das ohne jedwede Aussetzer. Die Signale sind quasi "handverlesen" und haben auf dem sendenden Server1 auch nur eine lokale Quelle. Die hohe CPU-Last/Load/Network-Traffic ist jetzt an 3 Tagen zu unterschiedlichen Zeiten (volle Stunde...!) aufgetreten und lässt sich durch stoppen der Adapter heilen. Wenn ich den MQTT-Server (Raspberry) neu starte, kann ich die hohe Belastung auch manuell hervorrufen. Ein Neustart der beiden Adapter richtet es dann wieder. Diese Probleme hatte ich in der Vergangenheit so definitiv nicht. Die Systeme werden permanent überwacht und alarmieren im Falle einer Abweichung hinsichtlich Belastung/CPU-Temp. etc.

@homoran beide Adapter sind schon immer so eingestellt gewesen. Auf Server 1 empfängt der Adapter nur ohne etwas zu senden. Auf Server 2 sendet der Adapter nur etwas und empfängt nix. Zwischen Server1 und Server2 gibt es keine gemeinsame Daten. Beide Server hängen eben nur an dem einen MQTT-Server.

Hallo zusammen. Also ich habe seit 3 Tagen nach Update auf Adapter-Version 4.07 (MQTT Broker/Client) das gleiche Problem.
Konfiguration:
1x Raspberry-Pi (Dietpi) mit Node-Red und MQTT-Server
2x IOBroker auf 2 unterschiedlichen Proxmox-Systemen (Adapter im Client-Modus) (Proxmox-Systeme 2x Intel-NUC)

Konfiguration lief seit ca. 2 Jahren ohne Probleme. Seit 3 Tagen steigt nun zu unterschiedlichen Zeiten die Gesamtbelastung beider Proxmox-System bis Anschlag an und geht von allein nicht mehr runter. Das Stoppen und erneute Starten der beiden Adapter in den IOBrokern beendet den "Spuk" und alles ist wieder normal. Auf beiden System sind zusätzliche MQTT-Adapter sowohl im Server- als auch im Clientmodus aktiv. Diese verursachen die Belastung nicht.
Den Raspberry-Pi und seine Systeme sind bereits neugestartet und auf aktuellem Software-Stand.
Ich werde jetzt einen der beiden Server mal auf die biss dato laufende Version des MQTT-Adapters downgraden. Vielleicht hilft das ja erstmal.

Bin für weitere Ideen/Vorschläge sehr dankbar.

@Slowman

hi, mit 2 Elementen...

LG Sven

@carsten04

ja, war wohl etwas voreilig....

hab das jetzt noch mal getestet (auf Testserver) und nun funktioniert es tadelos. Habe übrigens keine IBox sondern nur eine NodeMCU und die Lampen alle da direkt angelernt (hab auch keine Fernbedienung).
Alle Einstellungen an den Lampen (an/aus, Dimmer, Farbtemperatur sowie Farbwahl) funktionieren nun fehlerfrei.
Die App lässt sich aufrufen und die Lampen damit auch steuern. Passt alles von meiner Seite.

Habe den Adapter jetzt allerdings neu installiert. Werde den Adapter dann als nächstes auf dem Produktiv-Server aktualisieren. Dann natürlich streng nach Doku

LG Sven

@carsten04

erstmal vielen Dank für die Weiterentwicklung des Adapters. War heute mutig u. habe 7 Adapter auf die Version 0.6 geupdatet. Keine Fehlermeldungen - die Steuerung der Lampen funktioniert prima. In der kürzeren Vergangenheit hatte ich nach dem Upgrade des js-controllers auf V. 3.1.4 vermehrte Fehlermeldungen einzelner Adapter. Die sind bisher nicht mehr aufgetreten.

Mein System: NUC - Debian Buster - Node.js: v12.18.0 - npm: 6.14.4 - js-controller: 3.1.4

Bezüglich der App habe ich mehrere Browser ausprobiert:

Edge (Chromium): Website lässt sich aufrufen, die 7 Bridges lassen sich auswählen - es erscheint dann aber immer wieder nur das Einstiegsbild wie vor der Auswahl der einzelnen Bridge - also keine wirkliche Nutzung möglich

Firefox: Website lässt sich aufrufen - eine Auswahl einzelner Bridges ist nicht möglich (weil nicht angeboten)

Brave Browser: das Gleiche wie bei Firefox - es erscheinen keine Bridges zur Auswahl

LG Sven

PS: hab doch ein Problem bei der Farbwahl bzw. deren Definition. Bisher definierte Farben werden auf einmal anders dargestellt - aus Grün wird Rot und kann auch über die VIS-Steuerung nicht mehr zurück geändert werden. Bei Änderung der Helligkeit wird auch der Farbton geändert. Ich verwende die FUT103-Lampen als RGB-CCT, diese sind im Adapter auch als solche eingerichtet. Die Steuerung der Lampen erfolgen über 2 NodeMCUs. Beide funktionieren ohne Fehler. Bin jetzt erstmal wieder zurück auf die V 0.27.