UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[paul53]

@hsteinme sagte:

Mein Skript möchte Änderungen in diesem Teilbaum mitbekommen,

Da sehe ich momentan keine Chance.

[liv-in-sky]

@hsteinme sagte in Subscribe auf ganze Datenpunkt-Zweige:

Nachtrag: Ich hänge in dieser Fragestellung nicht am on-Statement. Paul53's Hinweis, was denn bei einem gelöschten Teilchen überhaupt gemeldet werden soll, habe ich schon verstanden. Mir würde auch schon eine Notification reichen, dass sich die Anzahl der Elemente im Zweig geändert hat. Hat jemand eine Idee dazu?

du könntest dir ein script machen, das diesen ordner scannt und alle id's in ein array speichern - dann frägst du jede z.b minute ab, ob diese array noch dem entspricht, das du gerade abfrägst - dann weißt du, dass es eine änderung
gegeben hat - du kannst sogar rausfinden an welcher stelle es sich geändert hat - ist nicht so schnell wie ein on{}, aber falls die zeit nicht unbedingt ein kriterium ist - letztlich kannst du auch auf das array triggern mit on{}

wenn du viele datenpunkte darin hast und öfter in der minute diese abfragen machst, wird dein load ziemlich hoch werden

[paul53]

@liv-in-sky sagte:

ein script machen, das diesen ordner scannt und alle id's in ein array speichern

Hast Du berücksichtigt, dass der Javascript-Adapter alle Objekte und Zustände puffert ?

[liv-in-sky]

@paul53 hab ich wohl nicht, wenn du so fragst

ich habe das getestet und es funktionierte

habe einfach von hand während der minute einen datenpunkt oder auch einen unterordner mit datenpunkten angelegt - das script hat sie gezeigt - der counter springt auf die richtige anzahl

 schedule('* * * *  *',  function () {
 var counter=0;
  $('0_userdata.0.Tabellen.*').each(function(id, i) {         
    counter++
  
log(id)

     
  }); 
  log(counter.toString())

   
   });    

selbst mit einem 10 sekunden schedule hat es richtig angezeigt

[paul53]

@liv-in-sky sagte:

selbst mit einem 10 sekunden schedule hat es richtig angezeigt

Um so besser, wenn es so funktioniert. Mit Subscriptions auf neue, per Hand angelegte Datenpunkte habe ich schon negative Erfahrungen gemacht.

[liv-in-sky]

@paul53 da ich weiß, das du bedeutend mehr erfahrung hast als ich:

gehst du davon aus, dass es situationen gibt, in dem das nicht funktioniert und ich nur eine art "glück" hatte - oder ich irgendwas eingestellt habe, dass ich vergessen habe ?

[liv-in-sky]

@paul53 ok - überschneidung

[hsteinme]

@liv-in-sky sagte in Subscribe auf ganze Datenpunkt-Zweige:

du könntest dir ein script machen, das diesen ordner scannt und alle id's in ein array speichern - dann frägst du jede z.b minute ab, ob diese array noch dem entspricht, das du gerade abfrägst - dann weißt du, dass es eine änderung
gegeben hat

Ja, diesen Notnagel habe ich schon fertig da liegen, weil ich ihn eh an anderer Stelle benötige. Aber das ist kein Ansatz, der mir Freude bereitet. Im besagten Objektbaum gibt es im Abstand von Tagen gelegentliche Änderungen, auf die ich dann zeitnah reagieren möchte. Dann ist das in kurzen Abständen durchzuführende "Durchwandern" des Baumes wirklich nur eine verschwenderische Notlösung.

Danke für Deine Anregung.

[hsteinme]

@paul53 sagte in Subscribe auf ganze Datenpunkt-Zweige:

Hast Du berücksichtigt, dass der Javascript-Adapter alle Objekte und Zustände puffert ?

Ooooh! Gibt es dazu irgendwo verlässliche nachlesbare Informationen? Diese Aussage stellt ja schließlich elementare Teile des ioBroker-Konzepts in Frage. Von daher fehlt mir hier ein wenig der Glaube.

Jeder, der einen Cache einführt, muss doch auch Mechanismen parat haben, die eine Inkonsistenz zwischen dem Cache und seinem repräsentierten Hintergrundmedium vermeiden.

[hsteinme]

@liv-in-sky sagte in Subscribe auf ganze Datenpunkt-Zweige:

du könntest dir ein script machen, das diesen ordner scannt und alle id's in ein array speichern [...] letztlich kannst du auch auf das array triggern mit on{}

Nein, damit komme ich nicht weiter, da ich in die gleiche Situation hineinlaufe wie mit meinem on-Beispiel aus meinem ersten Beitrag: Änderungen an den Datenpunkten werden Dir mitgeteilt, Löschungen von Datenpunkten jedoch nicht.

Ein Beispiel:

var MyDPs = ['javascript.0.Test1', 'javascript.0.Test1.Test11'];
on({id: MyDPs, change: 'any'}, function(DP) {
    console.log('Änderung in ' + MyDPs[MyDPs.indexOf(DP.id)]);
});

Änderst Du den Wert von Test11, so macht on fein säuberlich einen Vermerk im Log. Löschst Du jedoch Test11, so schweigt on Dich an.

Hier gilt auch wieder die Anmerkung von paul 53: Wenn Test11 gelöscht ist, wie soll on bzw. function damit noch arbeiten können?

[ticaki]

Hallo,

folgender Code erzeugt auf RB4 mit redis <1% load mit ca. 40-50 States:

var arrayofstates = $('state[state.id=javascript.0.*]');
setState("javascript.0.Test1",JSON.stringify(arrayofstates));

schedule("*/1 * * * * *", function() { // jede Sekunde
  arrayofstates = $('state[state.id=javascript.0.*]');
  setState("javascript.0.Test1",JSON.stringify(arrayofstates));
})

on({id:"javascript.0.Test1", change:"ne"},function(obj) {
    console.log("test 123 kann mich wer hören");
})

[hsteinme]

@ticaki sagte in Subscribe auf ganze Datenpunkt-Zweige:

  arrayofstates = $('state[state.id=javascript.0.*]');
  setState("javascript.0.Test1",JSON.stringify(arrayofstates));

Ein "schöner" :blush: Code, danke! Vor allem ein für mich brauchbarer Ansatz, insbesondere weil durch die Stringifizierung es ermöglicht wird, auch Löschungen innerhalb der Struktur als Änderung zu erfahren. Ganz herzlichen Dank!

Durch geeignete Wildcard-Wahl im $-Selektor kann ich darüber hinaus sogar erreichen, dass nur für mich relevante Teile des Objektbaums betrachtet werden.