MQTT

[eisler]

ist nicht ganz der Patch geworden aber das Problem sollte mit aktuellem update gelöst sein:

Code Auswählen Erweitern

define <name> MQTT <ip:port> [<username>] [<password>]

Grüße
Stephan

[klausw]

Super, da kann ich das jetzt aus der Ignoreliste rausnehmen.
Planst du zufällig auch TLS/SSL einzubauen? 

[eisler]

TLS/SSL steht auf meiner MQTT Todo Liste. 

Grüße
Stephan

[PatrickR]

Prima!


Von unterwegs gesendet.

[klausw]

Hi Stephan,

ich hatte ganz vergessen das Modul 00_MQTT.pm aus "excludefromupdate" rauszunehmen.
Jetzt habe ich mir die aktuelle Variante per update geholt.
Leider startet nun FHEM nicht mehr.
Die letzte Zeile im Log beim Startversuch ist:

Code Auswählen Erweitern

Undefined subroutine &MQTT::BRIDGE::client_attr called at ./FHEM/10_MQTT_BRIDGE.pm line 165, <$fh> line 1076.

Seltsamerweise bezieht sich das auf das Brigde Modul.
Allerdings funktionierte MQTT vor dem Update fehlerfrei (die user, passwort Geschichte hatte ich händisch eingebaut)

Grüße
Klaus

PS: ich habe NET::MQTT:SIMPLE installiert, was aber bisher problemlos funktionierte

[eisler]

Hallo Klaus,

die "Undefined subroutine &MQTT::BRIDGE::client_attr" kommt aus dem 00_MQTT.pm Modul.

"NET::MQTT:SIMPLE" sollte nicht benötigt werden.

kannst du prüfen ob das 00_MQTT.pm Modul bei dir ok ist?

Grüße
Stephan

[klausw]

Ich meine, dass ich nur Net::MQTT::Simple installiert haben. Wenn ich das richtig verstanden habe ist das eine abgespeckte Version von Net::MQTT.

Es funktioniert jetzt wieder.
Das Problem war, das nach dem Updaten von 00_MQTT.pm user und passwort nicht mehr in der Definition waren (bei meiner Modulanpassung hatte ich die direkt mit im define stehen).
Ein neues Eintragen half auch nicht.
Also habe ich das define gelöscht und neu angelegt.
Dadurch stand es am Ende des Configfiles und wurde erst nach den MQTT Bridges, etc. geladen. Das hat vermutlich zu diesem Fehler geführt. Denn nachdem ich es im Config File wieder vor die MQTT Devices gesetzt hatte lief es.

Evtl. lässt sich das noch abfangen (mit eval oder so). Es ist nicht gut, wenn ein Modul das ganze FHEM abschießen kann.

[bugster_de]

Hi,

ich nutze MQTT_DEVICE aber ich komme bei den Einstellungen für publishSet nicht weiter. Mein Arduino basierter MQTT versteht die Kommandos "on", "off" oder eine beliebige Zahl (z.B. 5).
Wenn ich das publishSet wie folgt definiere

Code Auswählen Erweitern

attr Wasserventil1 publishSet on off 5 15 30 Garden/Valve/1/set
dann kann ich

Code Auswählen Erweitern

set Wasserventil1 on
set Wasserventil1 off
set Wasserventil1 5
set Wasserventil1 15
set Wasserventil1 30
machen. Geht.

wenn ich aber

Code Auswählen Erweitern

set Wasserventil1 7
mache dann kommt

Code Auswählen Erweitern

Unknown argument 7, choose one of 15 30 5 off on

Aber wie muß ich das publishSet definieren, damit ich jede beliebige Zahl sowie on und off setzen kann?


