Nur ein Device oder Reading sharen/syncen? (MQTT?)

Begonnen von FunkOdyssey, 03 Mai 2020, 20:00:36

Vorheriges Thema - Nächstes Thema

FunkOdyssey

Hallo,
ich würde gerne ein Device meiner FHEM-Installation mit einem fremden FHEM teilen.

Wie könnte man das machen?
Über MQTT-Server und Portfreigabe?
Oder kennt jemand freie MQTT-Server, die man dafür nutzen kann?

Danke.

Gisbert

Hallo FunkOdyessey,

ohne andere Lösungen zu kennen, könnte man mit MQTT arbeiten, und ein Fhem-MQTT-Device kann die infrage kommenden Daten publishen. Die Messages können dann von einem anderen Client empfangen werden.
Die Voraussetzungen sind ein MQTT-Broker oder die in Fhem integrierten MQTT-Module. Wlan als Übertragungsweg wäre auch notwendig.

Vermutlich gibt es auch andere, einfachere Lösungen, die ich aber nicht kenne.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY

Otto123

Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

rudolfkoenig

Vollstaendigkeitshalber: Fuer diesen Zweck kann man auch das "alte" FHEM2FHEM Modul verwenden, allerdings muss man dafuer auf der Senderseite ein Port oeffnen, und eine telnet Instanz anlegen, die man sinnvollerweise mit einem allowed Instanz mit Passwort und Device-Zugriff einschraenkt.


Beta-User

Hier hat jemand berichtet, dass er einen mosquitto im Internet betreibt, vielleicht da mal nachhaken, wie/wo er das gemacht hat.

Eine Variante könnte daher sein, auf beiden Seiten je einen MQTT2_CLIENT mit dem mosquitto "reden zu lassen" und die "ver-MQTT-ung" auf Seiten des zu teilenden Devices als direkte publish-Anweisung über einen Eventhandler wie notify zu lösen. Wenn es schaltbar sein soll oder nicht nur einzelne Devices/Readings betroffen sind, ist es vermutlich am einfachsten, das per MQTT_GENERIC_BRIDGE (in der Installation, in der das zu teilende Device sich befindet) zu machen.

Generell stellt sich hier aber die Frage, inwieweit es dauerhaft gelingt, so einen Server im INet sicher zu betreiben. (Begrenzt man die lokalen Abonnements, ist das kein Problem innerhalb FHEM, aber man muß eben damit rechnen, dass schlecht abgesicherte MQTT-Server ggf. "zugespammt" werden oder mißlaunige Zeitgenossen dieses Einfallstor dazu nutzen, den Server insgesamt in die Knie zu zwingen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

FunkOdyssey

Ich bin auch vorsichtig damit, Server offen über Portfreigaben zu betreiben. Auch wenn es nur der MQTT-Port ist, so weiß ich nicht, ob die Absicherung dahinter dauerhaft gelingt. Egal ob es ein neuer MQTT-Broker im Docker-Container oder der FHEM-Dienst ist. Offen ist offen und das finde ich nicht ganz so glücklich.

Ich hatte die Idee, einige Sensoren mit Bekannten zu teilen.

Auch wenn es dauerhaft instabiler ist und ich mich abhängiger mache, würde ich lieber einen Public MQTT-Dienst nutzen. Dieser vermittelt dann zwischen den Installationen und ich muss keine Ports öffnen. Ich muss nur einen passenden Anbieter finden. Ottos Favorit erlaubt keine kostenfreien Server mehr.

Danke für eure Tipps.

Otto123

Ach schau, out of stock  :o niedliche Katze ausverkauft

Was ich dann machen würde, (wenn es keine anderen Anbieter gibt) einen völlig separaten MQTT selbst in eine DMZ stellen. Der Traffic ist ja gering und die Administration dieser Instanz ist doch überschaubar? Oder ist das zu blauäugig gedacht?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz