[gelöst] Werte im Schieberegister
-
Hallo, ich schreibe die Werte vom Regenmesser in zwei Schieberegister.
Einmal für 24 x 1 Stunde und 6 x 10 Minute (eine Stunde).
In den Objekten steht teilweise eine "null" anstatt einer "0".
Kommt das vom Start des Blocklys?
Die 0.45 Regen hätte er doch auch bei Regenmenge 1h übernehmen müssen?
@gonzokalle sagte: In den Objekten steht teilweise eine "null" anstatt einer "0".
Die beiden Listen-Datenpunkte müssen erst einmal richtig initialisiert werden. Das kann / sollte in einem getrennten Skript erfolgen, das nach Initialisierung gelöscht wird.
Außerdem verwendet man zum Hochzählen besser Integer-Werte. Dann muss anschließend nicht gerundet werden.
EDIT: Siehe hier
Den Faktor 0,45 wendet man dann erst bei Schreiben der Regenmenge in den Datenpunkt an:
-
@gonzokalle Die Ursache für die "null" könnte dort liegen.
Daneben musst Du aber auch dafür sorgen, dass das "10-Minuten" Skript sich nicht mit dem "1-Stunden" Skript "beißt". Da ist es unschön, dass sowohl das Stunden-Skript, als auch das 10-Minuten-Skript bei Minute "0" parallel ausgeführt werden...
(Nachtrag: Ich bin aber kein NodeJS Experte, und kann nicht sagen, ob es da ggfs, eingebaute Mechanismen gibt, die solche Nebenläufigkeiten ausschließen)
Entweder einen Zähler bis 6 in das 10-Minuten-Skript einbauen, der das Stunden-Skript nach dem Aktualisieren der 10-Minuten Liste triggert, oder es direkt in das 10-Minuten-Skript einbauen.
Eine andere Möglichkeit wäre, das Stunde-Skript mit cron parametrierung "1 * * * *" eine Minute nach dem "0" Durchlauf des 10-Minuten-Skripts zu starten,Nachtrag OFFTOPIC
Sind solche Probleme nicht eher etwas für die influx-DB und Grafana oder andere Analyse-Werkzeuge, die in ioBroker integriert werden können?@martinp sagte: das "10-Minuten" Skript sich nicht mit dem "1-Stunden" Skript "beißt".
Die "beißen" sich nicht, da sie verschiedene Variablen verwenden. Lediglich die Telegram-Nachricht sollte inkl. Prüfung etwas verzögert werden.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: RPi 2 mit S.USV, HM-MOD-RPI und SLC-USB-Stick mit root fs -
@gonzokalle sagte: In den Objekten steht teilweise eine "null" anstatt einer "0".
Die beiden Listen-Datenpunkte müssen erst einmal richtig initialisiert werden. Das kann / sollte in einem getrennten Skript erfolgen, das nach Initialisierung gelöscht wird.
Außerdem verwendet man zum Hochzählen besser Integer-Werte. Dann muss anschließend nicht gerundet werden.
EDIT: Siehe hier
Den Faktor 0,45 wendet man dann erst bei Schreiben der Regenmenge in den Datenpunkt an:
@paul53
Probiere ich heute Abend.
Muss erstmal arbeiten. -
@martinp sagte: das "10-Minuten" Skript sich nicht mit dem "1-Stunden" Skript "beißt".
Die "beißen" sich nicht, da sie verschiedene Variablen verwenden. Lediglich die Telegram-Nachricht sollte inkl. Prüfung etwas verzögert werden.
@paul53 said in Werte im Schieberegister:
@martinp sagte: das "10-Minuten" Skript sich nicht mit dem "1-Stunden" Skript "beißt".
Die "beißen" sich nicht, da sie verschiedene Variablen verwenden. Lediglich die Telegram-Nachricht sollte inkl. Prüfung etwas verzögert werden.
"Regenmenge_in_10 Min" wird in zwei Skripten verwendet, und "Regenmenge_im_60_Min" auch ...
Wobei ich eher in der C++ Welt zu Hause bin - bei C++ müsste man schon darauf achten, dass man einen atomaren Datentyp nimmt ... bei NodeJS weiß ich nicht, ob es da integrierte Schutzmechanismen gegen solche Nebenläufigkeiten gibt. Damit beschäftige ich mich erst seit ein paar Monaten ... und weiß nicht, ob die "asynchronen" Funktionen doch unter der Motorhaube z. B. fein säuberlich hintereinander über eine Warteschlange abgearbeitet werden ...
-
@gonzokalle sagte: In den Objekten steht teilweise eine "null" anstatt einer "0".
Die beiden Listen-Datenpunkte müssen erst einmal richtig initialisiert werden. Das kann / sollte in einem getrennten Skript erfolgen, das nach Initialisierung gelöscht wird.
Außerdem verwendet man zum Hochzählen besser Integer-Werte. Dann muss anschließend nicht gerundet werden.
EDIT: Siehe hier
Den Faktor 0,45 wendet man dann erst bei Schreiben der Regenmenge in den Datenpunkt an:
-
@paul53
Meinst du so?
Das nur der Kontakt gezählt wird und nachher mal 0,45 gerechnet wird habe ich verstanden.
Den Anfang noch nicht. Welcher DP muss ich denn bei Regenmenge in 10Min eintragen?
@gonzokalle sagte: Welcher DP muss ich denn bei Regenmenge in 10Min eintragen?
Dafür werden zwei weitere DP gebraucht, damit die beiden Variablen einen Skriptstart überstehen.
Außerdem müssen die beiden Listen-DP bei jeder Listenänderung aktualisiert werden, so wie du es ursprünglich schon hattest.
-
@gonzokalle sagte: Welcher DP muss ich denn bei Regenmenge in 10Min eintragen?
Dafür werden zwei weitere DP gebraucht, damit die beiden Variablen einen Skriptstart überstehen.
Außerdem müssen die beiden Listen-DP bei jeder Listenänderung aktualisiert werden, so wie du es ursprünglich schon hattest.
-
@gonzokalle sagte: So?
Ganz oben: Ohne Division durch 0,45 und ohne runden (war ursprünglich falsch gedacht von mir). Die Datenpunkte enthalten Integer-Werte, was du schon richtig im Namen berücksichtigt hast.
-
@gonzokalle sagte: So?
Ganz oben: Ohne Division durch 0,45 und ohne runden (war ursprünglich falsch gedacht von mir). Die Datenpunkte enthalten Integer-Werte, was du schon richtig im Namen berücksichtigt hast.
-
@paul53
Dann verstehe ich es jetzt auch.
Der erste Test sieht gut aus.
Dankeschön
@gonzokalle
Diesen Teil um 1 s verzögern, da sonst noch ein alter Wert gelesen werden kann:
-
@gonzokalle
Diesen Teil um 1 s verzögern, da sonst noch ein alter Wert gelesen werden kann: -
@paul53
Habe ich gemacht.Aber allgemein kann man den Liste DP doch auch manuell erstellen?
Oder muss man das über aktualisieren machen?
@gonzokalle sagte: kann man den Liste DP doch auch manuell erstellen?
Im Prinzip schon. Bei einem Array ist es aber nicht so einfach, den Startwert fehlerfrei hinzubekommen.
-
@gonzokalle sagte: kann man den Liste DP doch auch manuell erstellen?
Im Prinzip schon. Bei einem Array ist es aber nicht so einfach, den Startwert fehlerfrei hinzubekommen.
Bei einem Punkt bin ich mir unsicher.
Bei Contact in 10Min bleibt der letzte Wert immer stehen, obwohl es die letzten 10 Minuten nicht geregnet hat.
Beim Scriptstart wird dieser Wert aber in eine Variable eingelesen und mit neuen Regen addiert.
Hat es dann nicht zu viel geregnet?
-
Bei einem Punkt bin ich mir unsicher.
Bei Contact in 10Min bleibt der letzte Wert immer stehen, obwohl es die letzten 10 Minuten nicht geregnet hat.
Beim Scriptstart wird dieser Wert aber in eine Variable eingelesen und mit neuen Regen addiert.
Hat es dann nicht zu viel geregnet?@gonzokalle sagte: Bei Contact in 10Min bleibt der letzte Wert immer stehen, obwohl es die letzten 10 Minuten nicht geregnet hat.
Es wird nur die Variable alle 10 Minuten auf 0 zurück gesetzt. Soll auch dies einen Skriptstart überstehen, muss auch eine 0 in den Datenpunkt "Contact in 10Min" geschrieben werden. Das gilt auch für "Contact in 60MIn".
-
@gonzokalle sagte: Bei Contact in 10Min bleibt der letzte Wert immer stehen, obwohl es die letzten 10 Minuten nicht geregnet hat.
Es wird nur die Variable alle 10 Minuten auf 0 zurück gesetzt. Soll auch dies einen Skriptstart überstehen, muss auch eine 0 in den Datenpunkt "Contact in 10Min" geschrieben werden. Das gilt auch für "Contact in 60MIn".
@paul53
Vielleicht ist es einfacher gleich in den DP Contact in 10Min zu schreiben.
Gibt es für DP auch eine "erhöhe um 1" Möglichkeit? -
@paul53
Vielleicht ist es einfacher gleich in den DP Contact in 10Min zu schreiben.
Gibt es für DP auch eine "erhöhe um 1" Möglichkeit?@gonzokalle sagte: Gibt es für DP auch eine "erhöhe um 1" Möglichkeit?
Nein.
-
@paul53
Vielleicht ist es einfacher gleich in den DP Contact in 10Min zu schreiben.
Gibt es für DP auch eine "erhöhe um 1" Möglichkeit?@gonzokalle Das geht sicherlich, aber man sollte natürlich die Manipulation von Datenpunkten auf das minimal Mögliche reduzieren. Ist vermeidbarer Overhead ... Es wäre so etwas wie eine Read-Modify-Write Operation.
Die Frage ist aber, ob dieser jetzt genutzte Ringpuffer-Mechanismus "unter der Motorhaube" da effizienter ist ...
-
@gonzokalle Das geht sicherlich, aber man sollte natürlich die Manipulation von Datenpunkten auf das minimal Mögliche reduzieren. Ist vermeidbarer Overhead ... Es wäre so etwas wie eine Read-Modify-Write Operation.
Die Frage ist aber, ob dieser jetzt genutzte Ringpuffer-Mechanismus "unter der Motorhaube" da effizienter ist ...
@martinp
Klingt kompliziert.
Ich denke ich lasse es so wie es ist. -
@martinp
Klingt kompliziert.
Ich denke ich lasse es so wie es ist.@gonzokalle
Noch mal abschließend das etwas abgeänderte Blockly.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
552
Online32.8k
Benutzer82.8k
Themen1.3m
Beiträge