Umstieg von Homematic auf Node-RED

Node-RED als CCU3/RaspberryMatic Addon, WebApp, HomeKit, ...

Moderator: Co-Administratoren

MKaiser96
Beiträge: 44
Registriert: 20.09.2019, 13:42

Umstieg von Homematic auf Node-RED

Beitrag von MKaiser96 » 31.01.2021, 23:10

Hallo,

ich bin gerade dabei, meine Homematic-Programme mittels Node-RED zu programmieren, da ich des öfteren gewisse Programmabläufe nicht direkt nach vollziehen kann. An einem Tag funktionieren sie einwandfrei und am darauffolgenden wieder nicht, obwohl diese seit Monaten reibungslos liefen.

Ich habe hier schon öfter gelesen, dass Node-RED zuverlässiger und auch "logischer" funktioniert. Daher habe ich mich mit der Thematik intensiver beschäftigt.

Nach und nach möchte ich nun meine Programme in Node-RED nachbauen. Grundlegend basieren meine Programme größtenteils auf Variablen, um mit TinyMatic gewisse Funktionen steuern kann. Beispielsweise habe ich eine Beschattungsvariable, die ich in Abhängigkeit der Sonne und der Temperatur sowie einer Steuervariable, mit der ich die Beschattungsautomatik ein und auschalten kann, damit in bestimmten Situationen die Rollläden nicht verfahren (Reinigung der Fenster). Diese Variable triggert weitere Programme an, die die Beschattung für die einzelnen Fensterfronten in Abhängigkeit der Sonnenposition steuert und damit weitere Variablen schaltet (Beschattung Ost, Beschattung Süd,...). Diese Variablen sind Bestandteil meiner Rollladenprogramme.

Nun zur eigentlichen Problematik. Die Variablen werden ja nicht gepusht, sodass ein Programm erst spätestens mit 30 Sekunden Verzögerung startet. Beispielsweise wird im oberen Flow die Beschattungsvariable gesetzt und löst direkt den untern Flow aus. Jedoch werden die Beschattungsvariablen der Himmelsrichtungen erst mit dem nächsten Poll gesetzt und lösen damit meine Rollladenprogramme aus.
Node-RED_Beschattung.png
Ich bin von den Homemati-Programmen gewohnt, dass die Programme live abgearbeitet werden. Wie kann man das in Node-RED erzeugen. Ein manuelles Pollen sehe ich hier kritisch, da ja drei Variablen zeitgleich gesteuert werden sollen und somit drei Pollvorgänge kurz hintereinander ablaufen würden.

Eine Möglichkeit sehe ich evtl. in der Verwendung von Node-RED Variablen, die ich live steuern könnte und damit die Programme ablaufen lasse und parallel dazu die Systemvariablen befülle, damit ich sie beispielsweise mit Historien weiterhin loggen kann.

chrizz-o
Beiträge: 17
Registriert: 11.01.2021, 20:47
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 4 Mal

Re: Umstieg von Homematic auf Node-RED

Beitrag von chrizz-o » 01.02.2021, 09:11

Hallo,

das kannst mit Injection Nodes arbeiten und diese in zeitlichen Intervallen triggern lassen. Wenn du diese vor dein RPC Event setzt, sollten diese anhand des eingestellten zeitlichen Intervalls auch triggern lassen.

Viele Grüße
Christian

MKaiser96
Beiträge: 44
Registriert: 20.09.2019, 13:42

Re: Umstieg von Homematic auf Node-RED

Beitrag von MKaiser96 » 01.02.2021, 15:12

Eine Möglichkeit, die ich boch herausgefunden habe, ist die zeitlich versetzte Befüllung der Variablen. Sprich die Beschattungsvariable wird beispielsweise auf wahr gesetzt und Beschattung Ost mit 1s Verzögerung, Beschattung Süd mit 2s und Beschattung West mit 3s. Dann werden sie scheinbar direkt in die Rega geschrieben. Ohne Verzögerung hat er nur die erste Variable übergeben und erst im nächsten Poll die restlichen Variablen.

