neues Modul MQTT - Bridge zwischen mqtt und fhem

[hexenmeister]

beim qos ist mir auch noch nicht so recht klar, ob sich das auf die Message bezieht, die man aktuell abschickt, oder ob man beim subscribe angeben kann, mit welchem qos man messages zugestellt bekommen möchte (ich denke es ist ersteres...)

Da habe ich gestern auch drüber gegrübelt... Ich halte das erste auch für logischer.

[ntruchsess]

ich hab mir gestern mal die spec zum qos reingezogen. Das ist bei weitem nicht so automatisch, wie man erwartet - da muss der mqtt-client aktiv mitarbeiten. Ich mach mich mal dran, das im Modul zu implementieren...

Gruß,

Norbert

[hexenmeister]

Oha, muss ich mir auch mal durchlesen. Also beiseitig zu unterstützen... Mosquitto wird das wohl können, wäre zu prüfen, ob der MySensors-MQTT-Sketch das auch tut (bezweifle ich, beim kurzen Überblicken sah der Sketch rech einfch gestrickt aus).

[ntruchsess]

gerade eingecheckt: neues Attribut MQTT_DEVICE 'autoSubscribeReadings'

'attr <name> autoSubscribeReadings wohnzimmer/+' sorgt dafür, dass für alle empfangenen Messages automatisch das jeweils passende 'subscribeReading_xxx'-Attribut erstellt und das zugehörige Reading auch gleich geupdated wird.

(zum qos noch nix neues...)

Gruß,

Norbert

[ntruchsess]

so, qos ist jetzt implementiert.

Das MQTT-modul macht nach einem Reconnect einen Retransmit aller noch nicht bestätigten (acknowledged bzw. completet) Messages.

Gruß,

Norbert

[ntruchsess]

und 'retain' geht jetzt auch

Wenn man das Attribut 'retain' setzt, dann persistiert der mqtt-broker die jeweils letzte Message und stellt diese einem Client der ein Topic neu aboniert unabhängig vom Vorhandensein des eigentlichen Senders erneut zu.

Sehr nütztlich, wenn z.B. ein GUI beim Verbinden den jeweils letzten Stand einfach so zugespielt bekommen soll.

.....

das wars dann erst mal. Wer Ideen hat, was noch fehlt oder nützlich wäre, einfach hier im Thread posten...
Ich habe beispielsweise noch kein Konzept, wie ein echtes Autocreate von Devices sinnvoll funktionieren sollte.

Gruß,

Norbert

[hexenmeister]

Das ist sehr cool! Ich werde hute später mal testen.

Ob man MQTT-Gateway von MySensors dazu bringen kann, auch dies zu unterwstützen?.. Am besten mit der Möglichkeit, nicht versendete Meldungen zwischen zu speichern (SDCard-BreakoutBoard?). Dann würde gar nichts mehr verloren gehen, ob FHEM gerade läuft oder nicht.

Autocreate dürfte nicht ganz infach sein. Man kann ja nicht einfach alles anlegen, was da möglicherweise ankommt. Evtl. könnte man sich ein Schema für Sensoren/Aktoren überlegen. Eine Art Speziallmessage oder so, die zu anlage führt. Meinetwegen soll diese beim 'Pairen' (ein Knopf?) abgesetzt werden...

Ob man Deine Module zum Verbinden von 2 FHEM-Instanzen nutzen kann? Eine Art "Weitergereichte Devices", mehr oder weniger transparente Behandlung. Sensoren wie Aktoren...

Ideeen, Ideen... Ich denke, das hat noch Potential

[hexenmeister]

Hallo Norbert,

ich weiß nicht, ob Du das schon gesehen hast, da hat jemand eine Fehlermeldung bei einem Versuch mit FQTT:
http://forum.fhem.de/index.php/topic,27729.0/topicseen.html

Grüße,

Alexander

[hexenmeister]

Hallo Norbert,

entweder ich habe etwas nicht verstanden und mache was falsch, oder es tut mit qos immer noch nicht.

Also, ich habe folgendes angelegt:

Code Auswählen Erweitern

define lichtwohnzimmer dummy
define mqtt MQTT 127.0.0.1:1883
define mqtt_licht_wohnzimmer MQTT_BRIDGE lichtwohnzimmer
attr mqtt_licht_wohnzimmer subscribeSet fhem/wohnzimmer/licht/set
attr mqtt_licht_wohnzimmer publishState fhem/wohnzimmer/licht


testen:

Code Auswählen Erweitern

mosquitto_pub -q 2 -t fhem/wohnzimmer/licht/set -m test100
funktioniert.

dann

Code Auswählen Erweitern

sudo service mosquitto stop
sudo service mosquitto start

und sofort danach

Code Auswählen Erweitern

mosquitto_pub -q 2 -t fhem/wohnzimmer/licht/set -m test101

Kommt nicht an.

Grüße,

Alexander

[ntruchsess]

Kommt nicht an.

kommt an, wenn nach dem Restart das MQTT-modul wieder reconnected und die topic-subscriptions erneuert hat, bevor die Message gesendet wurde. Der qos bezieht sich wohl nur auf aktuell verbundene Geräte und deren Subscriptions und stellt sicher, dass Messages vom Empfänger bestätigt und falls das ausbleibt ggf noch mal gesendet werden (Man kann einer offenen Socketverbindung ja nicht ansehen, ob die Software am anderen Ende noch läuft, oder ob gesendete Daten einfach im schwarzen Loch verschwinden...). So was wie 'persistente Subscriptions' scheint es nicht zu geben.

Dafür gibt es aber 'retain'. Messages, die mit diesem Flag an ein Topic geschickt werden, werden vom Broker gespeichert und jedem Client der neu verbindet und das Topic aboniert zugestellt, (unabhängig davon, ob der ursprüngliche Sender noch verbunden ist).

Schick die Message mal mit '-r'

Gruß,

Norbert

[hexenmeister]

Danke, mit dem Parameter -r kommt die Meldung nach dem erfolgten Reconnect an. Dauert zwar ein bischen...
Schon eine coole Sache

[hexenmeister]

Ich schreibe mal hier rein, weil der Original-Thread-Ersteller hier nicht schreiben darf...

Eine Feature-Anfrage von smurfix bezüglich Username+Passwort für den Broker: http://forum.fhem.de/index.php/topic,32528.msg249314.html#msg249314

[smurfix]

Jetzt darf ich ...
Patch ist hier.

[John]

Hallo Norbert,
funktioniert ganz prächtig deine MQTT Anbindung.

Ich habe einen Arduino Uno mit DHT22 (Temperatur und Feuchte) als MQTT-Device eingebunden.
Geichzeitig subscribed er sich auf die Vorlauftemperatur meiner Heizung über die MQTT-Bridge.

Damit haben wir die erste normative, allgemeingültige Datenschnittstelle im FHEM (soweit ich weiss).

Vielen Dank für deine Arbeit
John


PS: den "Last Will" vermiss ich, aber der kommt ja vielleicht noch.