MQTT

hexenmeister · 24 Juni 2017, 15:47:04

Wenn ich auf die Schnelle richtig verstanden habe,muss etwas in der Art implementiert werden:


        my $client = IO::Socket::SSL->new(
        # where to connect
        PeerHost => "www.example.com",
        PeerPort => "https",

        # certificate verification - VERIFY_PEER is default
        SSL_verify_mode => SSL_VERIFY_PEER,

        # location of CA store
        # need only be given if default store should not be used
        SSL_ca_path => '/etc/ssl/certs', # typical CA path on Linux
        SSL_ca_file => '/etc/ssl/cert.pem', # typical CA file on BSD

        # or just use default path on system:
        IO::Socket::SSL::default_ca(), # either explicitly
        # or implicitly by not giving SSL_ca_*

        # easy hostname verification
        # It will use PeerHost as default name a verification
        # scheme as default, which is safe enough for most purposes.
        SSL_verifycn_name => 'foo.bar',
        SSL_verifycn_scheme => 'http',

        # SNI support - defaults to PeerHost
        SSL_hostname => 'foo.bar',

    ) or die "failed connect or ssl handshake: $!,$SSL_ERROR";

    # send and receive over SSL connection
    print $client "GET / HTTP/1.0\r\n\r\n";
    print <$client>;

Das müsste dann aber in HttpUtils.pm rein.

eisler · 24 Juni 2017, 16:18:52

Hallo Alexander,

an sowas hatte ich auch gedacht. Vor allem weil andere Module ja auch TLS benötigen. Aber dann eher nicht in
HttpUtils.pm weil Transport ja unter der Anwendungsschicht HTTP liegt und neben HTTP auch für andere Protokolle
verwendet werden kann.

Grüße
Stephan

hexenmeister · 27 Juni 2017, 23:50:17

Ich habe wieder etwas gebastelt... Jetzt mit Moglichkeit, Nachrichten direkt zu publishen:

Code Auswählen

set mqtt publish publish qos:0 retain:1 flur/licht on

Was ist bereits erledigt?
- MQTT_DEVICE: Erweiterung für 'publishSet':
bugfix: senden von beliebigen Werte (ohne Angabe von Wertelisten), auch Zeichenketten mit Leerzeichen
set <device> just a simple Test

feature: Angabe von mehreren Wertelisten gleichzeitig, Unterstützung von FHEM-Extensions ('slider' etc.)
Beispiel:
attr <device> publishSet on off switch:on,off level:slider,0,1,100 /topic/123

#In diesem Fall werden on und off in beim set-Befahl direkt akzeptiert:
set <device> on

#Eigenschaft 'switch' akzeptiert auch on oder off (FHEM-WebUI zeigt eine Auswahlliste):
set <device> switch on

#Eigenschaft 'level' akzeptiert einen Wertebereich von 0 bis 100 (WebUI zeigt einen Schieberegler mit Step 1):
set <device> level 50

- MQTT_DEVICE und MQTT_BRIDGE: Erweiterung für 'retain':
feature: Möglichkeit, Retain-Flag für verschiedene Readings einzeln anzugeben.
Beispiele:
# aus Kompatibilitätsgründen gleiches verhalten, wie bis jetzt, gilt allso für alles
attr <device> retain 0

# hier wird mit * die Default-Vorgabe angegeben, für set ohne Name (publishSet) gilt 1,
# für 'test' (set <device> test XYZ) gilt auch 1.
# Wichtig! Für die per publishSet definierten Namen (publishSet switch:on,off ...)
# müssen ebenso eigenen Angaben gemacht werden, sonst gilt Default-Wert!
attr <device> retain *:0 1 test:1

- MQTT: OnMessageFn: Unterstützung für andere Client-Module außer MQTT_DEVICE und MQTT_BRIDGE
Module müssen dabei eine Funktion zum Verarbeiten von eingehenden Messages anmelden:
$hash->{OnMessageFn} = "MQTT::MYDEVICE::onmessage";

- MQTT: Möglichkeit, MQTT-Nachrichten direkt zu versenden:
set <device> publish publish [qos:?] [retain:?] <topic> <value1> [<value2>]...

Ideen / Was wird möglicherweise noch implementiert?

- MQTT_DEVICE und MQTT_BRIDGE: Erweiterung für 'qos' (auf die gleiche Weise, wie für 'retain')