Wie klein kann man die Verzögerung wählen, dass die Werte alle live an die Rega übergeben werden? Könnte es hier zu Problemen kommen, wenn zu viele Variablen kurz hintereinander übergeben werden?

Oder ist es ratsam Node-RED Variablen zu nutzen? Wenn ja, wie funktioniert dies? Kann man diese Variablen wie die Homematic Variablen auch als Trigger nutzen?

HenningK
Beiträge: 210
Registriert: 22.09.2012, 20:56
Hat sich bedankt: 5 Mal
Danksagung erhalten: 11 Mal

Re: Umstieg von Homematic auf Node-RED

Beitrag von HenningK » 02.02.2021, 22:03

Vor einem Jahr bin ich auch von HomeMatic Skripten (70 Stück) auf Node-RED umgestiegen. Node-RED ist sehr stabil und extrem flexibel.

Die Verbindung von Homematic Systemvariablen und Node-RED ist allerdings nicht die beste. Da treffen zwei unterschiedliche Dinge aufeinander.

Erst hatte ich auch eine Mischung aus Homematic Systemvariablen und Node-RED flows. Es ist zu umständlich beide in Sync zu halten.
Ich habe alle Systemvariablen (bis auf Duty cycle) durch flows plus Node-RED variablen ersetzt.

Node-RED variablen sind einfache Speicher - es gibt keine Trigger. Du musst dir Trigger im Flow mit variable bauen.

MKaiser96
Beiträge: 44
Registriert: 20.09.2019, 13:42

Re: Umstieg von Homematic auf Node-RED

Beitrag von MKaiser96 » 02.02.2021, 22:40

Also bisher funktioniert Node-RED einwandfrei. Es gibt zwar einige Programme, die nicht auf anhieb laufen wie sie sollen, aber das liegt immer an Kleinigkeiten die beim Copy & Paste übersehen wurden. Beispielsweise ist ein true statt ein false gesetzt.

Für das erste möchte ich an meinen Homematic-Systemvariablen festhalten, bis ich alle Programme portiert habe und sie zuverlässig laufen. Aber nichtsdestotrotz würde ich mir mal die Node-RED Variablen mal genauer anschauen. Hast du vielleicht nützliche Infos oder Links, die mir dabei weiterhelfen. Ich habe davon bisher keine Ahnung.

Ich schätze aber, dass ich weiterhin meine Homematic-Systemvariablen weiterpflegen werde, da ich sie schön im CCU-Historian loggen und die aufgezeichneten Daten schnell abrufen kann.

vore
Beiträge: 163
Registriert: 28.11.2011, 20:31
System: CCU und Access Point
Hat sich bedankt: 4 Mal
Danksagung erhalten: 4 Mal

Re: Umstieg von Homematic auf Node-RED

Beitrag von vore » 05.02.2021, 16:43

Hallo Zusammen!
Ich bin noch teilweise bei Homematic Systemvariablen weil ich leider einige Programme nicht umstellen kann (mein Eintrag bei Github zu dem problematischen Gerät in Redmatic ist leider noch unbearbeitet). Daher die Frage: wie macht ihr dass, wenn ihr für einen Flow den Zustand von 3-4 Variablen als Bedingung abfragen wollt? Ich habe aktuell dann 4x eine CCU-Switch Node hintereinander geschaltet.. funktioniert aber nicht so schön.

Grüße
Vore
System: Asus TinkerS mit RaspberryMatic und Cubietruck mit IOBroker

HenningK
Beiträge: 210
Registriert: 22.09.2012, 20:56
Hat sich bedankt: 5 Mal
Danksagung erhalten: 11 Mal

Re: Umstieg von Homematic auf Node-RED

Beitrag von HenningK » 06.02.2021, 14:40

funktioniert aber nicht so schön
Kannst du das konkreter beschreiben?

Als zusätzliche Optionen kannst du

a) für jeden Check einen http request senden - hier als Beispiel für die Variable dutcycle, meine ccu is auf ...25

Code: Alles auswählen

