Wahrscheinlich ist es so implementiert, allerdings ohne Filterung.
Jeder Event wird als Array weitergereicht. Nur, wenn ich in dem Flow dann das ganze Array über z.B. php analysieren muss, hilft es mir nicht, weil das auch sehr aufwändig ist. Dadurch habe ich gegenüber den ausmultiplizierten Knoten nicht viel gewonnen, die sind zwar lästig, aber ohne viel Logik zu bearbeiten.
Wie gesagt, mir würde es schon reichen, wenn ich nicht für jede Instanz, sondern nur für jeden Gerätetyp einen Knoten bräuchte. Die Anwendungen für generische Events sind eher begrenzt, eigentlich nur für Bridges interessant, also wenn ich alle Ereignisse in einem weiteren System abbilden möchte.
Es macht meiner Ansicht nach wenig Sinn, in den gleichen Flow die Ventilposition und die Temperatur reinzureichen. Die Verarbeitung muss das ja dann sowieso unterscheiden. Dann würde ich eher unterschiedliche Flows machen.
Allerdings, die Ventilpositionen von allen Thermostaten macht schon Sinn, da man im Event dann über peerId/peerName Name weiterverarbeiten kann.
Mein obiger Flow errechnet übrigens, zu jeder Temperatur die reinkommt, die Differenz zur SET_TEMPERATURE und schreibt diese in eine Variable. Dadurch habe ich eine Übersicht, ob die Temperaturregelung im Groben Funktioniert. Über die Peer-Id ermittle ich die SET_TEMPERATURE, die Ziel-Variable ermittle ich über den Peer-Namen.
Sieht alles überschaubar aus, müsste ich jetzt hier erst ein Array analysieren, würde das viel komplizierter aussehen:
$p=$message['peerId'];
$c=$message['channel'];
$act = $hg->getValue($p, $c, "ACTUAL_TEMPERATURE");
$set = $hg->getValue($p, $c, "SET_TEMPERATURE");
$v= $message['peerName'] . "_DIFFTEMP";
$hg->setSystemVariable($v, $act-$set);
return $message;
Mich persönlich würde bei einer solchen generischen Node nur 1 Kanal einer Menge von Geräten interessieren.
Z.B.:
- LOWBAT von allen Homematic-Geräten.
- TEMPERATUREN von allen Thermostaten
- BRIGHTNESS oder STATE von allen Lampen
- MOTION von allen Bewegungsmeldern
- etc.