Anwendungsfall (zur Erklärung)
ich habe im Keller einen Arduino, der die Ventile meiner Gartenbewässerung steuert. Das war bisher auf einem proprietären Protokoll via TCP/IP und eine selbstgeschriebenen Modul in FHEM realisiert. Das hat immer wieder zu Problemen geführt, weshalb ich den Arduino jetzt auf MQTT umgebaut habe.
Der Arduino hat eine Art Zeitschaltuhr pro Ventil: nach Ablauf einer Zeit schliesst er das Ventil wieder. Und die Zahlen oben sind die Zeit in Minuten (also 5 = 5 Minuten Laufzeit). Somit versuche ich zu vermeiden, dass FHEM das Ventil auf On setzt und sich dann ggf. aufhängt oder mein Skript sich verlaufen hat bevor er irgendwann das Off Signal sendet, womit mein Garten unter Wasser wäre. Auch eine eventuell defekte Wasserleitung im Keller führt nicht dazu, dass das Haus stundenlang mit Wasser geflutet wird. Ich bin da aus historischer Erfahrung etwas paranoid. Bitte also keine Diskussionen, ob das sinnvoll ist. Ich will es genau so haben

[bugster_de]

Hi,

ich nutze MQTT_DEVICE aber ich komme bei den Einstellungen für publishSet nicht weiter. Mein Arduino basierter MQTT versteht die Kommandos "on", "off" oder eine beliebige Zahl (z.B. 5).
Wenn ich das publishSet wie folgt definiere

Code Auswählen Erweitern

attr Wasserventil1 publishSet on off 5 15 30 Garden/Valve/1/set
dann kann ich

Code Auswählen Erweitern

set Wasserventil1 on
set Wasserventil1 off
set Wasserventil1 5
set Wasserventil1 15
set Wasserventil1 30
machen. Geht.

wenn ich aber

Code Auswählen Erweitern

set Wasserventil1 7
mache dann kommt

Code Auswählen Erweitern

Unknown argument 7, choose one of 15 30 5 off on

Aber wie muß ich das publishSet definieren, damit ich jede beliebige Zahl sowie on und off setzen kann?


Anwendungsfall (zur Erklärung)
ich habe im Keller einen Arduino, der die Ventile meiner Gartenbewässerung steuert. Das war bisher auf einem proprietären Protokoll via TCP/IP und eine selbstgeschriebenen Modul in FHEM realisiert. Das hat immer wieder zu Problemen geführt, weshalb ich den Arduino jetzt auf MQTT umgebaut habe.
Der Arduino hat eine Art Zeitschaltuhr pro Ventil: nach Ablauf einer Zeit schliesst er das Ventil wieder. Und die Zahlen oben sind die Zeit in Minuten (also 5 = 5 Minuten Laufzeit). Somit versuche ich zu vermeiden, dass FHEM das Ventil auf On setzt und sich dann ggf. aufhängt oder mein Skript sich verlaufen hat bevor er irgendwann das Off Signal sendet, womit mein Garten unter Wasser wäre. Auch eine eventuell defekte Wasserleitung im Keller führt nicht dazu, dass das Haus stundenlang mit Wasser geflutet wird. Ich bin da aus historischer Erfahrung etwas paranoid. Bitte also keine Diskussionen, ob das sinnvoll ist. Ich will es genau so haben

[dev0]

ich nutze, wie auch viele andere, MQTT zusammen mit Sonoff und AhrendSt's sketch.
Nun hat ahrendst die Kommunikation auf JSON umgestellt: https://forum.fhem.de/index.php/topic,60336.msg578102.html#msg578102
Freundlicherweise hat dev(0) ein handler geschrieben, der auf Basis von notify eine Umsetzung macht. https://forum.fhem.de/index.php/topic,66761.0.html

Ich habe mir erlaubt, das Modul MQTT_DEVICE um JSON zu erweitern.

@Entwickler
Vielleicht könntet Ihr mal mein Modul ansehen und ggf den Code übernehmen.

Es ist genrell lobenswert sich an der FHEM Entwicklung zu beteiligen. Wenn Du Änderungen an einem bestehenden Modul einbringen möchtest, dann siehe How to write a patch. Ein modifiziertes Modul, mit identischen Namen, im Forum bereitzustellen kann, für den Modul Maintainer, zusätzlichen Supportaufwand bedeuten, wenn es zu Problemen kommt.

