MQTT

[dev0]

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

[hexenmeister]

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.

[Bapt. Reverend Magersuppe]

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:

Code Auswählen Erweitern


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.

[hexenmeister]

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?

[dev0]

average, statistics & Co. kann man sich dann aus den Readings bauen.

Das trifft auf JSON genauso zu.

[dev0]

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.

[hexenmeister]

Mein Verständnis sagt, es müsste so etwas in der Art werden:

Code Auswählen Erweitern

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...

[dev0]

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.

[andies]

Ich habe zu wenig Ahnung, aber ist nicht

Code Auswählen Erweitern

defmod ej3 expandJSON Sonoff.*:.*:.{.*}
seinerzeit für die Sonoff-Geräte entwickelt, die Lösung des Problems?

[hexenmeister]

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

[dev0]

Ich habe zu wenig Ahnung, aber ist nicht

Code Auswählen Erweitern

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.

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

[PatrickR]

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...

[Bapt. Reverend Magersuppe]

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!

[Floca]

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

[drdownload]

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.