Schedule im ms Bereich

[Asgothian]

@ben1983 Skript anhalten sollte reichen

[Ben1983]

@asgothian habe es hin bekommen,
aber leichter gesagt als getan. ich kam nicht mal auf den reiter instanzen.
irgebdwann klappte es mal und dann au h beim 50. mal stoppen hat er auch gestoppt.
glaube ein getstate oder setstate hat mir das genick gebrochen.

macht dann nicht wirklich sinn, wenn man nichts beschreiben kann.

[Asgothian]

@ben1983 in dem fall ist der trick ein setstateasync zu nutzen und jeweils nach dem erfolg es set state ein settimeout mit 200 ms zu nutzen

A.

[Asgothian]

@asgothian aus Neugier.. was genau willst du tun ?

[Ben1983]

@asgothian ich wollte ein regelallgorythmus für einen lowpass zyklisch aufrufen.
dazu ist halt ein timeout nicht so gut, da man dann natürlich nicht auf seinen wiederkehreneden zyklus kommt.
warum benötigt denn das setstate mehr als 200ms, ist das so unperformant?
habe es jetzt wieder mit schedule und im 2s takt laufen.
ist dann halt reglungstechnisch etwas grob.

[Asgothian]

@ben1983 Zeig doch mal das Skript.. die Kombination setState / getState auf den gleichen State ist nicht besonders gut.

A.

[Asgothian]

@asgothian Auch.. wenn du so schnell regelst solltest du darüber nachdenken die statesdb auf redis umzustellen.

A.

[Jey Cee]

@asgothian sagte in Schedule im ms Bereich:

@ben1983 Skript anhalten sollte reichen

Nein setIntervall verhält sich wie setTiemout, das muss beim beenden des Skripts gelöscht werden.
Sonst läuft das einfach fröhlich weiter.

[paul53]

@ben1983 sagte: setstate mehr als 200ms, ist das so unperformant?

200 ms benötigt setState() normalerweise nicht. Ein 200 ms Intervall sollte keine Probleme machen, wenn nur Standard-Befehle wie setState() verwendet werden.

[paul53]

@asgothian sagte: wenn du so schnell regelst solltest du darüber nachdenken die statesdb auf redis umzustellen.

Die Art der DB hat so gut wie keinen Einfluss, da alles im RAM abläuft.

[Asgothian]

@paul53 sagte in Schedule im ms Bereich:

@asgothian sagte: wenn du so schnell regelst solltest du darüber nachdenken die statesdb auf redis umzustellen.

Die Art der DB hat so gut wie keinen Einfluss, da alles im RAM abläuft.

Wenn die statesdb auf File steht dann wird es immer wieder zu Situationen kommen in denen die Kombination setstate/getstate zeit dauert da die states auf den Massenspeicher geschrieben werden. Ich konnte einen deutlichen Performancegewinn bei den States durch die Nutzung von redis feststellen.

[Ben1983]

@asgothian sagte in Schedule im ms Bereich:

redis

habe das script schon wieder umgestellt.
grundlegend ist es eine solche funktion:

setState(IdLowpass,getLowpass(getSTate(IdLowpass).val,getState(IdFilerTime).val,200);

[Asgothian]

@jey-cee sagte in Schedule im ms Bereich:

@asgothian sagte in Schedule im ms Bereich:

@ben1983 Skript anhalten sollte reichen

Nein setIntervall verhält sich wie setTiemout, das muss beim beenden des Skripts gelöscht werden.
Sonst läuft das einfach fröhlich weiter.

bist du sicher ? bei meinen Skripten muss ich die nicht löschen wenn ich das Skript anhalte.

A.

[paul53]

@ben1983 sagte: setState(IdLowpass,getLowpass(getSTate(IdLowpass).val,getState(IdFilerTime).val,200);

Verwende Variablen anstelle von getState(id).val.

[Ben1983]

@jey-cee hatte jetzt das setintervall aus dem script gelöscht und das script gespeichert, dann läuft es ja neu an und sollte weg sein, oder?

[paul53]

@asgothian sagte: bei meinen Skripten muss ich die nicht löschen wenn ich das Skript anhalte.

Mit Skript anhalten werden alle Timer des Skriptes gestoppt (gelöscht).

[Ben1983]

@paul53 und wann sollen die beschrieben werden?
Der Verwendete Wert ist nun mal global, wie soll ich den sonst bekommen, außer mit getState?

[paul53]

@ben1983 sagte: wie soll ich den sonst bekommen, außer mit getState?

Bei Skriptstart den Wert mit getState(id).val in die Variable einlesen und dann mit der Variablen weiter arbeiten. Den Datenpunkt dann laufend mit setState(id, variable, true) aktualiseren.

[Ben1983]

@paul53 würde funktionieren,
aber das was ich mit setstate beschreibe ist ja auch die zu lesende Variable.
ok, könnte man auch auf die Variable schreiben und direkt nach dem schreiben darauf dann mit setstate zuweisen. also quasi so:

let myVar = getState(Idxy).val;
let myTime = getState(IdTime).val;

im intervall dann:

myVar = getLowpass(myVar,myTime,200);
setState(Idxy,myVar);

sollte das besser funktionieren?

Bedeutet also, dass man in einem intervall besser kein getState verwenden sollte?
dann müsste ich nur den aktualwert über ein .on event der variable zuweisen.

ein .n event einer variable gibts nicht, oder?

[paul53]

@ben1983 sagte: sollte das besser funktionieren?

Ja.

Wenn myTime variabel sein soll, kann man sie per on(IdTime, callback) aktualisieren.