http://192.168.178.25:8181/Test.exe?rsp=dom.GetObject(%22dutycycle%22).Variable()
b) aus den 3 -4 Request oben einen einzige machen - ist aber etwas tricky

c) an Homematic ein script mit allen Operationen senden und das Ergebnis dann weiter nutzen.

MKaiser96
Beiträge: 44
Registriert: 20.09.2019, 13:42

Re: Umstieg von Homematic auf Node-RED

Beitrag von MKaiser96 » 21.09.2021, 20:37

Hallo zusammen,

ich habe schon seit einiger Zeit meine Homematic Programmierung in Node-Red laufen. Ich arbeite relativ viel mit Homematic Variablen. Problematisch ist hier nur die Tatsache, dass nur alle 30 Sekunden gepollt wird und damit Programme/Flows, die Homematic Variablen als Trigger nutzen, verzögert ausgeführt werden.

Welche sinnvolle Möglichkeit gibt es Node-Red Variablen zu nutzen bzw. diese auch als Trigger zu nutzen? Sinnvoll wäre hier eine Möglichkeit auf geänderte Werte reagieren zu können.

Hypnos
Beiträge: 460
Registriert: 06.01.2018, 12:48
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 57 Mal
Danksagung erhalten: 39 Mal

Re: Umstieg von Homematic auf Node-RED

Beitrag von Hypnos » 21.09.2021, 21:37

Hallo,

Node-Red/RedMatic hat hier ein anderes Konzept. Es gibt zwar sowas wie Variablen (flow/globaler context), diese triggern aber nix, sondern sind nur für das speichern von zuständen. Diese Contexte nutzt man, wenn man sich beispielsweise einen Staus merken will. Beispielsweise bei Tastendruck (=trigger), ob eine Lampe an oder aus war um sie auf das Gegenteil zu schalten.

Zum Triggern sind die Nachrichten da. -- Irgendwas löst eine Nachricht aus, und das ist der Trigger, den man dann an alle Stellen, welche "getriggert" werden sollen weitergeleitet wird.

Wenn du bisher
Du schreibst an Punkt A was in eine Variable und willst das an einem punkt B und C bei Änderung der variable etwas auslöst.

kannst du das in Node-Red/RedMatic wie folgt lösen
Anstelle das in eine Variable zu speichern, schickst du das auf eine link-Out-node und an den Stellen wo du darauf reagieren willst machst du eine Link-In Node und verbindest diese link Nodes.

Jetzt möchtest du vielleicht nicht bei jedem Trigger/Aktualisierung was auslösen/weiterleiten, sondern nur bei einer Änderung eines Wertes. Dazu gibt es die RBE Node (Ab Node-Red 2x heißt diese Filter). Diese leitet eine Nachricht nur bei Änderung einer Eigenschaft der Nachricht weiter.

Alternative:
Du setzt dir einen MQT Broker auf (Es gibt für die CCU mehrere AddOns [Mosquitto, CCu Jack, ...], die das können).
Anstelle von von Variablen schickst du das als Nachricht an den Broker mit einer Topic (= sowas wie der Variablenname) über die MQTT Out Nachricht und die Stellen wo du darauf triggern willst, hast du eine MQTT-In Node für den Topic.

Bei MQTT kannst du Nachrichten auch persistieren. Das bedeutet, wenn man eine Nachricht an den Broker mit Retain =true sendet, merkt sich der Broker diese (den letzten Wert zu einer Topic). Wenn man sich dann neu mit dem Broker verbindet (z.b. bei einem Neustart/etc...), sendet dieser dann den letzten Wert wieder aus.

Übrigens, die 30 Sekunden Pollzeit für die Abfrage der Homematic Variablen kann man in den Einstellungen auch ändern.

Gruß

MKaiser96
Beiträge: 44
Registriert: 20.09.2019, 13:42

Re: Umstieg von Homematic auf Node-RED

Beitrag von MKaiser96 » 25.09.2021, 17:41

Hallo,

vielen Dank für deine Ausführungen.