- MQTT_BRIDGE: subscribeSet / subscribeSet_XXX:
zusätzlich zum Topic kann ein Perl-Ausdruck mitgegeben werden, der beim Empfang ausgewertet wird.
Returnwert entscheidet, ob Reading gesetzt ('true'), oder verworfen wird ('false').
An das auszuwertende Ausdruck sollen folgende Variablen mitübergeben werden: $hash, $name, $topic, $value, $parentname
attr <device> subscribeSet /topic/cmd {if ($value eq "config") fhem("set $parentname getconfig");; 0}

- MQTT: last will: Unterstützung für "last will"-MQTT-Feature:
attr <device> lastWill /topic/status connection lost
last will qos, retain?

- MQTT: onConnect/onDisconnect: Publish on connect/disconnect (Gegenpart zum last will):
attr <device> onConnect /topic/status connected
eventuel auch:
attr <device> onConnect {Perl-Ausdruck} /topic/status connected

- MQTT_DEVICE und MQTT_BRIDGE: Möglichkeit, Readings neu zu versenden:
# bestimmte vorhandene Readings (wieder) versenden
set <device> publishReadings <reading>[,<reading]
# alle bekannten Readings versenden
set <device> publishReadings *

hexenmeister · 30 Juni 2017, 02:02:46

Last will implementiert.

Code Auswählen

attr mqtt last-will /fhem-instanz/status abgestürzt

Was ist bereits erledigt?
- MQTT_DEVICE: Erweiterung für 'publishSet':
bugfix: senden von beliebigen Werte (ohne Angabe von Wertelisten), auch Zeichenketten mit Leerzeichen
set <device> just a simple Test

feature: Angabe von mehreren Wertelisten gleichzeitig, Unterstützung von FHEM-Extensions ('slider' etc.)
Beispiel:
attr <device> publishSet on off switch:on,off level:slider,0,1,100 /topic/123

#In diesem Fall werden on und off in beim set-Befahl direkt akzeptiert:
set <device> on

#Eigenschaft 'switch' akzeptiert auch on oder off (FHEM-WebUI zeigt eine Auswahlliste):
set <device> switch on

#Eigenschaft 'level' akzeptiert einen Wertebereich von 0 bis 100 (WebUI zeigt einen Schieberegler mit Step 1):
set <device> level 50

- MQTT_DEVICE und MQTT_BRIDGE: Erweiterung für 'retain':
feature: Möglichkeit, Retain-Flag für verschiedene Readings einzeln anzugeben.
Beispiele:
# aus Kompatibilitätsgründen gleiches verhalten, wie bis jetzt, gilt allso für alles
attr <device> retain 0

# hier wird mit * die Default-Vorgabe angegeben, für set ohne Name (publishSet) gilt 1,
# für 'test' (set <device> test XYZ) gilt auch 1.
# Wichtig! Für die per publishSet definierten Namen (publishSet switch:on,off ...)
# müssen ebenso eigenen Angaben gemacht werden, sonst gilt Default-Wert!
attr <device> retain *:0 1 test:1

- MQTT: OnMessageFn: Unterstützung für andere Client-Module außer MQTT_DEVICE und MQTT_BRIDGE
Module müssen dabei eine Funktion zum Verarbeiten von eingehenden Messages anmelden:
$hash->{OnMessageFn} = "MQTT::MYDEVICE::onmessage";

- MQTT: Möglichkeit, MQTT-Nachrichten direkt zu versenden:
set <device> publish publish [qos:?] [retain:?] <topic> <value1> [<value2>]...

- MQTT: last will: Unterstützung für "last will"-MQTT-Feature:
attr <device> last-will [qos:?] [retain:?] <topic> <value1> [<value2>]...
Beispiel: attr mqtt last-will /fhem-instanz/status abgestürzt

Ideen / Was wird möglicherweise noch implementiert?

- MQTT_DEVICE und MQTT_BRIDGE: Erweiterung für 'qos' (auf die gleiche Weise, wie für 'retain')

- MQTT_BRIDGE: subscribeSet / subscribeSet_XXX:
zusätzlich zum Topic kann ein Perl-Ausdruck mitgegeben werden, der beim Empfang ausgewertet wird.
Returnwert entscheidet, ob Reading gesetzt ('true'), oder verworfen wird ('false').
An das auszuwertende Ausdruck sollen folgende Variablen mitübergeben werden: $hash, $name, $topic, $value, $parentname
attr <device> subscribeSet /topic/cmd {if ($value eq "config") fhem("set $parentname getconfig");; 0}

- MQTT: onConnect/onDisconnect/onTimeout: Publish on connect/disconnect (Gegenpart zum last will):
attr <device> onConnect /topic/status connected
eventuel auch:
attr <device> onConnect {Perl-Ausdruck} /topic/status connected

