MQTT

[Billy]

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.

Kann ich bestätigen, ging mir genauso!

Mal eine Frage, wäre es nicht sinnvoll diesen ganzen hervorragenden thread nach
--> FHEM Forum » FHEM - Hausautomations-Systeme » MQTT
zu verschieben wenn es schon diesen Oberbegriff gibt?
https://forum.fhem.de/index.php/board,94.0.html --> MQTT Themen zu MQTT.

Gruß Billy

[hexenmeister]

Sinnvoll wäre das

[Billy]

Sinnvoll wäre das

Und wer kann das machen?

[hexenmeister]

Entweder der Threadersteller oder der Moderator.

[PatrickR]

Oha! War in meinem jugendlichen Leichtsinn davon ausgegangen, dass es sich bei MQTT_BRIDGE um eine MQTT-Bridge handelt und hatte es mir garnicht angesehen. Jetzt steht es oben auf der Liste


Von unterwegs gesendet.

[slor]

Hallo Hexenmeister,
danke für das Weiterentwickeln des Moduls.
Ich hätte noch einen Wunsch für MQTT_Device:
Könnte man ein spezielles Device für die Sonoff Geräte mit Tasmota Firmware entwickeln?
Da könnten dann automatisch die richtigen Attribute, Subscriptions, WebCMD, Switches etc anlegen. Wie z.B. bei den Homematic Geräten. Da wird ja auch abhängig vom Gerät einiges automatisch definiert.
Die Sonoff Schalter mit Tasmota Software scheinen ja doch sehr verbreitet zu sein, dass sich hier eine Extra Wurst bestimmt lohnen würde.

Aktuell ist das doch sehr viel manuelle Arbeit und rum-geteste, bis es sauber läuft.

[hexenmeister]

Moin!
Kann man natürlich schon, habe sogar schon etwas in der Art überlegt (nicht unbedingt Tasmota, da keine im Einsatz). Problem besteht gerade mit der freien Zeit, ich muss erstmal das zu Ende bringen, was schon geplant ist.
Zum eigentlichen Frage: hier bin ich mir noch nicht sicher, was sinniger ist, eine Art automatisches Device, ein Template, eine Wiki-Anleitung...

[hexenmeister]

wieder etwas weiter implementiert...



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.
              An das auszuwertende Ausdruck sollen folgende Variablen mitübergeben werden: $hash, $name, $qos, $retain, $topic, $message
              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
             
- MQTT_DEVICE: subscribeReadings:
              Perl-Ausdruck, der beim Message-Empfang ausgewertet wird. Unterstützung für QOS- und RETAIN-Flags (optional)
              attr <device> subscribeReading_<reading> [{Perl-Ausdruck}] [qos:?] [retain:?] <topic>
              An das auszuwertende Ausdruck werden folgende Variablen mitübergeben: $hash, $name, $topic, $message
              Returnwert entscheidet, ob Reading gesetzt (true (z.B. 1) oder undef), oder verworfen wird (false (z.B. 0)).
              Beispiel:
              attr DEVICE subscribeReading_cmd {fhem("attr DEVICE verbose 1")} /topic/cmd
             
- MQTT_BRIDGE: subscribeSet / subscribeSet_XXX:
              Zusätzlich zum Topic kann ein Perl-Ausdruck mitgegeben werden, der beim Message-Empfang ausgewertet wird. Unterstützung für QOS- und RETAIN-Flags (optional)
              attr <device> subscribeSet[_reading] [{Perl-Ausdruck}] [qos:?] [retain:?] <topic>
              An das auszuwertende Ausdruck werden folgende Variablen mitübergeben: $hash, $name, $topic, $message, $devname (linked device)
              Returnwert entscheidet, ob Reading gesetzt (true), oder verworfen wird (false).
              Beispiel:
              attr DEVICE subscribeSet_cmd {if ($message eq "config") fhem("set $devname getconfig");; 0} /topic/cmd


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_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]

Heute keine neuen Features, aber schon mal den Commandref entsprechend erweitert.

[Tobias]

Super
checkst du Sie noch ein oder muss ich manuell ersetzen?

[eisler]

Aktuell manuell ersetzen. Offizielles checkin kommt.

Grüße
Stephan

[hexenmeister]

Aktuell möchte ich noch eine Feature fertig stellen und etwas mehr testen. Dann könnten die Module übernommen werden 

[eisler]

passt für mich. Einfach kurz Bescheid geben.

Grüße
Stephan

[hexenmeister]

Habe jetzt QOS-Attribut implementiert, kleine Bugs ausgemerzt, Doku-Reste geschrieben und rumgetestet. Bei mir funktioniert alles. So kann das meiner Meinung nach eingecheckt werden. Wäre natürlich trotzdem gut, wenn noch weitere Nutzer eigene Szenarien durchtesten.

[kumue]

moin, habe die Module frisch installiert und bekomme im Log die Meldung

Code Auswählen Erweitern

2017.08.24 06:23:31 1: PERL WARNING: Use of uninitialized value $msg{"qos"} in numeric eq (==) at ./FHEM/00_MQTT.pm line 567.