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

[Familienvater]

@oliverio
Da der Cache letztendlich doch Sourcefile-Abhängig ist, hat er auch nur die Subscriptions, die in diesem Sourcefile gemacht wurden.
Die "Core-Funktionalität" wollte/würde ich ins global packen, das "dynamische" Zufügen der Datenpunkte natürlich schon aus den individuellen Sourcefiles.
Wäre global ein echtes Global hätte jedes Sourcefile versucht, in einem globalen-Sourcefile Datenpunkte ins Cache-Directory zuzufügen, und alle anderen, die den gleiche Datenpunkt auch abonniert hätten wollen, hätten von der schon vorhandenen Subscription in der globalen Instanz profitiert. Ist aber nicht global, sondern doch Sourcefile-Abhängig, also hat/hätte jedes Sourcefile seine eigenen Subscriptions, egal ob die im globalen Sourcefile gemacht werden, oder im individuellen Sourcefile.

Da aber ein globales Function-Repository einfacher zu Pflegen ist, als 20x Copy-Paste-Code in 20 verschiedenen Sourcefiles (doppelte Daten/Sourcecode-Vorhaltung neigt zu Inkonsistenzen), werde ich den globalen Ansatz verfolgen.
Da getState wegen dem dazwischenliegenden socket.io anscheinend auch noch richtigen "Kommunikations-Overhead" zwischen dem Adapter und dem Kern erzeugt, scheint mir das Caching-Directory gar keine so schlechte Idee zu sein, wenn man groß denkt, selbst wenn es dafür mehr subscriptions gibt, die triggern ja wieder nur, wenn sich was subscribiertes ändert.
Und bei ggf. alle 5 min eine Änderung per Subscription erspart in den 300 Sekunden 60x getState, kann die Subscription mit ggf. 60x Directory-Lookup gar nicht so teuer sein, wenn 60x socket.io Zugriffe gespart werden, pro Variable.

Weil das javaScript halt kein c# ist, kann man wohl auch nicht "einfach" gewissen Funktionalitäten in Klassen kapseln, und muss sich gut überlegen, welche Funktion im global wirklich in "jedem" Sourcefile benötigt wird, weil es wieder nicht einfach nicht individuell optional dazu gebucht werden kann, so in der Art eines require("") oder "using".

Christian

[OliverIO]

@familienvater

Ich verstehe nicht warum du immer das Beispiel mit getstate bringst.
Ich glaube wir sind uns einig das pollen schlecht ist.

Lese die Doku zum on Befehls des JavaScript Adapters den du ja im Beispiel selbst schon verwendet hast.
Das ist genau die Ereignis gesteuerte Funktion die du brauchst und da brauchst du keinen weiteren Cache Mechanismus dazwischen.
Mit dem iobroker und JavaScript gibt es ja nur die 2 Möglichkeiten um an die Informationen eines datenpunkts zu kommen:
Getstate und der on trigger
Und die musst du in der Basis ja auch verwenden.

Aber probiere aus, mach Performance Messungen und präsentiere uns deine Ergebnisse

[Familienvater]

@oliverio
Dann zu meiner ganz ursprünglichen Frage:

Wie müsste die "MagicFunction" aussehen, um das als zwei-Zeiler funktionierend zu initialisieren?

const idFernseherAn = 'adapter.instanz.bla.blub';
let FernseherAn = MagicFunction(idFernseherAn, FernseherAn); 
// return der Function ist der initiale getState, und die MagicFunction registriert 
// die on-Subscription für den Datenpunkt, und "erstellt" die Callback-Function so, 
// das die übergebene Variable als Referenz aktuell gehalten wird, wenn sich der zugrundeliegende Datenpunkt ändert

Christian

[OliverIO]

@familienvater
Die hätte eine ähnliche Signatur wie die on Funktion
Je nachdem was dir lieber ist kannst du direkt eine callback Funktion mit übergeben oder die gibt ein promise zurück, damit du auf datenänderungen neben deinem caching auch reagieren kannst.
Zusätzlich würde ich auch eine unsubscribe Funktion schreiben, damit man das on für bestimmte datenpunkte wieder abmelden kann

[Familienvater]

@oliverio

Ich habe inzwischen eine funktionierende "SmarteVariablen"-TypeScript-Klasse, die wohl das tut, was ich möchte.

