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

[Homoran]

@laser sagte in Raspi GPIO wird gesetzt, wie Ursache herausfinden?:

Möchte kein neues Thema aufmachen

dann mach ich das für dich :rage:
hat ja wirklich überhaupt nichts mit GPIO zu tun

passe bitte als erstes den Titel an!

[ticaki]

@homoran
Jetzt war ich mir nicht sicher wo mein Beitrag landet :)

@laser
Sekunden sind kein Problem bei 1-2 stelligen Millisekunden wäre das was anderes.

Starten mehrere Programme/Scripte mit "setinterval" gleichzeitig oder welche Regel gilt da?

Ich kenne den Code nicht der dahinter steckt, aber der Wahrheit wird wohl sehr nahe kommen:

Mit setInterval trägst du deinen Befehl in eine Liste ein, und der Javascript Adapter (1 Thread IMHO) klappert die nacheinander ab. Wenn du da nicht extem aufwendige Berechungen anstellst, sollte das alles kein Problem sein. Auf meinem NUC sieht ein Test z.B so aus:

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

[Homoran]

@ticaki zu dicke Finger oder zu kleines Handy :joy:

[paul53]

@laser sagte: Sind 1- 2 Sekunden zu schnell (Raspi4 8GB RAM) ?

Nein, i.d.R. nicht.

@laser sagte in setinteval Zeiten:

Starten mehrere Programme/Scripte mit "setinterval" gleichzeitig oder welche Regel gilt da?

setIntervall(functionXYZ,1000) startet zyklisch die Callback-Funktion functionXYZ. Die Abarbeitungszeit der Callback-Funktion muss natürlich kürzer sein als die Zykluszeit, was i.d.R. gegeben ist.

[OliverIO]

@laser said in setinteval Zeiten:

Starten mehrere Programme/Scripte mit "setinterval" gleichzeitig oder welche Regel gilt da?

javascript ist ein single threaded system.
das heißt in einem Prozess kann immer nur genau eine einzige Codezeile gleichzeitig ausgeführt werden. (man kann natürlich mehrere javascript prozesse gleichzeitig starten, aber das ist nur was für fortgeschrittene und benötigt ein normal-programmierer nicht)

wenn du setinterval startet, dann wird zu gegebener zeit vom eventloop der javascript-engines der Aufruf deiner funktion auf den stack gelegt und bei nächster Gelegenheit (bspw eine evtl andere Funktion im skript ist fertig und springt zurück) aufgerufen.
daher gibt es auch keine garantie, das deine funktion exakt nach bspw 2000ms aufgerufen wird, sondern nur so ungefähr.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Event_loop

wie paul schon erwähnt hat, sollte die intervalzeit länger sein, wie die dauer der Abarbeitung der funktion.. Hintergrund ist, das wenn die funktion noch nicht fertig ist, ja schon wieder der nächste aufruf auf dem stack liegt und dann keine zeit mehr übrig bleibt andere dinge zu tun. das system/prozess wird langsam und irgendwann läuft der stack über, dann wird der prozess vom betriebssystem beendet.
aber wie gesagt, da ist viel luft bei 1-2 sekunden.
https://developer.mozilla.org/en-US/docs/Web/API/setInterval

Noch sicherer wäre es mit setTimeout zu arbeiten und die nächste Verarbeitung erst am Ende der vorhergehenden zu starten. Dann kann es keine Probleme geben.

Allerding muss man sich fragen, was du mit so einer geringen Auflösung an Genauigkeit den tatsächlich machen willst. Evtl gibt es eine andere Lösung dafür?

[Laser]

@oliverio ich möchte zum Beispiel die Spannung meines PV-Akku's überwachen. Wenn der langsam "leer" wird, soll ein Verbraucher abschalten. Wenn "voll" das Laden beenden. Eine andere Anwendung ist, das Steigen oder Sinken eines Temperaturwertes zu detektieren. Beide Werte "klappern" aber etwas hin und her.
Für mich ist wichtig, daß die Funktion überhaupt abgearbeitet wird, ob nach 2 oder 3 Sekunden, ist egal.

[OliverIO]

@laser
ok,
sorry das ich dich mit zu viel Informationen zugeschüttet habe.

[Laser]

@oliverio Ist nicht zu viel, muß ich aber erst durcharbeiten.

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