Modul-Konzeption: Generic MQTT Bridge

Begonnen von hexenmeister, 21 Dezember 2017, 22:35:38

Vorheriges Thema - Nächstes Thema

hexenmeister

Danke euch, es freut mich, dass meine Arbeit jemanden nützlich ist :)
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

SamNitro

Zitat von: hexenmeister am 16 Mai 2018, 21:47:54
Danke euch, es freut mich, dass meine Arbeit jemanden nützlich ist :)

Ja für mich sogar sehr nützlich. Endlich kann ich Node Red als Dashboard nutzen  :)
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

Master_Nick

 :) ;)

Der Marsch von Node-Red ist dank Hexenmeisters Arbeit ein unaufhaltsamer :-)
Rancher K8s Cluster mit nanoCUL (a-culfw) | IObroker | IT(V1&V3), IT-PIR, THGR122NX |Co² | alexa-fhem | WOL | NFC | Harmony UltimateHub | Anwesenheitserkennnung | Roomba | 10" Touch mit Node-Red | SonOff S20 | SonOff Touch | SonOff Dual | Rolladen | Und ganz viel anderes tolles Gerödel.... ;-)

Phantomato

Zitat von: hexenmeister am 01 Mai 2018, 23:22:18
Neue Version mit halbwegs funbktionierenden Wildcards.

Also so wie das hier: *:topic={"/TEST/$reading/set"}

Was an der Stelle ($reading) im Topic gefunden wird, wird als Reading-Name verwendet. Nicht vorhandenen Readings werden ggf. angelegt.

Wie kriegt man das zum laufen???

Bei Eingabe von "defmod mqttGeneric MQTT_GENERIC_BRIDGE" kommt die Meldung:


2018.05.21 20:26:38 1: reload: Error:Modul 10_MQTT_GENERIC_BRIDGE deactivated: Too many arguments for MQTT::parseParams at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 629, near "undef)"
2018.05.21 20:26:38 0: Too many arguments for MQTT::parseParams at ./FHEM/10_MQTT_GENERIC_BRIDGE.pm line 629, near "undef)"
Server: RaspberryPi4 4GB @Raspbian GNU/Linux 10 (buster), Docker, FHEM Docker | Homematic nanoCUL868 (VCCU) | Tasmota Switch & Sensors | Tasmota Zigbee | Zigbee2mqtt | SIGNALduino | Alexa & GoogleHome

hexenmeister

Ich tippe auf veraltete Version von 00_MQTT.pm. Mache ein Update.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Phantomato

#140
Danke. Das war der Grund.

Edit: Hatte leider Zeit nur eine Homematic Steckdose MQTT fähig zu machen und in Node Red einzurichten. Aber es hat sehr gut geklapt. Tolle Arbeit Hexenmeister und vielen Dank dafür  :) :) :) :) :) :) :)
Hoffe das kommt bald als offizielles Fhem Modul :)
Server: RaspberryPi4 4GB @Raspbian GNU/Linux 10 (buster), Docker, FHEM Docker | Homematic nanoCUL868 (VCCU) | Tasmota Switch & Sensors | Tasmota Zigbee | Zigbee2mqtt | SIGNALduino | Alexa & GoogleHome

Klausi

Hallo, liebe MQTT-ler,

ich lese schon einige Zeit in diesem Thread mit, konnte jedoch keine Antwort auf meine Frage herauslesen

"Kann mit dem Modul zwischen 2 Raspberry Pi FHEM-MQTT-Installationen eine Brücke erstellt werden"?

Wenn es möglich ist, wie müssen die define in den jeweiligen FHEM's aussehen?

MMn müsste einer der beiden Raspi die Rolle des Client übernehmen.

Ich habe in den FHEM's die Module "00_MQTT.pm" , "10_MQTT_BRIDGE", "10_MQTT_DEVICE" und
"10_MQTT_GENERIC_BRIDGE" installiert.

Die Publish- und Subscribe-Kommunikation der jeweiligen FHEM-MQTT-Inst. mit ihren Clients (ESP8266) funktioniert wie gewünscht, auch über die  MQTT_GENERIC_BRIDGE.

Besten Dank für Eure Hilfe
Klausi

hexenmeister

Moin!
Man kann auch so eine Art Brücke damit erstellen. Sowohl unidirektional (Server->Client) - indem man an einer Seite 'publish' definiert und an der anderen 'subscribe".
Aber auch biderektional ist möglich - man definiert jeweils beides und unterbindet die Schleifen durch event-on-change. Alles hängt von dem jewiligen Einsatszenario ab.

Grüße
Alexander

Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Klausi

Hallo Alexander,

danke für Deine schnelle Antwort.
Mir genügt eine unidirektionale Verbindung.