Langsam ahne ich aber evtl., was Du mit "doppelt gemoppelt" meintest, verstehe es mangels fehlender/nicht gefundener Dokumentation aber nicht.
Es gibt eine Option im Javascript-Adapter:

Nicht alle Zustände beim Start abonnieren

Leider finde ich keine Hinweise darauf, was diese Option bewirkt, aus das das Auswählen syncrone getState() "verhindert", und man dann alles mit await getStateAsync() machen muss, weil eben nicht alle States beim Start abonniert werden, aber getStateAsync ist z.B. in der Adapter-Doku gar nicht vorhanden, das muss man sich im Forum googlen, anderes Thema...

Welche "alle States" abonnieren? Alle States im ganzen ioBroker? Alle in dieser JavaScript-Instanz mit getState angesprochenen Datenpunkte?

I bims total verwirrt...

Christian

[paul53]

@familienvater sagte: Welche "alle States" abonnieren? Alle States im ganzen ioBroker?

Ja, alle ioBroker-States und -Objekte werden in den Puffer der Javascript-Instanz geladen.
Mit der asynchronen Version von getState() werden die Daten vom js-controller geholt.

[Familienvater]

@paul53 sagte in Zykl. getState-Aufrufe vs. eigenes "Cache-Dictionary":

Ja, alle ioBroker-States und -Objekte werden in den Puffer der Javascript-Instanz geladen.

und wie der Name/die Beschreibung der Option sagt, wahrscheinlich auch entsprechend alle im Java-Adapter abonniert.

Dann ist also ein Zugriff via syncronem getState im javaScript-Adapter ein Zugriff auf einen "State-Cache" im Adapter selber?

Blöde Frage:
Ist es bei einem subscribe() aus einem JS/TS-Sourcefile dann theoretisch egal, ob die "Nicht alle Zustände beim Start abonnieren"-Option ausgewählt ist oder nicht, weil da auf jeden Fall eine Subscription beim js-Controller selber gemacht wird, oder wird das ggf. auch aus dem vom Adapter selbst "vorhandenen" Abonnement vom JS-Adapter wieder an die Subscriptions in den Sourcefiles "multipliziert"?

Danke,
Christian

[OliverIO]

@familienvater

ja. ist egal.
getState ist die direkte Entsprechung eines Befehls des iobrokers, welcher der javascript-adapter ausführt. wenn alle dps abonniert sind, ist der wert dann schon im javascript adapter zwischengespeichert. wahrscheinlich spart man sich wartezeit, falls der rechner anderweitig schon ausgelastet ist.
auch das abonnieren aller datenpunkte ist ebenfalls so ein caching, welches der javascriptadapter macht.

es gab früher mal einen reiter, der wirklich alle ereignisse zu im browser datenpunktänderungen angezeigt hat. das hat aber den browser bzw. nur den tab schnell zur unbenutzbarkeit gebracht. ich denke er wurde deswegen aus iobroker entfernt

hast du den mal performancetests gemacht? da müsste man das messen können, auch wenn es nur wenige millisekunden sind

ich habe mal auf die schnelle einen test gemacht, aber mit und ohne alle abonnieren nicht viel unterschied festgestellt
es könnte natürlich sein, das der getstate befehl von der option nicht abhängt sondern immer bei iobroker nachfragt.
die abfrage hat bei mir immer zwischen 7 und 9 sekunden gedauert, egal ob die option aktiviert war oder nicht.
kann auch sein dass ich da noch ein denkfehler drin habe, aber await wartet ja immer bis der befehl abgeschlossen ist bevor dann der nächste dran ist.

async function test() {
    var start=new Date();
    for (var i=0;i<10000;i++) {
        var x = await getStateAsync("0_userdata.0.test1");
    }
    var end=new Date();
    console.log(start);
    console.log(end);
}

test();

[paul53]

@familienvater sagte: Dann ist also ein Zugriff via syncronem getState im javaScript-Adapter ein Zugriff auf einen "State-Cache" im Adapter selber?

Ja.

@familienvater sagte in Zykl. getState-Aufrufe vs. eigenes "Cache-Dictionary":

Ist es bei einem subscribe() aus einem JS/TS-Sourcefile dann theoretisch egal, ob die "Nicht alle Zustände beim Start abonnieren"-Option ausgewählt ist oder nicht, weil da auf jeden Fall eine Subscription beim js-Controller selber gemacht wird

