Sonoff 4CH 4-Kanal Schaltmodul per MQTT

[Otto123]

@Beta-User Er hat doch gar keine MQTT_GENERIC_BRIDGE (MGB) !? Er hat doch nur den MQTT2_CLIENT

[Beta-User]

@Beta-User Er hat doch gar keine MQTT_GENERIC_BRIDGE (MGB) !? Er hat doch nur den MQTT2_CLIENT

? Er hat doch oben eine DEF gepostet...! Und nach dem "count" zu gehen, sendet die auch fleißig...

Code Auswählen Erweitern


Internals:
[...]   TYPE       MQTT_GENERIC_BRIDGE
[...]
     2020-04-22 09:01:12   outgoing-count  807112[...]


Und der m2_CLIENT ist doch nur in der einen "Zielinstallation" vorhanden, oder bin ich jetzt auf dem Holzweg?

wenn ich zu sehr auf den Senkel gehe, bitte sagen.....

An sich nicht, aber du solltest bitte das Gesamtbild so pinseln, dass "alle auf Ballhöhe" sind (dich eingeschlossen). Bin zugegebenermaßen irritiert, dass du ein list postest, meine Antwort liest (in der die Abkürzung extra genannt ist) und dann die Frage kommt. Da scheint dir auch nicht so klar zu sein, was die MQTT_GENERIC_BRIDGE denn eigentlich für eine Funktion hat. Das bitte vorab vergegenwärtigen .

[Otto123]

Oh ja - jetzt bin ich auch verwirrt. Da meine ich auch: Zwischendecke einziehen und nochmal den Stand skizzieren
Mein letzter Stand war zentraler MQTT , MQTT2_CLIENT und Du hattest ihm dort MQTT2_CLIENT_general_bridge und ignoreRegexp empfohlen. Ich dachte das wollten wir in Ruhe aufarbeiten

Es gibt einfach zu viele Möglichkeiten

[FHEM-User22]

Hallo,
oh Mann, da habe ich mit meinem Nichtwissen ja was angerichtet.

Was gebt Ihr mir jetzt als Hausaufgabe auf?  Gibts da irgend was zum nachlesen? Was kann ich liefern? Alles was ich bisher gefunden habe, war (für mich) nur bruchstückhaft und ich fand schwer Zusammenhang.

Erstmal nochmal meine Ausgangssituation: Ich hätte gerne die MQTT-Dosen direkt mit meinem Mosquitto-Server verbunden. Von dort sollen sich die FHEM oder andere "MQTT-Bediener" (auf mehrere Grundstücke verteilt) "bedienen" und auch jeweils schalten können.
Direkt, da ich nicht an jedem Standort einen extra-FHEM haben möchte, der auch wiederum nur über MQTT mit der Aussenwelt kommunizieren kann.

Hintergrund ist, das ich die Internetzugänge nicht über DYNDNS anbinden kann und somit auch nicht von ausserhalb darauf zugreifen kann. Es sind alles DS-Lite Anschlüsse. Daher bin ich der Meinung, das ich zumindest einiges über einen gemieteten Server mit Mosquitto abdecken kann.

Wenn ich auf dem falschen Pferd sitze, bin gerne für neue Ideen offen.

Dankeschön für Eure Hilfeund sorry für mein nerven....

[Beta-User]

...aus meiner Sicht alles gut, da wurde nichts "angerichtet"...

Faktenlage also:

1. Es gibt nur den einen Server (mosquitto, irgendwo im Internet).
2. An den senden alle ESP-basierten Geräte direkt;
3. alle anderen FHEM-Devices sind via MQTT_GENERIC_BRIDGE "ver-mqtt-t" (es gibt also in jeder der FHEM-Instanzen so eine MGB).

Du hast jetzt "irgendwo in einem der FHEM's" den Versuch gestartet, eines der "nativen" MQTT-Geräte (den 4Ch-Sonoff) nicht mehr "klassisch" mit MQTT_DEVICE anzubinden (oder Dummy+MGB), sondern mit MQTT2_DEVICE.

