Wildcard Devices

Einen schönen guten Abend,

gibt es in Node Blue ein Wildcard Device (bzw. Input) um alle durch HG empfangenen Daten oder auch vorgefiltert nach Device Family, direkt zu verarbeiten? Ziel der Übung soll sein, nicht für jedes HM CC RT DN (gut 15 Stück) drei Variablen in Node Blue als einzelnen Block einfügen zu müssen.

Schalt einfach mqtt ein und du hast was du möchtest :wink:
Auch wenn es natürlich ein Umweg ist. @sathya?

1 Like

Per MQTT habe ich das in Node Red schon am Laufen. Es wäre mir nur lieber, wenn ich nicht per Drittprogramm einen Workaround bauen müsste.

Offtopic: funktioniert in NB das persistente Speichern von Variablen genauso wie in NR

Ja, sogar besser, da nodeblue alle Zustände an den nodes selbst persistent speichert.
Schau mal in die Info vom function node für infos zu Context.

Bzgl. mqtt verstehe ich deinen Punkt. Wenn du es aber sowieso schon am laufen hast, ist es ja nur ein kleiner Schritt. Mir ist aktuell keine direkte Möglichkeit über variable-in (o.ä.) bekannt.

Hallo @pino,

Node-BLUE kannst du ebenfalls mit Mosquitto verbinden und so die Ereignisse abgreifen. Intern gibt es aktuell leider (noch) keinen Weg.

Viele Grüße

Sathya

Im nächsten Nightly gibt es einen homegear-event-Knoten.

3 Likes

Das hört sich schon einmal vielversprechend an. Ich werde ausgiebig testen und bis dahin meine Arbeit auf Eis legen :slight_smile:

Ich habe mir den Event-Knoten etwas anders vorgestellt. Wahrscheinlich ist das nur noch viel generischer als ich bräuchte.

Im Grunde bräuchte man nur(*) einen Variable-In-Knoten, dem man mehrere Peers mitgeben kann. Für mich perfekt, wäre eine Regex oder Filter auf den Namen, das mag aber nicht bei jedem so sein. Ich würde nur gerne so etwas vermeiden:

Das sind alles Temperaturen der Thermostate, entweder Wand- oder Heizkörper-. Wenn man diesen Wust jetzt vereinfachen könnte, wäre es toll. Vielleicht einen Knoten pro Gerätetyp. Dann würden ca. 25 Knoten auf 2 Knoten verringert werden.

(*) Ich weiss, das das nur nichts mit dem Entwicklungsaufwand zu tun hat, es ist eine reine Anwendersicht.

In node-red-contrib-loxone hatte ich einen stream-in node programmiert. Damit konnte man alle Ereignisse eines Raums oder ein Kategorie abfangen. Macht es vielleicht sorum Sinn? So nach dem Motto, alles von “Heizung”?

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.
2 Likes

Ich stelle mir das folgendermaßen vor:

Der Knoten, unkonfiguriert, spuckt alle Events als Array aus. Schön wäre natürlich noch eine Möglichkeit den Knoten vorzufiltern nach z.B. DeviceType, DeviceFamily und/oder nach Namen, wobei spätestens hier regex möglich sein sollte.

@job: Deutlich komplizierter würde es ansich nicht werden. Viel mehr als eine umgebene For-Schleife fehlt meines Erachtens nicht.

Das verstehe ich nicht. Wieso eine For-Schleife? Es würde doch immer nur ein Event reinkommen.

Das Problem ist doch die Array-Struktur kennen zu müssen, um zu analysieren, ob das Event relevant ist oder nicht. Wenn ich diesen generischen Knoten auf mein System loslasse, habe ich jede Sekunde 5 Events, die alle im php-Knoten analysiert werden müssen. Das kann einfach nicht so performant sein wie die Analyse in C++/Homegear selbst.

Du wirst lachen. Ich mach etwas ähnliches mit 40 MQTT-Topics. Dauert 15ms pro msg im php-function-node (incl. regex, etc.). Geht also…

40 Topics ist ja nicht viel. Ich habe hier 140 peers mit jeweils 10-20 Kanälen. Wenn jedes Ereignis dann über die php-Node läuft ist das schon eine Hausnummer. Bei einer ordentlichen Organisation der Flows, braucht man diesen Knoten dann auch mehrfach. Das multipliziert sich dann.

Das führt dann zu einer grossen Menge

  • erzeugter aber verworfener Nachrichten
  • verwendeter nutzloser Threads
  • vervielfachter Analyselogik in den php-nodes (oder man hat eine “Ich kann alles analysieren Logik.”)

Meiner Ansicht nach ist eine Vorfilterung im Knoten selbst notwendig, damit es effektiv bleibt:

  • nach Familie
  • nach Gerätenamen (Regex/Filter optimal!, die peerId ist nicht so doll, da man die nicht wirklich unter Kontrolle hat)
  • Gerätetyp
  • nach Datenpunkt (Kanal, Variable)
1 Like

Ja, das wäre in jedem Fall der bessere und elegantere Weg. :+1:

1 Like

Ich fühle mich nur nicht gut dabei den neuen Knoten zu kritisieren. :frowning:

Wenn das jemand darf, dann sind das du und der Patrik :wink: . Konstruktive Kritik sollte doch immer willkommen sein!

1 Like

Ich weiss… ich habe mich nur in @sathya versetzt, er baut mal eben den super generischen Knoten, mit dem man alles machen kann, dann kommt der “Kunde” und sagt: “Nett, so kann ich aber nichts damit anfangen.”
Ich war selbst schon oft in dieser Position. Ist immer ein wenig doof.

3 Likes

Hallo @job,

dann kommt der “Kunde” und sagt: “Nett, so kann ich aber nichts damit anfangen.”

Ich bin ja für alle Vorschläge offen und dankbar. Ich muss die Tage mal schauen, wie einfach oder schwierig das Ganze umsetzbar wäre. Zunächst einmal bekommt der Node-BLUE-Client selbst (und damit die Knoten) nur Ereignisquelle, Peer-ID, Kanal, Variablenname und Wert mitgeteilt.

Viele Grüße

Sathya

Kann mir jemand der php-Experten zeigen, wie man auf das payload aus dem Homegear-Event zugreifen kann? Bei allen Varianten, die ich probiert habe, kommt immer nur null raus, obwohl ich über den Debug-Knoten die gesamte Struktur sehen kann.

Ich hab’s mit oder ohne json_encode versucht, immer alles null. php ist nicht so mein Steckenpferd. :wink:

Das ist wahrscheinlich was ganz simples, aber ich bin php-Laie.

Vielen Dank!