- MQTT_DEVICE und MQTT_BRIDGE: Möglichkeit, Readings neu zu versenden:
# bestimmte vorhandene Readings (wieder) versenden
set <device> publishReadings <reading>[,<reading]
# alle bekannten Readings versenden
set <device> publishReadings *

hexenmeister · 04 Juli 2017, 22:58:25

on-connect, on-disconnect, on-timeout hinzugefügt

Was ist bereits erledigt?
- MQTT_DEVICE: Erweiterung für 'publishSet':
bugfix: senden von beliebigen Werte (ohne Angabe von Wertelisten), auch Zeichenketten mit Leerzeichen
set <device> just a simple Test

feature: Angabe von mehreren Wertelisten gleichzeitig, Unterstützung von FHEM-Extensions ('slider' etc.)
Beispiel:
attr <device> publishSet on off switch:on,off level:slider,0,1,100 /topic/123

#In diesem Fall werden on und off in beim set-Befahl direkt akzeptiert:
set <device> on

#Eigenschaft 'switch' akzeptiert auch on oder off (FHEM-WebUI zeigt eine Auswahlliste):
set <device> switch on

#Eigenschaft 'level' akzeptiert einen Wertebereich von 0 bis 100 (WebUI zeigt einen Schieberegler mit Step 1):
set <device> level 50

- MQTT_DEVICE und MQTT_BRIDGE: Erweiterung für 'retain':
feature: Möglichkeit, Retain-Flag für verschiedene Readings einzeln anzugeben.
Beispiele:
# aus Kompatibilitätsgründen gleiches verhalten, wie bis jetzt, gilt allso für alles
attr <device> retain 0

# hier wird mit * die Default-Vorgabe angegeben, für set ohne Name (publishSet) gilt 1,
# für 'test' (set <device> test XYZ) gilt auch 1.
# Wichtig! Für die per publishSet definierten Namen (publishSet switch:on,off ...)
# müssen ebenso eigenen Angaben gemacht werden, sonst gilt Default-Wert!
attr <device> retain *:0 1 test:1

- MQTT: OnMessageFn: Unterstützung für andere Client-Module außer MQTT_DEVICE und MQTT_BRIDGE
Module müssen dabei eine Funktion zum Verarbeiten von eingehenden Messages anmelden:
$hash->{OnMessageFn} = "MQTT::MYDEVICE::onmessage";

- MQTT: Möglichkeit, MQTT-Nachrichten direkt zu versenden:
set <device> publish publish [qos:?] [retain:?] <topic> <value1> [<value2>]...

- MQTT: last will: Unterstützung für "last will"-MQTT-Feature:
attr <device> last-will [qos:?] [retain:?] <topic> <value1> [<value2>]...
Beispiel: attr mqtt last-will /fhem-instanz/status abgestürzt

- MQTT: bugfix: set connect hat im Falle einer bestehenden Verbindung diese hard abgebrochen und neu angelegt, was zum publishen von Last-Will geführt hat

- MQTT: onConnect/onDisconnect: Publish on connect/disconnect (Gegenpart zum last will) und/oder Auswertung einer Expression
attr <device> on-connect /topic/status connected
attr <device> on-connect {Perl-Ausdruck} /topic/status connected
Falls eine Perl-Expression mitangegeben wird, wird das eventuell vorhandene Message nur gesendet, wenn Expression true (z.B. 1) oder undef liefert.
Beipiel:
attr mqtt on-connect {Log3("abc",1,"on-connect")} /fhem-test connected
attr mqtt on-disconnect {Log3("abc",1,"on-disconnect")} /fhem-test disconnected
attr mqtt on-connect {$a>$b?1:0} /fhem-test sende nur, wenn a>b

onTimeout: Auswertung einer Expression beim Timeout

Ideen / Was wird möglicherweise noch implementiert?

- MQTT_DEVICE und MQTT_BRIDGE: Erweiterung für 'qos' (auf die gleiche Weise, wie für 'retain')

- MQTT_BRIDGE: subscribeSet / subscribeSet_XXX:
zusätzlich zum Topic kann ein Perl-Ausdruck mitgegeben werden, der beim Empfang ausgewertet wird.
Returnwert entscheidet, ob Reading gesetzt ('true'), oder verworfen wird ('false').
An das auszuwertende Ausdruck sollen folgende Variablen mitübergeben werden: $hash, $name, $topic, $value, $parentname
attr <device> subscribeSet /topic/cmd {if ($value eq "config") fhem("set $parentname getconfig");; 0}

- MQTT_DEVICE und MQTT_BRIDGE: Möglichkeit, Readings neu zu versenden:
# bestimmte vorhandene Readings (wieder) versenden
set <device> publishReadings <reading>[,<reading]
# alle bekannten Readings versenden
set <device> publishReadings *