Daraus ergeben sich für mich ein paar Fragen bzw. offene Flanken:
- gibt es weitere "native" MQTT-Geräte, die bereits eingebunden sind? Wenn ja: Bitte ein Beispiel und auch Info zur Frage, ob das dann in allen FHEM-Instanzen als MQTT_DEVICE angelegt war.
- Wie sind dann die per MGB "ver-mqtt-ten" Devices in anderen Instanzen eingebunden? Auch als MQTT_DEVICE oder dort Dummy+MBG?
- Das Konzept sieht vor, dass alle Info in allen Instanzen verfügbar ist und auch alles von überall her geschaltet werden kann. Kommt mir zum einen sehr offen vor, und zum anderen werden dadurch eine ganze Menge mehr Daten kreuz und quer erzeugt und übermittelt (und geloggt?) als notwendig, aber das sind eher Fragen, die mit Datenschutz und Absicherung zu tun haben. Zumindest letzteres sollte so oder so richtig gemacht werden, egal, ob jetzt nur ein Device schaltbar gemacht wird oder viele.
- Wie gehst du mit Verbindungsabbrüchen um? (Konkret: Ist der Mosquitto nicht zu erreichen, kannst du die Tasmota-Dosen nur noch lokal schalten, z.B. über das Web-Interface des jeweiligen ESP. Oder irre ich mich?).

Da mit letzerer Frage latent auch die Frage im Raum schwebt, wie es anders gehen könnte:
- Man kann auch mit mehreren MQTT-Servern arbeiten, also z.B. für jede "FHEM-Insel" einen MQTT2_SERVER aktivieren (z.B. Port 1884). Da senden alle "nativen" MQTT-Geräte ihre Daten hin.
Vorteile:
-- alles ist zumindest lokal verfügbar, selbst wenn der mosquitto weg ist.
-- Man kann die "nach außen" gehenden Daten auf das beschränken, was wirklich "kreuzweise" verfügbar sein soll/muß.
- Diesen "externen" Kanal kann man weiter über die MGB (Port 1883) machen, ich würde dann aber nicht mehr "alles" rauspusten, sondern nur noch das, was auch wirklich "extern" verfügbar sein soll...

Soweit nachvollziehbar?

[rudolfkoenig]

werden dadurch eine ganze Menge mehr Daten kreuz und quer erzeugt und übermittelt (und geloggt?) als notwendig

Nicht, wenn die Subscriptions richtig spezifiziert sind.

[Beta-User]

Nicht, wenn die Subscriptions richtig spezifiziert sind.

Jein. Wenn ich das richtig sehe, gehen aus allen FHEM-Instanzen über die MQTT_GENERIC_BRIDGES alle Daten erst mal raus (=kreuz). Die Subscriptions bestimmen dann, ob sie auch "quer" gehen. Da aber lt. Beschreibung alles von überall schaltbar sein soll, klingt das nicht nach Datensparsamkeit bei den subscriptions, sondern erst mal nach der großen Freude, dass es (überhaupt) "klappt".

Meine Anmerkung ging aber auch in die Richtung, hier ggf. mehr Sorgfalt bei der Frage walten zu lassen, was wo zu sehen sein soll, also die subscriptions mal näher anzusehen, damit die Freude auch länger währt...

[Otto123]

Ich dachte die MQTT_GENERIC_BRIDGES braucht man nicht?
Ich würde es nur mit einem MQTT2_CLIENT machen - oder geht das nicht?

[Beta-User]

No. MGB kann mit allen drei IO-Modulen und hat einen ganz anderen Zweck.

[Otto123]

Ich habe jetzt mal folgendes Setup probiert:
FHEM und MQTT Instanzen

• mqtt broker in der cloud (cloudmqtt)
  
• MQTT2_CLIENT FHEM Instanz1 verbunden mit cloudmqtt standard, autocreate nicht aktiv
  
