Moin,

also mit dem JSON-Chart habe ich es nicht hinbekommen, aber mit dem Bar Chart hat es geklappt, und es ist ausreichend "hübsch":

Zu meinem Code und als Entschuldigung: JavaScript ist nicht so meins :-), Kommentare sind immerhin überhaupt welche drin. Und die createChartData - Funktion ist das, was ich vergeblich für das JSON-Chart versucht hatte, vielleicht schleift das noch jemand rund...

var myName = "tibber.createchartdata";

var logOn           = false;     // Skript Logausgabe ein- (true) / ausschalten (false). Fehler werden immer ausgegeben.
var forceCreation    = false;    // Default: false. true: Datenpunkte werden überschrieben (wenn z.B. Bezeichnungen geändert wurden)

var tibberPricesToday = "tibber.0.priceInfo.today.";        // mit . am Ende!
var tibberPricesTomorrow = "tibber.0.priceInfo.tomorrow.";  // mit . am Ende!

var tibberStartsAt = "startsAt";
var tibberTotal = "total";


// Datenpunkte anlegen:
// -----------------------------------------------------------------------------
var idChartData = "tibber.prices.chartData";                      // Pfad und Name, unter dem in der Javascript-Instanz der Datenpunkte angelegt wird
createState(idChartData, '[{"label":"15","value":"25.2","dataColor":"#ffffff"},{"label":"16","value":"28.8","dataColor":"#ffffff"},{"label":"17","value":3"5.2","dataColor":"#ffffff"},{"label":"18","value":"33.2","dataColor":"#ffffff"},{"label":"19","value":"20.2","dataColor":"#ffffff"}]', forceCreation, {
     name: 'Chart-Data Price Forecast',
     desc: 'Chart-Data Price Forecast',
     type: 'string',
     role: 'value'
});

// Datenpunkte anlegen:
// -----------------------------------------------------------------------------
var idBarChartData = "tibber.prices.barChartData";                      // Pfad und Name, unter dem in der Javascript-Instanz der Datenpunkte angelegt wird
createState(idBarChartData, '[{"label":"15","value":"25.2","dataColor":"#ffffff"},{"label":"16","value":"28.8","dataColor":"#ffffff"},{"label":"17","value":3"5.2","dataColor":"#ffffff"},{"label":"18","value":"33.2","dataColor":"#ffffff"},{"label":"19","value":"20.2","dataColor":"#ffffff"}]', forceCreation, {
     name: 'Bar Chart-Data Price Forecast',
     desc: 'Bar Chart-Data Price Forecast',
     type: 'string',
     role: 'value'
});

createBarChartData();

// Cron-Job, zum Stundenwechsel
// Stundenwechsel, Ausführen immer um *:00:10
schedule('10 0 * * * *', function () {createBarChartData()});

function createBarChartData () {    
	if(logOn) console.log(myName + " Stundenwechsel");
    
    let barChart = [];

    var jetzt = new Date(Date.now());
    var aktStunde = jetzt.getHours();
    var unixTimestamp=new Date().getTime();

    // bis zu 18 Stunden in die Zukunft
    const offsets=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 13, 14, 15, 16, 17, 18];

    for (let offset of offsets)
    {
        // Template Objekt für BarChart erzeugen
        let itemData ={label:"", value:0.0, dataColor: "#c2c2c2", valueColor: "#dddddd"}; //, valueAppendix: "", valueColor: #ffffff"

        // Vorbereitung um Werte aus Tibber Adapter zu holen         
        var prefix="";
        aktStunde=jetzt.getHours()+offset;
        if (aktStunde>23)
        {
            aktStunde=aktStunde-24;
            prefix=tibberPricesTomorrow;
        }
        else
        {
            prefix=tibberPricesToday;
        }

        var strStunde = ("0" + aktStunde.toString()).slice(-2);
        itemData['label']=strStunde;

        prefix=prefix+strStunde+'.';

        var aktPrice=getState(prefix+tibberTotal).val;
 
        // falls keine Daten vorliegen, weiter ohne diese ItemData an das Chart-Objekt anzuhängen
        if (aktPrice==null && aktStunde>=0)
            continue;

        // von 0.2345 € auf Cent mit einer Nachkomma-Stelle umrechnen
        itemData['value']=Math.round(aktPrice*1000)/10.0;

        // Je nach Preis den Balken einfärben
        if (aktPrice<0.30)
            itemData['dataColor']="green";
        else
        if (aktPrice<0.40)
            itemData['dataColor']="yellow";
        else
        if (aktPrice<0.50)
            itemData['dataColor']="orange";
        else
        if (aktPrice<0.60)
            itemData['dataColor']="red";
        else
            itemData['dataColor']="magenta";

        // Daten für diese Stunde dem Objekt zufügen
        barChart.push(itemData);
    }

    // fertiges Objekt in den Datenpunkt als JSON schreiben
    setState("javascript."+instance+"."+idBarChartData, JSON.stringify(barChart), true);

};