klausw · 07 Juli 2017, 18:32:55

Zitat von: eisler am 24 Juni 2017, 16:18:52
an sowas hatte ich auch gedacht. Vor allem weil andere Module ja auch TLS benötigen. Aber dann eher nicht in
HttpUtils.pm weil Transport ja unter der Anwendungsschicht HTTP liegt und neben HTTP auch für andere Protokolle
verwendet werden kann.

HTTPS ist im HttpUtils.pm Modul bereits vorhanden.
Beispielsweise das Calendar Modul nutzt es schon.
Es kann sein, das es nur ein Problem mit dem Port gibt.
In Zeile 249 der HttpUtils.pm sind die Ports fest eingestellt:

Code Auswählen

$port = ($hash->{protocol} eq "https" ? 443: 80);

Aber wenn ich das richtig sehe wird die HttpUtils.pm vom MQTT Modul gar nicht genutzt, oder?

Grüße
Klaus

hexenmeister · 07 Juli 2017, 19:02:47

Wenn ich das richtig sehe, wird schon indirekt benutzt.
Die Probleme sind nicht nur Port, vor allem auch die Zertifikate und die Tatsache, dass alle mögliche embeddet Devices z. B . basiert auf ESP, können auch kein Https. Dann nutzt die Unterstützung an einer Stelle auch nicht mehr. Oder irre ich mich?

klausw · 07 Juli 2017, 20:00:04

Ich weiss nicht wie die SSL Bibliothek das macht, aber die Zertifikatsüberprüfung kann man ja weglassen.
Das Zertifikat selbst wird ja vom Mqtt Server bereit gestellt.
Und eben dieser kann ja beides. Eine unverschlüsselte Verbindung und auf einem zweiten Port eine TLS verschlüsselte Verbindung.
Daher kann der ESP sich auch unverschlüsselt verbinden (aber kann die ESP Mqtt Bibliothek nicht sogar TLS) und andere Systeme die nicht im lokalen Netz sind nutzen die Verschlüsselung.

Gesendet von meinem HTC One mit Tapatalk

hexenmeister · 07 Juli 2017, 20:06:14

Soweit ich weiß, kann man Zertifikat nur weglassen, wenn dieser von einer vertrauenswürdigen Stelle ausgestellt worden ist. Evtl. kann im Betriebssystem eigene Zertifikate bekannt machen.
Was für Sicherheitgewinn hat man, wenn man beides erlaubt? Dann kann man doch die Verschlüsselung gleich sparen, oder sehe ich das falsch?

PatrickR · 07 Juli 2017, 21:25:03

Mahlzeit!

Zitat von: hexenmeister am 07 Juli 2017, 19:02:47
Die Probleme sind nicht nur Port, vor allem auch die Zertifikate und die Tatsache, dass alle mögliche embeddet Devices z. B . basiert auf ESP, können auch kein Https. Dann nutzt die Unterstützung an einer Stelle auch nicht mehr. Oder irre ich mich?

Falls Du MQTT über TLS meinst: Die ESPs können das und sogar ausgesprochen gut.* Mein Staubsaugerroboter kommuniziert vollverschlüsselt mit dem mosquitto, nur FHEM (noch) nicht.

Zitat von: hexenmeister am 07 Juli 2017, 20:06:14
Soweit ich weiß, kann man Zertifikat nur weglassen, wenn dieser von einer vertrauenswürdigen Stelle ausgestellt worden ist. Evtl. kann im Betriebssystem eigene Zertifikate bekannt machen.
Was für Sicherheitgewinn hat man, wenn man beides erlaubt? Dann kann man doch die Verschlüsselung gleich sparen, oder sehe ich das falsch?

Das ist 100% korrekt. Wenn ich jedes Zertifikat akzeptiere wird MITM nicht verhindert. Wenn man sich den Aufwand mit den Zertifikaten sparen möchte kann man einfach den TLS Fingerprint des Servers in FHEM hinterlegen. So ist es bspw. in den mir bekannten Implementierungen auf den ESPs gelöst, da es schlichtweg viel Aufwand spart, u. a. das Verifizieren einer ganzen Kette von Zertifikaten bis zu einer vertrauenswürdigen CA.

Patrick

* https://hackaday.io/project/12482-garage-door-opener/log/45617-connecting-the-esp8266-with-tls

Tobias · 11 Juli 2017, 14:46:31

