Durchfluss Liter/Min aus Zählerstand

[paul53]

@klassisch sagte: Wenn man z.B. alle Minute neue Daten bekommt (egal ob gepusht oder gepullt) braucht man dieses extra Nullen nicht.

Das ist richtig. Man hat bei einer Zählerauflösung von 1 l aber keine Nachkommastellen, sondern der Wert schwankt zwischen zwei Integer-Werten.

@klassisch sagte in Durchfluss Liter/Min aus Zählerstand:

Das Zyklische Nullen verfälscht die Flusswerte, meine ich.

Es wird nicht zyklisch genullt, sondern nur, wenn lange genug nicht mehr getriggert wird, weil sich der Zählerstand nicht ändert.

[klassisch]

@paul53 sagte in Durchfluss Liter/Min aus Zählerstand:

Das ist richtig. Man hat bei einer Zählerauflösung von 1 l aber keine Nachkommastellen, sondern der Wert schwankt zwischen zwei Integer-Werten.

Wenn der Zähler steht, dann wird der Zählerdes Bruchs und damit der berechnete Durchfluss Null.

Es wird nicht zyklisch genullt, sondern nur, wenn lange genug nicht mehr getriggert wird, weil sich der Zählerstand nicht ändert.

Ja, da hast Du recht und ich habe es falsch geschrieben Genullt wird nach einem (beliebig gewähltem) timeout. In dieser Timeout Zeit kann was falsches angezeigt werden. Es wird noch Durchfluss gezeigt, obwohl keiner mehr da ist.

Meine Wasserzähler ESPs (und früher die S0 Zähler ESPs) schicken jede Minute eine Impulssumme. Also wird jede Minute der Wert aktualisiert und der Durchfluß (bzw. Leistung) berechnet. Bei der Methode braucht es den Timeout Reset nicht. ioBroker muß halt jede Minute was tun. Aber der Rechner packt das schon.

[paul53]

@klassisch sagte: Es wird noch Durchfluss gezeigt, obwohl keiner mehr da ist.

Richtig. Im zyklischen Fall wird zwischendurch "kein Durchfluss" angezeigt, obwohl geringer Durchfluss vorhanden ist. Man muss sich also entscheiden, was man bevorzugt.

[klassisch]

[OT "philosophische" Diskussion]
@paul53 sagte in Durchfluss Liter/Min aus Zählerstand:

Im zyklischen Fall wird zwischendurch "kein Durchfluss" angezeigt, obwohl geringer Durchfluss vorhanden ist. Man muss sich also entscheiden, was man bevorzugt.

Es wird halt beim zyklischen Messen und Rechnen kein zusätzlicher Durchfluß erzeugt. Kleine Durchflüsse werden u.U. ungeschickt "gerundet", die Fehler sollten sich aber wegintegrieren .
Wenn ich die Durchflüsse beider Methoden wieder zu einem Volumen aufintegrieren würde, dann wäre die zyklische Verarbeitung näher an der Volumenanzeige des Zählers. Deshalb habe ich mich für die Wasserzähler und die ehem. S0 Zähler (jetzt durch Modbus Zähler ersetzt) für dieses Verfahren entschieden.

Bei den Wasserzählern taste ich optisch das Sternrad ab.
Bei der letzten Jahresablesung hatten meine elektronischen Werte zu den abgelesenen folgende Abweichung: -0,07%; -0,01%; -0,08% . Gut, hat jetzt mit der eigentlichen Fragestellung nach Durchfluß (bzw Leistung) nichts zu tun, habe die Daten aber jetzt gerade gesichtet und finde sie gar nicht so schlecht...

Beim Regenmesser mache ich es noch anders, mit Resetierung nach timeout. Da interessiert mich vor allem die Gesamtmenge, die davon nicht beinflußt wird, und eigentlich nur bei sehr starken Regenfällen noch die maximale Regenintensität (wow, gestern hatten wir kurzzeitig mal 91mm/h). Da halte ich es lean und prozessiere nur, wenn die Kippwaage umschlägt. Ab und an denke ich wieder über diese meßtechnische Unsauberkeit nach, aber dann ist es mir an dieser Stellen auch nicht soo wichtig.....

[duffy6]

@homoran
Könntest Du mir den Codeschnipsel der minütlichen Ausführung hier mal reinstellen?

Bin nämlich gerade am überlegen wie ich an den "alten" Wert (der eine Minute alt ist) komme ohne ein weiteres Binding anzulegen.
"oldvalue" klappt ja bei einer Intervall-Ausführung nicht, oder?

[paul53]

@duffy6 sagte: "oldvalue" klappt ja bei einer Intervall-Ausführung nicht, oder?

Nein, man benötigt eine eigene Variable "lastValue", die bei Skriptstart initialisiert werden muss.

const idZaehler = 'abc'; // ID eintragen
const idDurchfluss = '0_userdata.0.xyz'; // ID eintragen
const Faktor = 0; // selbst ermitteln!
 
var lastValue = getState(idZaehler).val;
 
schedule('* * * * *', function() {
    let value = getState(idZaehler).val;
    let durchfluss = Faktor * (value - lastValue);
    lastValue = value;
    setState(idDurchfluss, durchfluss, true);
});

[Homoran]

@duffy6 sagte in Durchfluss Liter/Min aus Zählerstand:

@homoran
Könntest Du mir den Codeschnipsel der minütlichen Ausführung hier mal reinstellen?

Bin nämlich gerade am überlegen wie ich an den "alten" Wert (der eine Minute alt ist) komme ohne ein weiteres Binding anzulegen.
"oldvalue" klappt ja bei einer Intervall-Ausführung nicht, oder?

ich arbeite mit dem Datenpunkt vom Zählerstand auf Aktualisierung.
Dann steht auch old value zur Verfügung.

[paul53]

@homoran sagte: Datenpunkt vom Zählerstand auf Aktualisierung.

Der DP wird jede Minute aktualisiert?

[Homoran]

@paul53 sagte in Durchfluss Liter/Min aus Zählerstand:

@homoran sagte: Datenpunkt vom Zählerstand auf Aktualisierung.

Der DP wird jede Minute aktualisiert?

nee, nicht wirklich!
das ist alle drei Minuten. Ich mache das mit dem ESP32 CAM Projekt von @jomjol

[paul53]

@homoran sagte: alle drei Minuten.

Hauptsache zyklisch.

[Homoran]

@paul53 sagte:

Hauptsache zyklisch.

ja!
ich hatte sogar einen Algorithmus drin, der überprüft hat, ob ein Wert ausgesetzt hatte und dann die entsprechenden Werte in das Schieberegister für den Mittelwert nachgetragen hat.

Hier der Gasverbrauch (in dem Heizkreisgraphen)

und hier der "Kessel"kreislauf mit errechneter Brennerleistung (magenta) über den Durchschnitt der letzten 10 Messungen

[klassisch]

Bei meinen zyklischen Daten (Wasserzähler, früher auch S0 Stromzähler) habe ich den Zyklus durch die Sensoren vorgeben lassen. Diese senden jede Minute neue Daten (Gesamtsumme).
Dann kann man auf die Datenpunkte triggern und "old" funktioniert auch wieder.
Das Ursprungsskript von @paul53 passt dann, wenn man den timeout block raus nimmt.