UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[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.