Ja, Subscriptions verwenden nicht den internen Puffer.

[Familienvater]

@oliverio

Hi,

nein, ich habe noch nicht auf Performance getestet, auch weil mir offensichtlich die Basics noch nicht klar waren, und es damit Garbage In => Garbage Out wäre.

@oliverio sagte in Zykl. getState-Aufrufe vs. eigenes "Cache-Dictionary":

kann auch sein dass ich da noch ein denkfehler drin habe, aber await wartet ja immer bis der befehl abgeschlossen ist bevor dann der nächste dran ist
Denkfehler könnte sein, ich denke, mit dem getStateAsync ist es "egal", welche Option gewählt ist, das wird immer an den JS-Controller durchgestochen, wenn ich es richtig verstanden habe.
Man müsste also wahrscheinlich ein normales syncrones getState im "cachenden" Modus gegen ein asyncrones im nicht-Cachenden Modus vergleichen (und dann sollte das syncrone schneller sein, eigentlich).

Und eigentlich müsste man dann schauen, wie viel Zeit die reine Benachrichtigung über die Subscription nach einem "setState" braucht, um eine Aussage zu treffen, ob das Konstrukt mit "abonnierten" Änderungen abbilden auf Variablen CPU-Zyklen-schonender ist als zyklische getStates, und bei welcher Änderungshäufigkeit der BreakEven liegt. Ändert sich der "beobachtete" Datenpunkt häufiger, als er in einer zyklischen Routine abgefragt wird, erzeugt die häufiger triggernde Subscription evtl. mehr Overhead.
Aber ich gehe ja davon aus, das sich z.B. meine "Switches", die ich zyklisch Abfrage, nicht wirklich häufig ändern, sondern fast statisch verhalten.
Aber da kommt mir eine Idee, ich kann ja noch eine Statistk in die Klasse einbauen, die trackt, wie oft der Wert "gelesen" wurde, und wie oft die Subscription getriggert hat, und daraus kann ein "Cache-Hit-Ratio" für den Wert ermitteln, und ggf. Hinweise bei Tageswechsel oder so ins Log schreiben, das dieser Wert evtl. besser jedesmal neu abgefragt wird, und dafür zig unnötige Änderungen über den Trigger eingespart werden könnten.

Bleibt auf jeden Fall spannend das Thema,
Christian

[Familienvater]

Also, ich habe mal getestet, und zwar so:

async function test_async() {
    var start=Date.now();
    var i=0;
    for (i=0;i<50000;i++) {
        var x = (await getStateAsync("0_userdata.0.test1")).val;
    }
    var end=Date.now();
    console.log(i+".loops with async getState, delta " + (end-start) + "ms");
}
function test_sync() {
    var start=Date.now();
    var i=0;
    for (i=0;i<50000;i++) {
        var x = getState("0_userdata.0.test1").val;
    }
    var end=Date.now();
    console.log(i+".loops with sync getState, delta " + (end-start) + "ms");
}
 
test_async();
test_sync();

21:01:42.991	info	javascript.0 (320155) script.js.Logik.PerformanceTests: 50000.loops with sync getState, delta 12ms
21:01:42.991	info	javascript.0 (320155) script.js.Logik.PerformanceTests: registered 2 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions
21:01:46.748	info	javascript.0 (320155) script.js.Logik.PerformanceTests: 50000.loops with async getState, delta 3769ms

Also getState ist "definitv" gecached, und deutlich schneller...
Falls Du Dich wegen der Speed bei mir grundsätzlich wunderst, ioBroker läuft in einer VM mit 2 vCPUs, allerdings ist das ein hochdrehender 6-Core Workstation-XEON mit 3,7GHz (Basis) Takt...