• MQTT2_SERVER intern FHEM Instanz2
  

2 Geräte

• shellyplug s verbunden zu MQTT2_SERVER intern FHEM Instanz2, MQTT2_DEVICE vorhanden mit autocreate und attrTemplate eingerichet
  
• gosund sp111 mit tasmota verbunden zu MQTT2_SERVER intern FHEM Instanz2, MQTT2_DEVICE vorhanden mit autocreate und attrTemplate eingerichet
  

Umzug in die cloud

• Beide Definitionen aus Instanz2 kopiert, IODev geändert auf den MQTT2_CLIENT, in Raw Definition der Instanz1 ausgeführt.
  
• shellyplug s und gosund sp111 verbunden zu cloudmqtt
  

Fertig - läuft

@Beta-User Ist das so ein möglicher sinnvoller Weg? Umständlich - aber ohne zusätzliche Devices und ohne Gefahr was falsch zu machen mit "kreiselnden" MQTT Messages.

Gruß Otto

[Beta-User]

@Beta-User Ist das so ein möglicher sinnvoller Weg? Umständlich - aber ohne zusätzliche Devices und ohne Gefahr was falsch zu machen mit "kreiselnden" MQTT Messages.

Für reine MQTT-Geräte (hier: Tasmota-firmware) sollte das passen; ist ja im Prinzip genau das, was ich bei den "wie stelle ich um?"-Threads gerne schreibe.

Aber hier sind bei den Anforderungen des TE noch zwei "Besonderheiten" drin:

Zum einen sind auch ein paar "nicht-native-MQTT-" Geräte im Spiel, jedenfalls deutet die Existenz der MQTT_GENERIC_BRIDGE stark in diese Richtung.