function createChartData () {    
	if(logOn) console.log(myName + " Stundenwechsel");
    
    let chart = {};
    let axisLabels =[];
    let values =[];
    let datalabels =[];

    var jetzt = new Date(Date.now());
    var aktStunde = jetzt.getHours();
    var unixTimestamp=new Date().getTime();

    const offsets=[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 13, 14, 15, 16, 17, 18];

    // Spaltenbeschriftungen
 
    //chart.graphs[0].axisLables=axisLabels;
    chart.graphs=new Array();
    chart.graphs.push({});
    chart.graphs[0].color="green";
    chart.graphs[0].type="bar";
    chart.graphs[0].datalabel_rotation=-90;
    chart.graphs[0].datalabel_color="lightgreen";
    chart.graphs[0].datalabel_fontSize=10;
    chart.graphs[0].yAxis_title_text="cent";
    chart.graphs[0].yAxis_show=true;
    chart.graphs[0].legendText="Uhrzeit";
    chart.graphs[0].datalabel_show=true;
    chart.graphs[0].yAxis_minimumDigits=1;
    chart.graphs[0].yAxis_maximumDigits=1;

    for (let offset of offsets)
    {
        // Spaltenbeschriftungen
        aktStunde=jetzt.getHours()+offset;
        if (aktStunde>23)
            aktStunde=aktStunde-24;
        var strStunde = ("0" + aktStunde.toString()).slice(-2);
        axisLabels.push(strStunde)
        //axisLabels.push(aktStunde);
               
        var prefix="";
        aktStunde=jetzt.getHours()+offset;
        if (aktStunde>23)
        {
            aktStunde=aktStunde-24;
            prefix=tibberPricesTomorrow+".";
        }
        else
        {
            prefix=tibberPricesToday+".";
        }

        strStunde = ("0" + aktStunde.toString()).slice(-2);
        prefix=prefix+strStunde+'.';

        //if(logOn) console.log(myName + " Stundenwechsel, akt Stunde "+strStunde+", prefix "+prefix);
        var aktPrice=getState(prefix+tibberTotal).val;
        //var aktStartAt=getState(prefix+tibberStartsAt).val;
        //if(logOn) console.log(myName + " aktPrice "+aktPrice+", aktStartAt "+aktStartAt);
        //let itemData ={t:0, y:0.0};
        //itemData['t']=unixTimestamp+3600*offset;
        //itemData['y']=aktPrice;
        values.push(Math.round(aktPrice*1000)/10.0);
        var cents=(Math.round(aktPrice*1000)/10.0).toString();
        datalabels.push(cents);

    }
    chart.graphs[0].data=values;
    chart.graphs[0].datalabel_override=datalabels;
    chart.data=values;
    chart.datalabel_override=datalabels;
    chart.axisLables=axisLabels;

    setState("javascript."+instance+"."+idChartData, JSON.stringify(chart));

};

Christian

Und hier noch das exportierte Widget