Aber zum "Profilen" der Subscription habe ich nicht wirklich eine Idee, evtl. ein PingPong-Messung(Zeitstempel vor setState auf Id1, in der Subscription von Id1 wird Id2 geändert und in Subscription von Id2 wieder Id1, und Id2 macht das nur 1000x oder so und ermittelt dann das Delta, und evtl. könnte man dann mit dem delta/2 sagen, wie lange ein setState mit trigger dauert?

Muss ich mal testen
Und dann könnte es interessant werden, das ganze in einer mit und einer ohne State-Cache-Instanz zu machen

Christian

[Familienvater]

Ich bin selbst leicht "erstaunt", das es funktioniert, weil eigentlich darf die gecachte Instanz nur die default 1000 setState pro Minute triggern, aber der callback in den subscriptions läßt sich evtl. nicht auf die zurückverfolgen, oder ist so schnell rum, das noch kein Limiter anspricht?
Und weil ich es in meiner "leeren" Instanz.1 getestet habe, läuft da auch sonst gar nix

"use strict";

const loops=5000;
let start=0;
let end=0;

async function test_asyncStartPingPong() {

    // short delay, to let everything register...
    await new Promise(r => setTimeout(r, 2000));
    console.log("Start "+loops+".loops PingPong now!");

    start=Date.now();
    // start ping pong
    await setStateAsync('0_userdata.0.test1',loops);
}

on({id: '0_userdata.0.test1', change:'any'}, 
function (obj) {
    setState('0_userdata.0.test2', obj.state.val-1);
});

on({id: '0_userdata.0.test2', change:'any'}, 
function (obj) {
    if (obj.state.val>0)
        setState('0_userdata.0.test1', obj.state.val-1);
    else
    {
        end=Date.now();
        console.log(loops+".loops PingPong, received .val "+obj.state.val+" in " + obj.id + ", delta " + (end-start) + "ms");
    }
});

test_asyncStartPingPong();

Ohne "Caching" geht gar nix, obwohl in meinem Script keine getStates sind, werden welche angemosert, und globale/common Files habe ich keine expliziten in Instanz.1. Und die Werte schwanken "stark", der erste Wert ist direkt nach dem ich die Instanz neu gestartet habe, da ist die aber im Hintergrund evtl. noch dabei, den Cache zu füllen, nach 5 min Wartezeit ist das ganze 10x schneller, dann sogar nochmal etwas schneller, und dann ist es deutlich langsamer, da kann halt auch noch sonstwas auf dem ioBroker los sein, oder auch die anderen VMs auf dem esxi könnten "sonstwas" treiben...

21:59:15.800	info	javascript.1 (327919) Start javascript script.js.TestInstanz1.PerformanceTests
21:59:15.813	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: registered 4 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions
21:59:17.813	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: Start 5000.loops PingPong now!
22:00:00.194	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: 5000.loops PingPong, received .val -1 in 0_userdata.0.test2, delta 42380ms
22:05:12.407	info	javascript.0 (327870) Stop script script.js.TestInstanz1.PerformanceTests
22:05:12.413	info	javascript.1 (327919) Stop script script.js.TestInstanz1.PerformanceTests
22:05:12.416	info	javascript.1 (327919) Start javascript script.js.TestInstanz1.PerformanceTests
22:05:12.422	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: registered 4 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions
22:05:14.422	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: Start 5000.loops PingPong now!
22:05:19.332	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: 5000.loops PingPong, received .val -1 in 0_userdata.0.test2, delta 4910ms
22:05:42.881	info	javascript.0 (327870) Stop script script.js.TestInstanz1.PerformanceTests
22:05:42.885	info	javascript.1 (327919) Stop script script.js.TestInstanz1.PerformanceTests
22:05:42.931	info	javascript.1 (327919) Start javascript script.js.TestInstanz1.PerformanceTests
22:05:42.934	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: registered 4 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions
22:05:44.934	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: Start 5000.loops PingPong now!
22:05:49.415	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: 5000.loops PingPong, received .val -1 in 0_userdata.0.test2, delta 4481ms
22:06:04.647	info	javascript.1 (327919) Stop script script.js.TestInstanz1.PerformanceTests
22:06:04.646	info	javascript.0 (327870) Stop script script.js.TestInstanz1.PerformanceTests
22:06:04.650	info	javascript.1 (327919) Start javascript script.js.TestInstanz1.PerformanceTests
22:06:04.653	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: registered 4 subscriptions, 0 schedules, 0 messages, 0 logs and 0 file subscriptions
22:06:06.653	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: Start 5000.loops PingPong now!
22:06:17.941	info	javascript.1 (327919) script.js.TestInstanz1.PerformanceTests: 5000.loops PingPong, received .val -1 in 0_userdata.0.test2, delta 11287ms

Ich danke, man kann so eine ungefähre Aussage zur RoundTrip-Zeit machen, im Optimalfall ist es ca. 1 ms, die es vom setState bis zur Ankunft im subscribe-Callback braucht (auf meinem 3,7GHz-Xeon).

Christian