{Frage] Erkennen der Geschwindigkeit einer Temperaturänderung

[Linedancer]

Hallo Gemeinde,

ich benötige mal ein Schubs in die richtige Richtung für ein neues Script (vorzugsweise Blockly, aber mit Javascript komme ich wenns sein muss auch irgendwie hin).

Aufgabe:

Es soll erkannt werden wie schnell eine Temperatur steigt. Wenn die Änderung schnell genug erfolgt wird ein Aktor geschaltet.

Anwendung:

Ich habe mittlerweile einen Temperaturfühler am Warmwasser Ausgang des Trinkwasser Speichers und möchte bedarfsgesteuert die Zirkulationspumpe einschalten.

so sieht das Sensorsignal aus:

Der Ansatz alle 5 Sekunden die aktuelle Temperatur mit der vor 5 Sekunden gespeicherten zu vergleichen kann ja nicht zielführend sein. Ein sinnvoller Ansatz fällt mir leider nicht ein.

Vielleicht gibt's ja hier Ideen. Ich sag schonmal Danke

[AlCalzone]

@Linedancer:

Der Ansatz alle 5 Sekunden die aktuelle Temperatur mit der vor 5 Sekunden gespeicherten zu vergleichen kann ja nicht zielführend sein. Ein sinnvoller Ansatz fällt mir leider nicht ein. `
Aber (fast) genau so funktioniert numerische Differentiation:

Geschwindigkeit = [Wert(jetzt) - Wert(vorher)] / [Zeit(jetzt) - Zeit(vorher)]

Wenn du etwas weniger Schwankungen haben willst, kannst du die Werte über einen größeren Zeitraum vergleichen.

[Linedancer]

Das man das so machen kann ist mir schon klar und so ein Script bekomme ich auch hin, aber ist so ein Script das alle 5s läuft nicht zu Ressourcen fressend? In meinem fall würde der Javascript Adapter, der dafür zuständig wäre, auf eine Synology Disk Station im Docker Container laufen.

[AlCalzone]

@Linedancer:

ein Script das alle 5s läuft nicht zu Ressourcen fressend? `
Nee, da mach dir mal keine Sorgen. Wenn es wirklich nur 1 Wert aus 4 berechnet, ist das kein Thema.

[Linedancer]

Na dann werd ich mal los legen.

[paul53]

Vorschlag:

const idTemp = '...';

on(idTemp, function(dp) {  // Triggern bei Wertänderung
   var speed = 60000 * (dp.state.val - dp.oldState.val) / (dp.state.lc - dp.oldState.lc);  // K/min
});

[AlCalzone]

@paul53:

Vorschlag:

const idTemp = '...';

on(idTemp, function(dp) {  // Triggern bei Wertänderung
   var speed = 60000 * (dp.state.val - dp.oldState.val) / (dp.state.lc - dp.oldState.lc);  // K/min
});
```` `  

Sollte das nicht ts sein statt lc?

[paul53]

@AlCalzone:

Sollte das nicht ts sein statt lc? `
Nein, denn es wird auf Wertänderung getriggert. Da z.B. HM-Sensoren ihren Wert auch ohne Wertänderung aktualisieren, kann ein dp.oldState.ts zu jung sein (ist nicht an eine Wertänderung gebunden).

[pix]

Hallo,

hier sind ja die Parameter für die on-Subscriptions aufgelistet: https://github.com/ioBroker/ioBroker.ja ... some-state

Aus "change" und "valGt" dem Operator "and" müsste sich was basteln lassen, das im Fall eines schnellen Anstiegs die Funktion ausführt.

Leider habe ich gerade keine Kapazitäten das selbst zu testen (Kinderbetreuung parallel).

Gruß

Pix

[paul53]

@pix:

Aus "change" und "valGt" dem Operator "and" müsste sich was basteln lassen, das im Fall eines schnellen Anstiegs die Funktion ausführt. `
Nein, das geht nicht. Die Abhängigkeit von der Änderungsgeschwindigkeit erfordert eine Division dWert/dt.

[paul53]

@Linedancer:

Wenn die Änderung schnell genug erfolgt wird ein Aktor geschaltet. `
Erweiterung des Skriptes um den Aktor.

const idTemp = '...';
const idAktor = '...';
const gw = 2;  // Grenzwert in K/min

var aktor = getState(idAktor).val;
var timer = null;

on(idTemp, function(dp) {  // Triggern bei Wertänderung
   var speed = 60000 * (dp.state.val - dp.oldState.val) / (dp.state.lc - dp.oldState.lc);  // K/min
   if(speed >= gw) {
      if(!aktor) setState(idAktor,true);
      clearTimeout(timer);
      timer = setTimeout(function() {
         if(aktor) setState(idAktor, false);
      }, 120000); // 2 Minuten
   }   
});

on({id: idAktor, ack: true}, function(dp) {
   aktor = dp.state.val;
});

EDIT: Um Auschalten nach 2 Minuten ergänzt.

[AlCalzone]

@paul53:

Nein, denn es wird auf Wertänderung getriggert. Da z.B. HM-Sensoren ihren Wert auch ohne Wertänderung aktualisieren, kann ein dp.oldState.ts zu jung sein (ist nicht an eine Wertänderung gebunden). `
Ok, dann sollte es wahrscheinlich keinen Unterschied machen. Wenn ich im stationären Zustand bin (d.h. keine Wertänderung auftritt), ist die Differenz im Zähler eh 0, egal ob man im Nenner jetzt ts oder lc verwendet.

[paul53]

@AlCalzone:

dann sollte es wahrscheinlich keinen Unterschied machen Doch, macht es. Beispiel: > Wert 20.0 –> 20.1 °C: ts = lc

Wert 20.1 °C bleibt 2,5 Minuten später: ts > lc, oldts = oldlc

Wert 20.1 --> 20.2 °C weitere 2,5 Minuten später ts = lc, oldts > oldlc

speed mit ts: 0,1/2,5

speed mit lc: 0,1/5,0 ` Bei Verwendung von ts kann eine zu hohe Änderungsgeschwindigkeit berechnet werden.

[pix]

Wenn ich mir die Kurve des steigenden Wertes ansehe, wird der Abstand zwischen oldState und newState größer. Darauf kann man reagieren.

Pix

[Linedancer]

Wow, hier ist ja was los

Erstmal danke für den Input. Muss erstmal nachlesen, damit ich das alles verstehe…. :?:

Da trau ich mich ja fast nicht mein Blockly zu zeigen mit dem ich hier experimentiere.

Da der Aktor noch nicht existiert hab ich das mal mit einem Datenpunkt nachgebildet. Der Sensor von dem die Temperatur kommt, ist ein One Wire DS18b20

der am Raspi im Heizungskeller hängt und alle 10 Sekunden mit dem Parser Adapter ausgelesen wird.

Der erste Test mit dem Blockly hat mal nicht soooo schlecht funktioniert, 23 Sekunden nach öffnen des Wasserhahns kam die Telegram message.

Jetzt fehlt noch ne Funktion die die Zirkulation nur startet, wenn es auch nötig ist.

[AlCalzone]

@paul53:

` > Wert 20.0 –> 20.1 °C: ts = lc

Wert 20.1 °C bleibt 2,5 Minuten später: ts > lc, oldts = oldlc

Wert 20.1 --> 20.2 °C weitere 2,5 Minuten später ts = lc, oldts > oldlc

speed mit ts: 0,1/2,5

speed mit lc: 0,1/5,0 Bei Verwendung von ts kann eine zu hohe Änderungsgeschwindigkeit berechnet werden.
Okay, du willst auf eine Änderung nach dem stationären Zustand hinaus - macht Sinn. Dennoch stimme ich nicht vollständig zu - die Wahrheit liegt irgendwo in der Mitte:

Rot ist die momentane Geschwindigkeit mit ts. Grün ist die Geschwindigkeit, wenn man wie du vorschlägst statt ts lc verwendet. Mmn ist die im vorliegenden Fall zu gering. Gelb wäre vermutlich die "wahre" Geschwindigkeit.

Im Prinzip haben wir hier nur die Stützstellen-Distanz verändert. Welche sinnvoll ist, hängt stark vom Verlauf und der zeitlichen Auflösung ab.

Das war auch das was ich vorhin meinte:
> Wenn du etwas weniger Schwankungen haben willst, kannst du die Werte über einen größeren Zeitraum vergleichen.
Nebeneinanderliegende Datenpunkte führen zu hohen Änderungen in der Ableitung - und damit teils zu hohe oder zu niedrige (bei negativem Trend) Geschwindigkeiten. Je weiter die Datenpunkte auseinanderliegen, desto genauer erfasst du das globale Verhalten, aber umso träger wird es auch.

[paul53]

@Linedancer:

alle 10 Sekunden mit dem Parser Adapter ausgelesen wird. `
Diese Information erspart die Division dWert/dt.
@Linedancer:

Jetzt fehlt noch ne Funktion die die Zirkulation nur startet, wenn es auch nötig ist. `
Wann ist es nötig (Definition) ?

Zu dem Blockly Script:

Die Verzögerung (timeout) startet alle 10 s, solange die Temperatur ansteigt. Es wird dabei jedesmal ein neuer Timer erzeugt. Richtig: Die Verzögerung muss auch innerhalb des Bedingungsblocks (neu > alt + 0.3) gestartet und vorher muss der Timer (timeout) <u>gestoppt</u> werden.

Der "Wert vom Objekt WW _Speicher_Auslauf" existiert bereits als lokale Variable value. Der "Wert vom WW_Speicher_Auslauf_aktuell" existiert bereits als lokale Variable oldValue; der 2. Trigger und der zusätzliche Datenpunkt werden also nicht benötigt.

[Linedancer]

@paul53:

Wann ist es nötig (Definition) ? `
Jedwede Zirkulation entläd den Trinkwasserspeicher, deswegen soviel Zirk wie nötig und so wenig wie möglich. Wenn ide Temperatur an den Zapfstellen hoch genug ist muss keine Zirk laufen. Idee ist hier ein Temp Sensor an der höchsten Stelle de Zirkulationsleitung.

@paul53:

Die Verzögerung (timeout) startet alle 10 s, solange die Temperatur ansteigt. Es wird dabei jedesmal ein neuer Timer erzeugt. Richtig: Die Verzögerung muss auch innerhalb des Bedingungsblocks (neu > alt + 0.3) gestartet und vorher muss der Timer (timeout) <u>gestoppt</u> werden. `
Ok, verstanden und umgesetzt.

@paul53:

Der "Wert vom Objekt WW _Speicher_Auslauf" existiert bereits als lokale Variable value. Der "Wert vom WW_Speicher_Auslauf_aktuell" existiert bereits als lokale Variable oldValue; der 2. Trigger und der zusätzliche Datenpunkt werden also nicht benötigt. `
Der zweite Trigger muss den oldValue auch wenn die Zirk nicht aktiv ist (bei fallender Temperatur) aktualisiern, sonst würde er ja bei max stehenbleiben.

[paul53]

@Linedancer:

Der zweite Trigger muss den oldValue auch wenn die Zirk nicht aktiv ist (bei fallender Temperatur) aktualisiern, sonst würde er ja bei max stehenbleiben.
Nein, oldValue ist eine lokale Variable, die nur innerhalb der Funktion aktualisiert wird mit oldValue = obj.oldState.val. obj.oldState.val gehört zum Zustand eines Datenpunktes und wird durch ioBroker aktualisiert, nicht durch den Trigger.