Sammel-MQTT-Publish für mehrere Datenpunkte?
-
@kater klingt doch cool - schreib ein passendes Skript was das alles macht ... das wäre dein Workaround
kannst natürlich auch auf GitHub das als Issue als Featurerequest absetzen. Ich kann mir beim besten willen nicht vorstellen das es als Feature geplant ist.
Daten werden aktualisiert (und ggf. aufgezeichnet) wenn sich der Datenpunkt ändert. Das muss im Normalfall auch so sein.
Die Zeitstempel kannst du am besten erreichen indem du die Daten einfach nimmst und direkt in die Datenbank schreibst - dann kannst du nämlich den Zeitstempel mitgeben so das alle einfach den gleichen nutzen. -
Mit NodeRed ist es easy. Alles in einem Kontextobjekt sammeln und mit meinem Flow das Objekt schreiben.
https://forum.iobroker.net/topic/43856/json-oder-javascript-objekt-in-iobroker-datenpunkte-zerlegen
-
@mickym Was du mit deinem Flow machst, ist genau die andere Richtung, nämlich von draußen kommend in ein ioBroker-Objekt.
Ich will dagegen ein zusammengesetztes ioBroker-Objekte nach einem Update durch z.B. eine Gerätekopplung quasi en bloc (d.h. 1:1 als JSON-Struktur) auf MQTT absetzen, um es dann ebenso zusammenhängend in meine InfluxDB zu schreiben. -
@kater Na dafür sammelst Du alles in einer JOIN Node und schreibst das Objekt mit einer JSON Node wieder in den Datenpunkt. Oder Du sammelst alles im Flow Kontext und speicherst es dann weg, wann Du willst.
-
@bananajoe Das (Node-RED-)Skript, das das macht, habe ich ja schon. Mich stört nur, dass es zum einen strukturspezifisch angepasst sein muss, und zum anderen, dass es sich auf eine Heuristik verlassen muss, d.h. ich muss die Zeitstempel so „π * Daumen“ ansetzen, dass zusammengehörende Änderungen auch korrekt zusammengefasst werden. Und ich empfinde es als nicht sooo sinnvoll, zusammengehörige Daten erst zu zerlegen und dann wieder „ungefähr“ zusammenzufassen
. -
@mickym Meinst du mit "JOIN Node" den Node aus
node-red-contrib-join? Muss ich mir mal angucken. Könnte aber problematisch werden, weil ich nicht weiß, in welcher Reihenfolge die zerlegten Einzelmeldungen eintrudeln. Bestenfalls habe ich wieder eine Heuristik, weil ich mir das ein paar Mal angucke und dann feststelle, dass typischerweise eine bestimmte Komponente als letzte generiert wird – wenn das so ist. -
@kater Die JOIN Node erstellt Dir ein Objekt, wo Du bestimmen kannst wann ein Objekt fertig ist. Wenn Du die Anzahl auf 1 setzt dann baut sich das Objekt auf. Ansonsten wird mit jeder Nachricht nur die entspechende Eigenschaft aktualisiert und kann weggeschrieben werden:
Wann was eintrudelt ist egal - weil nach jedem Update auch das ganze Objekt geschickt wird.
-
@mickym said in Sammel-MQTT-Publish für mehrere Datenpunkte?:
Wann was eintrudelt ist egal - weil nach jedem Update auch das ganze Objekt geschickt wird.
Das wäre eher kontraproduktiv. Wenn z.B. drei Einzelwerte zusammengehören und im Minutenrhythmus aktualisiert werden, dann wird knapp 60 Sekunden nach dem letzten Update der erste neue Wert in den Node gesendet. Der kombiniert ihn dann mit den anderen beiden alten Werten und schickt alles raus. Beim zweiten Wert passiert das entsprechend nochmal, erst beim dritten werden sie alle korrekt zusammengefasst.
Aber dein Screenshot zeigt, dass man das auch zeitgesteuert konfigurieren kann. Wenn man „bei Zeitablauf nach erster Nachricht von“ z.B. auf 5 Sekunden setzt, ist man wohl einigermaßen auf der sicheren Seite. Vielleicht probiere ich das dann beim nächsten Mal, bis auf weiteres lasse ich meinen Flow mit Speicherung im Kontext laufen. Der macht ja im Prinzip dasselbe
-
@kater Nun Du kannst aber mit der Anzahl der Nachrichten und ohne den Haken dass bei jeder nachfolgenden Nachricht geschickt wird - quasi warten bis alle Eigenschaften aktualisiert wurden und selbst wenn eine zweimal reinkommt, wird immer nur das komplette Objekt gesendet. Macht die Node alles automatisch
-
@mickym Ja, klar. Trotzdem muss ja irgendwie der Zusammenhang definiert sein bzw. festgestellt werden. Entweder durch die zeitliche Lücke zwischen zwei „Nachrichtenschauern“ (→ Timeout-Parameter) oder durch eine feste Reihenfolge, bei der bekannt ist, welche Komponente als letztes kommt.
Im übrigen muss ich nach dem Join-Node dann ohnehin nochmal mit JS drübergehen und die erzeugte Struktur mit dem
joinedMsgs-Array etc. umbauen in die Ziel-Struktur, die an die Datenbank weitergeleitet wird. Da wäre dann vielleicht der Vorteil gegenüber meinem alten Workaround auch nicht mehr so groß. -
@kater sagte in Sammel-MQTT-Publish für mehrere Datenpunkte?:
oder durch eine feste Reihenfolge, bei der bekannt ist, welche Komponente als letztes kommt.
Nein eben nicht. Die Reihenfolge ist egal - wenn Du die Anzahl der Nachrichten auf die Anzahl der Eigenschaften im Objekt setzt, wird es erst geschickt, wenn es vollständig ist, egal wie die Nachrichten eintrudeln. Der Zusammenhang wird anhand der topics ermittelt, die ja dann Eigenschaften im Objekt sind (falls Du msg. topic) verwendest.
-
@mickym Das setzt voraus, dass Join-Node und Nachrichten synchronisiert sind. Das ist höchstwahrscheinlich der Fall, aber sobald z.B. eine Nachricht verlorengeht oder eine Seite während eines Bulks neu gestartet wird, verschiebt sich alles.
-
@kater Ja klar - dann bist natürlich mit dem Zeitintervall besser dran, wenn Du nicht garantieren kannst, dass alle Nachrichten zusammengehörig kommen.
