@myzerat
Der finale Test mit der zweiten Instanz via MQTT-Protokoll war jetzt erfolgreich. Alle Datenpunkte werden synchronisiert. Die Aussage, dass MQTT von allen Geräten der Gen. 1 und Gen. 2 unterstützt wird hat mich etwas verwirrt. Das ließ mich vermuten, dass ich nur eine Instanz benötige. Vielen Dank für eure Rückmeldungen.

Hallo zusammen,

aktuell werden eine Vielzahl von unterschiedlichen Shellys der Generation 1 über den Shelly-Adapter via CaAP verwaltet. Zusätzlich sollte jetzt der Shelly Plus 2PM integrieren werden. Der Shelly der Generation 2 wurde über die Shelly-App angelernt. Zustandsänderungen werden ordnungsgemäß ausgeführt und in der App zurückgemeldet.

Im Anschluss wurde der Shelly in ioBroker integriert. Im Shelly-Adapter wurde das Protokoll von CoAP auf MQTT umgestellt und die erforderlichen MQTT-Einstellungen vorgenommen. Weiterhin wurde in der Shelly-Webkonfiguration IP-Adresse vom ioBroker-Server und der Port: 1882 eingetragen. Alle RPC-Optionen wurden aktiviert. SSL ist inaktiv. In der Shelly-App wurde für das Geräte MQTT aktiviert. Art der Verbindung: RPC-Statusbenachrichtigungen über MQTT aktiv, Allgemeine Statusbenachrichtigung über MQTT aktiv. Nach dem Neustart des Shellys ist dieser mit MQTT verbunden. Zustandsänderungen werden korrekt umgesetzt/dargestellt.
Problem: Nach dem Umstellen des Shelly-Adapters auf MQTT können alle Shellys der Generation 1 nicht mehr über ioBroker gesteuert werden. Unabhängig davon, ob die Statusänderung manuell oder via VIS erfolgt. Umgekehrt kann bei Aktivierung des Protokolls CoAP der Shelly der Generation 2 nicht mehr verwaltet werden. Der parallele Betrieb zweier Adapter mit (1. CoAP und 2. MQTT) löst das Problem nicht.
Hat jemand noch eine Idee?

ioBroker (docker): Host Version 6.0.11
Shelly-Adapter Version: 8.2.1

@bananajoe OK.

Ich werde bei Gelegenheit die MQTTs aufsetzen und ein Feedback geben.

Hochverfügbarkeit ist bei mir immer wichtiger geworden. Ein zweiter Server stand ohnehin zur Verfügung. IoB steuert bei mir nicht nur Lampen sondern aktiv die komplette Heizung, Warmwasser, Lüftung, Kameras, Bewegungsmelder, Anwesenheitskontrolle, etc. spricht viele sicherheitsrelevante Endgeräte. Die Verfügbarkeit ist insbesondere dann wichtig, wenn keiner Zuhause ist. Die automatische Umschaltung erfolgt in < 1 Minute. Eine Ausfallzeit von > 1 Stunde hätte schon erhebliche Auswirkung auf die Steuerung. Außerdem dient der Slave als Entwicklungsumgebung, um nicht am offenen Herzen operieren zu müssen.

@bananajoe Vielen Dank für deine Rückmeldung.
Die Idee, dass Problem über MQTT zu lösen werde ich gerne ausprobieren. Allerdings ist das für mich Neuland.
Kurz zu den Installationen. Aus Gründen der Ausfallsicherheit laufen bei mir 2 identische IOB-Instanzen. Der Master befindet sich in einem Docker-Container auf dem NAS und ist standardmäßig aktiv. Der zweite befindet sich auf einem Raspi. Hier gibt es ein WatchDog-Skript, welches überwacht, ob der Master zur Verfügung steht. Ist das nicht der Fall wird automatisch auf den Slave umgeschaltet, spricht die Skripte auf diesem gestartet. Akutell kommuniziert die Wetterstation nur mit dem Master. Die Wetterdaten sind jedoch essentiell auf beiden Servern, um die Jalousien zu steuern.

Was ist deine Empfehlung für das Aufsetzen des MQTT-Servers? Den Server direkt im IOB-Master aufzusetzen schließe ich aus, denn wenn dieser auffällt hilft das nicht weiter. Ich würde den MQTT-Server als Docker direkt auf dem NAS aufsetzen. Die Frage ist, ob der Server sowohl mit dem Master als auch dem Slave kommunizieren kann? Alternativ könnte ich den Server auch auf dem Slave aufsetzen. Vielen Dank im Voraus.

