Berechnung erst starten sobald mehrere Werte aktuell sind

[paul53]

@mickym sagte: alle Werte mit einer JOIN Node in einem Objekt sammelt. Erst wenn die Anzahl der Werte/Eigenschaften voll ist, wird dieses Objekt weitergegeben.

Die Idee ist nicht schlecht, nur dass Objekte in Blockly schlecht unterstützt werden, so dass man besser ein Array verwendet.

[OliverIO]

@christian23
Nur mal eine Logik frage.
Ab wann werden den die Werte alt und ein bereits als gemeldeter wert müsste dann wieder zurückgesetzt werden?
Warum ist die Berechnung nicht zustandslos,
Also es kann zu jedem Zeitpunkt mit allen Werten gerechnet werden egal wie alt/ aktuell sie sind?
Ich fürchte wenn du dein beschriebenes Problem gelöst hast, wird ein neues auftauchen das mein beschriebenes Szenario zur Grundlage hat.

Aber zu dieser Lösung.
ich würde es über ein bit register lösen.
du nimmst eine variable oder datenpunkt und setzt ihn auf 0. das passiert auch immer nachdem deine berechnung erfolgt ist.
jeder wert auf den du wartest ist ein bit in diesem wert, also

2**0 für datenpunkt 1
2**1 für datenpunkt 2
2**2 für datenpunkt 3
2**3 für datenpunkt 4

und sofort
jedem dieser positionen 0,1,2,3 ordnest du einen datenpunkt zu
wenn sich nun ein wert ändert, setzt du das entsprechende bit
mit folgender operation, hier am beispiel dem 4.datenpunkt
in register mekrst du die den aktuellen meldestatus

register |=2**3

wenn du auf alle 4 werte wartest, dann prüfst du bei jeder Meldung dann am Ende ob register einen gewissen wert überschreitet, also

if (register>= (2**0+2**1+2**2+2**3)) {
  //hier dann deine berechnung
}

Anmerkungen
Für den Ausdruck 2**0+2**1+2**2+2**3 kannst du auch den berechneten Wert hinschreiben also in diesem Fall 15

den ** operator aus javascript kennst du in der mathematik normalerweise als ^ Operator, dieser hat in javascript aber eine andere bedeutung

[mickym]

@oliverio Nein die JOIN Node funktioniert so, dass alle Werte in ihren Eigenschaften oder beim Array halt die Indizes aktualisiert werden (Arrays sind ja in JS streng genommen auch Objekte mit dem Index als Eigenschaft ), das Objekt aber erst released wird, wenn die letzte Eigenschaft gesetzt ist. Dann beginnt das wieder von vorne. Insofern sind alle Werte aktuell bzw. entsprechen dem letzten gelieferten Stand, wenn released wird, aber die letzte Eigenschaft bestimmt wann.

Aber Du hast natürlich Recht - wenn der letzte Wert mal ganz ausfällt und am nächsten Zyklus als Erstes meldet, dann sind in den anderen Eigenschaften noch die alten Werte drin. Also funktioniert das ganze nur, wenn die Werte in einem Zyklus zuverlässig kommen. In einer JOIN Node - kann man das auch resetten, so dass man dann wieder von vorne anfangen kann, wenn in einem bestimmten Zeitraum kein Objekt/Array released wurde. Müsste man hier halt alles manuell abbilden.

[paul53]

@mickym sagte: wenn der letzte Wert mal ganz ausfällt und am nächsten Zyklus als Erstes meldet

Es sind verschiedene Geräte, die in unterschiedlichen Zeitabständen senden, also gibt es keinen Zyklus in dem Sinne. Das Gerät mit der niedrigsten Sendefrequenz bestimmt i.d.R. den Zyklus.

[mickym]

@paul53 sagte in Berechnung erst starten sobald mehrere Werte aktuell sind:

@mickym sagte: wenn der letzte Wert mal ganz ausfällt und am nächsten Zyklus als Erstes meldet

Es sind verschiedene Geräte, die in unterschiedlichen Zeitabständen senden, also gibt es keinen Zyklus in dem Sinne. Das Gerät mit der niedrigster Sendefrequenz bestimmt i.d.R. den Zyklus.

Richtig, das Gerät mit der niedrigsten Sendefrequenz bestimmt den Zyklus. - Ich hatte ja nur mal den Fall geschildert, dass wenn dieses Gerät mal gar nichts meldet, man dann ggf. den Zyklus resetten müsste, um quasi den Zyklus "beieinander" zu behalten.

[mickym]

@oliverio, @paul53 Na am Prinzip ist das nun egal, ob ich es über ein Bitregister, ein Array und Index oder ein Objekt mit Eigenschaften lösen.

Das Prinzip ist doch in allen 3 Fällen das Gleiche, das gewartet wird bis alles vollständig ist.

