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

[smartin23]

@liv-in-sky Okay, danke!

Schade - damm müsste ich ja eine Menge Daten am besten jede Sekunde im Interval abrufen, damit ich sie alle immer in Echtzeit dargestellt bekomme. Ziemlich aufwändig.

Um mal alleine beim Sonos-Beispiel zu bleiben:

Dann müsste ich also das Cover jede Sekunde aktualisieren, damit es direkt mit Start eines neuen Titels auch korrekt angezeigt wird. Dann müsste ich den Sender oder den Titel/Interpret jede Sekunde abfragen, damit das immer zeitnah korrekt angezeigt wird. Und ich müsste auch die laufende Zeit jede Sekunde abfragen, um sie aktuell anzuzeigen und aus Endzeit und aktueller Zeit den Fortschritt für den Fortschrittsbalken zu berechnen und anzuzeigen. Dazu müsste ich auch den Play/Stop-Status ich jede Sekunde abfangen, um den Play-Button korrekt anzuzeigen.

Bin ich da auf dem richtigen Weg? Oder würdet Ihr da grundsätzlich eine ganz andere Herangehensweise wählen?

Hintergrund ist ja, dass ich meine VIS komplett in eigenem Design und nach eigenen Vorstellungen bauen möchte - daher baue ich alles händisch. Irgendwie hatte ich mir das mit ein bisschen Erfahrung in Javascript einfacher vorgestellt, aber irgendwie stoße ich bei jedem kleinen Schritt wieder an neue Herausforderungen... Daher noch mal: Tausend dank, dass Ihr hier so gut weiterhelft!

[OliverIO]

@smartin23
Ja du kannst das binding erweitern und Entscheidungen einbauen
Hier ist ein Beispiel für die Textfarbe
Aber das kannst du in jedes Konfigurationsfeld für ein Widget reinschreiben
https://forum.iobroker.net/topic/49699/binding-textfarbe-nach-wert/3

[smartin23]

@oliverio Alles klar, das schaue ich mir auch an und gucke mal, was für mich die beste Variante ist.

[smartin23]

Hallo zusammen,

habe es jetzt so gelöst:

    const devicename = "sonos.0.root.192_168_178_21.";

    function sonosrefresh () {
        servConn.getStates([
                devicename + "state_simple",
                devicename + "current_type",
                devicename + "current_cover",
                devicename + "current_station",
                devicename + "current_title",
                devicename + "current_artist",
                devicename + "current_elapsed",
                devicename + "current_elapsed_s",
                devicename + "current_duration",
                devicename + "current_duration_s",
                devicename + "members"
            ], (error, states) => {
        
            // Werte abfragen
            let members = states[devicename + "members"].val;
            let status = states[devicename + "state_simple"].val;
            let type = states[devicename + "current_type"].val;
            let cover = states[devicename + "current_cover"].val;
            let station = states[devicename + "current_station"].val;
            let title = states[devicename + "current_title"].val;
            let artist = states[devicename + "current_artist"].val;
            let elapsed = states[devicename + "current_elapsed"].val;
            let elapsed_text = states[devicename + "current_elapsed_s"].val;
            let duration = states[devicename + "current_duration"].val;
            let duration_text = states[devicename + "current_duration_s"].val;

            // Verwendung der Parameter
               
            }
        
        });
    }

    setInterval(sonosrefresh, 1000);
</script>

Ich habe mich für diese Variante entschieden, damit ich umfangreiche Operationen mit den Parametern durchführen kann: Texte verketten, CSS-Klassen in abhängigkeit von berechneten Werten zuordnen und so weiter - das würde so umfangreich und speziell innerhalb von Bindings wohl eher nicht gehen, oder?

Grundsätzlich funktioniert das auch prima. Nur: Nach so 10-15 Minuten schmeißt die Konsole hundertfach die Fehlermeldung " Trying to get states again, because emitted getStates still pending." raus und die Oberfläche aktualisiert sich nicht mehr.

Kann es sein, dass das VIS dann einfach überfordert durch die sekündlichen Anfragen ist? Wie kann ich das denn auch für den Dauerbetrieb stabilisieren?

[liv-in-sky]

@smartin23

du könntest mal folgendes testen (weiß nicht, ob das mehr sinn macht)

in einem versteckten html widget erstelle ein binding des dp: z.b.

{0_userdata.0.CONTROL-OWN.AAATEST.TestLogic3}

anstatt nun den server abzufragen, könntest du folgendes script nehmen - ich denke, da wird nur lokal in der seite abgefragt - sicher bin ich mir da aber nicht, aber wenn du kein binding des datenpunktes hast, wird der wert nicht angezeigt