Die Idee mit dem Link-In und Link-Out hatte ich auch schon. Aber wenn ich auf eine Variable in mehreren Flows als Trigger reagieren möchte, wird dies sicher schnell unübersichtlich. Daher habe ich diese Ausführung erstmal nicht weiter verfolgt.

MQTT ist sicher eine nette Sache, aber ich möchte meinen RaspberryPi, auf dem Raspberrymatic und Redmatic läuft, nicht mit noch einer Software beschäftigen. Daher möchte ich mit den Bordmitteln von Node-RED arbeiten.

Ich habe aber an einem eigenen Subflow gearbeitet. Ich triggere in einem bestimmten Intervall meine Variable aus dem globalen Kontext. Zusätzlich habe ich dahiner einen RBE Node geschaltet, sodass nur Änderungen durchgelassen werden. Das ganze sieht dann so aus.

Subflow.png
Subflow
Subflow.png (8.77 KiB) 1439 mal betrachtet
Subflow_Einstellungen.png
Subflow Einstellungen
Subflow_Einstellungen.png (13.27 KiB) 1439 mal betrachtet
Flow.png
Flow
Flow.png (5.33 KiB) 1439 mal betrachtet
Nun weiß ich allerdings nicht, in welchem Intervall ich meine Variablen abfragen soll. Ideal wäre natürlich sekündlich. Weiß jemand, ob dies ratsam ist oder ob das System dabei schnell ausgelastet ist?

Den Flow habe ich hier für euch exportiert.

Code: Alles auswählen

[
    {
        "id": "23d9bf02.7165b",
        "type": "subflow",
        "name": "glob. Variable",
        "info": "",
        "category": "",
        "in": [],
        "out": [
            {
                "x": 440,
                "y": 60,
                "wires": [
                    {
                        "id": "6f94dcb8.1c1ca4",
                        "port": 0
                    }
                ]
            }
        ],
        "env": [
            {
                "name": "Variable",
                "type": "str",
                "value": ""
            },
            {
                "name": "Intervall",
                "type": "num",
                "value": "5"
            }
        ],
        "color": "#3FADB5",
        "icon": "node-red/inject.svg",
        "status": {
            "x": 440,
            "y": 120,
            "wires": [
                {
                    "id": "6f94dcb8.1c1ca4",
                    "port": 0
                }
            ]
        }
    },
    {
        "id": "c827a0df.65bac",
        "type": "inject",
        "z": "23d9bf02.7165b",
        "name": "",
        "props": [
            {
                "p": "payload"
            }
        ],
        "repeat": "${Intervall}",
        "crontab": "",
        "once": false,
        "onceDelay": 0.1,
        "topic": "",
        "payload": "${Variable}",
        "payloadType": "global",
        "x": 150,
        "y": 60,
        "wires": [
            [
                "6f94dcb8.1c1ca4"
            ]
        ]
    },
    {
        "id": "6f94dcb8.1c1ca4",
        "type": "rbe",
        "z": "23d9bf02.7165b",
        "name": "",
        "func": "rbe",
        "gap": "",
        "start": "",
        "inout": "out",
        "septopics": true,
        "property": "payload",
        "x": 330,
        "y": 60,
        "wires": [
            []
        ]
    },
    {
        "id": "b623f861.68c848",
        "type": "subflow:23d9bf02.7165b",
        "z": "d1784ed1.fab9b",
        "name": "00Test",
        "env": [
            {
                "name": "Variable",
                "value": "00Test",
                "type": "str"
            },
            {
                "name": "Datenpunkt",
                "value": "00Test",
                "type": "str"
            },
            {
                "name": "Name",
                "value": "00Test",
                "type": "str"
            }
        ],
        "x": 230,
        "y": 900,
        "wires": [
            [
                "2b03e82f.e83b98"
            ]
        ]
    },
    {
        "id": "2b03e82f.e83b98",
        "type": "debug",
        "z": "d1784ed1.fab9b",
        "name": "",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 390,
        "y": 900,
        "wires": []
    }
]

Antworten

Zurück zu „RedMatic“