Hallo,
ich mag es, wenn meine Automatisierungssysteme miteinander reden. Idealerweise können die alle AMQP oder MQTT, und RabbitMQ kann beides.
FHEM hat MQTT. Das ist gut. Beispiel-Konfigs hat es nicht, das finde ich weniger gut.
Mein erstes Ziel ist es, via MQTT+FHEM+CUL ein paar FHT-Ventilen zu sagen, wie weit sie aufmachen sollen.
Findet sich dazu eine Beispielanwendung? Irgendwer muss es ja mal für sinnvoll erachtet haben, den MQTT-Konnektor zu schreiben ...
Norbert (ntruchsess) hat mal MQTT-Connector geschrieben um MySensors-MQTT-Gateway zu unterstützen.
Ankündigungsthema gefunden:
http://forum.fhem.de/index.php/topic,27532.15.html (http://forum.fhem.de/index.php/topic,27532.15.html)
(Praktischerweise darf ich da keine Antwort schreiben)
Was mir fehlt: Username+Passwort für den Broker. Meinen kann ich nicht einfach offen rumliegen lassen.
Habe Deine Anfrage dort platziert: http://forum.fhem.de/index.php/topic,27532.msg249337.html#msg249337
Gibt es schon etwas neues für den Username+Passwort Request für den Broker? Würde auch gerne RabbitMQ mit Autorisierung verwenden.
Vielen Dank.
Alles muss man selber machen ... 8)
Patch im Anhang. Getestet. Jemand mit Schreibrechten importiere dies bitte ins CVS.
NB: das MQTT-Modul müllt den Server zu, wenn der die Verbindung gleich wieder schließt, z.B. weil das Passwort fehlt oder falsch ist.
Das sollte jemand mit weniger rostigen Perlkenntnissen als ich gelegentlich beheben.
Hi, ich bin gerade hierauf gestoßen.
Ist es mögliche ALLE FHEM-Events in die Queue zu pumpen und alle Ereignisse aus der Queue in FHEM-Kommandos umzusetzen.
Also den gesamten FHEM-Verkehr bidirektional mit der Queue verknüpfen.
Ich würde darüber gerne eine Anbindung an openhab realisieren....
Thanks!
dero
Zitat von: smurfix am 22 Februar 2015, 00:01:14
NB: das MQTT-Modul müllt den Server zu, wenn der die Verbindung gleich wieder schließt, z.B. weil das Passwort fehlt oder falsch ist.
Das sollte jemand mit weniger rostigen Perlkenntnissen als ich gelegentlich beheben.
Gute Arbeit smurfix! Ich habe den Patch getestet - funktioniert einwandfrei. Kann das bitte jemand commiten? ntruchsess scheint gerade indisponiert zu sein...
Danke!
Leider wurde die Unterstützung von Benutzername+Passwort wohl nicht umgesetzt. Dankenswerterweise gibt es ja ein paar Posts weiter oben einen Patch, der diese Funktionalität nachrüstet. Vielen Dank dafür.
Nur muss ich jetzt mal blöd fragen: Wie installiere ich den Patch? Meine Suche diesbezüglich war leider erfolglos.
Danke und Gruß
Wolle
Zitat von: Wolle02 am 14 Januar 2016, 19:12:26
Leider wurde die Unterstützung von Benutzername+Passwort wohl nicht umgesetzt. Dankenswerterweise gibt es ja ein paar Posts weiter oben einen Patch, der diese Funktionalität nachrüstet. Vielen Dank dafür.
Nur muss ich jetzt mal blöd fragen: Wie installiere ich den Patch? Meine Suche diesbezüglich war leider erfolglos.
Danke und Gruß
Wolle
Hallo,
dafür gibt es Editoren, die das können sollen. Anbei das gepatche Modul. Bitte das Modul dann vom Update ausnehmen. Sonst wird es wieder überschrieben.
Grüße Jörg
Da gibt es ein Programm für. Heißt "patch".
Leider kann ein Online-Update jederzeit deine Änderung wieder wegpflügen, wenn du die aktiviert hast.
SVN ist gefühlte Steinzeit und der Updatemechanismus von FHEM auch. :-\
Vielen Dank für die Erklärungen und für das bereits gepachte Modul. :)
Gruß
Wolle
ZitatSVN ist gefühlte Steinzeit und der Updatemechanismus von FHEM auch.
Erfahrene Entwickler sind immer willkommen.
Zitat von: rudolfkoenig am 14 Januar 2016, 21:12:35
Erfahrene Entwickler sind immer willkommen.
Manchmal passen Arbeitsstile nicht wirklich zusammen. Sonst hätte jemand längst diesen Trivial-Passwort-Patch eingecheckt.
Und mit git könnte man auch das Autoupdate-Problem anders lösen als "Modul komplett ausblenden".
Aber das ist nicht das Thema dieses Themas.
Hier gilt Vereinbahrung, nicht in fremden Module zu "wildern" ;)
Die Änderung sollte der Autor (Norbert) durchführen.
Man sollte ihm den Patch, genauer ein Pull-Request (Norbert unterhält ein Git-Mirror https://github.com/ntruchsess/fhem-mirror) zusenden.
Ich könnte das ggf. auch machen, das kann aber etwas dauern, habe in den nächsten Tagen sehr wenig Zeit. :(
Zitat von: JoWiemann am 14 Januar 2016, 19:54:09
Hallo,
dafür gibt es Editoren, die das können sollen. Anbei das gepatche Modul. Bitte das Modul dann vom Update ausnehmen. Sonst wird es wieder überschrieben.
Grüße Jörg
Hallo,
entschuldigt bitte diese Anfängerfrage aber wo kann ich dann den Benutzernamen und das Passwort für den MQTT Broker eingeben? Ich habe das Modul 00_MQTT.pm mit der gepatchten Version ersetzt und FHEM sicherheitshalber neu gestartet. Wo kann ich jetzt den Benutzernamen und das Passwort eingeben?
Danke!!!
Schau ins Commandref in dem gepatchten Modul.
Define
define <name> MQTT <ip:port> <username:password>
Specifies the MQTT device.
Username and password are optional.
Das Modul unterstützt nicht zufällig TLS? :o
Zitat von: klausw am 06 Juni 2016, 10:33:53
Das Modul unterstützt nicht zufällig TLS? :o
gute frage, müsste man reinschauen. Würde aber eher nicht erwarten.
Zitat von: klausw am 06 Juni 2016, 10:33:53
Das Modul unterstützt nicht zufällig TLS? :o
Nö. Bau es ein ... oder verfrachte deine Infrastruktur in ein eigenes VLAN, so dass von vornherein keiner mitlesen kann. (Intelligente Switche sind was Feines.)
Hallo,
ich habe eine Frage zu autoSubscribeReadings
Laut commandref soll man es zum generieren der subscribe attribute verwenden und dann kann man es wieder löschen.
Ohne diesen Attribut empfange ich aber keine Readings mehr.
Muss man es doch dauerhaft verwenden und Topics zu empfangen?
Weiteres ist mir aufgefallen das manche statt dem + ein # verwenden.
Das # wird aber in der commandref gar nicht erwähnt. Wo liegt da der Unterschied?
Zitat von: smurfix am 06 Juni 2016, 12:14:05
Nö. Bau es ein ...
im mom ist der Leidensdruck noch nicht groß genug 8)
Zitat von: smurfix am 06 Juni 2016, 12:14:05
oder verfrachte deine Infrastruktur in ein eigenes VLAN, so dass von vornherein keiner mitlesen kann. (Intelligente Switche sind was Feines.)
im Heimnetz ist das überflüssig, alllerdings will ich über das Inet gehen und wenn möglich ohne vpn wie bisher
Hallo,
Zitat von: netbus am 06 Juni 2016, 16:06:54
Weiteres ist mir aufgefallen das manche statt dem + ein # verwenden.
Das # wird aber in der commandref gar nicht erwähnt. Wo liegt da der Unterschied?
ich habe mich gerade erst angemeldet und FHEM auch erst vorgestern installiert, um zu schauen, wie es mir gefällt.
Da es bei mir im Moment sozusagen nur "FrontEnd" für MQTT ist, antworte ich hier mal trotzdem:
+ und # sind die MQTT Subscribe/Publish-Platzhalter. + ersetzt genau einen topic-Teil, # alle folgenden.
Beispiel: Haus/Wohnzimmer/Temperatur
+/Wohnzimmer/Temperatur liefert auch Sommerhaus/Wohnzimmer/Temperatur
Haus/+/Temperatur liefert auch Haus/Keller/Temperatur
+/+/Temperatur liefert alle Temperaturen.
Haus/# liefert alle mit Haus am Anfang, Haus/Wohnzimmer/# alle vom Wohnzimmer
# liefert überhaupt alles...
Damit kann man in MQTT schon schön gruppieren, mit Haus/+/Licht aus im ganzen Haus das Licht ausmachen...
Inwiefern das in FHEM ein Vorteil ist, muß ich noch ergründen...
Ich hänge hier mal gleich eine Frage ran, weil ich zu MQTT und FHEM noch nicht allzuviel gefunden habe.
# PC-Steckdose
define DOSE_1 MQTT_DEVICE
attr DOSE_1 IODev mqtt
attr DOSE_1 group Energie
attr DOSE_1 publishSet ein aus Dose/1
attr DOSE_1 room Wohnzimmer
attr DOSE_1 stateFormat state
attr DOSE_1 webCmd ein:aus
set DOSE_1 ein usw. geht problemlos.
MQTT verschickt ja im payload prinzipiell beliebige Daten.
Also mein Versuch mit meiner Thermometeranzeige in gleicher Art. Geht nicht, weil ein publishSet angegeben werden muß und
attr IN9 publishSet state IN9/Temperatur
einen Fehler erzeugt.
Eigentlich will ich nur mit
set IN9 245
den Temperaturwert in 1/10 Grad schicken.
Ich habe es jetzt erstmal mit einem dummy-Device und MQTT_BRIDGE gelöst, da gibt es publishState und der schickt auch meinen analogwert richtig raus.
Macht es aber unnötig kompliziert in der Config.
Kann man publshState auch in MQTT_DEVICE mit einbauen oder im publishSet eben state einbinden?
Ich schaue da im Moment noch etwas hilflos rein, Perl und die Struktur von FHEM sind mir dazu noch zu fremd...
Gruß aus Berlin
Michael
Danke fürs Erklären
Gesendet von meinem SM-G935F mit Tapatalk
Zitat von: amithlon am 07 Juni 2016, 18:29:42
Also mein Versuch mit meiner Thermometeranzeige in gleicher Art. Geht nicht, weil ein publishSet angegeben werden muß und
attr IN9 publishSet state IN9/Temperatur
einen Fehler erzeugt.
Eigentlich will ich nur mit
set IN9 245
den Temperaturwert in 1/10 Grad schicken.
Ich habe es jetzt erstmal mit einem dummy-Device und MQTT_BRIDGE gelöst, da gibt es publishState und der schickt auch meinen analogwert richtig raus.
Macht es aber unnötig kompliziert in der Config.
Kann man publshState auch in MQTT_DEVICE mit einbauen oder im publishSet eben state einbinden?
Ich schaue da im Moment noch etwas hilflos rein, Perl und die Struktur von FHEM sind mir dazu noch zu fremd...
Die MQTT_BRIDGE ist eigentlich auch genau das, was du brauchst.
MQTT_DEVICE -> empfangen und senden von MQTT Telegrammen
MQTT_BRIDGE -> Readings eines anderen Devices über MQTT rausschicken bzw. über MQTT empfangene Telegramme als set an dieses Device schicken.
Ist die Temperaturanzeige ein Device in FHEM?
In diesem Fall kannst du mit publishReading_* über eine MQTT_BRIDGE das entsprechende Reading einfach über MQTT rausblasen.
Hallo,
vorab: ich habe es mit MQTT_BRIDGE in Betrieb, insofern also kein direkter Handlungsbedarf.
Zitat von: klausw am 08 Juni 2016, 09:39:30
Die MQTT_BRIDGE ist eigentlich auch genau das, was du brauchst.
MQTT_DEVICE -> empfangen und senden von MQTT Telegrammen
Genauso würde ich es interpretieren, so stimmt es aber eben nicht ganz.
MQTT_DEVICE verschickt nur genau die Werte, die als Vorgaben in publishSet definiert wurden.
Letztlich scheint publishSet ja nur ein Filter zu sein, der alles verwirft, dort nicht definiert wurde.
Bei attr DOSE_1 publishSet ein aus Dose/1 wird eben ein oder aus mit dem MQTT-topic DOSE/1 geschickt.
publishSet state DOSE/1 sollte eben einfach den Inhalt von state mit topic DOSE/1 schicken können, wäre für mich einfach konsistenter, MQTT hat dort ja keine Einschänkung.
Ich kann somit "set DOSE_3 ein" schicken oder "set DOSE_3 aus". Aber nicht z.B. "set DOSE_3 125" wenn es z.b. ein Dimmer mit Analogwerten ist.
Dann baut man extra ein dummy und muß MQTT_BRIDGE benutzen, unnötige config-Zeilen meine ich.
Gruß aus Berlin
Michael
Ak ok, jetzt verstehe ich.
attr <name> publishSet [<commands>] <topic>
Hast du schonmal versucht <commands> wegzulassen?
Evtl. kannst du auch ein regex z.B. für Zahlen verwenden.
Noch ein kleiner Hinweis: wenn du den den MQTT Geräten die Attribute veränderst dann wurde das bei mir nicht korrekt übernommen. Ich musste die attribute immer löschen und neu anlegen.
Zitat von: klausw am 08 Juni 2016, 18:15:32
Ak ok, jetzt verstehe ich.
attr <name> publishSet [<commands>] <topic>
Hast du schonmal versucht <commands> wegzulassen?
Evtl. kannst du auch ein regex z.B. für Zahlen verwenden.
Noch ein kleiner Hinweis: wenn du den den MQTT Geräten die Attribute veränderst dann wurde das bei mir nicht korrekt übernommen. Ich musste die attribute immer löschen und neu anlegen.
Eine Aufzählung geht, z.B. attr DOSE_1 publishSet 100 150 200 300 350 400 Dose/1
Dann kann man jeden dieser Werte benutzen. Eine RegEx ist mir nicht gelungen, da kommt dann (frei übersetzt) "Einen Wert aus xxx benutzen"" xxx ist dann genau der Text.
Ohne <commands> kommt eben "Einen Wert aus benutzen ".
Ich werde da vermutlich mal reinschauen, wenn ich mich etwas mehr mit Perl angefreundet habe.
Ich suche mir sowieso immer Seltsames aus. ;)
Meine Sensoren sind 433MHz Eigenbau (AVRtiny/RFM02), schon ein paar Jahre in Betrieb. Jetzt mit den ESP8266 rumgespielt, eine 433MHz-WLAN/MQTT-Bridge mit dem ESP8266 gebaut, ein paar MQTT-Clients mit den ESP, eine alte Pearl-Laufschrift als MQTT-Client usw.
FHEM ist da jetzt eigentlich "drübergestülpt" und gefällt mir.
Die Laufschrift zeigt jetzt auch den nächten Titel an, den der IceCast-Player spielt. Stream-Client ist ein Eigenbau mit ESP8266 und VS1003.
IceCast, Mosquitto als MQTT-Broker und FHEM laufen auf einem RasPi.
Mal schauen, was daraus noch wird, ist letztlich Zeitvertreib, nichts davon ist mir bis jetzt lebenswichtig.
Gruß aus Berlin
Michael
Hallo,
mein Problem hat sich gelöst...
Ein anderer thread hat mich zur Lösung gebracht:
# IN9
define IN9_1 MQTT_DEVICE
attr IN9_1 IODev mqtt
attr IN9_1 publishSet_IN9temp IN-9/Temperatur
attr IN9_1 stateFormat IN9status
attr IN9_1 subscribeReading_IN9status IN-9/Status
Die attr-Vorbelegung mit publishSet_.* ist leider wenig hilfreich, dort muß der FHEM-Variablenname hin und der MQTT-topic hin.
Dann wird der Inhalt von IN9temp auch unabhängig vom Inhalt rausgeschickt.
Dort wäre publishSet_ angebrachter um dann das Parameterfeld auszufüllen und anzuhängen.
Gruß aus Berlin
Michael
Mahlzeit!
Zitat von: smurfix am 22 Februar 2015, 00:01:14
Patch im Anhang. Getestet. Jemand mit Schreibrechten importiere dies bitte ins CVS.
Sorry, dass ich das Thema wieder pushe aber der Patch läuft einwandfrei und es wäre schön, wenn den jemand einchecken würde.
Danke, Smurfix.
Patrick
ist nicht ganz der Patch geworden aber das Problem sollte mit aktuellem update gelöst sein:
define <name> MQTT <ip:port> [<username>] [<password>]
Grüße
Stephan
Super, da kann ich das jetzt aus der Ignoreliste rausnehmen.
Planst du zufällig auch TLS/SSL einzubauen? 8)
TLS/SSL steht auf meiner MQTT Todo Liste. ;)
Grüße
Stephan
Prima!
Von unterwegs gesendet.
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:
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
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
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.
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
attr Wasserventil1 publishSet on off 5 15 30 Garden/Valve/1/set
dann kann ich
set Wasserventil1 on
set Wasserventil1 off
set Wasserventil1 5
set Wasserventil1 15
set Wasserventil1 30
machen. Geht.
wenn ich aber
set Wasserventil1 7
mache dann kommt
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 :-)
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
attr Wasserventil1 publishSet on off 5 15 30 Garden/Valve/1/set
dann kann ich
set Wasserventil1 on
set Wasserventil1 off
set Wasserventil1 5
set Wasserventil1 15
set Wasserventil1 30
machen. Geht.
wenn ich aber
set Wasserventil1 7
mache dann kommt
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 :-)
Zitat von: ZeitlerW am 10 Februar 2017, 10:03:11
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 (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 (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 (https://wiki.fhem.de/wiki/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).
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
Wird denn das MQTT-Modul noch weiterentwickelt?
Zitat von: Bapt. Reverend Magersuppe am 14 Februar 2017, 09:43:58
Wird denn das MQTT-Modul noch weiterentwickelt?
hoffentlich bald wieder :)
Es wurden schon Bugs und Verbesserungsvorschläge hier im Forum berichtet.
Zitat von: dev0 am 14 Februar 2017, 07:19:53
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
Zitat von: Reinhart am 14 Februar 2017, 10:31:57
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...
Zitat von: ZeitlerW am 14 Februar 2017, 08:35:33
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
Das ist schade, kannst du mir den Code per PM zukommen lassen?
Billy
Hallo,
ich hab den MQTT-Broker mit <user:password> in Fhem angelegt.
Auf den RPi3B hab ich einen user in MQTT angelegt.
Der MQTT-Broker ist in Fhem opened - soweit sieht es gut aus.
Ich nutze ESPEasy Build 136.
Ohne user:password funktioniert die Einstellung Protocol: PiDome MQTT; mit user:password finde ich keine Einstellung, die Daten nach Fhem schreibt.
Was mache ich falsch bzw. hat jemand den hier genannten patch in Kombination mit ESPEasy erfolgreich zum Laufen gebraucht?
Viele Grüße Gisbert
Zitat von: Gisbert am 19 Februar 2017, 10:48:00
Hallo,
ich hab den MQTT-Broker mit <user:password> in Fhem angelegt.
Auf den RPi3B hab ich einen user in MQTT angelegt.
Der MQTT-Broker ist in Fhem opened - soweit sieht es gut aus.
Ich nutze ESPEasy Build 136.
Ohne user:password funktioniert die Einstellung Protocol: PiDome MQTT; mit user:password finde ich keine Einstellung, die Daten nach Fhem schreibt.
Was mache ich falsch bzw. hat jemand den hier genannten patch in Kombination mit ESPEasy erfolgreich zum Laufen gebraucht?
Viele Grüße Gisbert
Du solltest den Openhab MQTT im ESPEasy konfigurieren. Danach musst doch noch die Subcribe- und Publish Template anpassen!
Dieser Artikel hat mir geholfen: http://xbmcnut.blogspot.de/2017/02/how-to-flash-espeasy-onto-sonoff-touch.html
Hallo P.A.Trick,
vielen Dank für den Hinweis die Subcribe- und Publish-Templates anzupassen.
Damit hat es geklappt und Fhem registriert Daten.
Was noch etwas verwirrend war, ist die Angabe für user und password, die je nach Quelle unterschiedlich ist, mal mit Leerzeichen, mal mit Doppelpunkt.
Bei mir hat nur die Schreibweise <user:password> mit Doppelpunkt zwischen user und password funktioniert.
Viele Grüße Gisbert
Leider scheitert die Verwendung des MQTT_DEVICES mit ein vertxMQTT Broker. Und das Problem scheint im MQTT_DEVICES/MQTT Perl Modul zu liegen. Denn mit verschiedenen anderen Clients gelingt problemlos ein abonnieren der Topics. Den Test habe ich auch vom FHEM Knoten aus mit Net::MQTT erfolgreich absolviert.
Der eigentliche Connect zum Broker gelingt:
2017.03.03 17:00:17 3: Opening vertxMQTT device 192.168.###.###:1885
2017.03.03 17:00:17 3: vertxMQTT device opened
bzw. auf der Server Seite:
2017-03-03 17:00:17 INFORMATION io.github.giovibal.mqtt.MQTTSession New connection client : clientID: NetMQTTpm5058, MQTT protocol: MQIsdp
Versuche ich dann aber eine Subscription durchzuführen - aktivieren des Attributs attr environment_Treppenhaus subscribeReading_Environment /sensor/indoor/treppenhaus/environment
kommt es unmittelbar zu einer Exception beim Broker:
2017-03-03 17:00:17 SCHWERWIEGEND io.github.giovibal.mqtt.MQTTSocket clientID: NetMQTTpm5058, MQTT protocol: MQIsdp, Bad error in processing the message
io.netty.handler.codec.CorruptedFrameException: Received a message with fixed header flags (a) != expected (2)
at io.github.giovibal.mqtt.parser.DemuxDecoder.genericDecodeCommonHeader(DemuxDecoder.java:50)
at io.github.giovibal.mqtt.parser.DemuxDecoder.decodeCommonHeader(DemuxDecoder.java:29)
at io.github.giovibal.mqtt.parser.SubscribeDecoder.decode(SubscribeDecoder.java:22)
at io.github.giovibal.mqtt.parser.MQTTDecoder.decode(MQTTDecoder.java:69)
at io.github.giovibal.mqtt.parser.MQTTDecoder.dec(MQTTDecoder.java:44)
at io.github.giovibal.mqtt.MQTTSocket.onToken(MQTTSocket.java:63)
...
Offensichtlich ist im Flag Nibble der MQTT Nachricht vom FHEM Modul an den Broker sowohl das Bit 3 und das Bit 1 gesetzt. Diese Bit-Kombination ist für den Broker nicht zulässig und gemäß Spezifikation
http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.html#_Toc385349758 (http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.html#_Toc385349758)
schließt er unmittelbar die Verbindung:
2017-03-03 17:00:17 INFORMATION io.github.giovibal.mqtt.MQTTNetSocket clientID: NetMQTTpm5058, MQTT protocol: MQIsdp, net-socket closed ... d6db662f-0182-4bbd-9ddb-c2b83161619f
bzw.
2017.03.03 17:00:17 1: 192.168.###.###:1885 disconnected, waiting to reappear (vertxMQTT)
2017.03.03 17:00:17 1: 192.168.###.###:1885 reappeared (vertxMQTT)
Wie kann ich das Problem in den beiden Perl Modulen weiter eingrenzen?
Vielen Dank
Hallo AutomationBaer,
zum weiter eingrenzen beim MQTT und beim MQTT_DEVICE verbose auf 5 stellen.
Grüße
Stephan
Hallo Stephan,
leider gab die zusätzlichen Logausgaben keine verwertbaren Hinweise. Nach einigen Wiederholungen ergibt sich jetzt das folgende Bild: das Anlegen des MQTT IO-Devices funktioniert problemlos. Ebenso die Definition von MQTT_DEVICEs solange diese keine Subscription machen. Das heißt, ich kann das folgende in die fhem.cfg eintragen:
#
# MQTT
define vertxMQTT MQTT 192.168.###.###:1885
attr vertxMQTT icon it_net
attr vertxMQTT verbose 5
#
# MQTT Subscriptions
# Bewegungsmelder Treppenhaus EG
define bewegungsmelder_Treppenhaus MQTT_DEVICE
attr bewegungsmelder_Treppenhaus IODev vertxMQTT
attr bewegungsmelder_Treppenhaus verbose 5
attr bewegungsmelder_Treppenhaus icon people_sensor
attr bewegungsmelder_Treppenhaus room Treppenhaus
attr bewegungsmelder_Treppenhaus stateFormat transmission-state
#attr bewegungsmelder_Treppenhaus subscribeReading_Motion sensor/indoor/treppenhaus/eg/motion
und FHEM damit (re)starten. Es kommt zu keinen Fehlermeldungen und beide Devices werden im Web-Frontend angezeigt. Der Status des IODevices wird als active und opened angezeigt. Editiere ich jetzt über das Web-Frontend die fhem.cfg und entferne den Kommentar-Hash vor der Subscription - aktiviere also den Eintrag - und speiche die Konfiguration ab, dann tritt unmittelbar das beschriebene Fehlverhalten auf. >:( Das Device wechselt zwischen subscribed und unsubscribed hin und her. Synchron dazu wirft der Broker die Exception. Nur durch das Löschen des Attributs kehrt wieder Ruhe ein. :(
Und nun das Erstaunliche: aktiviere ich die Subscription nicht durch das Editieren der Konfiguration, sondern setzte das Attribut über die Komandozeile des Web-Frontends dann wird die Subscription ohne Fehler durchgeführt und das Topic auch ausgelesen. Auch das Speichern der jetzt aktiven Konfiguration gelingt und die Kommunikation läuft problemlos weiter...?! Auf diesem Weg gelingt auch das Aktivieren weiterer Devices.
Wird jetzt allerdings FHEM neu gestartet, zum Beispiel via shutdown restart stellt sich wieder das Eingangs geschilderte Problem ein und der Broker wirft Exceptions. Das Problem scheint also in den Statusübergängen bei FHEM respektive in den beiden MQTT Modulen begründet zu sein.
Ratlose Grüße von
thomas
Hallo Thomas,
Da die FHEM Module auf Net::MQTT basieren verstehe ich nicht das es mit Net::MQTT funktioniert aber mit den FHEM MQTT Modulen nicht.
Kannst du mir dein Net::MQTT Test zukommen lassen?
Ich werde mir mal testweise den vertx-mqtt-broker installieren.
Grüße
Stephan
Hallo Stephan,
vielen Dank für dein Angebot, doch ich glaube ein Test von Net::MQTT und vertxMQTT führt nicht auf die Spur. Denn die Diskrepanz zwischen der native Nutzung und der Nutzung via FHEM hat mich auch verwundert. Darauf hin habe ich einen Blick auf die Module in FHEM geworfen. Meine Perl Kenntnisse sind mehr als eingerostet, aber soweit ich die die Module 00_MQTT.pm und 10_MQTT_DEVICE.pm verstanden habe verwenden diese Net::MQTT nicht zur Kommunikation. Aus Net::MQTT werden die Konstanten und der Message Builder verwendet - quasi als Utility. Der eigentliche Statusautomat ist in den beiden Modulen realisiert. Zur Low-Level Kommunikation wiederum wird DevIo.pm verwendet.
Im Moment vermute ich, daß das Problem in der init_done Section begründet ist. Ich vermute die meisten/alle verwenden lokale MQTT Broker und nicht wie ich einen Remoten Cluster, so daß Latenzen in der Kommunikation bisher nicht aufgefallen sind:
sub client_subscribe_topic($$) {
my ($client,$topic) = @_;
push @{$client->{subscribe}},$topic unless grep {$_ eq $topic} @{$client->{subscribe}};
my $expr = topic_to_regexp($topic);
push @{$client->{subscribeExpr}},$expr unless grep {$_ eq $expr} @{$client->{subscribeExpr}};
if ($main::init_done) {
if (my $mqtt = $client->{IODev}) {;
my $msgid = send_subscribe($mqtt,
topics => [[$topic => $client->{qos} || MQTT_QOS_AT_MOST_ONCE]],
);
$client->{message_ids}->{$msgid}++;
readingsSingleUpdate($client,"transmission-state","subscribe sent",1)
}
}
};
Der Grund kann aber auch ein ganz anderer sein... Ich bin im Moment zumindest Ratlos :-[
By the way: warum wird in der Sequenz des Subscribes mit zwei verschiedenen QOS Werten gearbeitet? client_subscribe_topic setzt MQTT_QOS_AT_MOST_ONCE, in der dann aufgerufenen Funktion send_subscribe wird dann MQTT_QOS_AT_LEAST_ONCE verwendet...
Einen schönen Sonntag wünscht
thomas
Hallo Stephan,
wenn ich folgende Definition nutze, und das Modul 00_MQTT.pm update, dann bekomme ich keine Verbindung hin.
define <name> MQTT <ip:port> [<username>] [<password>]Im logfile erscheint alle 100-200 ms der folgende Eintrag:
2017.03.09 16:30:20 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.03.09 16:30:20 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)Im define steht:
define <name> MQTT <ip:port>Obwohl das Gerät modifiziert wurde (mit [<username>] [<password>]) und abgspeichert wurde, fehlen <username> und <password>.
Ich habe 00_MQTT.pm vom update ausgeschlossen.
Die auf der 1. Seite dieses Threads vorhandene 00_MQTT.pm funktioniert, wenn die Definition wie folgt ausssieht:
define <name> MQTT <ip:port> <username>:<password>Ich wüsste gerne, wie die Definition richtig heißt, wenn das Modul aus dem update in FHEM benutzt.
Ich würde gerne alle Module updaten, da in der Regel das von Vorteil ist.
Viele Grüße Gisbert
define <name> MQTT <ip:port> [<username>] [<password>]passt.
Das nach dem speichern <username> und <password> fehlen ist beabsichtigt.
<username> und <password> werden in $modpath/FHEM/FhemUtils/uniqueID gespeichert.
Grüße
Stephan
Mahlzeit!
Ich klinke mich mal hier ein, weil ich ein Problem habe, was vermutlich mit dem Username-Patch zusammenhängt. Nach dem Neustart meines fhem-Servers flutet MQTT reproduzierbar das Log mit Fehlermeldungen:
2017.03.09 20:23:38.972 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:38.979 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:39.513 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:39.520 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:40.076 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:40.083 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:40.635 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:40.642 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:41.197 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:41.204 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:41.759 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:41.766 1: localhost:1883 reappeared (MQTTBroker)
2017.03.09 20:23:42.327 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.03.09 20:23:42.333 1: localhost:1883 reappeared (MQTTBroker)
Das Problem lässt sich beheben, indem man im Webinterface auf "DEF" klickt und den Benutzernamen und das Passwort anhängt. Dann läuft es wieder.
Patrick
P. S.: Ich bin persönlich kein Freund von dem informatischen Taschenspielertrick mit der uniqueID, zumal damit das Risiko massiv steigt, dass man unvollständige Backups erzeugt/restored.
Ich habe das gleiche Phänomen. Löschen und Wieder anlegen des Devices hilft. Ob es was nützt, die Definition in der fhme.cfg weiter nach oben zu ziehen? Einen "shutdown restart" hat das jedenfalls bei mir überlebt. Ob es auch ein Update überlebt, werden wir sehen ...
Nach update und restart startet FHEM heute gar nicht mehr.
Letzte Zeile im Log:
Undefined subroutine &MQTT::BRIDGE::client_attr called at ./FHEM/10_MQTT_BRIDGE.pm line 166, <$fh> line 744
Mal sehen, ob ich das wieder gestartet bekomme ...
Hallo,
ich pushe das hier mal. Nach einem FHEM "update" - "shutdown restart" startet FHEM nicht.
Workaround bei mir:
Manuell die fhem.cfg editieren (pfui!) und die MQTT-Basis-Definition löschen, (nicht die devices).
FHEM starten und neu definieren.
Läuft, aber geht natürlich nicht per cron oder so ... :'(
Hat jemand eine Idee, woran das liegt?
Hallo fstefan1960,
in der fhem.cfg hats du zuerst MQTT und dann MQTT_BRIDGE definiert?
Für mich sieht das so aus wie wenn 10_MQTT_BRIDGE.pm ausgeführt wird aber 00_MQTT.pm noch nicht geladen ist.
Grüße
Stephan
Ja, danke.
Durch die nötige Redefinition stand MQTT jetzt natürlich am Ende der fhem.cfg.
@eisler:
Brauchst Du zu meinem Problem noch Infos?
Von unterwegs gesendet.
Hallo PatrickR,
falls du noch Infos hat gerne.
Das sieht für mich nach fehlendem Username und Passwort aus.
Username und Passwort werden in $modpath/FHEM/FhemUtils/uniqueID gespeichert
und werden beim einem Neustart von FHEM von dort gelesen.
Grüße
Stephan
Hallo Stephan, dieser schaudrige Umstand war mir schon bewusst. Werde bei Gelegenheit mal probieren, ob ich das Problem rekonstruieren kann.
Patrick
Von unterwegs gesendet.
Mahlzeit!
Da ich heute wegen eines Kernel-Updates mal wieder die Systeme durchbooten musste, hatte ich die Gelegenheit, die Problematik der vergessenen Passwörter näher anzusehen. Zur Erinnerung: Nach dem Neustart kommt keine Verbindung zum MQTT-Broker zu stande:
2017.05.07 15:09:07.641 1: localhost:1883 reappeared (MQTTBroker)
2017.05.07 15:09:10.332 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.05.07 15:09:10.339 1: localhost:1883 reappeared (MQTTBroker)
2017.05.07 15:09:13.038 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
2017.05.07 15:09:13.057 1: localhost:1883 reappeared (MQTTBroker)
2017.05.07 15:09:15.758 1: localhost:1883 disconnected, waiting to reappear (MQTTBroker)
Das Problem lässt sich lösen, indem man in FHEMWEB den Benutzernamen und das Passwort an die vorhandene Definition anhängt und fhem durchstartet. So weit so bekannt.
Vor der Behebung des Problems waren MQTT-Daten nicht in der uniqueID vorhanden:
################################################################
# [...]
################################################################
uniqueID:BBBBBBBBB
FRITZBOX_OG.WO.Fritzbox_passwd:AAAAAAAAA
Nach der Änderung in FHEMWEB und restart:
################################################################
# [...]
################################################################
uniqueID:BBBBBBBBB
FRITZBOX_OG.WO.Fritzbox_passwd:AAAAAAAAA
MQTTBroker_user:fhem
MQTTBroker_pass:XXXXXXXXX
Nachdem ich etwas Debugcode eingebaut habe, stellt sich die Situation wie folgt dar:
2017.05.07 17:53:49.039 1: getKeyValue(MQTTBroker_user): fhem
2017.05.07 17:53:49.039 1: getKeyValue(MQTTBroker_pass): XXXXXXXXX
2017.05.07 17:53:49.163 0: Server started with 419 defined entities (fhem.pl:14152/2017-05-01 perl:5.020002 os:linux user:root pid:1928)
2017.05.07 18:49:31.473 1: MQTTDEBUG, Undef()
2017.05.07 18:49:31.473 1: setKeyValue(MQTTBroker_user): undef
2017.05.07 18:49:31.475 1: setKeyValue(MQTTBroker_pass): undef
2017.05.07 18:49:31.500 1: Including fhem.cfg
Man sieht sehr schön, dass zunächst die korrekten Zugangsdaten vorliegen, dann aber die Werte durch die UndefFn von 00_MQTT explizit gelöscht werden. Lt. Doku wird die UndefFn sowohl bei delete als auch bei rereadcfg aufgerufen. Mir ist zugegebenermaßen nicht klar, was den Aufruf der UndefFn in meinem Fall ausgelöst hat. Dennoch ist das Löschen der Zugangsdaten an dieser Stelle m. E. ein Bug. 00_MQTT speichert die Logindaten nicht zwischen sondern bemüht bei Bedarf _immer_ getKeyValue. Rereadcfg würde die Daten also an der einzigen Stelle vernichten, an der sie vorliegen. Die Doku empiehlt derartige Arbeiten in der DeleteFn:
Zitat
[X_Delete] dient eher zum Aufräumen von dauerhaften Daten, welche durch das Modul evtl. für dieses Gerät spezifisch erstellt worden sind.
Patrick
Hallo Patrick,
Danke fürs genaue Debuggen. Schaue ich mir noch mal genau an und werde das fixen.
Grüße
Stephan
Hallo zusammen,
ich bin der Verzweifelung nahe.
Ich habe Linux upgedatet, dannach bekomme ich keine Verbindung mehr zum MQTT-Broker:
2017.06.04 11:22:17 3: Opening MyBroker device 192.168.178.26:1883
2017.06.04 11:22:17 3: Can't connect to 192.168.178.26:1883: Connection refused
Ich habe 00_MQTT.pm von der 1. Seite nach FHEM kopiert und vom update-Prozess ausgeschlossen; das hat bisher auch nach einem Linux-update immer funktioniert.
Wie bekomme ich wieder eine Verbindung?
Wie genau muss die Definition des MQTT, insbesondere user password aussehen?
Was muss ich noch beachten?
Viele Grüße Gisbert
Hallo Gisbert,
läuft der MQTT-Broker nach dem update noch?
>Wie genau muss die Definition des MQTT, insbesondere user password aussehehn?
define <name> MQTT <ip:port> [<username>] [<password>]
also
define MyBroker MQTT 192.168.178.26:1883 username password
Grüße
Stephan
Hallo Stephan,
Zitatläuft der MQTT-Broker nach dem update noch?
Da hätte ich auch eher draufkommen können; danke für deine Hilfe.
Er lief nicht mehr - aber warum?
Bisher hat er nach einem reboot des RPi von selbst gestartet.
Mal sehen, wie ich das einstellen kann.
Nach der Definition des Brokers "verschwinden" user und password; ist das richtig so?
define MyBroker MQTT 192.168.178.26:1883 username passwordMuss 00_MQTT.pm noch vom update auschlossen werden?
Im Moment läuft der MQTT-Broker wieder; ich werde mal ein reboot bei RPi versuchen.
Viele Grüße Gisbert
Hallo Stephan,
nach einem reboot des RPi startet der MQTT service nicht von selbst wie vor dem update des RPi.
Noch 2 Fragen:
Wie kann ich den Start des Service automatisieren?
Muss 00_MQTT.pm weiterhin vom update ausgeschlossen werden?
Viele Grüße Gisbert
Hallo Gisbert,
vermutlich muss dein mosquitto broker im autostart deines systems eingetragen sein.
Gab es einen Grund warum du die 00_MQTT.pm vom update ausgeschlossen hast?
Grüße
Stephan
Hallo Stephan,
Mosquitto steht im Autostart:
/etc/init.d/mosquitto
fährt aber trotzdem bei Booten des RPi / Jessie nicht hoch.
Den Ausschluss des Moduls vom update hatte ich gemacht, da ich Probleme bei dem Setzen von user und password hatte.
Heißt das, dass ich 00_MQTT.pm wieder updaten sollte?
Ich werde es erst Ende nächster Woche probieren, da ich die zuhause gebliebenen nicht auf dem Trockenen sitzen lassen möchte.
Viele Grüße Gisbert
Mahlzeit!
Zitat von: eisler am 07 Mai 2017, 22:51:12
Danke fürs genaue Debuggen. Schaue ich mir noch mal genau an und werde das fixen.
Wenn Du noch Hilfe brauchst, einfach melden.
Da ich aktuell schrittweise Geräte auf MQTT umstelle habe ich noch ein weiteres Anliegen. Ich müsste MQTT-Nachrichten mit Leerzeichen publishen können. publishSet scheint das aber nicht zuzulassen.
Patrick
Zitat von: eisler am 04 Juni 2017, 13:18:37
Hallo Gisbert,
vermutlich muss dein mosquitto broker im autostart deines systems eingetragen sein.
Gab es einen Grund warum du die 00_MQTT.pm vom update ausgeschlossen hast?
Grüße
Stephan
Hallo Stephan,
zur obigen Vermutung konnte ich Hilfe bei meinem Sohn bekommen.
Um den Service dauerhaft nach einem Neustart des RPi zu bekommen, muss folgender Befehl beim RPi (Jessie) eingegeben werden:
sudo systemctl enable mosquitto.serviceZum anderen Thema:
Ich hab 00_MQTT.pm upgedated. Mit der Definition
define MyBroker MQTT 192.168.178.26:1883 user passwordfunktioniert MQTT, so dass es keinen Grund gibt 00_MQTT.pm vom update auszuschließen.
Viele Grüße Gisbert
Hallo Stephan,
ich bin's nochmals, mit einem merkwürdigen Verhalten.
Wenn ich den RPi boote, funktioniert alles bestens, dank systemctl.
Wenn ich jedoch im laufenden Betrieb in Fhem "rereadcfg" durchführe erscheint dies im logfile:
2017.06.13 22:44:36 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:36 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.06.13 22:44:36 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:38 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.06.13 22:44:38 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:38 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.06.13 22:44:38 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:38 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.06.13 22:44:38 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:38 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.06.13 22:44:38 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:39 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.06.13 22:44:39 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:40 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.06.13 22:44:40 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:40 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.06.13 22:44:40 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:40 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.06.13 22:44:40 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:40 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.06.13 22:44:40 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:40 1: 192.168.178.26:1883 reappeared (MyBroker)
2017.06.13 22:44:40 1: 192.168.178.26:1883 disconnected, waiting to reappear (MyBroker)
2017.06.13 22:44:40 1: 192.168.178.26:1883 reappeared (MyBroker)
usw.
Es läßt sich leicht beheben, indem ich define MyBroker MQTT 192.168.178.26:1883 user password eingebe, aber das kann nur ein Notbehelf sein.
Es scheint so, als habe der MQTT Broker user password "vergessen".
Woran könnte es liegen?
Viele Grüße Gisbert
Hallo Stephan,
es ist tatsächlich so, dass nach einem rereadcfg in der Datei /opt/fhem/FHEM/FhemUtils/uniqueID die Einträge für user und password des MQTT-Brokers nicht mehr vorhanden sind. Die Datei ist mit aktuellem Datum/Zeit neu gespeichert im Dateiverzeichnis vorhanden.
Vorher standen die beiden Zeilen am Ende dieser Datei, in meinem Fall:
myBroker_user:xxxxxx
mBroker_pass:yyyyyy
Nach dem rereadcfg sind diese Einträge verschwunden; andere user/password von anderen Modulen sind noch vorhanden.
Viele Grüße Gisbert
Hi! Das Problem ist bekannt (s. o.) und ein Patch auf dem Weg.
Von unterwegs gesendet.
Hallo Stephan,
könntest Du ein Patch für 10_MQTT_DEVICE.pm prüfen und aufnehemen?
Grund:
Im Falle folgender Definition
define XXX MQTT_DEVICE
attr XXX publishSet /topic/set
ohne Werteliste, also nicht so:
attr XXX publishSet on off /topic/set
funktioniert set XXX <wert> nicht, sondern wird mit Meldung "Unknown argument $command, choose one of ..." quittiert.
Ursache: Fehlende Bedingung in der Prüfung.
Warum ich das für einen Fehler halte? Weil man bei einigen Geräten keine abschliessende Werteliste definieren kann oder will (wenn diese z.B zu lang wird). So bei einem Dimmer möchte man eher nicht alle möglichen Prozentwerte angeben müssen.
Patch:
diff U3 D:/Develop/fhem/FHEM/10_MQTT_DEVICE.pm W:/FHEM/10_MQTT_DEVICE.pm
--- D:/FHEM_ORIGINAL/10_MQTT_DEVICE.pm Sat Feb 11 04:53:52 2017
+++ W:/FHEM_DEV/10_MQTT_DEVICE.pm Wed Jun 14 20:57:24 2017
@@ -83,7 +83,7 @@
my ($hash,$name,$command,@values) = @_;
return "Need at least one parameters" unless defined $command;
return "Unknown argument $command, choose one of " . join(" ", map {$hash->{sets}->{$_} eq "" ? $_ : "$_:".$hash->{sets}->{$_}} sort keys %{$hash->{sets}})
- if(!defined($hash->{sets}->{$command}));
+ if(!defined($hash->{sets}->{$command}) && @values);
my $msgid;
if (@values) {
my $value = join " ",@values;
Danke und Grüße
Alexander
P.S.
Ich würde gerne in den nächten Tagen noch einen Patch einreichen, diesemal für 00_MQTT.pm. Dieser soll es ermöglichen, andere Clients-Module zu verwenden, als MQTT_DEVICE und MQTT_BRIDGE. Ich würde gernen ein eigenes Modul schreiben, das erstens anderen Syntax für subscribe/publish versteht (die jetztzigen kann man leider nicht nachträglich in WebUI editieren) und zweitens eine bequemmere Verwendung für bestimmte Device-Typen anbietet.
Ich habe mehrere per MQTT angebundenen Schalter und Dimmer und würde gerne diese mit wenigen Zeilen definieren können, auch bereits mit allem, was eine Bedienung in WebUI braucht.
Vermuttlich so:
define WZDGOST MQTT_DEVICE_TYPE dimmer
attr WZDGOST IODev MQTT
attr WZDGOST base /haus/dg/wz/licht/ost
Hallo Alexander,
habe deinen Patch mit aufgenommen. ( https://svn.fhem.de/trac/changeset/14520/ )
Grüße
Stephan
Prima, Danke! :)
Hallo zusammen,
mit heutiger Version der 10_MQTT_DEVICE.pm kommen in meinem FHEM beim Start folgende Warnungen:
2017.06.16 09:34:35.182 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at /opt/fhem/FHEM/lib/Net/MQTT/Message/Publish.pm line 28.
2017.06.16 09:34:35.182 1: PERL WARNING: Use of uninitialized value $_[0] in pack at /opt/fhem/FHEM/lib/Net/MQTT/Constants.pm line 130.
Kurz darauf erscheinen im Log dauerhaft und beständig folgende Einträge der Art:
2017.06.16 09:35:05.349 1: 127.0.0.1:1883 disconnected, waiting to reappear (MQTT_SRV_lokal)
2017.06.16 09:35:05.388 1: 127.0.0.1:1883 reappeared (MQTT_SRV_lokal)
2017.06.16 09:35:05.529 1: 127.0.0.1:1883 disconnected, waiting to reappear (MQTT_SRV_lokal)
2017.06.16 09:35:05.685 1: 127.0.0.1:1883 reappeared (MQTT_SRV_lokal)
2017.06.16 09:35:06.397 1: 127.0.0.1:1883 disconnected, waiting to reappear (MQTT_SRV_lokal)
2017.06.16 09:35:06.437 1: 127.0.0.1:1883 reappeared (MQTT_SRV_lokal)
und es kommen auch keine Messages mehr rein (laienhaft ausgedrückt).
Ein Rückspielen der alten Version behebt das Problem.
Kann/muss ich noch etwas "nachkonfigurieren" oder ist es ein allgemeines Problem mit der neuen Version?
Weitere Infos kann ich gerne liefern wenn gewünscht.
Vielen Dank,
Andreas
Kann ich leider bestätigen.
Gesendet von iPhone mit Tapatalk
Zitat von: deluxe41 am 16 Juni 2017, 10:25:18
Kann ich leider bestätigen.
Gesendet von iPhone mit Tapatalk
ebenso, alles schick derzeit...
Bin leider derzeit nicht zuhause und kann nicht testen. Bei meiner Installation hat es noch funktioniert. Habe aber wohl irgendwo zu kurz gedacht, werde abends ansehen.
Kein Stress, mit der alten Version läuft's ja.
Vielen Dank für die schnelle Rückmeldung,
Andreas
Arghhhh! Man darf sich nie auf einen einfachen Anwendungsfall beschränken und glauben, dass der Rest schon passen wird.
War letztendlich (natürlich >:( ) deutlich komplexer. Aber ich glaube, ich habs 8)
Bevor ich um eine übernahme bitte (ich möchte nicht den gleichen Fehler nochmal machen ;D ), bitte ich um Test, daher hänge ich auch die ganze neue Datei an. Bei mir passt alles und keine Meldungen im Log. Zum Testen habe ich ein Device wie im Anhang angelegt. Funktioniert alles: Set-Liste, Slider, State-Icons, Feedback per mqtt...
Fehlt jmanden noch etwas? Weitere Ideen?
Patch:
diff U3 D:/Develop/fhem/FHEM/10_MQTT_DEVICE.pm W:/FHEM/10_MQTT_DEVICE.pm
--- D:/FHEM_ORIG/10_MQTT_DEVICE.pm Fri Jun 16 18:01:34 2017
+++ W:/FHEM_DEV/10_MQTT_DEVICE.pm Fri Jun 16 18:02:09 2017
@@ -82,16 +82,22 @@
sub Set($$$@) {
my ($hash,$name,$command,@values) = @_;
return "Need at least one parameters" unless defined $command;
- return "Unknown argument $command, choose one of " . join(" ", map {$hash->{sets}->{$_} eq "" ? $_ : "$_:".$hash->{sets}->{$_}} sort keys %{$hash->{sets}})
- if(!defined($hash->{sets}->{$command}) && @values);
my $msgid;
- if (@values) {
- my $value = join " ",@values;
- $msgid = send_publish($hash->{IODev}, topic => $hash->{publishSets}->{$command}->{topic}, message => $value, qos => $hash->{qos}, retain => $hash->{retain});
- readingsSingleUpdate($hash,$command,$value,1);
- } else {
- $msgid = send_publish($hash->{IODev}, topic => $hash->{publishSets}->{""}->{topic}, message => $command, qos => $hash->{qos}, retain => $hash->{retain});
- readingsSingleUpdate($hash,"state",$command,1);
+ my $mark=0;
+ if($command ne '?') {
+ if(defined($hash->{publishSets}->{$command})) {
+ my $value = join " ",@values;
+ $msgid = send_publish($hash->{IODev}, topic => $hash->{publishSets}->{$command}->{topic}, message => $value, qos => $hash->{qos}, retain => $hash->{retain});
+ readingsSingleUpdate($hash,$command,$value,1);
+ $mark=1;
+ } elsif(defined($hash->{publishSets}->{""})) {
+ $msgid = send_publish($hash->{IODev}, topic => $hash->{publishSets}->{""}->{topic}, message => $command, qos => $hash->{qos}, retain => $hash->{retain});
+ readingsSingleUpdate($hash,"state",$command,1);
+ $mark=1;
+ }
+ }
+ if(!$mark) {
+ return "Unknown argument $command, choose one of " . join(" ", map {$hash->{sets}->{$_} eq "" ? $_ : "$_:".$hash->{sets}->{$_}} sort keys %{$hash->{sets}})
}
$hash->{message_ids}->{$msgid}++ if defined $msgid;
readingsSingleUpdate($hash,"transmission-state","outgoing publish sent",1);
@@ -151,8 +157,19 @@
topic => $topic,
};
if ($2 eq "") {
- foreach my $set (@values) {
- $hash->{sets}->{$set}="";
+ if(@values) {
+ foreach my $set (@values) {
+ $hash->{sets}->{$set}="";
+ my($setname,@restvalues) = split(":",$set);
+ if(@restvalues) {
+ $hash->{publishSets}->{$setname} = {
+ 'values' => \@restvalues,
+ topic => $topic,
+ };
+ }
+ }
+ } else {
+ $hash->{sets}->{""}="";
}
} else {
$hash->{sets}->{$2}=join(",",@values);
Gestern habe ich nicht mehr geschafft zu beschreieben, was mein Patch genau alles tut, das hole ich jetzt nach...
Damit wird es möglich, mit dem Attribut publishSet nicht nur eine feste Anzahl der Werte zu definieren, sondern auch FHEM-spezifische Erweiterungen für Slider samt min/max/step, oder Wertelisten. Auch ganz ohne Wertedefinition funktioniert es jetzt und es können beliebige Werte gepublisht werden.
attr XXX publishSet on off topic/123 # nur on oder off werden akzeptiert: set XXX on
attr XXX publishSet switch:on,off topic/123 # set XXX switch on
attr XXX publishSet level:slider,0,1,100 topic/123 # set XXX level 50
attr XXX publishSet topic/123 # set XXX wasAuchImmer
oder auch alles zusammen
attr XXX publishSet on off switch:on,off level:slider,0,1,100 topic/123
Für publishSet_.* habe ich das jetzt nicht implementiert, da mir nicht eingefallen ist, wie da ein logisch aussehende Syntax sein soll.
Hexenmeister Du bist ein Gott! Funktioniert mir bei super! Danke dafür!
defmod mqtt_Test MQTT_DEVICE
attr mqtt_Test IODev myBroker
attr mqtt_Test publishSet on off switch:on,off level:slider,0,1,100 topic/123
attr mqtt_Test stateFormat transmission-state
BTW: Die Connect/Disconnect Meldungen sind auch Geschichte! Mercí
Zitat von: P.A.Trick am 17 Juni 2017, 14:18:02
Hexenmeister Du bist ein Gott! Funktioniert mir bei super! Danke dafür!
;D Vielen Dank für die Blumen ;D
Freut mich, dass das funktioniert und nützlich ist :)
Ich brauche noch eine weitere Feature, die ich impelentieren möchte: https://forum.fhem.de/index.php/topic,73279.0.html (sorry für doppelposting). Wie ist Deine Meinung dazu?
Hallo Stephan,
würdest Du den letzten Patch auch übernehmen? Diesmal habe ich wesentlich intensiever getestetund es dürfte nicht mehr so daneben gehen. :o
Danke und Grüße
Alexander
Hallo Alexander,
habe deinen Patch mit aufgenommen. ( https://svn.fhem.de/trac/changeset/14529 )
Grüße
Stephan
Danke,
dann kann ich mich ja an QOS/RETAIN (und Doku) dram machen :)
Da Qos-Steuerung in dem IO-Modul implementiert ist, wird das leider Änderungen in allen drei Dateien (MQTT; MQTT_BRIDGE und MQTT_DEVICE) nach sich ziehen >:(
Dann hätte ich (glaube ich) alles, was ich für mein Mqtt-Projekt brauche 8)
Grüße
Alexander
Hallo Alexander,
können wir gerne so machen. :)
Grüße
Stephan
Mahlzeit!
Zitat von: hexenmeister am 17 Juni 2017, 12:15:33
Auch ganz ohne Wertedefinition funktioniert es jetzt und es können beliebige Werte gepublisht werden.
Großartig, ich habe gerade auf den 10. Blick festgestellt, dass das mein Problem mit den Leerzeichen in den messages löst. Danke!
Patrick
Letzte Tage hatte ich keine Zeit für die Weiterentwicklung. Jetzt habe ich erste Testversion mit einer erweiterten Retain-Unterstützung.
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
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: ClientFn: Unterstützung für andere Client-Module außer MQTT_DEVICE und MQTT_BRIDGE
- 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
- MQTT: onConnect: Publish on connect (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, MQTT-Nachrichten direkt zu versenden:
set <device> publishRaw <topic> <value>
# bestimmte vorhandene Readings (wieder) versenden
set <device> publish <reading>[,<reading]
# alle bekannten Readings versenden
set <device> publishAll
Danke!
Billy
Ich würde das Thema TLS gern in den Raum stellen.
Es wäre super wenn sich die das MQTT Modul auch verschlüsselt mit dem Server unterhalten kann.
Grüße
Klaus
+1 für TLS
Von unterwegs gesendet.
TLS ist sicher ein nützliches Feature. Aber ich bin hier raus. Keine Ahnung, wie man das in Perl implementieren soll, außerdem unterstützen keine meiner Devices MQTT mit TLS.
Net::Mqtt unterstützt meines Wissens bereits TLS.
Vermutlich müssen nur ein paar Parameter übergeben werden.
Gesendet von meinem HTC One mit Tapatalk
Zitat von: klausw am 23 Juni 2017, 20:29:56
Net::Mqtt unterstützt meines Wissens bereits TLS.
Vermutlich müssen nur ein paar Parameter übergeben werden.
Nein, leider nicht so einfach. Das Modul benutzt Net::MQTT nur zum Erstellen der Messages, kommunikation erfolgt per DevIo_SimpleWrite.
Zumindest, wenn ich es richtig verstanden habe.
Hallo Alexander,
TLS sollte mit DevIo_OpenDev funktionieren falls $hash->{SSL} gesetzt ist und der DeviceName der Regexp ^(.+):([0-9]+)$ entspricht.
Grüße
Stephan
Hallo Stephan,
das wusste ich nicht, allerdings dürfte das auch noch nicht reichen. Wie übergibt man den notwendigen Zertifikat? Evtl. geht das über das Betriebssystem, aber wie gesagt, habe leider keine Erfahrung mit SSL und Perl.
Grüße
Alexander
Hallo Alexander,
Dazu kann ich in DevIo.pm auch nichts finden. Vor einiger Zeit hatte ich mir das Thema schon mal angeschaut, hatte leider keine Zeit das weiter zu verfolgen:
https://forum.fhem.de/index.php/topic,64358.msg555768.html#msg555768
Grüße
Stephan
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.
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
Ich habe wieder etwas gebastelt... Jetzt mit Moglichkeit, Nachrichten direkt zu publishen:
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 *
Last will implementiert.
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 *
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 *
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:
$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
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?
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
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?
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
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
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.
danke, das hat geholfen. Dein Beispiel würde ja bedeutetn, das FEHM2FHEM obsolet wäre..??
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:
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:
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
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.
Zitat von: hexenmeister am 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.
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 (https://forum.fhem.de/index.php/board,94.0.html) -->
MQTT Themen zu MQTT.
Gruß Billy
Sinnvoll wäre das :)
Entweder der Threadersteller oder der Moderator.
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.
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.
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...
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 *
Heute keine neuen Features, aber schon mal den Commandref entsprechend erweitert.
Super :)
checkst du Sie noch ein oder muss ich manuell ersetzen?
Aktuell manuell ersetzen. Offizielles checkin kommt. ;)
Grüße
Stephan
Aktuell möchte ich noch eine Feature fertig stellen und etwas mehr testen. Dann könnten die Module übernommen werden :)
passt für mich. Einfach kurz Bescheid geben.
Grüße
Stephan
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.
moin, habe die Module frisch installiert und bekomme im Log die Meldung
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.
Danke fürs Testen, schaue mir heute Abend an. Ich gehe erstmal davon aus, dass es einfach eine Warnung beim fehlenden Werten ist. Sonst funktioniert aber alles?
Bisher ist mir nicht weiter aufgefallen... aber der Tag ist ja noch lang :D
Danke für die Module !
Ich kannte weder MQTT noch Sonoff und arbeite mich langsam ein. Da ich ein Wiki-Fan bin, würde ich das gern umschreiben, das geht momentan etwas durcheinander. Dazu brauche ich sicher Hilfe. Aber vorab: Hat da jemand massiv Aktien dran, dem man auf die Füße treten könnte?
Zitat von: kumue am 24 August 2017, 06:31:34
moin, habe die Module frisch installiert und bekomme im Log die Meldung
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.
Wann kommt die Meldung genau?
Probiere mal die angehängte Version.
Moin, die Meldung kam gestern gleich nach/mit dem Neustart.
Habe die neue 00_MQTT soeben einspielt und FHEM neu gestartet.
Die Meldung kommt jetzt nicht mehr. :)
ich habe gestern Abend ebenfalls diese Version eingespielt und neu gestartet, bei mir kamen allerdings keine Meldungen im Log (verbose 3).
LG
Dann läuft es ja schon bei mindestens drei Installationen. Aus meiner Sicht können die Module eingecheckt werden. :)
Hallo Alexander,
alle Module eingecheckt. ( https://svn.fhem.de/trac/changeset/14964 )
Grüße
Stephan
Danke :)
Ich häng mich hier mal ran weil ich die neuen PerlAusdrücke beim MQTT_BRIDGE benötige.
Folgends Problem:
attr MQTT_Bridge_ML_DG subscribeSet_Play {if ($message eq "1") fhem("set $devname play");;} /MPD_DG/set/Play
2017.09.25 13:59:57 5: publish received for /MPD_DG/set/Play, 1
2017.09.25 13:59:57 5: evaluating cmd: {if ($message eq "1" ) fhem("set $devname play"); 0}
2017.09.25 13:59:57 1: PERL WARNING: Bareword found where operator expected at (eval 2332) line 1, near ") fhem"
2017.09.25 13:59:57 1: PERL WARNING: (Missing operator before fhem?)
2017.09.25 13:59:57 1: ERROR evaluating {if ($message eq "1" ) fhem("set $devname play"); 0}: syntax error at (eval 2332) line 1, near ") fhem"
2017.09.25 13:59:57 5: calling DoSet(MPD_DG,Play,1
2017.09.25 13:59:57 5: Notify for MPD_DG
2017.09.25 13:59:57 5: Play 1, 'Play 1', ''
Dann also mal so:
attr MQTT_Bridge_ML_DG subscribeSet_Play {($message eq "2")?fhem("set $devname play"):0;;} /MPD_DG/set/Play
2017.09.25 14:14:52 5: publish received for /MPD_DG/set/Play, 2
2017.09.25 14:14:52 5: evaluating cmd: {($message eq "2")?fhem("set $devname play"):0;}
2017.09.25 14:14:52 1: ERROR evaluating {($message eq "2")?fhem("set $devname play"):0;}: Global symbol "$devname" requires explicit package name at (eval 8544) line 1.
2017.09.25 14:14:52 5: calling DoSet(MPD_DG,Play,2
2017.09.25 14:14:52 5: Notify for MPD_DG
2017.09.25 14:14:52 5: Play 2, 'Play 2', ''
Dann testweise mal so, und auf einmal gehts:
attr MQTT_Bridge_ML_DG subscribeSet_Play {($message eq "2")?fhem("set MPD_DG play"):0;;} /MPD_DG/set/Play
2017.09.25 14:16:10 5: publish received for /MPD_DG/set/Play, 2
2017.09.25 14:16:10 5: evaluating cmd: {($message eq "2")?fhem("set MPD_DG play"):0;}
2017.09.25 14:16:10 5: Notify for MPD_DG
[....]
Die Frage, warum 1) nicht funktioniert und warum $devname nicht verfügbar ist? Habe ich etwas wichtiges vergessen?
Noch etwas, wenn ich ein existierendes subscribeSet_.* erneut überschreibe mit einer geänderten Perl Funktion, dann wird diese nichtbeim nächsten Event angewendet. Ich muss zuerst das Attribut löschen und dann neu anlegen. Dann wird es auch beim nächsten Event auch korrekt angewendet.
Alles in allem: ein super Modul mit enorm Potential :) :)
eine gute Frage, warum "if" nicht funktioniert... Ich verwende einfach eval. Gibt es einen besseren Vorschlag?
Log3($hash->{NAME},5,"evaluating cmd: $cmd");
my $name = $hash->{NAME};
my $device = $hash->{DEF};
$do=eval($cmd);
Log3($hash->{NAME},1,"ERROR evaluating $cmd: $@") if($@);
Mit $devname ist meine Schuld. In der Doku steht so, in Code dagegen $device. Muss natürlich angegliechen werden. Welchen Name nehmen wir?
Dass die Attribute-Änderung nicht funktioniert, ist mir auch schon aufgefallen. Hat wohl was damit zu tun, wie das Modul schon vor mir implementiert war. Ich befürchte, das bedarf einiges an Überarbeitung.
ich bin für $device.
Warum "if" nicht funktioniert kann ev. Rudi was dazu sagen..??
mit dem $device ist einfach, habe Doku angepasst.
Stephan nimmst Du bitte die Änderung auf?
Mir dem "if" habe ich leider immer noch keine Idee >:(
kann ich gerne machen... ist aber keine Änderung im 10_MQTT_BRIDGE.pm ;)
Ähem... Sorry. Verstehe zwar gerade nicht, wo ich was geändert habe. Ich mit meinen vielen Testinstanzen ;D
Ein neuer Versuch...
done.
https://svn.fhem.de/trac/changeset/15150/trunk/fhem
Grüße
Stephan
Hallo zusammen,
ich komme leider nicht weiter.
Folgendes Setting. Ich habe einen Sensor (Vair-Monitor) und der sendet über MQTT Daten (Temperatur, Feuchtigkeit, usw) an meinen Raspi 3. Dort läuft mosquitto. Das funktioniert auch so weit. Es gibt eine Funktion, dass man per MQTT auch die LED steuern kann.
Dazu benötigt man einen trigger. Das habe ich eingerichtet und es funktioniert auch über die Funktion per Putty "mosquitto_pub -t led/cmd -m "ledcolor green". Nun habe ich versucht, diesen Befehl per FHEM zu setzten. Dazu nutze ich MQTT_DEVICE. Diesen habe ich eingerichtet. IODev ist richtig eingerichtet und auch verbunden. publishSet sollte auch stimmen: led/cmd.
Bei der Fehlersuche ist mir aufgefallen, dass ich zwei Wörter sende ich wenn ich "set xyz ledcolor green" eingebe, mein state reading nur "ledcolor" anzeigt. Alles nach dem Leerzeichen wird weggelassen. ggf. liegt es hierdran. Ich habe gelesen, dass eigentlich Leerzeichen gehen sollten.
Vielleicht könnt Ihr mir helfen.
Grüße
Basty
Sollte eigentlich möglich sein. Wie ist die genaue Konfiguration? Ist das Modul aktuell?
meine Konfiguration:
define mqttserver MQTT 127.0.0.1:1883
define vairsensor.mqtt.send2 MQTT_DEVICE
attr vairsensor.mqtt.send2 IODev mqttserver
attr vairsensor.mqtt.send2 publishSet led/cmd
attr vairsensor.mqtt.send2 stateFormat transmission-state
update all habe ich gestern gemacht
Habe jetzt ausprobiert. Das ist tatsächlich ein Bug. Für die benannte "publishSets" (publishSet_xxx) habe ich es korrigiert, bei dem ohne Namen funktioniert tatsächlich immer noch nicht.
Nehme stattdessen
attr vairsensor.mqtt.send2 publishSet_cmd led/cmd
dann wird mit
set vairsensor.mqtt.send2 cmd ledcolor green
die gewünschte Zeichenfolge gesendet.
Passt... Dank Dir...
Fehler gefunden und beseitigt. Neue Version im Anhang :)
Jetzt werden auch bei "set XXX word1 word2" die Argumente komplett übertragen.
Ich habe den Sonoff B1 erworben, mit Theo Arendst TASMOTA geflasht und würde nun gern im Modul die Farbe für die LED einstellen. Meines Wissens muss dazu der Colorpicker in dem Modul aktiviert/eingestellt/hinzugefügt werden. Da ich leider davon keine Ahnung habe: Welche Datei würde man dazu verändern? Wem muss ich diese Änderung vorschlagen? Ist das überhaupt eine MQTT-Sache?
<edit> Falsches Suchwort, alles im Kasten: https://forum.fhem.de/index.php?topic=38336.0 (https://forum.fhem.de/index.php?topic=38336.0)
Änderungen mit eingecheckt:
https://svn.fhem.de/trac/changeset/15202/trunk/fhem
Grüße
Stephan
Hi,
irgendwie habe ich etwas den Überblick verloren.
Momentan benötigt man wohl leider noch dieses mqtt-json Modul. Ist geplant eine solche Funktion direkt im MQTT_DEVICE abzuwickeln?
Was ist der Anwendungsfall? Welche Notwendigkeit besteht, Werte als json zu übertragen?
Zitat von: hexenmeister am 09 Oktober 2017, 17:41:11
Was ist der Anwendungsfall? Welche Notwendigkeit besteht, Werte als json zu übertragen?
Zum Beispiel die RGB-Werte an die Strip-Controller. Wenn alles in eim Modul funktioniert wär das doch schläucher.
Oder die stat-Strings vom Tasmota. Da wird eine Menge an Informationen übertragen.
Dies in Readings verwandeln.
Verstehe. Wo könnte ich diesen json Modul und Beispiele für Verwendung finden? Evtl. lässt sich das leicht verheiraten.
JSON -> Readings: https://fhem.de/commandref.html#expandJSON
Diese rekursive Methode dadrin hat es in sich ;D
Ich könnte die tage versuchen, das aufzunehmen.
Kann jemand ein Beispiel für JSON-Value und die gewünschte Aufteilung in Readings liefern? Ich habe selbst keine solche Devices.
Ich habe nichts dagegen, dass eine JSON Dekodierung von Readings ins MQTT Modul eingebaut wird. Allerdings sollte beachtet werden, dass nicht jeder Anwender das notwendige JSON Perl Modul installalieren kann oder will -> bitte darauf achten, dass das MQTT Modul auch ohne JSON Perl Modul funktionsfähig bleibt.
Weiterhin fehlt in meiner expandJSON Implementierung noch die Verarbeitung von JSON Arrays. zZ. werden nur JSON Objekte vollständig unterstützt. Arrays wird man aber nur mit zusätzlichen Angaben vom User halbwegs sinnvoll verarbeiten können. Einen ersten Ansatz dazu findest Du auf github.com/ddtlabs.
Aus der Diskussion, ob die Integration von bestehenden Helper Modulen, wie zB. auch average, statistics, readingsChange, THREHOLD,... sinnvoll ist, werde ich mich raushalten ;)
average, statistics & Co. gehören mMn definitiv nicht direkt in Module rein. Bei JSON bin ich mir unschlüssig. Ich brauche das nicht, sehe aber ein, dass jemand das nützlich findet. Allerdings sehe ich allerhöchstens eine Unterstützung für simple flache Key-Value-Paare. Alles andere ginge aus meiner Sicht im Modul zu weit.
Zitat von: hexenmeister am 09 Oktober 2017, 21:31:59
Kann jemand ein Beispiel für JSON-Value und die gewünschte Aufteilung in Readings liefern? Ich habe selbst keine solche Devices.
Guten Morgen Hexenmeister!
Aus dem Tasmota kommt so ein Konstrukt heraus:
tele/tasmota/STATE {"Time":"2017-10-10T07:45:36", "Uptime":86, "Vcc":3.190, "POWER":"OFF", "Wifi":{"AP":2, "SSId":"ESPTOTAL", "RSSI":60, "APMac":"F2:9F:C2:F7:50:A6"}}
tele/tasmota/SENSOR {"Time":"2017-10-10T07:45:36", "Switch1":"OFF", "BH1750":{"Illuminance":2}}
tele/tasmota/SENSOR {"Time":"2017-10-10T07:51:02", "Switch1":"ON", "DS18B20":{"Temperature":33.0}, "TempUnit":"C"}
average, statistics & Co. kann man sich dann aus den Readings bauen.
so was habe ich befürchtet. Wie kann eine (möglichst einfache und generische) Regel aussehen, um daraus Readings zu erstellen.
Wie sollen zu diesen Einträgen passende Readings aussehen?
Zitat von: Bapt. Reverend Magersuppe am 10 Oktober 2017, 08:58:39
average, statistics & Co. kann man sich dann aus den Readings bauen.
Das trifft auf JSON genauso zu.
Zitat von: hexenmeister am 10 Oktober 2017, 09:25:17
Wie kann eine (...) Regel aussehen
Die wirst Du mAn nicht finden ohne alles rekursiv zu verarbeiten und ggf. dann zu filtern. Sonst legst Du Dich auf eine Struktur fest, die nur von Firmware Version x.y von Gerät z geliefert wird.
Mein Verständnis sagt, es müsste so etwas in der Art werden:
tele/tasmota/STATE {"Time":"2017-10-10T07:45:36", "Uptime":86, "Vcc":3.190, "POWER":"OFF", "Wifi":{"AP":2, "SSId":"ESPTOTAL", "RSSI":60, "APMac":"F2:9F:C2:F7:50:A6"}}
=>
Uptime=86
Vcc=3.190
POWER=OFF
WIFI.AP=2
WIFI.SSId=ESPTOTAL
WIFI.RSSI=60
WIFI.APMac=F2:9F:C2:F7:50:A6
tele/tasmota/SENSOR {"Time":"2017-10-10T07:45:36", "Switch1":"OFF", "BH1750":{"Illuminance":2}}
=>
Switch1=OFF
BH1750.Illuminance=2
tele/tasmota/SENSOR {"Time":"2017-10-10T07:51:02", "Switch1":"ON", "DS18B20":{"Temperature":33.0}, "TempUnit":"C"}
=>
Switch1=OFF
DS18B20.Temperature=33.0
Und gleich stellen sich die Fragen, wie gibt man an, welche Daten wie zu verarbeiten sind, wie man Daten kennzeichnet, die nicht zu verarbeiten sind etc.
Langsam neige ich auch zu sagen, dies in jedem Modul zu machen, wäre falsch. Höchtens als eine Art Fertigbibliothek, die man einfach in verschiedenen Module gleichsam integrieren kann. Hat aber gleichzeitig nur einen geringen Vorteil vor dem Extramodul...
Zitat von: hexenmeister am 10 Oktober 2017, 10:19:30
Und gleich stellen sich die Fragen, wie gibt man an, welche Daten wie zu verarbeiten sind, wie man Daten kennzeichnet, die nicht zu verarbeiten sind etc.
Ich habe das über eine 2. optionale Regex gelöst, die auf das anzulegende Reading matchen muss, damit es angelegt wird, aber das hast Du ja bestimmt schon im Code gesehen.
Die Idee, die eigentliche "JSON->Readings" Funktion in eine generische *Utils.pm Fn auszulagern finde ich gut und würde mein Modul auch darauf umstellen. Mir selbst fehlt im Moment die Zeit dazu.
Ich habe zu wenig Ahnung, aber ist nicht
defmod ej3 expandJSON Sonoff.*:.*:.{.*}
seinerzeit für die Sonoff-Geräte entwickelt, die Lösung des Problems?
Zitat von: dev0 am 10 Oktober 2017, 10:30:46
Ich habe das über eine 2. optionale Regex gelöst, die auf das anzulegende Reading matchen muss, damit es angelegt wird, aber das hast Du ja bestimmt schon im Code gesehen.
Die Idee, die eigentliche "JSON->Readings" Funktion in eine generische *Utils.pm Fn auszulagern finde ich gut und würde mein Modul auch darauf umstellen. Mir selbst fehlt im Moment die Zeit dazu.
Habe ich gesehen. Finde langsam zu viel des Guten, dies in jedem MQTT-Device machen zu müssen, da ist ein extra-Device doch irgendwie elegenter. Es sei denn, wir schaffen das mit einer generischen Bibliothek. Aber das Problem mit der zeit kenne ich auch leider nur zu gut ;D
Zitat von: andies am 10 Oktober 2017, 10:42:23
Ich habe zu wenig Ahnung, aber ist nicht
defmod ej3 expandJSON Sonoff.*:.*:.{.*}
seinerzeit für die Sonoff-Geräte entwickelt, die Lösung des Problems?
Ja, das ist jetzt schon mit dem zusätzlichen expandJSON Device möglich ist. Es kam aber die Idee auf, diese Funktion direkt in das MQTT Modul zu integrieren. Es hätte den Vorteil, dass Anwender, die die regex sehr ungeschickt wählen (zB. .* als Device), theoretisch einen leichten Performancevorteil hätten und keine 2. Devicekonfiguration nötig wäre.
Zitat von: hexenmeister am 10 Oktober 2017, 10:48:41
Es sei denn, wir schaffen das mit einer generischen Bibliothek.
Wäre sinnvoll, ich schreib das mal auf mein todo... Wenn das allerdings jemand anderes in die Hand nimmt, dann wäre ich auch nicht böse, so gar nicht ;)
Mahlzeit!
Um ehrlich zu sein ist mir persönlich ausgesprochen unwohl bei dem Gedanken, dass etwas so Generisches Einzug in ein Modul wie MQTT hält:
- Es ist offenbar jetzt schon durch ein generisches Modul lösbar, wie dev0 korrekterweise feststellt. Das Modul kann separat gepflegt werden (divide et impera) und zudem für mehr als MQTT Verwendung finden. Der Performancegewinn bei Fehlbedienung(!) ist m. E. kein Argument.
- Die Diskussion um die zusätzliche Abhängigkeit von JSON entfällt.
- Kommt nun der nächste verrückte Firmwareentwickler auf die Idee, die Daten per XML oder XLSX zu verschicken, müsste auch das konsequenterweise in MQTT implementiert werden.
Patrick
P. S.: Um ehrlich zu sein kann ich ohnehin nicht nachvollziehen, warum man ein so elegantes, schlankes und flexibles Protokoll wie MQTT dazu verwendet, um json zu verschicken...
Zitat von: PatrickR am 10 Oktober 2017, 18:54:23
P. S.: Um ehrlich zu sein kann ich ohnehin nicht nachvollziehen, warum man ein so elegantes, schlankes und flexibles Protokoll wie MQTT dazu verwendet, um json zu verschicken...
Jajein. Das ist natürlich ein Argument von Schlagheftigkeit was nicht zu vernachlässigen gilt!
Man hat eben wenig Overhead (das Topic) und recht viel Nutzlast (payload) für die Verschickung mit dem json.
Das kleine Sensorgerät hat nicht viel zum Tun. Mqtt-port auf, Daten ausspeien, Port zu. Sonst müssten alle in Portionen gegeben werden.
Server hat die ganze Last!
Guten Morgen zusammen,
ich habe den Thread ausführlich studiert, allerdins hat die diskzssion zu ssl vor ein paar seiten aufgehört.
ich würde gerne daten an einen Remote Mqtt Server senden, nichts hochsicherheitsrelevantes, aber ssl wäre schon schick.
Kommt noch eine SSL funktion um zu gesicherten Servern zu connecten?
liebe grüße
Zitat von: Bapt. Reverend Magersuppe am 09 Oktober 2017, 18:46:10
Zum Beispiel die RGB-Werte an die Strip-Controller. Wenn alles in eim Modul funktioniert wär das doch schläucher.
Oder die stat-Strings vom Tasmota. Da wird eine Menge an Informationen übertragen.
Dies in Readings verwandeln.
Ginge es nicht auch über Userreadings?
PS. Das Thema TLS würde mich auch nach wie vor intressieren, weil ich auch einen Remote MQTT habe und eine Device die senden soll hinter einer Firewall sitzt die keine VPNs zulässt.
Hallo,
Ist es eigentlich möglich auch Funkionen die in der MyUtil sind mit subscribeSet aufzurufen?
Mit:
attr mqtt_bridge subscribeSet_cmd {calcValues($device, $message);; 0} topic/cmd
oder so ähnlich?
Im Log taucht immer was mit
ERROR evaluating { calcValues($device, $message); 0}: Undefined subroutine &MQTT::BRIDGE::calcValues called at (eval 10898) line 1.
auf..
Beste Grüsse
Das Modul verwendet ein package "MQTT::BRIDGE" und dort ist deine Methode unbekannt. Versuche sie explizit anzugeben, das sollte funktionieren:
attr mqtt_bridge subscribeSet_cmd {main::calcValues($device, $message);; 0} topic/cmd
Muss mir anschauen, vlt. stlle ich einen Patch zusammen, damit der Aufruf von externen Funktionen außerhalb von einem package-Namespace passiert.
Danke
Genau das "main::" hat mir gefehlt!
Jetzt funktioniert es.
Würde die Info in die Commandref aufnehmen, das sollte reichen....
Grüsse
Gesendet von meinem Apollo Lite mit Tapatalk
Hallo Leute um einen Doppelpost zu vermeiden der Link zu meinem Mqtt Problem:
https://forum.fhem.de/index.php/topic,73242.msg746780.html#msg746780
Kurzfassung:
Fhem connected und disconnected mehrfach pro Sekunde zum MQTT Broker, der auf dem gleichen system (pi2) ohne Probleme läuft...
An Mqtt hängt bei mir wirklich viel, es wäre super wenn mir jemand helfen könnte :)
Hallo,
Ich benötige mal Hilfe, ich schreibe in den Topic "SENSOR/FEUCHTIGKEIT/01" einen Wert. Mit einer Handy App kann ich das abfragen. Ich bekomme es aber nicht mit FHEM hin. Es wird kein Reading angelegt. Das einzige was ich habe ist:
transmission-state subscription acknowledged 2018-02-03 23:55:43
Ich habe schon mit autoSubscribeReadings und subscribeReading rumgespielt aber ich bekomme es nicht hin. Also ich verstehe es auch gar nicht was ich nun machen muss. Die Hilfe ist da auch nicht besonders hilfreich, zumindest hatte ich es so wie da angegeben probiert.
Hat da mal jemand ein Tip für mich was ich hier falsch mache.
/Daniel
versuche es doch mal in lege dir selbst ein Reading an:
attr (dein_DeviceName) subscribeReading_SENSOR SENSOR/FEUCHTIGKEIT/01
dann solltest du ein Reading "SENSOR" haben wo der MQTT String/Wert drinnen steht.
Es kommt dann drauf an in welchem Format du den MQTT String überträgst, entweder Legacy oder Json und musst es entsprechend filtern.
LGReinhart
Ich bin einfach zu blöde glaube ich, es möchte nicht klappen (ist nur ein wert, kein json):
Internals:
CFGFN
DEF
IODev MQTT_Broker
NAME PSM_Sense
NR 15744
STATE unsubscription acknowledged
TYPE MQTT_DEVICE
READINGS:
2018-02-04 12:36:31 transmission-state unsubscription acknowledged
message_ids:
sets:
subscribe:
Sensor/Feuchtigkeit
subscribeExpr:
^Sensor\/Feuchtigkeit$
subscribeReadings:
Sensor/Feuchtigkeit:
cmd
name Humidity
Sensor/Feuchtigkeit/01:
cmd
name Humidity
Attributes:
IODev MQTT_Broker
room X_Test
stateFormat transmission-state
subscribeReading_Humidity Sensor/Feuchtigkeit/01
Du musst aber unbedingt die Groß/Kleinschreibung der Topic beachten!
wenn du am Broker in der Konsole mitlauscht, wie sieht den der gewünschte MQTT String aus?
mosquitto_sub -d -v -t \#
Ich sehe mir immer den String an und kopiere die gewünschte Topic dann raus wenn ich unsicher bin.
LG
Sollte alles stimmen:
Subscribed (mid: 1): 0
Received PUBLISH (d0, q0, r1, m0, 'Sensor/Feuchtigkeit/01', ... (3 bytes))
Sensor/Feuchtigkeit/01 296
Received PUBLISH (d0, q0, r0, m0, 'Sensor/Feuchtigkeit/01', ... (3 bytes))
Sensor/Feuchtigkeit/01 296
ja, dann muss es so heißen:
define myBroker MQTT 127.0.0.1:1883
define (dein_DeviceName) MQTT_DEVICE
attr (dein_DeviceName) IODev myBroker
attr (dein_DeviceName) subscribeReading_SENSOR Sensor/Feuchtigkeit/01
du hattest es ursprünglich Groß geschrieben.
Broker und FHEM läuft am selben Device?
LG
Ja, das passt aber alles, habe ich richtig. Hatte das nur groß geschrieben damit es sich absetzt ...
Mhh aber komisch, es will einfach nicht. Vielleicht sollte ich das Device nochmal löschen.
/Daniel
ja sollte alles passen, ich poste dir hier einmal einen typischen Device von mir, dann kannst du vergleichen. Hier sind zwar mehr Daten enthalten und die kommen im Json Format, das sollte aber egal sein.
Eventuell Broker und FHEM neu starten versuchen.
Internals:
IODev myBroker
NAME Sonoff_electrodragon2
NR 424
STATE Temperatur: 6.0 Grad Feuchte: 58.0 Lux: 0
TYPE MQTT_DEVICE
Helper:
DBLOG:
BH1750_Illuminance:
myDbLog:
TIME 1517756780.00948
VALUE 0
DHT11_Humidity:
myDbLog:
TIME 1517756780.00948
VALUE 58
DHT11_Temperature:
myDbLog:
TIME 1517756780.00948
VALUE 6
Sensor:
myDbLog:
TIME 1517756779.95076
VALUE {"Time":"2018-02-04T16:06:20", "DHT11":{"Temperature":6.0, "Humidity":58.0}, "BH1750":{"Illuminance":0}, "TempUnit":"C"}
TempUnit:
myDbLog:
TIME 1517756780.00948
VALUE C
Time:
myDbLog:
TIME 1517756780.00948
VALUE 2018-02-04T16:06:20
transmission-state:
myDbLog:
TIME 1517756779.90672
VALUE incoming publish received
READINGS:
2018-02-04 16:06:19 BH1750_Illuminance 0
2018-02-04 16:06:19 DHT11_Humidity 58
2018-02-04 16:06:19 DHT11_Temperature 6
2018-02-04 16:06:19 Sensor {"Time":"2018-02-04T16:06:20", "DHT11":{"Temperature":6.0, "Humidity":58.0}, "BH1750":{"Illuminance":0}, "TempUnit":"C"}
2018-02-04 16:06:19 TempUnit C
2018-02-04 16:06:19 Time 2018-02-04T16:06:20
2018-02-04 16:06:19 transmission-state incoming publish received
message_ids:
sets:
subscribe:
tele/sonoff_electrodragon2/SENSOR
subscribeExpr:
^tele\/sonoff_electrodragon2\/SENSOR$
subscribeReadings:
tele/sonoff_electrodragon2/SENSOR:
cmd
name Sensor
Attributes:
IODev myBroker
alias Garage Tempsensor
group Garage
icon temperature_humidity
room _Garage
stateFormat {sprintf("Temperatur: %.1f Grad Feuchte: %.1f Lux: %.0f", ReadingsVal($name,"DHT11_Temperature",0), ReadingsVal($name,"DHT11_Humidity",0), ReadingsVal($name,"BH1750_Illuminance",0))}
subscribeReading_Sensor tele/sonoff_electrodragon2/SENSOR
LG
OK, das MQTT Modul scheint wohl noch etwas unsauber zu sein, neu anlegen hat geholfen.
Wenn man ein MQTT_Device anlegt fliegt man ja auch erst mal zurück in die Übersicht mit einer "0" anstelle man das Device gleich sieht. Also da ist noch der ein oder andere Bug drin ;-)
/Daniel
Das kenne ich auch, hatte mich mal auch nerven gekostet.
Wenn man ein reading, subscription oder publish ändern möchte MUSS man es löschen und neu anlegen damit es funktioniert.
Gesendet von meinem Leap mit Tapatalk
Hallo Forum!
Ich versuche mich gerade an dem Thema MQTT und habe lokal einen Mosquitto-Server mit Benutzer/Kennwort inkl. TLS/SSL-Verschlüsselung hochgezogen.
https://www.auxnet.de/verschluesseltes-mqtt-vom-und-zum-mosquitto-server/ (https://www.auxnet.de/verschluesseltes-mqtt-vom-und-zum-mosquitto-server/) mit guter Beschreibung...
Nun kommt aber der Teil, das ganze FHEM einzubinden - es gelingt mir net.
Als ich das TLS noch nicht aktiv hatte, konnte sich ein FHEM MQTT_Broker verbinden - nu nicht mehr.
Hat FHEM ein Zertifikatsspeicher, in dem man das Zertifikat vom Mosquitto-Server importieren kann/muss?
Oder, ich habe das in einigen recht alten Beträgen gelesen, das diese Funktionalität (noch) nicht implementiert ist?
MfG
Moin!
User und Passwort sollte gehen, TLS vermutlich nicht. Das Modul benutzt DevIo von FHEM, ob das damit geht weiß ich leider nicht.
Als workaround (wenn du TLS wirklich brauchst, weil z. B. MQTT Server über Internet angebunden ist) kannst du zweiten Mosquitto lokal installieren (ohne Verschlüsselung) und zwischen beiden eine verschlüsselte Bridge konfigurieren.
Danke für deine Antwort.
Aber das war nicht ganz, was ich hören wollen (bez. TLS).
Wo kann man den diesen Funktionswunsch zur Erweiterung platzieren?
Oder sollte man den Entwickler direkt anschreiben um nachzufragen, ob er überhaupt in die Richtung entwickeln möchte?
MfG
Es gab schon Bestrebungen in diese Richtung, findest du im forum. Im meine, dies ist noch nicht integriert worden, ich kenne den Stand aber nicht. Der Maintainer fürs MQTT Modul nutzt im Forum den Nick "eisler".
Und für MQTT gibt es einen eigenen Forumbereich...
Hallo,
TLS steht leider immer noch auf der TODO Liste. Wenn mich dabei jemand überstürzen möchte nehme ich gerne Patches an.
Grüße
Stephan
Zitat von: eisler am 10 Juni 2018, 14:55:22
Wenn mich dabei jemand überstürzen möchte
Hallo Stephan,
überstürzen nicht, aber unterstützen würde ich dabei gerne.
Wollen wir zum Thema TLS-Support vielleicht einen eigenen Thread im richtigen Unterforum aufmachen? Oder noch besser im Developer Bereich, da die Verbindungsverwaltung ja über DevIO erfolgt und eventuell Fragen an Rudi auftauchen können.
Ein paar Tests zu dem Thema habe ich in meiner Testinstallation schon durchgeführt.
Edit: https://forum.fhem.de/index.php/topic,88561.0.html
klar unterstützen nicht überstürzen. :)
Super! Ich denke auch das Problem passt in den Developer Bereich. Andere Module die DevIO verwenden können ja auch von der Lösung profitieren.
Grüße
Stephan
Vielen Dank, das ihr Euch alle mit dem Problemchen beschäftigt!
Hallo,
sicherlich kann mir jemand einen Tipp geben:
Ich möchte meine Sonoffs auf Befehl neu starten.
In der Konsole mit restart 1 funktioniert dieses. Aus Fhem über einen Systemaufruf oder Shellscript habe ich kein Glück.
Kann mir jemand sagen, wie ich es realisieren kann?
Vielen Dank
Update:
Habe es zwischenzeitlich hinbekommen:
{
system "mosquitto_pub -h 192\.168\.178\.111 -t /cmnd/%TOPIC%/Restart -m \"1\"\ ";
}
Moin, ich möchte gerne eine meiner MQTT Lampen über das Modul in FHEM einbinden.
Die Lampe kennt 2 Befehle, ct (von 2500 bis 6500) und pct (von 0 bis 100). Nun hätte ich gerne für pct und ct jeweils einen Slider. Bei einem dummy geht's so:
setList on off ct:colorpicker,CT,2500,10,6500 pct:colorpicker,BRI,0,1,100
Habe beim MQTT Device schon folgendes probiert:
publishSet on off "ct:colorpicker,CT,2500,10,6500" "pct:colorpicker,BRI,0,1,100" light/pct
Dann bekomme ich 2 Slider, diese senden allerdings beide auf light/pct und nicht wie gewünscht auf light/pct und light/ct.
Habe auch schon probiert ct extra anzulegen, dann wird mir aber kein Slider angezeigt.
publishSet_ct "ct:colorpicker,CT,2500,10,6500" light/decke/ct
Geht das wirklich nur über einen Dummy? :(
webCmd hilft nicht?
Sonst wäre MQTT_GENERIC_BRIDGE eine Möglichkeit.
Zitat von: hexenmeister am 27 Oktober 2018, 03:57:05
webCmd hilft nicht?
Sonst wäre MQTT_GENERIC_BRIDGE eine Möglichkeit.
Also ich habe es irgendwie mit webCmd noch nicht geschafft 2 Slider anzuzeigen.
Vielen Dank, schaue ich mir gleich mal an!
Hi,
ich hab seit 30.12.18 plötzlich nur noch ein disconnected, Fhem ist uptodate, und mein Cubietruck auch, auch der Fhem neustart sowie der Neustart des Cubies haben keine Besserung gebracht.
Internals:
DEF 127.0.0.1:1883
DeviceName 127.0.0.1:1883
NAME myBroker
NEXT_OPEN 1546617066.18172
NOTIFYDEV global
NR 371
NTFY_ORDER 50-myBroker
PARTIAL
STATE disconnected
TYPE MQTT
msgid 1
timeout 60
Helper:
DBLOG:
state:
myDbLog:
TIME 1546616450.46702
VALUE connect 127.0.0.1:1883
READINGS:
2019-01-02 20:21:26 connection disconnected
2019-01-04 16:50:06 state disconnected
messages:
Attributes:
room Zentral
der mosquitto Dienst läuft aber
[code]sudo service mosquitto status
* mosquitto.service - LSB: mosquitto MQTT v3.1 message broker
Loaded: loaded (/etc/init.d/mosquitto; generated; vendor preset: enabled)
Active: active (exited) since Thu 2018-12-13 18:30:42 CET; 3 weeks 0 days ago
Docs: man:systemd-sysv-generator(8)
Process: 804 ExecStart=/etc/init.d/mosquitto start (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
CGroup: /system.slice/mosquitto.service
Dez 13 18:30:41 cubietruck systemd[1]: Starting LSB: mosquitto MQTT v3.1 message broker...
Dez 13 18:30:41 cubietruck mosquitto[804]: Starting network daemon:: mosquitto.
Dez 13 18:30:42 cubietruck systemd[1]: Started LSB: mosquitto MQTT v3.1 message broker.
[/code]
Was kann ich machen?
Danke
Hallo Tommy82,
ich muss vorausschicken, dass ich keine tiefgründige Kenntniss über MQTT habe, und deshalb mein Hinweis ins Leere laufen kann.
Ich hatte diesen Fall auch einmal, und damals hat geholfen die Credentials in Fhem neu zu definieren , also
define <MyBroker> MQTT IP:1883 <userID> <password>mit je einer Leerstelle zwischen 1883 <userID> und <password>.
Viel Glück und viele Grüße
Gisbert
Hallo,
ich habe mir einen Dimmer eingerichtet, soweit funktioniert das grundsätzliche, hat aber eine unschöne Eigenschaft.
Schalte ich den Dimmer direkt oder über das Webinterface auf, bleibt der eingestellte Dimmwert gespeichert. Schalte ich ihn über fhem aus wird der Dimmwert immer auf 0 gesetzt, heißt, beim nächsten einschalten ist der dunkelste Wert aktiv.
Kann man dies Eigenschaft umgehen? Wie müsste man die Einstellungen ändern?
defmod WoZi_SofaTisch MQTT_DEVICE
attr WoZi_SofaTisch IODev myBroker
attr WoZi_SofaTisch devStateIcon on:10px-kreis-rot off:10px-kreis-gruen
attr WoZi_SofaTisch eventMap ON:on OFF:off
attr WoZi_SofaTisch group Beleuchtung
attr WoZi_SofaTisch publishSet on off switch:on,off Dimmer:slider,0,10,100 /dimmer/sofa/cmnd/Dimmer
attr WoZi_SofaTisch room Wohnzimmer
attr WoZi_SofaTisch stateFormat POWER
attr WoZi_SofaTisch subscribeReading_POWER dimmer/sofa/stat/POWER
attr WoZi_SofaTisch subscribeReading_RESULT dimmer/sofa/stat/RESULT
attr WoZi_SofaTisch subscribeReading_presence dimmer/sofa/tele/LWT
attr WoZi_SofaTisch subscribeReading_status dimmer/sofa/tele/STATE
attr WoZi_SofaTisch webCmd Dimmer:on:off
setstate WoZi_SofaTisch off
setstate WoZi_SofaTisch 2019-01-12 22:51:24 Dimmer 40
setstate WoZi_SofaTisch 2019-01-12 22:51:24 POWER off
setstate WoZi_SofaTisch 2019-01-12 22:50:24 RESULT {"POWER":"OFF"}
setstate WoZi_SofaTisch 2019-01-12 22:51:24 Wifi_RSSI 56
setstate WoZi_SofaTisch 2019-01-12 22:35:46 presence Online
setstate WoZi_SofaTisch 2019-01-12 22:49:30 state ON
setstate WoZi_SofaTisch 2019-01-12 22:51:24 status {"Time":"2019-01-12T22:51:24","Uptime":"0T10:16:53","Vcc":3.466,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"POWER":"OFF","Dimmer":40,"Fade":"OFF","Speed":1,"LedTable":"OFF","Wifi":{"AP":1,"SSId":"Airport","BSSId":"7C:FF:4D:5A:F0:56","Channel":1,"RSSI":56}}
setstate WoZi_SofaTisch 2019-01-12 22:51:24 transmission-state incoming publish received
defmod WoZi_SofaTisch_json expandJSON WoZi_SofaTisch:(status|RESULT):.{.*} (Wifi_RSSI|POWER|Dimmer)
Ich kenne das Problem. Die Lösung würde mich auch sehr interessieren.
Hallo,
ich habe eine MQTT-Frage (bzw. generell wohl zu readings).
Ich habe mir ein MQTT_DEVICE eingerichtet und einen Slider ( attr publishSet brightness:slider,0,0.5,100,1 awtrix/com )
Eingerichtet, wie man schon sieht soll der die Helligkeit meiner AWTRIX matrix regeln.
jetzt sendet der aber nur die reinen Werte also z.B. '12.5'.
Die Matrix will aber 'bri%12.5' haben. Wie kann ich denn dem Slider sagen, dass er den String 'bri%' davorhängen soll und erst dann alles verschickt?
Danke im Voraus :)
Ein list vom Device würde weiterhelfen,
außerdem gibt es einen MQTT Thread.
https://forum.fhem.de/index.php?board=94.0 (https://forum.fhem.de/index.php?board=94.0)
Ich würde die Frage dort stellen und deinen Beitrag hier löschen. ;)
Zitat von: freakadings am 13 Januar 2019, 15:26:04
Hallo,
ich habe eine MQTT-Frage (bzw. generell wohl zu readings).
Ich habe mir ein MQTT_DEVICE eingerichtet und einen Slider ( attr publishSet brightness:slider,0,0.5,100,1 awtrix/com )
Eingerichtet, wie man schon sieht soll der die Helligkeit meiner AWTRIX matrix regeln.
jetzt sendet der aber nur die reinen Werte also z.B. '12.5'.
Die Matrix will aber 'bri%12.5' haben. Wie kann ich denn dem Slider sagen, dass er den String 'bri%' davorhängen soll und erst dann alles verschickt?
Danke im Voraus :)
Du kannst das z.B. mit MQTT_GENERIC_BRIDGE anstatt MQTT_DEVICE machen. Damit kannst Du ein Dummy erstellen mit allen nötigen Slidern etc. und diesen per GenericBridge 'mqtt-fähig' machen. Zusätzlich zu Topic kannst Du noch expression angeben, dass die zu versendende Nachricht nach Wunsch erweitert.
Vielen Dank euch beiden :)
Hallo zusammen,
ich werde mich auch mal mit MQTT beschäftgen (müssen). Nun eine kurze Frage zur Hardware, ich habe einen Raspberry Pi3 auf dem laufen FHEM, Pilight und Homebridge - alles meiner Meinung nach mit geringer Last. Der sollte einen MQTT Broker doch noch zusätzlich verpacken, oder wie sind da eure Erfahrungen??
Beste Grüße
Jan
Mosquitto erzeugt sehr wenig Last. Kommt natürlich trotzdem auf das Nachrichtenaufkommen an. Für das, was normalerweise so zuhause anfällt, wirst du keine zusätzliche Belastung merken.
Zitat von: Beetle2003 am 01 August 2018, 08:31:56
Hallo,
sicherlich kann mir jemand einen Tipp geben:
Ich möchte meine Sonoffs auf Befehl neu starten.
In der Konsole mit restart 1 funktioniert dieses. Aus Fhem über einen Systemaufruf oder Shellscript habe ich kein Glück.
Kann mir jemand sagen, wie ich es realisieren kann?
Vielen Dank
Update:
Habe es zwischenzeitlich hinbekommen:
{
system "mosquitto_pub -h 192\.168\.178\.111 -t /cmnd/%TOPIC%/Restart -m \"1\"\ ";
}
Wo muss man das eintragen und wie kann man das aufrufen?
Gruß Chris
Zitat von: chq am 09 April 2019, 06:53:27
Wo muss man das eintragen und wie kann man das aufrufen?
wie sieht dein MQTT Device denn aus ?
Wenns vom Typ MQTT2_Device ist einfach die setList und setStateList um den reset Befehl erweitern ( cmnd/deinTopic/restart 1 )
Mein MQTT ist noch der erste Typ, sprich nur MQTT.
Alle IO's kennen auch das direkte publishen (also 00_MQTT, 00_MQTT2_SERVER und 00_MQTT2_CLIENT).
Die genause Syntax steht jeweils in der cref.
Man muß also nicht auf die Systemebene ausweichen.
Und auch ein MQTT_DEVICE müßte sich um einen restart-Befehl erweitern lassen.
also TYPE = MQTT_DEVICE ? die haben halt das attribut publishSet in dem die Kommandos hinterlegt sind
Ok, cool. Werd's ausprobieren, danke.
Gruß Chris
Edit: Hab's hinbekommen. Vielen Dank Euch!
attr steuerung publishSet_RESTART 1 cmnd/steuerung/RESTART
set steuerung RESTART 1
("steuerung" ist hierbei das MQTT-Device, welches gesteuert werden soll)
Zitat von: freakadings am 12 Januar 2018, 14:27:39
Hallo Leute um einen Doppelpost zu vermeiden der Link zu meinem Mqtt Problem:
https://forum.fhem.de/index.php/topic,73242.msg746780.html#msg746780
Kurzfassung:
Fhem connected und disconnected mehrfach pro Sekunde zum MQTT Broker, der auf dem gleichen system (pi2) ohne Probleme läuft...
An Mqtt hängt bei mir wirklich viel, es wäre super wenn mir jemand helfen könnte :)
selbe Fehler hier mit FHEM (Docker), und Mosquitto läuft in einem weiterem Container. Wenn ich User+ Passwort vergebe, verbindet FHEM nicht mehr, ohne geht es
Zitat von: Typ1er am 16 Februar 2020, 23:12:37
selbe Fehler hier mit FHEM (Docker), und Mosquitto läuft in einem weiterem Container. Wenn ich User+ Passwort vergebe, verbindet FHEM nicht mehr, ohne geht es
Hatte das Problem auch mit Docker FHEM und MQTT auf einer Synology. Gelöst habe Ich es, indem Ich dem FHEM Docker einen 2.ten Schnittstelle spendiert habe! Also in Docker habe Ich eine 2.te Netzwerkbrücke konfiguriert und der FHEM Container greift jetzt auf beide Schnittstellen zu!
Das Problem hat sich geklärt, das Passwort nachträglich zu ändern klappt nicht in FHEM, sonder nur beim ersten Mal über das define. Im Anschluss die Client-ID noch vergeben, einmal FHEM neustarten und es läuft.
Hallo, habe mal eine kurze Frage:
Kann man bei gewissen topics mit retain publishen und bei anderen nicht oder gilt das retain immer für alle topics?