MQTT_BRIDGE - Frage zum Attribut 'publishReading_.*'

[ohweh]

Hallo Norbert,

ich spiele gerade mit dem Modul MQTT_BRIDGE. Ich habe zahlreiche Devices, welche wiederum über noch mehr Readings (>100) verfügen. Ich möchte sämtliche Readings an MQTT übergeben. Wenn ich nun jedes zu publizierende Reading einzeln spezifiere, wird die Config reichlich unleserlich. Darüber bietet es Raum für "Fehler", denn wenn neue Readings hinzukommen, kann man das Bridge-Device ja schnell mal vergessen.

Ich bin aber auch auf das Attribut "publishReading_.*" gestossen, welches von MQTT-BRIDGE jedoch aktuell nicht unterstützt zu werden scheint. Kannst Du vielleicht kurz erläutern, wie Du dieses Attribut zu verwenden gedenkst? Als Flag (true/false), oder als Basis für ein RegEx gegen existierende Readings?

Ich könnte die Funktionalität gut gebrauchen, sie würde die Konfiguration erheblich verschlanken. Ich hab Dir schonmal ein paar Zeilen per PM geschickt, diese würden zumindest mal die Flag-Funktionalität abdecken. Vielleicht kannst Du Dir das mal anschauen?

Danke und Gruss
Oliver

[ntruchsess]

Das Attribut 'pubishReading_*' ist kein Attributname im eigentlichen Sinne, sondern eine Regexp gegen die fhem den übergebenen Attributnamen validiert. FHEMWeb unterstützt das halt nicht vernünftig, deshalb sieht es da wie ein normales Attribut aus und man kann die 'publishReading_xxx'-Attribute auch nur über die Kommandozeile anlegen bzw. ändern.

Das was Du brauchst sollte man vieleicht besser 'publishAllReadings' oder so nennen, allerdings sollte man das Schema, nach dem die Topics abgeleitet werden irgendwie sinnvoll konfigurieren können. Hättest Du da Vorschläge, wie das aussehen könnte?

[ohweh]

Na ja, ich für meinen Fall fänd's schon hinreichend, wenn das Topic auf 'publish-topic-base' basieren würde (bzw. auf dem Device-Name, falls das Attribut nicht gesetzt ist), ergänzt wiederum um den Namen des Readings... Ist das zu kurz gedacht?

Dann wär da noch was... Siehst Du eine Möglichkeit, wie man die Readings vor dem Publish noch bearbeiten kann? E.g. durch eine User-definierte Funktion? Insbesondere wenn mit "Retain" gearbeitet wird, wird der Timestamp eines Readings wichtig... sonst weiss die Gegenseite beim Subscribe nicht, ob der initiale Wert halbwegs aktuell ist. Das könnte man natürlich auch im Modul parametrisierbar machen... aber was, wenn man die Values dann z.B. gern als JSON übergeben möchte um sie im Browser besser auswerten zu können? Aber eines nach dem anderen...

Gruss
Oliver

[ntruchsess]

ich persönlich würde das eher auf eine Topic-hirarchie abbilden. Also so in der Art:

basetopic/value
basetopic/timestamp

ich weiß aber auch nicht, was bei mqtt bezüglich des message-formats da so 'best practice' ist. Und es sitzt ja nicht immer ein Browser oder node.js am anderen Ende. Wenn es Dir um einfachen Javascript-zugriff geht, solltest Du Dir mal mein neues websocket-modul ansehen.

- Norbert

[Wzut]

Hallo Norbert,
habe die Tage zum ersten Mal die MQTT-Bridge eingesetzt und bin begeistert wie einfach man damit Daten von A mach B bekommt.
Wird es zum Thema  autoSubscribeReadings noch eine direkte Unterstützung für den # Joker geben ?
Setzt man das # Zeichen heute am Ende ein werden alle empfangenen Topics unter subscribeReading_ vereint, da der / im Reading Namen nicht zulässig ist.
Wäre schön wenn der Slash automatisch in ein Underline (_ ) konvertiert werden könnte, bzw. es wäre mir schon sehr damit geholfen zu wissem an welcher Stelle im MQTT_BRIDGE Modul ich dafür ansetzen müsste.