[{"tpl":"tplVis-materialdesign-Chart-Bar","data":{"oid":"javascript.0.tibber.prices.barChartData","g_fixed":false,"g_visibility":false,"g_css_font_text":false,"g_css_background":false,"g_css_shadow_padding":false,"g_css_border":false,"g_gestures":false,"g_signals":false,"g_last_change":false,"visibility-cond":"==","visibility-val":1,"visibility-groups-action":"hide","chartDataMethod":"jsonStringObject","dataCount":"0","chartType":"vertical","backgroundColor":"#mdwTheme:vis-materialdesign.0.colors.charts.background","chartAreaBackgroundColor":"#mdwTheme:vis-materialdesign.0.colors.charts.background_chart","titleLayout":"#mdwTheme:vis-materialdesign.0.fontSizes.card.title","titleFontFamily":"#mdwTheme:vis-materialdesign.0.fonts.card.title","colorBackground":"#mdwTheme:vis-materialdesign.0.colors.card.background","colorTitleSectionBackground":"#mdwTheme:vis-materialdesign.0.colors.card.background_title","colorTextSectionBackground":"#mdwTheme:vis-materialdesign.0.colors.card.background_body","colorTitle":"#mdwTheme:vis-materialdesign.0.colors.card.title","globalColor":"#mdwTheme:vis-materialdesign.0.colors.charts.global","hoverColor":"#mdwTheme:vis-materialdesign.0.colors.charts.bar.hover","hoverBorderColor":"#mdwTheme:vis-materialdesign.0.colors.charts.bar.hover_border","showValues":"showValuesOn","valuesFontColor":"#mdwTheme:vis-materialdesign.0.colors.charts.value","valuesFontFamily":"#mdwTheme:vis-materialdesign.0.fonts.charts.value","valuesFontSize":"10","valuesPositionAnchor":"end","valuesPositionAlign":"top","valuesTextAlign":"center","yAxisPosition":"left","yAxisTitleColor":"#mdwTheme:vis-materialdesign.0.colors.charts.y_axis_title","yAxisTitleFontFamily":"#mdwTheme:vis-materialdesign.0.fonts.charts.y_axis_title","yAxisTitleFontSize":"#mdwTheme:vis-materialdesign.0.fontSizes.charts.y_axis_title","yAxisValueLabelColor":"#dddddd","yAxisValueFontFamily":"#mdwTheme:vis-materialdesign.0.fonts.charts.y_axis_values","yAxisValueFontSize":"#mdwTheme:vis-materialdesign.0.fontSizes.charts.y_axis_values","yAxisValueDistanceToAxis":"10","yAxisShowAxis":"true","yAxisShowAxisLabels":"true","yAxisShowGridLines":"true","yAxisGridLinesColor":"#ffffff","yAxisShowTicks":"true","yAxisZeroLineColor":"#mdwTheme:vis-materialdesign.0.colors.charts.y_axis_zeroline","xAxisPosition":"bottom","xAxisTicksSource":"auto","xAxisTitleColor":"#mdwTheme:vis-materialdesign.0.colors.charts.x_axis_title","xAxisTitleFontFamily":"#mdwTheme:vis-materialdesign.0.fonts.charts.x_axis_title","xAxisTitleFontSize":"#mdwTheme:vis-materialdesign.0.fontSizes.charts.x_axis_title","xAxisValueLabelColor":"#dddddd","xAxisValueFontFamily":"#mdwTheme:vis-materialdesign.0.fonts.charts.x_axis_values","xAxisValueFontSize":"#mdwTheme:vis-materialdesign.0.fontSizes.charts.x_axis_values","xAxisValueDistanceToAxis":"0","xAxisShowAxis":"true","xAxisShowAxisLabels":"true","xAxisShowGridLines":"true","xAxisGridLinesColor":"#ffffff","xAxisShowTicks":"true","xAxisZeroLineColor":"#mdwTheme:vis-materialdesign.0.colors.charts.x_axis_zeroline","xAxisMinRotation":"0","xAxisMaxRotation":"0","legendPosition":"right","legendFontColor":"#mdwTheme:vis-materialdesign.0.colors.charts.legend","legendFontFamily":"#mdwTheme:vis-materialdesign.0.fonts.charts.legend","legendFontSize":"#mdwTheme:vis-materialdesign.0.fontSizes.charts.legend","legendPointStyle":"true","showTooltip":"true","tooltipBackgroundColor":"#mdwTheme:vis-materialdesign.0.colors.charts.tooltip_background","tooltipShowColorBox":"true","tooltipTitleFontColor":"#mdwTheme:vis-materialdesign.0.colors.charts.tooltip_title","tooltipTitleFontFamily":"#mdwTheme:vis-materialdesign.0.fonts.charts.tooltip_title","tooltipTitleFontSize":"#mdwTheme:vis-materialdesign.0.fontSizes.charts.tooltip_title","tooltipBodyFontColor":"#mdwTheme:vis-materialdesign.0.colors.charts.tooltip_text","tooltipBodyFontFamily":"#mdwTheme:vis-materialdesign.0.fonts.charts.tooltip_text","tooltipBodyFontSize":"#mdwTheme:vis-materialdesign.0.fontSizes.charts.tooltip_text","signals-cond-0":"==","signals-val-0":true,"signals-icon-0":"/vis/signals/lowbattery.png","signals-icon-size-0":0,"signals-blink-0":false,"signals-horz-0":0,"signals-vert-0":0,"signals-hide-edit-0":false,"signals-cond-1":"==","signals-val-1":true,"signals-icon-1":"/vis/signals/lowbattery.png","signals-icon-size-1":0,"signals-blink-1":false,"signals-horz-1":0,"signals-vert-1":0,"signals-hide-edit-1":false,"signals-cond-2":"==","signals-val-2":true,"signals-icon-2":"/vis/signals/lowbattery.png","signals-icon-size-2":0,"signals-blink-2":false,"signals-horz-2":0,"signals-vert-2":0,"signals-hide-edit-2":false,"lc-type":"last-change","lc-is-interval":true,"lc-is-moment":false,"lc-format":"","lc-position-vert":"top","lc-position-horz":"right","lc-offset-vert":0,"lc-offset-horz":0,"lc-font-size":"12px","lc-font-family":"","lc-font-style":"","lc-bkg-color":"","lc-color":"","lc-border-width":"0","lc-border-style":"","lc-border-color":"","lc-border-radius":10,"lc-zindex":0,"chartPaddingBottom":"1","cardUse":false,"xAxisTitle":"","showLegend":false,"axisValueAppendText":"","axisLabelAutoSkip":false,"g_layoutForData_§0":false,"g_oids":false,"barWidth":"","valuesRotation":"-90","valuesPositionOffset":"","valuesMaxDecimals":"1","valuesMinDecimals":"1"},"style":{"left":"420px","top":"248px","width":"410px","height":"213px"},"widgetSet":"materialdesign"}]