Inhaltlich ist die Umsetzung leider auch mangelhaft, da
- Anwerder, die kein JSON Perl Modul installiert haben, dauerhaft Warnungen erhalten.
- nicht jeder Anwender die Key:Value eines empfangenen JSON String in Readings benötigt oder haben möchte.
- EDIT: alle empfangenen Werte, die keinen JSON String enthalten, eine Warnung Perl erzeugen.

Nebenbei angemerkt lautet mein Benutzername in diesem Forum dev0 und nicht dev(0).

[ZeitlerW]

Hallo dev0,

da ich mich nicht wirklich mit perl auskenne, habe ich mit meinen Mitteln versucht, eine Verbesserung zu realisieren.

Nachdem dies mangelhaft zu sein scheint, ziehe ich den code natürlich zurück.

vG
Wolfgang

[Bapt. Reverend Magersuppe]

Wird denn das MQTT-Modul noch weiterentwickelt?

[hexenmeister]

Wird denn das MQTT-Modul noch weiterentwickelt?

hoffentlich bald wieder
Es wurden schon Bugs und Verbesserungsvorschläge hier im Forum berichtet.

[Reinhart]

Inhaltlich ist die Umsetzung leider auch mangelhaft, da
- Anwerder, die kein JSON Perl Modul installiert haben, dauerhaft Warnungen erhalten.
- nicht jeder Anwender die Key:Value eines empfangenen JSON String in Readings benötigt oder haben möchte.
- EDIT: alle empfangenen Werte, die keinen JSON String enthalten, eine Warnung Perl erzeugen.

Hallo dev0!

Danke dass du dir Gedanken machst und das angesehen hast!
Aus Sicht des Anwenders ist das eine große Erleichterung zur Handhabung mit den Sonoff Modulen. Ich finde die Idee von Wolfgang, deinen Code in das Modul zu integrieren ja generell gut weil der notify somit gänzlich wegfällt und alles auf einem Platz sitzt, aber auf der anderen Seite sollte man deine bemängelten Punkte sehr wohl berücksichtigen. Ich sehe es von dir auch als konstruktive Kritik über die man diskutieren sollte.

Ich fände es nun als gute Lösung, wenn man nun beide Ideen zusammen fassen könnte und durch zB. Prüfungen ob das JSON Perl Modul installiert ist zu erweitern, bzw. die JSON Umsetzung durch einen Parameter schaltbar machen könnte. Aber als nicht Perl Programmierer möchte ich mich da zur Umsetzung nicht einmischen weil ich das leider nicht genau beurteilen kann.

Jeder von euch hat Zeit investiert und es wäre schade solch guten Ideen im Sand verlaufen zu lassen. Dein Modul funktioniert ja prima und die Idee der Integration sehe ich als Steigerung des Komforts. Ich habe das erweiterte Modul von Wolfgang bei mir installiert weil alle von dir bemängelten Voraussetzungen bei mir ja gegeben sind und es stellt für mich momentan die Beste Lösung der Problematik JSON und Sonoff dar.

LG
Reinhart

[dev0]

Ich finde die Idee von Wolfgang, deinen Code in das Modul zu integrieren ja generell gut

Finde ich auch ok, deshalb habe ich auch aufs Wiki verwiesen, wie man dabei vorgehen sollte. Es lag auch nicht in meiner Absicht, dass der Beitrag mit dem Feaurewunsch gelöscht wird.

Vielleicht solltet Ihr aber erst einmal mit dem Maintainer klären, ob so etwas überhaupt, in das bisher sehr leichtgewichtige Modul, einfließen könnte. Eine neue Abhängigkeit zu einem Perl Modul kann bei vielen Anwendern auch zu Frust führen. Wobei das aber auch anders zu lösen wäre...