Trigger bei Änderungen von Werten

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

[smartin23]

@oliverio Suuuuper, vielen Dank! Jetzt kann ich die Funktion noch besser nachvollziehen. Gut, dann nehme ich das Speichern der Observer doch wieder rein - ich hatte sie erst mal rausgenommen, um mir erst mal die Kernfunktion zu erarbeiten und zu testen. Ich taste mich ja so langsam ran. Im nächsten Schritt baue ich sie dann wieder ein.

Grundsätzlich ist es erst mal super zu sehen, dass es funktioniert!

[liv-in-sky]

@smartin23 wäre schön, wenn du deine ergebnisse dann posten könntest - wird immer wieder mal alle paar monate nachgefragt und ich würde es gerne in meine "private" bibliothek einfügen

[smartin23]

@liv-in-sky Klar, kann meine Ergebnisse gerne posten! Ich glaube nur, es dauert noch ein bisschen - bin ja eher so Amateuer auf dem Gebiet und muss mich Stück für Stück "durchwurschteln".

Gerade verzweifele ich wieder, weil meine Konstruktion im Desktop-Browser perfekt läuft, auf dem iPad aber nichts dynamisch anzeigt und auf dem FireHD zwar alles korrekt anzeigt, aber dafür hier wieder mal auf keinen Tastendruck reagiert.

Also: Es dauert noch...

[liv-in-sky]

@smartin23

wollte keinen stress machen

ja - das gute alte dilemma mit den verschiedenen browsern - viel spaß damit

[OliverIO]

@smartin23
Da hab ich doch erst vor kurzem was gelesen.
Auf dem Tablet werden manche Events anders interpretiert
https://developer.mozilla.org/en-US/docs/Web/API/Touch_events