Monatsrückblick Januar/Februar 2026 ist online!

[MartinP]

Kann man auch eine Liste als Trigger-Quelle nutzen?

Bisher habe ich nur die Möglichkeit gefunden, die Datenpunkte einzeln in den Kopf der entsprechenden Variante des Trigger Blocks einzutragen.

[paul53]

@martinp sagte: Kann man auch eine Liste als Trigger-Quelle nutzen?

Ja, eine Liste aus Datenpunkt-IDs.

Diese Version erzeugt intern ebenfalls eine ID-Liste:

Und diese Version erzeugt eine ID-Liste anhand der Selektionskriterien:

[MartinP]

@paul53 Kann man irgendwie auf diese intern erzeugte ID Liste zugreifen?

Das Blockly dient der Alive Überwachung von Geräten nebst eMail versand, und Ich würde im Text der Mail dann einfach den Zustand jedes Gerätes in einer Zeile ausgeben. Da wäre ein Recycling der Liste einfacher, als eine Variable anzulegen....

[Ro75]

@martinp so mache ich es via JS:

var list_gc_temperatur  = ['fritzdect.0.DECT_087610464655.celsius','fritzdect.0.DECT_087610465893.celsius','fritzdect.0.DECT_087610482188.celsius','fritzdect.0.DECT_087610517354.celsius','fritzdect.0.DECT_116300042978.celsius','fritzdect.0.DECT_116300052609.celsius','fritzdect.0.DECT_116300299458.celsius','fritzdect.0.DECT_116300299459.celsius','fritzdect.0.DECT_116300299460.celsius'];

on({id: list_gc_temperatur, change: 'ne'}, function (dp) {
   // hier der Code oder einen Aufruf einer Funktion
});

Ro75.

[paul53]

@ro75 sagte: so mache ich es via JS:

Das entspricht der ersten Version.

@martinp sagte in Ein Trigger auf alle Datenpunkte in einer Liste:

Kann man irgendwie auf diese intern erzeugte ID Liste zugreifen?

Nein. Nimm die Version mit der Variablen.

[MartinP]

@paul53 So, das ist der erste Versuch ... sind noch nicht annähernd alle Geräte ...
Vielleicht wäre "über Bande" mit einer Sammlung von "Alive" Punkten als Aliase zu arbeiten eine bequemere Lösung, als da im Blockly die Liste zu pflegen... bin da noch unsicher

[paul53]

@martinp sagte: Sammlung von "Alive" Punkten

Kann man keinen Selektor verwenden? Wie sieht die ID-Struktur aus?

Anmerkung: Die Variable EmailBody muss vor der Schleife initialisiert werden.

[MartinP]

@paul53 Die meisten Datenpunkte kommen aus dem Ping-Adapter. Die hätten natürlich eine einheitliche Struktur ... man muss sich da ansonsten durch die Objektbäume der Adapter, und die Lesarten, wie man so etwas ausgeben sollte der verschiedenen Entwickler kämpfen...

Inzwischen habe ich zwei zigbee2MQTT Datenpunkte hinzugefügt, aber selbst die sind nicht untereinander "Kompatibel":
beim Lidl-Fluter "...availability={"state" : "online"}",
beim aqara-thermometer "...availability=true (bool)

... und deshalb habe ich mir schon einmal Alias-Datenpunkte für die beiden angelegt ...

Vielleicht wäre es da wirklich das Einfachste, in einem ersten Schritt allen Geräten, die überwacht werden sollen dort unter "alias.0.available" einen Eintrag zu verschaffen, der über read Konvertierungsfunktion dann die Unterschiede glattbügelt, und verlässlich true/false enthält ...

[paul53]

@martinp sagte: allen Geräten, die überwacht werden sollen dort unter "alias.0.available" einen Eintrag zu verschaffen, der über read Konvertierungsfunktion dann die Unterschiede glattbügelt, und verlässlich true/false enthält ...

Gute Idee.

[paul53]

@martinp sagte: Die meisten Datenpunkte kommen aus dem Ping-Adapter.

Man kann auch eine Liste per Selektor erstellen und sie anschließend um weitere IDs erweitern:

[MartinP]

@paul53 Danke, das würde das Blockly wieder um einiges verkürzen.

[MartinP]

So, hier die endgültige Lösung

Initialisierung:

Trigger-Schleife:

Durch die um 3 Sekunden verzögerte Ausführung möchte ich die Anzahl der Mails verringern. Häufig fallen ja die Geräte in "Rudeln" aus, z. B. bei WLAN-Problemen, und dann ist es sicher gut, erst eine Mail zu bekommen, wenn das ganze Rudel die Probleme gemeldet hat ... Vielleicht spiele ich noch mit der Wartezeit. Der Ping-Adapter ist auf 60 Sekunden eingestellt, wahrscheinlich wären da mehr als 70 Sekunden besser, aber dann dauert es noch länger, bis die Mail eintrudelt...