[gelöst]: Async: Verständnisproblem

[ticaki]

@mcm1957 sagte in Async: Verständnisproblem:

@ticaki said in Async: Verständnisproblem:

@oliverio

Mir hat da die installation von @iobroker/types@6.0.11 geholfen, damit ich mit 6 kompatibel bleibe.

Jep klingt vernünftig
dann bitte auch js-controller > 6.0.11 in dependencies des Adapters eintragen

Wegen der Anmerkung das 5 noch immer aktiv ist, werde ich erstmal schauen wie weit ich ohne das ich mich umgewöhnen muß zurück kann.

[Codierknecht]

@oliverio sagte in Async: Verständnisproblem:

Ich interpretiere, das

So lese ich das auch. Also ein await davor, um erst weiterzumachen wenn der Aufruf zurückkehrt.
Die aufrufende Funktion muss damit zwingens auch async sein.

[mcm1957]

@codierknecht said in Async: Verständnisproblem:

@oliverio sagte in Async: Verständnisproblem:

Ich interpretiere, das

So lese ich das auch. Also ein await davor, um erst weiterzumachen wenn der Aufruf zurückkehrt.
Die aufrufende Funktion muss damit zwingens auch async sein.

ja
oder ESM.

async ist im Adapter aber kein Problem.

[Codierknecht]

@mcm1957 sagte in Async: Verständnisproblem:

ABER es sollte auch nicht vor jedem setState ein setObjectNotExists stehen. Das ist Beschäftigungstherapie für den core aber auch eine zweite Baustelle.

Muss ich mir anschauen.
Eine Möglichkeit wäre, nur den allerersten Aufruf des API mit setObjectNotExists zu verarbeiten.
Alle folgenden setzen dann nur noch die (dann hoffentlich existierenden) States.

Könnte allerdings dann ein Problem werden, wenn im API plötzlich neue Werte geliefert werden, die beim allerersten Aufruf nicht bekannt waren.

[mcm1957]

@codierknecht
Der adapter kann die Stateids cachen für die er seit seinem lStart bereits ein setObject oder exten Object abgesetzt hat. Ist durchaus üblich.

Prinzipiell ist es aber imemr ein Problem wenn der Adapter States auf Grund der Antwort des Apis anlegt da er dann den Typ meist nur heuritisch ermitteln kann und Roles, Units etc. gar nicht. Oft ist es besser, wenn der Adapter eine Liste der bekannten States kennt, diese mit Typ, Role, UNits etc. anlegt und allenfalls vom Api neu gelieferte Werte zunächst ignoriert und/oder einmal (!) als Info loggt. Kann man dann in einer neuen Release ergänzen.

[OliverIO]

@ticaki sagte in Async: Verständnisproblem:

Wegen der Anmerkung das 5 noch immer aktiv ist

5.0.19 hat auch noch relativ viele nutzer.

[mcm1957]

@oliverio
js-controller 5 wird aber abnehmen. Telegram als ein Massenadapter verlangt schon js-controller 6 (wenn ichs richtig im Kopf habe). Weitere werden sicher bald folgen. Immerhin ist js-controlelr 6 jetzt schon bald ein Jahr draußen.

Also wenn wer will und ev. eh na major Release erstellt kann / soll er ruhig js-controller 6 verlangen.

[OliverIO]

@codierknecht sagte in Async: Verständnisproblem:

Eine Möglichkeit wäre, nur den allerersten Aufruf des API mit setObjectNotExists zu verarbeiten.

würde ich schon bei jedem machen.
die überprüfung ob states existieren und angelegt werden, mache ich immer nur bei adapter start.

es kann ja immer mal sein, das ein user einen einzelnen state herauslöscht (warum auch immer, halt für DAUs). wenn du nur den ersten prüfst, könnte der adapter sich durch Neustart nie reparieren, da ja der erste state uU existiert.

so teuer (performance) ist das alles nicht, ich denke die ganzen states werden sowieso im hauptspeicher gehalten

[ticaki]

@oliverio

Dazu eine Anmerkung - der Tagesschau Adapter konnte am Anfang bevor ich es begrenzt habe 10000 und mehr states erzeugen - das extendObject das ich beim restart mache hat auf schnellen Rechnern dafür gesorgt das der Javascript Adapter ganz kurz rot wurde.

Jetzt ist da ein sleep drin, ist ja nicht eilig und im default macht der auch deutlich weniger datenpunkte

[Codierknecht]

@OliverIO @ticaki @mcm1957
Bei meinem anderen Adapter mache ich das sogar auch so, dass ich mir die einmal angelegten States in einem Array merke.

Hab ich jetzt auch beim Neuen Adapter so eingebaut.
Ich verzichte allerdings darauf, einen Eintrag beim Löschen eines State wieder aus dem Array zu kicken.
Sollte ein DAU mal (versehentlich) einen State löschen, lässt sich das ja durch einen Neustart reparieren.

Mein Verständnisproblem ist erstmal geklärt.
Vielen Dank euch allen!

[mcm1957]

@oliverio
Ja bei JEDEM Start des Adapter EINMALIG die States zu testen (= setObjectNotExists / extendObject) aufzurufen ist völlig OK. Nur in der processing Loop (d.h. alle x Sekunden / Minuten) nach dem holen der aktuellen Werte sollte man nicht jedesmal setObjectNotExists und co machen.

[OliverIO]

@ticaki sagte in [gelöst]: Async: Verständnisproblem:

Jetzt ist da ein sleep drin, ist ja nicht eilig und im default macht der auch deutlich weniger datenpunkte

hm

• 10000 states? hört sich nach viel an. wenn nutzer nicht auf jeden einzelnen zugriefen müssen, könnte ein JSON objekt in einem state auch ausreichend sein.
  sollte eigentlich nicht notwendig sein.
• sleep sollte wegen der menge eigentlich nicht notwendig sein. wenn man serialisierte asynchrone aktivitäten hat, die uU die Menge des Hauptspeichers ausreizt, dann könnte man die einzelnen aktivitäten über eine concurrency queue abarbeiten, die immer nur eine gewisse menge an aktivitäten "gleichzeitig" zulässt. gleichzeitig in ", da es in javscript innerhalb eines prozesses nix gleichzeitiges gibt. es wird alles auf den stack/heap geschrieben und der reihe nach abgearbeitet.
• das wenn man extendObject auf die Adapter-config macht (also system.adapter.<adapter.name>.0 macht, startet iobroker automatisch den adapter neu, das ist das selbe wenn man über adminui auf speichern drückt.

[ticaki]

@oliverio
Wie ich geschrieben habe, war am Anfang der Entwicklung so:

Mit dem Sleep ist der Javascript Adapter nicht mehr rot geworden, wollte ich nur anmerken. Und der Adapter kann, wird aber im Default bei weitem nicht soviele States erzeugen.