setInterval( () => { 
var myRunningDevice1=vis.states.attr('0_userdata.0.CONTROL-OWN.AAATEST.TestLogic3.val');
 console.log(myRunningDevice1)      
}, 1000);

[OliverIO]

@liv-in-sky
@smartin23

Dann würde ich es lieber nicht so machen wie Liv es zeigt. Da werden die Mechanismen von iobroker verwendet.
Das andere Beispiel erzeugt viel unnötigen Netztraffic und Last auf iobroker

Noch besser wäre folgendes

vis.states.attr ist ein Array von Objekten vom typ
Map aus der Bibliothek CanJS

https://v2.canjs.com/docs/can.Map.html

Da kann man observer anmelden und auf Änderungen hören.
Genau so macht vis auch um nur dann Programm auszuführen wenn es wirklich notwendig ist
Bei den observern muss man aufpassen das sich der Pointer der callback Funktion sich nicht ändern, sonst kann man den observern nicht mehr abmelden und man erzeugt memory leaks

[liv-in-sky]

@oliverio

meinst du das : https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver/MutationObserver

wie definiert man das ? habe ich schon versucht - aber nicht den durchblick

hbe das versucht und als queryselector eine eigene class angegeben - da passiert nix

// identify an element to observe
const elementToObserve = document.querySelector("#abcdd");

// create a new instance of `MutationObserver` named `observer`,
// passing it a callback function
const observer = new MutationObserver(() => {
  console.log("callback that runs when observer is triggered");
});

// call `observe()` on that MutationObserver instance,
// passing it the element to observe, and the options object
observer.observe(elementToObserve, { subtree: true, childList: true, characterData: true,  attributes: true });

[OliverIO]

@liv-in-sky
Nein, das ist was anderes.
Mutation observer ist auch nicht über alles Browser consistent umgesetzt.

Observers steht für die Bezeichnung eines entwicklungsmuster.
Davon gibt es mehrere. Die wurden mal aufgeschrieben, das man ähnliche Probleme nicht immer wieder anders löst. Lohnt sich mal durchzulesen (auch die anderen)
https://de.wikipedia.org/wiki/Beobachter_(Entwurfsmuster)
https://de.wikipedia.org/wiki/Entwurfsmuster

Les den link zu canjs. Dort steht es genau beschrieben, wie man das auf Basis eines states umsetzen kann.
Wie gesagt vis selbst nutzt diese Bibliothek und man kann natürlich das selbst nutzen. Mach ich in meinen Widgets auch und eigentlich die anderen Widgets ebenfalls.

[OliverIO]

@liv-in-sky

Ich mach mal ein Beispiel für vis

vis.states.attr.bind('datenpunktname mit .val am Ende ', function(ev, newVal, oldVal) {
    console.log(ev + ', ' + newVal + ', ' + oldVal);
});

Allerdings ungetestet. Feinjustierung muss ggfs mit debugging erfolgen
Anstatt dem einzelnen datenpunktnamen kann man auch ein Array mit einer Liste von datenpunktnamen übergeben
Wie die datenpunktnamen genau heißen kann man im debuggen unter vis.states.attr nacgeschaut werden, dann ist das Prinzip klar.
Der datenpunkt muss aber durch vis schon beim Server abonniert sein.
Das erfolgt dadurch das der datenpunkt in einem Widget oder per binding schon irgendwo mal notiert wurde.
Wichtig zu wissen ist, vis edit abonniert einfach alle datenpunkte vis runtime nur die die notiert wurden.

Puh jetzt geht es hier wirklich an die innereien von vis

[liv-in-sky]

@oliverio sagte in Trigger bei Änderungen von Werten:

Ich mach mal ein Beispiel für vis
vis.states.attr.bind('datenpunktname mit .val am Ende ', function(ev, newVal, oldVal) { console.log(ev + ', ' + newVal + ', ' + oldVal); });

was genau soll das machen ? das einzige, was mir klar ist, ist das der dp schon mal "notiert" sein muss - das habe ich in einem html widget gemacht

  vis.states.attr.bind('0_userdata.0.CONTROL-OWN.AAATEST.TestLogic5.val', function(ev, newVal, oldVal) {
    console.log(ev + ', ' + newVal + ', ' + oldVal);
});

sollte dann doch das log ausgeben, wenn sich der dp ändert ? ich habe das ganze noch in einem timeout, damit auch alles geladen ist, bevor das ...bind aufgerufen wird - aber es gibt keinen log-eintrag bei änderung des dp's