@homoran

OK, ich habe es geschafft, das aus dem nicht-Stable zu Installieren, und auch aus dem großen Hilfe-Thread mit Beispiel-Daten was zu erzeugen (was mir mit der Anleitung anleine nicht gelungen ist).
Erstmal Danke an alle, dann wird mir heute sicherlich nicht mehr langweilig.

Danke,
Christian

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

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

@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

@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

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

@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
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

Habe jetzt eher zufällig eine Antwort gefunden:

das ganze in den global-folder macht es trotzdem nicht global für alle sourcefiles, weil es wird ja nur das global-File Zeugs vor jedes individuelle Source-File Zeugs gepackt.
Um von einem Sourcefile in ein anderes zu "kommunizieren", muss man Datapoints nutzen...

Christian

@oliverio
Wie gesagt, mir ist nicht klar, wie "teuer" (overHead) ein getState Aufruf ist, oder ob das im Hintergrund auch nur eine Abfrage auf ein Dictionary ist.
Sicherlich wird ein, oder auch 20 getState-Aufrufe ioBroker nicht ins stocken bringen, aber macht man es einmal so, und es funktioniert, dann macht man es evtl. immer so, und dann rächt es sich irgendwann, und dann stellt man fest, das "alles" Grütze ist.

Ich bin schon immer ein Freund der Event getriebenen Programmierung, und ein "zyklisches" Pollen (abfragen) von Zuständen ist mir von meiner Programmierlogik zuwider, ich vergleiche das gerne mit dem gemütlichen Menschen, der vor dem Fernseher sitzt, und wartet, bis es an der Türe klingelt, oder bei dem sich die Blase meldet, und er dann auf Toilette geht. Dem stehen die zyklischen Programmieransätze entgegen, wo Bildliche gesprochen einer alle 5 Sekunden an die Türe rennt, und schaut, ob da jemand ist, und dann zur Toilette rennt, und schaut, ob was kommt, und sich dann wieder vor den Fernseher setzt.

Vielleicht versteht man jetzt eher mein Hintergedanken, vielleicht sehe ich aber auch einfach ein Problem, wo kein Problem existiert, und ich bin nur von c#/unity getrieben, alles so CPU-Zyklen schonend/frameraten-freundlich zu erstellen, wie möglich, weil sich auch da alles bei einem oder nur ein paar Objekten absolut performance-Neutral verhält, aber später dann, wenn es zum richtigen Einsatz kommt, ist es auf einmal mit tausenden von Objekten überhaupt gar nicht mehr so performant.