Hi,
ich suche ein Beispiel was in in FHEM anlegen muss damit mein Topic "outTopic" in FHEM als Reading angelegt und aktualisiert wird.
Ein "define MQTT MQTT localhost 1883" habe ich schon gemacht und es ist connected. Aber was nun= Was ist der UNterschied ztwischen MQTT_Bridge und MQTT_DEVICE? was brauche ich? Das WIki mit den 3 Teilen habe ich schon durch, habe aber auch dort keine Antwort gefunden

hexenmeister · 11 Juli 2017, 14:59:15

Bridge verbindet ein existierendes device (z. B. Homematic etc.) mit der mqtt-welt. Bridge spiegelt die Zustände des Gerätes nach außen per mqtt und empfängt von dort auch welche zurück.
Ein DEVICE ist ein Endepunkt in fhem, der auf ankommende messages reagiert (setzt readings) und auch messages senden kann.
Ich verbinde z. B. mehrere fhem Instanzen per mqtt. An einer stelle ist die mqttbridge, auf der anderen - mgttdevice.

Tobias · 11 Juli 2017, 15:09:13

danke, das hat geholfen. Dein Beispiel würde ja bedeutetn, das FEHM2FHEM obsolet wäre..??

hexenmeister · 11 Juli 2017, 15:23:31

Hm, obsolet mag ich nicht zu beurteilen. Für mich jedoch schon. Ich habe schon eh mehrere MQTT-basierte Devices (ESPEasy) und stelle nach und nach alles auf MQTT um.

Beispiele (alles nicht der Wahrheit letzter Schluss, ich bin noch daran, für mich den 'Optimum' zu finden, schraube auch parallel an MQTT-Module rum):

Bridge für ein EnOcean-Dimmer:

Code Auswählen

define MB_DG_WZ_DA_Licht_Ost MQTT_BRIDGE DG_WZ_DA_Licht_Ost
attr MB_DG_WZ_DA_Licht_West IODev mqtt
attr MB_DG_WZ_DA_Licht_West group Wohnzimmer
attr MB_DG_WZ_DA_Licht_West publishReading_dim /ha/dg/wz/licht/ost/level
attr MB_DG_WZ_DA_Licht_West publishState /ha/dg/wz/licht/ost/state
attr MB_DG_WZ_DA_Licht_West room MQTT
attr MB_DG_WZ_DA_Licht_West stateFormat transmission-state
attr MB_DG_WZ_DA_Licht_West subscribeSet /ha/dg/wz/licht/ost/set

MQTT-Device an dem anderen Ende:

Code Auswählen

define MQ_DG_WZ_Licht_Ost MQTT_DEVICE
attr MQ_DG_WZ_Licht_Ost IODev mqtt
attr MQ_DG_WZ_Licht_Ost devStateIcon off:light_light_dim_00@gray 0:light_light_dim_00@gray dark:light_light_dim_10@yellow \d:light_light_dim_10@yellow 1\d:light_light_dim_20@yellow 2\d:light_light_dim_30@yellow 3\d:light_light_dim_40@yellow 4\d:light_light_dim_50@yellow 5\d:light_light_dim_60@yellow half:light_light_dim_60@yellow 6\d:light_light_dim_70@yellow 7\d:light_light_dim_80@yellow bright:light_light_dim_80@yellow 8\d:light_light_dim_90@yellow 9\d:light_light_dim_100@yellow 100:light_light_dim_100@yellow on:light_light_dim_100@yellow .*:hourglass
attr MQ_DG_WZ_Licht_Ost eventMap on:on 70:bright 40:half 13:dark off:off
attr MQ_DG_WZ_Licht_Ost group Beleuchtung
attr MQ_DG_WZ_Licht_Ost mqttDeviceType dimmer
attr MQ_DG_WZ_Licht_Ost publishSet on off switch:on,off level:slider,0,1,100 /ha/dg/wz/licht/ost/set
attr MQ_DG_WZ_Licht_Ost room Wohnzimmer_DG
attr MQ_DG_WZ_Licht_Ost stateFormat level
attr MQ_DG_WZ_Licht_Ost subscribeReading_level /ha/dg/wz/licht/ost/level
attr MQ_DG_WZ_Licht_Ost subscribeReading_state /ha/dg/wz/licht/ost/state
attr MQ_DG_WZ_Licht_Ost webCmd on:bright:half:dark:off:level

hexenmeister · 11 Juli 2017, 15:28:48

Das schöne an MQTT, man so sehr vieles miteinander integrieren, nicht nur FHEM, sondern auch ggf. andere Automatisierungs-Server etc. Ich nutze u.A. NodeRED, viel Logik würde ich da nicht machen (Übersicht geht schnell verloren), aber für manche Sachen (z.B. Licht-Szenen) ist das Tool echt gut.