setinteval Zeiten

[OliverIO]

@laser
Das Gerät meldet den Wert nicht von sich aus?
Das was du da machst, nennt sich pollen.
Manche Geräte/APIs bieten die Möglichkeit sich dort technisch zu registrieren und die melden dann wenn es eine Veränderung gibt.

Auch musst du daran denken, wenn du das Gerät direkt abfragst (und nicht den Datenpunkt), beschäftigst du das Gerät, was uU verhindert, das es in einen Stromsparmodus geht und so wieder mehr Strom verbraucht.

Auch könnte eine Abfrage pro Minute auch schon reichen, da du da ja nicht zu einem exakten Zeitpunkt abschalten musst, sondern nur wenn gewisse Grenzen überschritten sind. Das wäre dann der Fall, wenn innerhalb einer Minute weniger als 1 Prozent verbraucht wird. Wenn der Verbrauch größer innerhalb einer Minute ist, dann kann man den Zeitraum vergrößern.

[Laser]

@oliverio Im Falle der Spannungsüberwachung reicht ein größerer Zeitraum, so schnell entlädt der Akku nicht. Das Gerät (Victron Akkulader) bietet einen Grenzwert, ich möchte aber vorher reagieren. Der Grenzwert ist dann eine weitere Sicherheit, noch vor dem Batterieinternen BMS. Ob der Lader einen Stromsparmodus hat, weiß ich nicht. Das "pollen" brauche ich für verschiedene Überwachungen. Vlt. nicht ideal, aber einfach in der Anwendung. Oftmals reicht ein Intervall von 3-5 Sekunden.
In der Funktion werden eigentlich nur Werte abgefragt und verglichen. Und ein Schreibe- oder Schaltbefehl generiert. Sollte wesentlich schneller gehen als die " interval"- Zeit.

[ticaki]

@laser sagte in setinteval Zeiten:

@oliverio Im Falle der Spannungsüberwachung reicht ein größerer Zeitraum, so schnell entlädt der Akku nicht. Das Gerät (Victron Akkulader) bietet einen Grenzwert, ich möchte aber vorher reagieren. Der Grenzwert ist dann eine weitere Sicherheit, noch vor dem Batterieinternen BMS. Ob der Lader einen Stromsparmodus hat, weiß ich nicht. Das "pollen" brauche ich für verschiedene Überwachungen. Vlt. nicht ideal, aber einfach in der Anwendung. Oftmals reicht ein Intervall von 3-5 Sekunden.
In der Funktion werden eigentlich nur Werte abgefragt und verglichen. Und ein Schreibe- oder Schaltbefehl generiert. Sollte wesenlich schneller gehen als die " interval"- Zeit.

Wesentlich? Wenn du etwas ein paar Millionen mal machen kannst, in der von dir vorgegebenen Zeit ist "wesentlich scheller" nicht ganz die Beschreibung die ich wählen würde.

Intervalle im Sekundenbereich sind wie oben geschrieben kein Problem solange du deine Werte über Trigger oder getState() bekommst.

Die Ausgabe muß aber auch bedacht werden, wenn du damit z.B. ein Relais schaltest, muß du verhindern das der Ausgabewert flackert. Bei meiner Warmwassersteuerung, braucht es 4 Minuten bis es an geht und 2 Minuten bis es aus geht, anschließend ist es für 5 Minuten gesperrt und würde bei Minute 6 wieder angehen. Wenn das durchgehend so geschaltet würde wäre mein Relais nach ca. 4 Jahren kaputt... wirds aber nicht. Da die Zieltemperatur bei 40% der Schaltvorgänge erreicht wäre, also hälts 10 Jahre. Da so ein bescheuertes Wetter nicht so oft vorkommt, sind wohl eher 20 Jahre.

[Laser]

@ticaki Damit die Ausgabe nicht "flackert", baue ich eben etwas ein. Entweder eine Mittelwertbildung, eine Hysterese oder etwas Anderes. "Wesentlich schneller", etwas Anderes fiel mir gerade nicht ein. Ich frage z.B. einen Datenpunkt ab. Mit getState. Das geht in einer kürzeren Zeit als mich die 3 Sekunden "interval" limitieren. ( Hoffe ich mal.)

[ticaki]

@laser
Abfragen eines Datenpunktes mit getState() dauert irgendwas im Nanosekunden Bereich

[OliverIO]

@ticaki said in setinteval Zeiten:

Nanosekunden

eher nicht.
ich hab mal vor einiger Zeit Messungen gemacht, da hat get/setState so zwischen 10 und 30 ms auf einem NUC mit Celeron benötigt. Auf einem neueren i7 evtl etwas schneller.
Aber Nano-Bereich würde ich bezweifeln.
1.000ms = 1 Sekunde
1.000.000.000 ns = 1 Sekunde
dazwischen gäbe es noch Mikrosekunden

[paul53]

@oliverio sagte: Mikrosekunden

Es sind wohl eher wenige Mikrosekunden.
Getestet:

• RasPi 2: 20 µs
• i7: 0,3 µs

[Laser]

@paul53 Habe versucht, über "htop" auf der Konsole etwas auszuloten. So richtig erkennbar ist das nichts. Vermutlich sind die laufenden Scripte auch dermaßen winzig, so daß man nichts mitbekommt, egal, ob alle 10 Sec. oder 1 Sec. abgefragt.

[ticaki]

@oliverio

script.js.Test.Skript_122: 100000 x getState().val in 23ms
script.js.Test.Skript_122: while (i++ < 1000000) x = (x+2)/6+i in 8ms

Das sind dann was? 2,3ns

war N100 Proxmox 1 core