Zweitens war meine Frage ja auch in die Richtung, wie man die Tasmota-Geräte auch vom lokalen FHEM aus schaltbar hält, wenn der zentrale Broker weg ist (insbesondere: Mobilfunknetz fällt aus). Ist bei deinem Vorschlag völlig offen.
Das kann man m.E. nur lösen, wenn man entweder
- den MQTT-Weg "doppelt" (also via MGB noch einen zweiten Pfad zu einem ANDEREN Broker generiert, auf den jeweils Status-updates erfolgen bzw. auf dem Schaltanweisungen erwartet werden, oder
- die Broker "brückt". Das kenne ich nur vom "vorbeilesen" aus der Mosquitto-Welt... Was ich dazu verstanden habe: Man kann einen Mosquitto auch als "MQTT-Client" eines anderen Broker konfigurieren und so Nachrichten weiterleiten. Müßte mich da  auch eindenken/einlesen, aber mMn. wäre das "der Königsweg" für solche Installationen:
Jeweils einen lokalen MQTT2_SERVER, und am Mosquitto dann die Entscheidung, was jeweils (nur!) abboniert wird bzw. weitergeleitet an eine andere Instanz.
Kann aber nicht sagen, inwieweit M2_Server das unterstützt... (_sollte_ aber gehen, wenn die Subscriptions und "Publish-Forwards" auf der zentralen Mosquitto-Seite konfiguriert werden können).

Ziemlich abstrakt, das ganze, aber hoffentlich nachvollziehbar?

[Otto123]

Ich denke die Anforderung vom TE:

Erstmal nochmal meine Ausgangssituation: Ich hätte gerne die MQTT-Dosen direkt mit meinem Mosquitto-Server verbunden. Von dort sollen sich die FHEM oder andere "MQTT-Bediener" (auf mehrere Grundstücke verteilt) "bedienen" und auch jeweils schalten können.
Direkt, da ich nicht an jedem Standort einen extra-FHEM haben möchte, der auch wiederum nur über MQTT mit der Aussenwelt kommunizieren kann.

ist durch mein Beispiel Szenario relativ simpel und genau abgedeckt?!

Zum Thema: "Internet ist weg" lokale Bedienung ist entweder nur der Taster am Gerät oder noch die HTTP Schnittstelle. Die bleibt ja lokal erreichbar (wie auch immer) und mqtt ist eben nur mit der Zentrale und nur wenn Internet verfügbar.
Wird mal irgendwann wie Strom: Kein Strom - nix geht mehr, kein Internet - nix geht  mehr.
--------------------------------------------------
Eigentliche Frage zu deiner Antwort:
Ich glaube so langsam verstehe ich aber da ist noch viel zu tun in meinem Kopf

Könnte man vielleicht einen MQTT2_CLIENT auch als Mittler zwischen zwei MQTT Servern implementieren?
Also ein MQTT2_Server lokal, ein MQTT2_CLIENT Lokal und ein MQTT Server in der cloud?

[rudolfkoenig]

Könnte man vielleicht einen MQTT2_CLIENT auch als Mittler zwischen zwei MQTT Servern implementieren?

Klar, fuer die Weitergabe kann man je nach Praeferenz MQTT_GENERIC_BRIDGE oder notify verwenden.
Man sollte nur die Topics gut ueberlegen und die MQTT2_CLIENT subscriptions richtig setzen, sonst baut man eine Endlosschleife.

[Beta-User]

Klar, fuer die Weitergabe kann man je nach Praeferenz MQTT_GENERIC_BRIDGE oder notify verwenden.

Das versuche ich (mit Schwerpunkt auf MGB) hier die ganze Zeit zu erklären.

Ich denke die Anforderung vom TE:ist durch mein Beispiel Szenario relativ simpel und genau abgedeckt?!

Schon, wobei ich zugeben muß, dass mich die Anforderung "ohne lokales FHEM" etwas irritiert, weil der TE ja gerade eine MQTT_GENERIC_BRIDGE als "Beispiel" hier gelistet hatte - und die setzt zwingend voraus, dass ein FHEM vorhanden ist. Für einen "FHEM-losen" "Satelliten" erfüllt dein Szenario aber in jedem Fall die Anforderung .

Ich würde nur eben hinterfragen, ob es überhaut Sinn macht, FHEM-lose Satelliten zu haben . Sobald das Risiko besteht, dass die Verbindung abbricht und irgendeine Art lokaler Logik laufen soll, die nicht durch direkte Hardware-to-Hardware-Kommunikation (HM-Sprech: Peering) gelöst werden kann, würde ich den "Verbesserungsvorschlag" machen wollen, das mit lokaler FHEM-Installation+"doppeltem Broker" zu lösen, wobei die Anbindung des 2. Brokers mMn. am einfachsten über MQTT_GENERIC_BRIDGE+MQTT2_CLIENT zu machen ist. Das kann universell die Sende- und Empfangsrichtung abdecken und die Angaben, was (über diesen 2. Weg) zu senden und was zu empfangen ist, sind dann direkt beim "Zieldevice" zu finden. Das ist mMn. übersichtlicher als eine notify+IO-publish/supscribe-Lösung. Das "Zieldevice" der MGB kann eine Vielzahl beliebiger FHEM-Devices beliebigen TYPEs sein, also CUL_HM, ZWave oder eben auch MQTT2_DEVICEs, die mit einem anderen Broker (z.B. TYPE=MQTT2_SERVER) sprechen.

Hoffe, das hilft für das Sortieren der Gedanken?

Es wäre aber ganz gut, wenn der TE sich mal wieder meldet . Sonst ist das alles nur theoretischer Kauderwelsch...

[Otto123]

Es wäre aber ganz gut, wenn der TE sich mal wieder meldet . Sonst ist das alles nur theoretischer Kauderwelsch...

Vielleicht gibt es am Donnerstag ne "Leipziger Videoschalte" dann kann man einfach mal reden

Und Du weisst doch wie das ist: mach die Kiste auf wo MQTT drauf steht, nimm ein paar Bausteine raus zum Spielen und fang mal an.