Christian

Moin,

ich habe hier und mit google gesucht, mich ausführlich mit ChatGPT unterhalten, aber javaScript ist (noch) nicht meins, ich bin inzwischen beruflich sehr viel mit c# in Unity unterwegs, Programmieren an sich ist weniger das Problem...
Also, für Entscheidungen in ioBroker, unter welchen Bedingungen Geräte z.B. ein-/ausgeschaltet werden sollen, um den Eigenverbrauch zu optimieren, habe ich die Einspeise- und Bezugsdatenpunkt von meinem Discovergy-Stromzähler-Adapter in js "abonniert", und sollte alle 5 Sekunden neue Werte bekommen.

Da ich (mit mir meine ich meistens die Logik in ioBroker) für die Entscheidungen, "viele" andere Datenpunkte in Betracht ziehen will, stelle ich mir die Frage, wie "teuer" ein getState alle 5 Sekunden ist (mal x-Datenpunkte), wenn sich der Wert evtl. nur alle paar Minuten oder noch seltener ändert.

Da ich gerne "groß" denke, suche ich nach einer pflegeleichten Lösung, eigentlich hätte ich gerne etwas in der folgenden Art, aber "automatisiert" mit vielleicht einem 2-Zeiler:

const idFernseherAn = 'adapter.instanz.bla.blub';
let FernseherAn = getState(idFernseherAn); // absichtlich State, weil mich evtl. auch .lc interessiert
on({id: idFernseherAn  ,change:'any'}, function (obj) {
FernseherAn = obj.state;
    });

// FernseherAn  sollte jetzt immer "aktuell" sein, ohne das alle 5 Sekunden getState aufgerufen werden muss

Wunsch:

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

Aktueller Lösungsansatz:

const dataPoints = {};
const idFernseherAn = 'adapter.instanz.bla.blub';

// Initialisieren Sie die Cache-Objekte für jede Datenpunkt-ID
SetupCacheStateVariable(idFernseherAn);
    
function SetupCacheStateVariable(idDataPoint)
{
    dataPoints[idDataPoint] = getState(idDataPoint);
    on({id: idDataPoint, change:'any'}, function (obj) {
        UpdateCache(obj);
    });
}

function UpdateCache(obj)
{
    dataPoints[obj.id] = obj.state;
}

// Zugriff mit z.B. dataPoints[idFernseherAn].val

Wie gesagt, ich denke "groß", und habe aktuell sicherlich 20 Datenpunkte, die ich zyklisch für die Entscheidung, einschalten, an lassen, ausschalten oder womöglich auch "umkonfigurieren" durchkauen lasse.

Eigentlich würde ich lieber mit Variablennamen arbeiten, und nicht alles über Zugriffe auf das Dictionary lösen.

Jetzt noch zwei Gretchenfragen:
Nach dem ich jetzt mal in TypeScript reingeschnuppert habe, und ich eigentlich die strikte-Typprüfung zum Compile-Zeitpunkt ala c# mag, wäre so etwas mit TypeScript "einfacher"/anders/besser lösbar?

Würde es sich anbieten, oder verbieten, den ganzen Cache-Kram in ein Sourcefile im global-Folder zu packen? Dann müsste man im SetupCacheStateVariable prüfen, ob es den Key noch nicht gibt, und nur dann die Subscription machen.
Pro: Ein Cache-Object für alle Source-Files, evtl. weniger Subscribes im ganzen auf häufiger benötigte Datenpunkte, weil einmal Zentral und nicht n-mal in x-Sourcefiles
Contra: Beim Beenden eines Sourcefiles wird keine Subscription gelöscht, wenn am global-File was geändert wird, muss eh die komplette JS-Adapterinstanz neu getartet werden?
Contra: Unmöglich zu debuggen/nachzuvollziehen?
Unklar: Könnte Threading ein Issue sein oder schwer zu findende RaceConditions auslösen (ich habe da manchmal Spaß mit c# und "fremdem" Code)?

Schubst mich bitte mal in die ein oder andere Richtung, hoffentlich in die richtige...

Danke,
Christian