[OliverIO]

@mickym sagte in Berechnung erst starten sobald mehrere Werte aktuell sind:

Nein die JOIN Node funktioniert

ich weiß wie die join node funktioniert.
in meinem ersten absatz wollte ich nur darauf hinweisen, warum nicht zu jedem zeit die werte zur Berechnung verwendet werden können.
Das was ihr im folgenden Beschrieben habt mit, der kürzeste Zyklus bestimmt die Berechnung entspricht ja dem was ich gesagt habe, das bei jeder Änderung die Berechnung durchgeführt werden kann.

In meinem 2.Absatz habe ich versucht einen javascript lösungsweg aufzuzeigen, falls er nicht node red verwenden will.

[mickym]

Super: Dann haben wir jetzt für alle 3 am häufigsten benutzten Logikmaschinen eine Lösung. -
Ich denke aber - @paul53's Lösung wird wahrscheinlich siegen. - Der TE hat es ja in die Blockly Rubrik gestellt.

- So was sollten wir öfter machen.

[Homoran]

@paul53 sagte:

@mickym sagte: wenn der letzte Wert mal ganz ausfällt und am nächsten Zyklus als Erstes meldet

Es sind verschiedene Geräte, die in unterschiedlichen Zeitabständen senden, also gibt es keinen Zyklus in dem Sinne. Das Gerät mit der niedrigsten Sendefrequenz bestimmt i.d.R. den Zyklus.

und selbst wenn dann nur noch seltener gerechnet wird müssen die Werte nicht passen.
ich rechne nur den Hausverbrauch aus Smartmeter und Wechselrichter.
dazu startet die Abfrage des Wechselrichter wenn der Smartmeter liefert.

Bei stark wechselnder Bewölkung habe ich dann falsche Verbrauchswerte

[paul53]

@homoran sagte: müssen die Werte nicht passen.

Richtig. Aber die Wahrscheinlichkeit ist höher, dass die Werte zueinander passen - vor allem dann, wenn ein Gerät mit hoher Frequenz (alle 2 s) sendet. Wenn das langsame Gerät allerdings intern eine zeitliche Mittelwertbildung vornimmt, müsste diese für das schnelle Gerät nachgebildet werden.

[mickym]

Ich finde den Median eh viel besser, als die Mittelwertbildung - da damit einfach Ausreißer besser ausgefiltert werden.

[OliverIO]

@mickym sagte in Berechnung erst starten sobald mehrere Werte aktuell sind:

Der TE hat es ja in die Blockly

ach herrjeh, dann hätt ich ja nix schreiben müssen, leider nicht gesehen

[Christian23]

@oliverio
Herzlichen Dank für die Info. Ich werde es probieren, damit umzusetzen.

[Andersmacher]

@christian23 Ich möchte mich in Eure Diskussion nicht einmischen, aber einen kurzen Hinweis geben:
Seid Ihr sicher, daß das Problem (nur) an unterschiedlichen Zeitpunkten/Laufzeiten für Berechnungen in Euren Skripten liegt?
Ich meine mich zu erinnern (finde ihn aber momentan nicht), daß es bereits einen Thread zu dieser Problematik gibt, der als Ursache die MOD-Bus-Abfrage der PV-Werte aus dem WR nennt. Zu mindest bei mir ist das auch so:
Die Rückgabewerte einer Modbusabfrage des WR beinhalten Werte, die (zumindest teilweise) aus unterschiedlichen Meßperioden innerhalb des WR stammen, je nach dem, wann genau die Modbusabfrage gestartet wurde. Das Problem tritt aus meiner Sicht also bereits beim Beschreiben der Modbusregister im WR auf. Ich habe nicht in Erinnerung, daß es dafür damals eine Lösung gab.

[Matzebhv]

@paul53 Moin, ich versuche grade dein Blockly zu verstehen. An welcher Stelle des Blockly wird denn die Variable "result" befüllt? Oder fehlt hier die Berechnung der Werte?

Gruß
Matze

[paul53]

@matzebhv sagte: Oder fehlt hier die Berechnung der Werte?

Ja, result ist das Ergebnis einer beliebigen Berechnung.

[Matzebhv]

@paul53 Danke für deine Antwort. Die Berechnung würde an Stelle des Kommentar stehen, oder? Bin bei Schleifen nicht wirklich sattelfest.

Gruß
Matze

[paul53]

@matzebhv sagte: Die Berechnung würde an Stelle des Kommentar stehen, oder?

Ja.

[Matzebhv]

@paul53 Das Blockly funktioniert wesentlich besser als die Mittelwertbildung, die ich bis jetzt benutzt habe. Danke für den Denkanstoß, deine Beispiele sind immer absolut Lehrreich!
Gruß
Matze