NEWS
[gelöst]: Async: Verständnisproblem
-
Mir hat da die installation von
@iobroker/types@6.0.11geholfen, damit ich mit 6 kompatibel bleibe.@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. -
Mir hat da die installation von
@iobroker/types@6.0.11geholfen, damit ich mit 6 kompatibel bleibe.@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. -
@mcm1957 sagte in Async: Verständnisproblem:
setState (wenn es die adapater.setState / this.setState Funktion ist) ist ASYNCHRON. Diese retourniert sofort
Es geht um Adaptercode - kein Script.
Im Adaptercode wird in einer "normalen" (nicht async) Funktion ein
this.setObjectNotExistsohneawaitaufgerufen. Geht ja auch nicht, weil keine Async-Funktion.
Direkt im Anschluss wirdsetStateaufgerufen.Wartet der Code an der Ecke jetzt bis
this.setObjectNotExistszurückkehrt, oder ist das auch auf die Art immer asynchron?
Das würde die Fehlermeldunghas no existing objecterklären, da ja dann dassetStateaufgerufen wird und evtl.setObjectNotExistsnoch gar nicht beendet wurde.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.
Macht für mich an der Ecke allerdings auch Sinn, da man die Abarbeitung von Code so vorhersehen kann.
Asynchronität wird da in der Regel nur über die Message-Queue verwendet, damit z.B. MouseMove oder ButtonClick nix blockieren. Oder (mit relativ viel Aufwand) um z.B. während lang laufender Datenbanloperationen einen BusyDialog anzuzeigen.Ich würde den Adaptercode vermutlich umbauen.
Alle Funktionen grundsätzlich alsasyncdeklarieren und bei jedem Funktionsaufruf mit 'nemawaitauf die Beendigung derselben warten. Wäre das verwerflich? ;-)für wirklich umfassende Aufarbeitung von javascript von Anfänger bis Experten level
finde ich diese Seite hervorragend -
@ticaki said in Async: Verständnisproblem:
Mir hat da die installation von
@iobroker/types@6.0.11geholfen, damit ich mit 6 kompatibel bleibe.Jep klingt vernünftig
dann bitte auch js-controller > 6.0.11 in dependencies des Adapters eintragen@mcm1957 sagte in Async: Verständnisproblem:
@ticaki said in Async: Verständnisproblem:
Mir hat da die installation von
@iobroker/types@6.0.11geholfen, damit ich mit 6 kompatibel bleibe.Jep klingt vernünftig
dann bitte auch js-controller > 6.0.11 in dependencies des Adapters eintragenWegen 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 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 (also void)
@oliverio sagte in Async: Verständnisproblem:
Ich interpretiere, das
So lese ich das auch. Also ein
awaitdavor, um erst weiterzumachen wenn der Aufruf zurückkehrt.
Die aufrufende Funktion muss damit zwingens auchasyncsein."Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")
Proxmox 9.1.1 LXC|8 GB|Core i7-6700
HmIP|ZigBee|Tasmota|Unifi
Zabbix Certified Specialist
Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag -
@oliverio sagte in Async: Verständnisproblem:
Ich interpretiere, das
So lese ich das auch. Also ein
awaitdavor, um erst weiterzumachen wenn der Aufruf zurückkehrt.
Die aufrufende Funktion muss damit zwingens auchasyncsein.@codierknecht said in Async: Verständnisproblem:
@oliverio sagte in Async: Verständnisproblem:
Ich interpretiere, das
So lese ich das auch. Also ein
awaitdavor, um erst weiterzumachen wenn der Aufruf zurückkehrt.
Die aufrufende Funktion muss damit zwingens auchasyncsein.ja
oder ESM.async ist im Adapter aber kein Problem.
-
@codierknecht said in Async: Verständnisproblem:
Im Adaptercode wird in einer "normalen" (nicht async) Funktion ein
this.setObjectNotExistsohneawaitaufgerufen. Geht ja auch nicht, weil keine Async-Funktion.
Direkt im Anschluss wirdsetStateaufgerufen.Wartet der Code an der Ecke jetzt bis
this.setObjectNotExistszurückkehrt, oder ist das auch auf die Art immer asynchron?
Das würde die Fehlermeldunghas no existing objecterklären, da ja dann dassetStateaufgerufen wird und evtl.setObjectNotExistsnoch 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 alsasyncdeklarieren und bei jedem Funktionsaufruf mit 'nemawaitauf 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 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 mitsetObjectNotExistszu 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.
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." (Martin Fowler, "Refactoring")
Proxmox 9.1.1 LXC|8 GB|Core i7-6700
HmIP|ZigBee|Tasmota|Unifi
Zabbix Certified Specialist
Konnte ich Dir helfen? Dann benutze bitte das Voting unten rechts im Beitrag -
@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 mitsetObjectNotExistszu 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.
@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.
-
@mcm1957 sagte in Async: Verständnisproblem:
@ticaki said in Async: Verständnisproblem:
Mir hat da die installation von
@iobroker/types@6.0.11geholfen, damit ich mit 6 kompatibel bleibe.Jep klingt vernünftig
dann bitte auch js-controller > 6.0.11 in dependencies des Adapters eintragenWegen 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.
@ticaki sagte in Async: Verständnisproblem:
Wegen der Anmerkung das 5 noch immer aktiv ist
5.0.19 hat auch noch relativ viele nutzer.
-
@ticaki sagte in Async: Verständnisproblem:
Wegen der Anmerkung das 5 noch immer aktiv ist
5.0.19 hat auch noch relativ viele nutzer.
@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.
-
@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 mitsetObjectNotExistszu 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.
@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
Meine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
@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
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
-
@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! -
@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
@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. -
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
@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.
- 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.
-
@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.
@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.
- 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.
Support us
533
Online32.4k
Benutzer81.6k
Themen1.3m
Beiträge