Hallo, ich betreibe zwei separate IoBroker-Installationen. Meine Wetterstation habe ich erfolgreich mit dem Sainlogic-Adapter eingebunden.
Listen on all IPs on Port 45000
Pfad: /weatherstation/data
Protocol: Ecowitt
Der Sainlogic Adapter wurde auf der 2. Ibo-Installation mit der gleichen Konfiguration installiert. Die Datenpunkte wurden angelegt. Adapter steht auf grün. Im Log steht "Starting Listener". Leider werden keine Werte geschrieben ("null"). Beim Vergleich der Objektdaten fehlen die "acl" Angaben:
"acl": {
"object": 1636,
"state": 1636,
"owner": "system.user.admin",
"ownerGroup": "system.group.administrator"

Hat jemand einen Tipp?

@homoran
Vielen Dank für deinen Support. Jetzt funktioniert wieder alles!
Lösung:
Wenn Master im WLAN-Mode nicht zur Verfügung steht, dann kann manuell auf den Slave durch Wechsel der Socket URL gewechselt werden. Bei Ausfall des Masters wird der Cloud-Adapter auf dem Slave gestartet. Dieser Verbindet sich dann korrekt mit iob.pro. Beim Switch auf dem Master wird der Cloud-Adapter auf dem Slave gestoppt und im Anschluss auf dem Master gestartet. So ist sichergestellt, dass immer nur ein Server mit iob.pro verbunden ist. Beim Remote-Zugriff wird so automatisch auf die Maschine umgeschaltet, die gerade aktiv ist.

Ich hatte nicht auf dem Schirm, dass immer nur ein Cloud-Adapter mit dem iob.pro verbunden sein darf. Kleiner Verbesserungsvorschlag: Beide Cloud-Adapter (wenn zeitgleich gestartet) - erwecken den Eindruck, dass alles OK ist (alles grün - auch verbunden mit Gerät oder Dienst), was eigentlich nicht der Fall ist. Der Adapter, der als erster die Verbindung aufgebaut hat, hat gewonnen. Bei der zweiten Cloud-Verbinddung, mit den gleichen Zugangsdaten, hätte ich eine gelbe Ampel erwartet.

@homoran

• web mit Verschlüsselung und Authenifikation, socket.io = integriert
• log beim start:
  info: cloud.0 (17283) starting. Version 4.3.0 (non-npm: ioBroker/ioBroker.cloud) in /opt/iobroker/node_modules/iobroker.cloud, node: v19.3.0, js-controller: 4.0.24

info: email.0 (5252) sent to hem-d@online.de
info: cloud.0 (17283) Connecting with https://iobroker.pro:10555 with "@pro_muster@gmail.com 345d62a0-309d-11ea-8ff5-372a081f"
error: cloud.0 (17283) Cannot activate web.0 for cloud, because authentication is enabled. Please create extra instance for cloud
info: cloud.0 (17283) Trying to connect as system.user.admin to cloud
info: cloud.0 (17283) Adapter redirected temporally to "https://iobroker.pro:10556" in 30 seconds. Reason: command from server
cloud.0 (17283) Connection changed: disconnect
error: cloud.0 (17283) Cannot activate web.0 for cloud, because authentication is enabled. Please create extra instance for cloud
info: cloud.0 (17283) Trying to connect as system.user.admin to cloud
info: cloud.0 (17283) Connection changed: connect

• cloud Instanz mit gleichen Zugangdaten ist inaktiv

@homoran OK. Im cloud-Adapter des Masters stehen die korrekten Zugangsdaten von iob.pro. Dieser verweist auf die Web-Instanz. Cloud und Web auf dem Slave ist inaktiv. Warum bekommt er die Verbindung über iob.pro nicht mehr hin?

@homoran
... korrekt! Sieht aus, als würde sich iobroker.pro die letzte IP-Adresse (Slave) merken.

@homoran
Guter Tipp! In der Vergangenheit habe ich die Instanzen auf dem Slave erst gestartet, wenn der Master nicht zur Verfügung stand. Ich habe jetzt auf dem Slave die Instanzen: cloud, vis und web gestoppt. Unter WLAN wird die Verbindung korrekt aufgebaut. Remote erhalte ich die Nachricht, ioBroker is not connected. Die App zeigt Status verbunden: "ja" an und Projekt "abfragen ...". Offenbar kann das Main-Projekt nicht gefunden werden. Im Log wird im Unterschied zum WLAN auch keine Verbindung zur Web-Instanz angezeigt. Hast du noch einen Tipp?