Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[mcm1957]

@codierknecht said in Async: Verständnisproblem:

Im Adaptercode wird in einer "normalen" (nicht async) Funktion ein this.setObjectNotExists ohne await aufgerufen. Geht ja auch nicht, weil keine Async-Funktion.
Direkt im Anschluss wird setState aufgerufen.

Wartet der Code an der Ecke jetzt bis this.setObjectNotExists zurückkehrt, oder ist das auch auf die Art immer asynchron?
Das würde die Fehlermeldung has no existing object erklären, da ja dann das setState aufgerufen wird und evtl. setObjectNotExists noch gar nicht beendet wurde.

Wenn das so OHNE callback drinnen steht ist es fehlerhaft.

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

Ich komme aus einer Welt, in der Asynchronität (Multithreading) mit viel Aufwand erkauft werden muss und bin es gewohnt, dass eine aufgerufene Funktion erst von A bis Z abgearbeitet wird, bevor der Code nach dem Funktionsaufruf weitermacht.

Davon musst du dich lösen. :-) Hier läuft node / js.

Ich würde den Adaptercode vermutlich umbauen.
Alle Funktionen grundsätzlich als async deklarieren und bei jedem Funktionsaufruf mit 'nem await auf die Beendigung derselben warten. Wäre das verwerflich? ;-)

Nö - spricht mal generell nichts dagegen. Aber bitte nicht mit Callbacks mischen.

Und weil die Frage dann sicher kommt: do onXxxx können async declariert werden (async onReady... usw).

[mcm1957]

@oliverio said in Async: Verständnisproblem:

@codierknecht sagte in Async: Verständnisproblem:

setObjectNotExists

hier die funktionssignatur aus vscode

du siehst der parameter callbacl ist optional und als return type gibt es entweder Promise oder CallBackReturnType oder void

Ich interpretiere, das

• wenn du ein callback funktion angibst ist es eine callback funktion (also ohne promise/await/async) und die rückgabe des ergebnisses wird im callback behandelt oder
• ohne callback-parameter gibt die funktion ein promise zurück, also musst du auch await davor schreiben, wenn du den rückgabe wert auswerten willst oder auf das ende der abbarbeitung des befehl wartest oder
• du wertest überhaupt keinn rückgabe wert aus, dann wird die aktion einfach ausgeführt, aber willst kein ergebnis auswerten

Aber ACHTUNG:
set(Foreign)Object ist erst ab js.controller 7 gesichert async fähig. Sie Changelog des js.controllers. Soll der Adapter mit js-controller vor 7 laufen sollte man noch setObjectAsync verwenden ...

[OliverIO]

@mcm1957 sagte in Async: Verständnisproblem:

Aber ACHTUNG

es wäre natürlich schön wenn diese information dann im jsdoc stehen würde, das würde dann vscode (und die anderen IDEs) dann im infofenster auch anzeigen.
https://jsdoc.app/tags-since

[ticaki]

@oliverio

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

[mcm1957]

@oliverio
Ja auch ne Möglichkeit.

Schreibs bitte im Issue von mir (https://github.com/ioBroker/ioBroker.js-controller/issues/3010) dazu was du ergänzen oder kritisieren willst. Je mehr fachlicher Input kommt desto leichter ist es für Moritz das zu erfüllen oder abzulegen (wenns eh niemand interessiert)<

Derzeit gibts leider gar keine Infos ab wann was gesichert funktioniert. Oder zumindest funktionieren sollte. Ein paar xxxAsync sind ja noch nicht umgestellt sondern nur für die Umstellung geplant (ist zumindest mein WIssensstand). ICh hab auch im Changelog des js-controllers nur die SetObject erwähnt geunden bei einer js-controller 7 Release. (Ev. brauch ich aber auch ne neue Brille)

Und das Schema zeigt ja den aktuellen Stand (js-.controller 7 ). User verwenden aber womöglich noch js-controller 3 (erst gestern im Forum :-) ), 4 (druchaus realistisch) oder 5 (weit verbreitet und bisher nicht offiziell abgekündigt)

[mcm1957]

@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

[OliverIO]

@ticaki sagte in Async: Verständnisproblem:

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

das wäre sicherlich auch ein guter Best practise Hinweis für die developer
um zu entscheiden wie weit Rückwärtskompatibel man sein möchte.

[carsten04]

@Codierknecht Ist zwar schon 10 Jahre alt, aber wenn Du gerne mal ein Youtube-Video schaust, dann empfehle ich Dir dieses. Hier geht es grundsätzlich zum Thema Eventloop. Das muss man einmal ungefähr kapiert haben, dann sind Promises, async-Functions und Callbacks auch nicht mehr die wirklich große Hürde.
Wenn Du lieber was lesen möchtest, dann empfehle ich immer gerne modern javascript und für async/await diese Kapitel.

[OliverIO]

@codierknecht

für wirklich umfassende Aufarbeitung von javascript von Anfänger bis Experten level
finde ich diese Seite hervorragend

https://javascript.info/

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