Trigger bei Änderungen von Werten

[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

[smartin23]

@oliverio Okay, super. Danke für das Angebot, dass ich hier weiter fragen darf.

Ich habe direkt eine konkrete Frage: Wie kriege ich die Inhalte aus dem Script-Tab in einen View? Wenn ich das richtig sehe, wird der Script-Tab ja zuerst abgearbeitet, danach erst der View erstellt.

Wenn ich also jetzt im Script-Tab auf ein HTML-Element zugreifen will, um den Inhalt zu verändern, geht es nicht - weil das Skript die ID (noch) nicht kennt.

Konkretes Beispiel:

vis.states.bind('sonos.0.root.192_168_178_96.current_station.val', function(ev, newVal, oldVal) {
    console.log(ev.type + ', ' + newVal + ', ' + oldVal);
    $('#sonostext').html(newVal);
});

Sobald sich der Radiosender ändert, wird ganz korrekt ein Log erzeug mit dem neuen und alten Namen. Das funktioniert.

Aber: Der Sendername wird nicht im Element mit der ID "sonostext" ausgegeben, weil das Skript die ID nicht kennt.

Umgekehrt: Wenn ich in einem HTML-Widget ein Skript mit $('#sonostext').html('Testsender'); ausführe, wird der Text verändert. Aber im Widget soll ich vis.states.bind ja nicht einsetzen, um nicht immer neue Observer zu erzeugen.

Also: Wie kriege ich den in vis.states.bin ermittelten Wert aus dem Script-Tab jetzt sauber in einem HTML-Widget dargestellt, sobald er übergeben wird? Wenn ich ihn nur in eine Variable schreibe, die ich dann wieder im Widget sekündlich abfragen muss, habe ich ja nichts gewonnen.

[OliverIO]

@smartin23 sagte in Trigger bei Änderungen von Werten:

@oliverio Okay, super. Danke für das Angebot, dass ich hier weiter fragen darf.

Also das javascript aus dem Skripttab wird direkt in die Html-Seite mit eingebunden und ist da auch verfügbar,
Da vis die einzelnen widgets erst nach und nach erstellt, kann es schon ein paar Millisekunden bis Sekunden dauern bis das widget mit der ID ansprechbar ist. Es gibt hier im Forum eine Hilfsfunktion, die einem dabei hilft. aber ich habe sie nicht gefunden. Ich glaube @liv-in-sky kenn die,

@smartin23 sagte in Trigger bei Änderungen von Werten:

Also: Wie kriege ich den in vis.states.bin ermittelten Wert aus dem Script-Tab jetzt sauber in einem HTML-Widget dargestellt, sobald er übergeben wird? Wenn ich ihn nur in eine Variable schreibe, die ich dann wieder im Widget sekündlich abfragen muss, habe ich ja nichts gewonnen.

Du solltest dir schon überlegen für welches Szenario du die einzelnen Dinge einsetzt.
Das was du geschrieben hast, macht so nicht soviel Sinn, da das ja vis von alleine macht,
wenn du ein Text-Widget nimmst und dann den Sonos Datenpunkt ID dort einträgst.
Dann wird vollautomatisch der Wert auch im widget eingetragen, ganz ohne Skript-Magie und Verwendung von Funktionen, die nicht so einfach sind.

Ich habe verstanden, das du im client ein paar Berechnungen machen möchtest, die anders nicht gehen oder nicht so einfach sind. Theoretisch kannst du die Berechnungen auch auf dem Server machen (im javacript-Adapter oder auch node-red-Adapter, neue Datenpunkte aktualisieren und dann über die Vielzahl von widgets dir die Daten anzeigen lassen.

[smartin23]

@oliverio Okay, ich mache mich dann auch mal auf dei Suche nach der Hilfsfunktion. Vermutlich so eine Art Verzögerung, bis alle Widgets erstellt wurden, oder?

Mein Beispiel war natürlich sehr stark vereinfacht - um nur den Kern meiner Frage zu verdeutlichen. Tatsächlich ist der Plan so: Wenn sich ein Wert ändert, wird eine Funktion aufgerufen, die mit dem neuen Wert und anderen Werten arbeitet und daraus dann die Visualisierung inklusive den ermittelten Farben, Formen und Inhalten erstellt.