[OliverIO]

@liv-in-sky
https://v2.canjs.com/docs/can.Map.html
Siehe Beispiele

Habe gerade gesehen statt vis.states.attr muss es vis.states heißen

[liv-in-sky]

@oliverio

danke dir - eine lösung dafür suche ich schon seit langer zeit - so sollte ein trigger ohne interval möglich sein

  vis.states.bind('0_userdata.0.CONTROL-OWN.AAATEST.TestLogic5.val', function(ev, newVal, oldVal) {
    console.log(ev.type + ', ' + newVal + ', ' + oldVal);
});

[OliverIO]

@liv-in-sky
Nochmal zur Warnung.
Sowas nie in ein HTML Widget reinschreiben insbesondere nicht wenn das Widget sich aktualisiert
ansonsten wird der Code bei jeder Änderung erneut ausgeführt. Dadurch fügst du immer wieder neue Observer hinzu, ohne die alten zu entfernen. Das führt automatisch zu memory Leaks, da du die alten binds nicht mehr entfernen kannst
Beziehungsweise du da extra Aufwand betreiben musst, damit du das kannst.

Den Mechanismus des abonierens,kann man ebenfalls nachempfinden, aber auch hier sind mehrere Schritte notwendig. Den Mechanismus des abonierens,kann man ebenfalls nachempfinden, aber auch hier sind mehrere Schritte notwendig.
das erspart einem, dann das notieren jedes einzelne Datenpunkts In einem Widget.

[liv-in-sky]

@oliverio steht im script tab !

mit einem dp- array bekomme ich es noch nicht hin

[liv-in-sky]

@oliverio

ich meine sowas:

  vis.states.bind(['0_userdata.0.CONTROL-OWN.AAATEST.TestLogic3.val','0_userdata.0.CONTROL-OWN.AAATEST.TestLogic4.val'], function(ev, newVal, oldVal) {
    console.log(ev.type + ', ' + newVal + ', ' + oldVal);
});

[OliverIO]

@liv-in-sky
Sorry
Schlechtes Gedächtnis
Ich hab mit da was selbst gebaut
https://github.com/oweitman/ioBroker.rssfeed/blob/11fc3d443148a58c1739db2797a57befefe7b4a4/widgets/rssfeed/js/rssfeed.js#L820
Also doch kein array

Spoiler

[smartin23]

@oliverio @liv-in-sky
Hallo zusammen, danke für den regen Austausch hier. Das ist echt interessant und kann ich gut gebrauchen. Allerdings muss ich sagen, dass ich bei dem verlinkten GitHub-Beispiel programmiertechnisch an meine Grenzen komme... :-)

Gibt es irgendwo eine gute Übersicht oder verständliche Dokumentation der Funktionen? Oder habt Ihr einen Tipp, wo ich mich gut einlesen und einarbeiten kann, ohne hier dauernd mit Frage um die Ecke zu kommen? Google und die IOBroker-Homepage haben mich bisher nicht weitergebracht.

Funktionen, wie vis.states.bind, servConn.getStates oder servConn.setState habe ich ja nur durch die Suche und Eure Hilfe hier im Forum gefunden. Damit kann ich gut arbeiten. Und wenn ich ins GitHub-Script schaue, gibt es da ja anscheinend noch mehr Möglichkeiten - ich sehe da zum Beispiel auf die Schnelle sowas wie vis.states.unbind oder vis.updateStates oder vis.conn.subscribe.

[OliverIO]

@smartin23
Nein nicht an einer Stelle
Das habe ich mir durch reengineering und Debugging von Vis erarbeitet

Stelle konkrete Fragen dann kann ich evtl antworten

[liv-in-sky]

@smartin23 dito - alles gesammelt - so wie hier mit @OliverIO

ein subscribe für einen dp würde mich auch interessieren - im moment muss ich ja die dp extra mit einem binding einbinden - das müßte doch auch anders gehen :-)

[OliverIO]

@liv-in-sky
Ja ist alles in der Funktion bindstates enthalten.
Bevor ich jede einzelne Zeile beschreibe, schau sie dir an und frag zu konkreten Anteilen, die du nicht verstehst

aber ganz grob
diese Funktion schaut, ob entsprechende Observer für diese Datenpunkte für dieses Widget schon mal gesetzt wurden.
Falls ja, werden die Observer entfernt.
danach werden die States vom Server abgerufen, Dann abonniert, dann die neuen Observer gesetzt und im Widget gemerkt