Mein Szenario stellt sich wie folgt dar:
Auf der einen Seite entsteht eine Wintergartensteuerung (bisher im Versuchsaufbau) mit kabelgebundenen Sensoren und Aktoren, die über Relais die Steuerung durchführen. An diesen "Wiga-Raspi" ist über mqtt (ESP8266) ein TFT-Display mit touch angeschlossen, auf dem verschiedene Info-Screens erstellt sind.
Die Daten der Sensoren werden auf dem "Sensor-Screen" und die der Aktoren auf dem "Aktor-Screen" angezeigt.

Auf der anderen Seite habe ich in meiner Elektro-Verteilung einen 2.Raspi verbaut, der mir die Daten eines Smart-Meters (Q3D) erfasst.

Ich möchte nun die Daten, die der "Q3D-Raspi" ermittelt, zum "Wiga-Raspi" übertragen, sodass auch diese Daten auf dem TFT-Display auf einem "Q3D-Screen" angezeigt werden.

Ich habe bisher im Q3D-Raspi eine

define Q3D_Meter MQTT_BRIDGE SWU_Q3D
attr Q3D_Meter IODev Mosquitto

definiert, die z.B über


attr publishReading_powerL1   /SWU_Q3D/power_L1

die Leistung  der Phase L1 published.

Das funktioniert, ich sehe zyklisch

transmission-state     outgoing publish sent

und auch in MQTTfx kann ich sehen, dass die Daten published werden.

Im Wiga-Raspi habe ich ein

define Q3D_Meter MQTT_DEVICE
attr Q3D_Meter IODev Mosquitto
attr Q3D_Meter subscribeReading_power /SWU_Q3D/power_L1

erstellt.

Die Daten kommen jedoch nicht im Wiga-Raspi an. Auch wenn ich den Wiga-Raspi mit MQTTfx beobachte sehe ich keine Q3D-Daten.
Wo liegt mein Gedankenfehler?

lg

Klausi

hexenmeister

Hallo Klausi,

in diesem Thread geht es um ein anderes Modul: MQTT_GENERIC_BRIDGE. Du verwendest jedoch konventionelle MQTT_BRIDGE und MQTT_DEVICE. Erstelle ein neues.
Hier nur kurz: Wenn Deine Sendeseite funktioniert, dann muss man natürlich auf der Empfängerseite suchen. Was ich jedoch nicht verstehe, was meinst Du denn mit
ZitatAuch wenn ich den Wiga-Raspi mit MQTTfx beobachte sehe ich keine Q3D-Daten.
Wenn es gesendet wird, dann sind die Daten überall verfübar. Man kann mit einem Client nicht gezielt ein anderes 'beobachten'. Ich vermute, Du hast irgendein Problem mit der Deiner Infrastruktur.
Beschreibe das Problem genau in einem neuen Thread.

Grüße
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Willi66

Hallo Alexander,

vielen herzlichen Dank für Deine Arbeit!
Vor gut einer Woche bin ich über Node-RED gestolpert und war begeistert von der Einfachheit. Bei meiner Recherche hier im Forum bin ich dann auf Dein Modul gestoßen und konnte so auf einen halben Tag ein funktionierendes Dashboard erstellen welches mir in FHEM zu umständlich war. Ich bin Begeistert.

Nochmal vielen Dank und weiter so!

Grüße Willi
RPI3B Buster,  FHEM6.0, ATMEGA2560 MegaCore Firmata, Alexa

WBraun2014

Dem kann ich mich nur anschließen.
Alexander, dein Modul ist Gold wert !

mrbreil

Zitat von: Willi66 am 14 Juni 2018, 14:01:19
Hallo Alexander,

vielen herzlichen Dank für Deine Arbeit!
Vor gut einer Woche bin ich über Node-RED gestolpert und war begeistert von der Einfachheit. Bei meiner Recherche hier im Forum bin ich dann auf Dein Modul gestoßen und konnte so auf einen halben Tag ein funktionierendes Dashboard erstellen welches mir in FHEM zu umständlich war. Ich bin Begeistert.

Nochmal vielen Dank und weiter so!

Grüße Willi
Kannst du bitte mal ein paar Bilder posten.

Gruß Christian


Gesendet von iPhone mit Tapatalk

Willi66

Hallo Christian,

wenn mal alles so läuft wie ich möchte gern. Derzeit komme ich aber auch nicht dazu aber da nötigste funktioniert.

Gruß
Willi
RPI3B Buster,  FHEM6.0, ATMEGA2560 MegaCore Firmata, Alexa

Shojo

Zitat von: mrbreil am 15 Juni 2018, 21:27:00
Kannst du bitte mal ein paar Bilder posten.
Gruß Christian

Ich habe mal ein kleines Video von Steuerung vom Handy gemacht.

https://youtu.be/UuBnA_2GGrs
FHEM auf: Shuttle PC (x64) (Docker)
Bridge: SignalESP 433mHz, ConBee (deCONZ in Docker)
Rest: ESP8266, SONOFF, Sonos, Echo Dot, Xiaomi Vacuum (root), ESP RGBWW Wifi Led Controller, Node-RED, LEDMatrix, Pixel It