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

[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.

[liv-in-sky]

@smartin23

https://forum.iobroker.net/topic/48663/howto-skripte-im-vis-editor-mit-jquery

[smartin23]

@liv-in-sky Super, danke! Das funktioniert!

@OliverIO Jetzt habe ich aber doch noch mal etwas konkretre Fragen zu Deinem Skript.

Ich habe das Abrufen der Werte ja hiermit probiert:

vis.states.bind('sonos.0.root.192_168_178_21.state_simple.val', function(ev, newVal, oldVal) {
    console.log(ev.type + ', ' + newVal + ', ' + oldVal);
});

Das geht im Prinzip auch - aber nur, wenn gleichzeitig auch ein Widget (zum Beispiel ein Basic-String-Widget) im Vis eingebaut ist, was diesen Wert darstellt. Ansonsten wird nichts ausgegeben, wenn sich der State_Simple ändert.

Ich vermute also, dass man diesen Datenpunkt erst abonnieren muss, damit er zuverlässig Daten liefert.

Daher habe ich nun Dein GitHub-Script herangezogen und für mich zusammengekürzt:

// Array mit zwei Geräten zum Testen
bound = ["sonos.0.root.192_168_178_22.state_simple",
"sonos.0.root.192_168_178_21.state_simple"];

// Ausgabe-Funktion der geänderten Werte
function onChange(e, newVal, oldVal) {
    console.log(e.type, newVal, oldVal);
}

function binStates (bound, change_callback) {

        // vis.conn.gettingStates = 0; // hier weiß nicht, wofür das ist

        vis.conn.getStates(bound, function (error, states) {
            vis.conn.subscribe(bound); // hier wird der Datenpunkt abonniert, richtig?

            for (var i=0;i<bound.length;i++) {
                bound[i]=bound[i]+'.val';
                vis.states.bind(bound[i], change_callback); // hier erfolgt dann das Binding, oder?
            }
            console.log("states", states);
            // vis.updateStates(states); // wofür ist das da?
        });
        // }.bind({change_callback})); // hier weiß ich auch nicht, was das noch bewirkt
}

binStates (bound, onChange);

Wie Du siehst, waren mir ein paar Befehlszeilen unklar - vor allem, weil sich die Ausgaben nicht ändern, wenn ich sie auskommentiere. Kann ich die getrost weglassen oder was bewirken diese?

Und: Auch bei diesem Script kommt die Meldung "Trying to get states again, because emitted getStates still pending" beim Abrufen der States. Muss mir das Sorgen machen?

[OliverIO]

@smartin23
Du hast recht, das bind funktioniert nur wenn die datenpunkte schon abonniert wurden.
Um es nicht zu kompliziert zu machen war mein Vorschlag die datenpunkte per binding in ein unsichtbares html Widget rein zu schreiben.
Aber per Code geht es natürlich auch, wenn man aufpasst.

Zum Skript
Zeile 12
Das trickst den original Code etwas aus. Der hat nämlich eine Begrenzung eingebaut, die bei mir gelegentlich die Abfragen abgewürgt haben. Ich setze einfach den Zähler auf 0 und alles ist gut. Habe bisher keine negativen Effekte bemerkt. Die Bremse wirkt sich eigentlich nur auf sehr langsame Geräte aus. Leider gibt es da keine Alternative fehlerbehandlung. Also am besten wieder reinnehmen

Zeile 15. Ja, is nimmt den datenpunkt dann in seine eigenen variablen auf, damit wenn Änderungen vom Server kommen die richtig abgespeichert werden können.

Zeile 19
Der Bund Befehl meldet den observer an, der dann bei Änderung aufgerufen wird (die callback Funktion hier change_callback)

Zeile 22
Das ist auch eine vis interne Funktion. Da es schon eine Weile her ist kenne ich die super Details nicht. Aber ich denke es ist notwendig sonst funktioniert der Mechanismus nicht. Du kannst es ja mal weglassen und schauen

Zeile 24
Da vis.conn.getStates eine asynchrone Funktion ist, ist der scope des funktionaufrufs (also im spezielle die Variable change_ callback nicht vorhanden. Mit diesem bind (Achtung es ist hier ein anderes bind wie oben, dieses bind gehört zum Objekt Funktion) kann man variablen an den scope der Funktion binden, so das sie auch innerhalb verfügbar sind.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Function/bind?retiredLocale=de

Das bind aus Zeile 19 gehört zum Map Objekt der Bibliothek canjs

Die Meldung kann ich jetzt nicht zuordnen. Müsst ich in vis nachschauen. Bin aber da gerade etwas ausgelastet. In vis reinschauen oder debuggen ist leider etwas zeitaufwändig.

Du hast jetzt den ganzen Teil weggelassen, wo sich die Funktion merkt welche observer angemeldet worden sind.
Wie oben schon erwähnt, kannst du dann diese nicht wieder abmelden. D.h. Sie bleiben im Speicher bis die Seite komplett neu geladen wird.
Wenn das nur einmal passier oder nur selten ist das kein Problem. Wenn aber aus irgendeinem Grund das Skript oft ausgeführt wird, sammelt sich Datenmüll im Browser und wird ihn ggfs zum Absturz bringen (zumindest den einen Reiter)