var i=0
var start = new Date().getTime()
while (i++ < 1000) {
    let x = getState('0_userdata.0.Test').val
    x = (x+2)/6+i
    setState('0_userdata.0.Test',x)
}
var sum = new Date().getTime() - start
log('code in '+sum+'ms')

code in 6ms

[paul53]

@ticaki sagte: Das sind dann was? 2,3ns

230 ns.

[ticaki]

@paul53
argh, hast recht habs nicht gerechnet.

[ticaki]

@laser sagte in setinteval Zeiten:

@paul53 Habe versucht, über "htop" auf der Konsole etwas auszuloten. So richtig erkennbar ist das nichts. Vermutlich sind die laufenden Scripte auch dermaßen winzig, so daß man nichts mitbekommt, egal, ob alle 10 Sec. oder 1 Sec. abgefragt.

Das geht schon Lass es einen Tag laufen und schau dir an wieviel CPU-Zeit die Javascript Instanze verbraucht bei mir ist sie auf platz 3 - wenn redis 100h hat, hat shelly 25h und Javascript 8h. Aber ansonsten sieht du mit htop nur wenn es hängt.

[Laser]

@ticaki lasse das heute nochmal laufen. Gestern lag Javascript aber relativ hoch (über Shelly). Aber weit weg von hoher Auslastung.
Ein Problem habe ich noch. Ich vergleiche zwei Zahlenwerte (so der Plan).

  function akkumess() { 
     let minwert, spannung;
     let gpiostate, minalarm;
     gpiostate = getState('rpi2.0.gpio.22.state'/*Gpio 22*/).val;
     minalarm  = getState('javascript.0.Logik.AkkuMin'/*AkkuMin*/).val;
     minwert   = getState('javascript.0.variables.AkkuMinWert'/**/).val;
     spannung  = getState('vedirect.0.V'/*Main or channel 1 (battery) voltage*/).val;
      //console.log("Min-Wert: " + minwert);
      //console.log("spannung: " + spannung);
      //console.log("22 State:"  + gpiostate);
      //console.log("minalarm :" +minalarm);

  if ((spannung <= minwert) & (minalarm == false)) {

Der "minwert" wurde mit einem Komma als Dezimaltrenner gezeigt. Wie das Komma da reingekommen ist, weiß ich nicht.
Da spielt immer noch das Problem rein, wenn einmal etwas gespeichert wurde, bleibt es nach einer Änderung erhalten.
Nach JS Adapter "Restart" ist es dann meist richtig. Aber nicht immer. Wie kann ich einen bestimmten Datentyp "erzwingen" ? Der Vergleich mit dem Komma und dem Punkt klappte natürlich nicht. Wenn sowas unbemerkt bleibt, ist es sehr schlecht. Der Datenpunkt "AkkuMinWert" ist als Zahl deklariert.

[paul53]

@laser sagte: Der Datenpunkt "AkkuMinWert" ist als Zahl deklariert.

Das spielt keine Rolle, wenn er mit Komma dorthin geschrieben wird - dann bleibt es ein String.

@laser sagte in setinteval Zeiten:

Wie kann ich einen bestimmten Datentyp "erzwingen" ?

     if(typeof minwert == 'string') minwert  = parseFloat(minwert.replace(',', '.'));

Das & in Zeile 13 ist falsch. Richtig logisches UND: &&

[OliverIO]

@laser
ich weiß nicht, ob das beobachten der Auslastung da tatsächlich ein Hinweis bietet.
Wenn du die Laufzeit deiner Funktion in ms messen möchtest, dann könntest du das folgende einbauen

var start=new Date().getTime();
//hier dein code
var end=new Date().getTime();
console.log(end-start);

Ein Wert der ein Komma enthält wird immer als String gespeichert.
Du musst das komma erst ein ein . verwandeln. Besser wäre es das bereits an der Quelle zu ändern, wenn aber das von aussen schon so reinkommt, dann halt im Skript

"123,45".replace(",",".")

Wenn du das dann in einen expliziten Typ umwandeln willst, kannst du den jeweiligen Typ-Konstruktor verwenden

Number("123.45")+5
oder
parseFloat("123.45")  //parseFloat hat den Vorteil, das es flexibler mit ungültigen Zeichen umgeht
parseFloat("3px")  // -> 3
Number("3px")  // -> NaN

[Laser]

@oliverio , @paul53
Das Doppelund (&&) ist mir beim "Aufräumen" verlustig gegangen. Steht wieder drin.
Mit "parse" werde ich mich beschäftigen.
Die Auslastung wird sicher erst wichtig, wenn der Pi kurz vor dem Blockieren ist.

[ticaki]

@laser

Zur Auslastung, glaube mir einfach, mit den Skripten die du schreibst, wirst du da nie ein Problem haben, solange du halt nicht mit setInterval in dem Millisekundenbereich kommst oder Schleifen mit zehntausenden Abfragen benutzt.

Und zu shelly... ich hab 20 Geräte mit 5 Sekundenaktualisierung Großteil davon sind 1/2pm und 2 em3. Da wird einiges an Daten bewegt und das 24/7. Das als Begründung warum es bei mir viel Zeit benötigt.

Wenn du dir tatsächlich Gedanken darüber machst, dann prüfe ab und an ob eine Core oder der Speicher auf 100% Auslastung ist oder der Load Average größter/gleich (beim 3. Wert) 4 dann mußte was machen.

[Laser]

@ticaki Die Scripte von mir sind Null Komma null nichts. Wenn da nicht ein riesiger IOBroker Overheed dranhängt....
Die 2 Energie- Shellys frage ich auch mit 5 Sekunden ab.