Node-RED läuft auf dem Timberwolf Server

[tws88_user]

Weil Node Red jetzt hier salonfähig wird....

ELABNET - ich will Zigbee am TWS per CC2531 Zigbee-USB-Stick nutzen !!! ;o)

Auf der Synology läuft das mit iOBroker.

Auf dem TWS muss dat doch auch! Dann bekomme ich den TWS in die Vollproduktivität.

[Dragonos2000]

Mal ne ganz dumme Frage: Wo liegt der unterschied zwischen Node-Red und bspw. OpenHAB? Ohne mich intensiv in Node-Red vergraben zu haben sieht das für mich wie ein weiteres Projekt aus, um unterschiedliche Technologien via entsprechender Bindings (um diesen mit sehr griffigen Ausdruck zu bemühen) interagieren zu lassen...
Was kann Node-Red mehr/besser als bspw. OpenHAB ?

[tws88_user]

Naja. Verstehe es so, dass NR ein visueller (flowbasierter) Javascript-Editor ist. Skripten/Coden sollte damit theoretisch zum Kinderspiel werden.

Zugegebenermaßen wird ein Umdenken für die Nutzung benötigt, aber die Möglichkeiten sind schon gewaltig. Alles, was IP läuft, kann theoretisch nun verknüpft werden. Die Übersetzung von JS bspw. in MQTT kann mit NR erfolgen. Damit sind tolle Sachsen möglich.

Es existieren massig sogenannter Nodes, die fertige Codepakete für bestimmte Funktionen darstellen, all schon völlig kostenlos auf der NodeRed-Seite.

Mit den Nodes erstellt man dann sog. Flows. Es gibt einen Inputnode (Flowanfang) als Trigger, der eine Inormation in den Flow gibt und
einen Outputnode (Flowende), der wie ein Aktor verstanden werden kann (gibt bspw. passende Info per Telegramm auf den KNX-Bus).

Dazwischen können beliebige Nodes zur Umwandlung der Signalinfo, Weiterverarbeitung usw. "geklemmt" werden.+

OH IoBroker und Co verstehe ich als ähnliche Konstrukte, die meistens mit angepassten Frontends verschiedene, komplexere Arbeitsmodule beinhalten.

Für mich ist es zur Zeit bspw. sehr interessant, iObroker zu nutzen. Hier ist NodeRed als eigene iObroker-Instanz nutzbar mit aber dem Vorteil, dass ich mir direkt Inputs aus iObroker in NodeRed-Nodes holen kann.

Bspw. nutze ich das für Statusabfragen, aber auch KNX-Kommunikation sowie weiteren Adaptern in iOBroker, die dort wesentlich bequemer zu bedienen sind. Prominent bei mir ist HUE, Zigbee, Steuerung meiner Stiebel Eltron WP, meines Sonos-Systems, Türkommunikation, Zigbeesensoren usw. usw.

Da hole ich mir die Kommunikationsobjekte aus iOBroker, dem KNX-Bus sowie dem 1-Wire-Bus und die Timeseries (macht bei mir alles der TWS, der dann zugleich iObroker und Node Red hostet) dann in meine Node-Red-Flows und kann dort alle Welten ideal orchestrieren. Macht richtig Spaß

Unsere Haus-logik mache ich damit auch und einige Dashboard/Visuanwendungen! Die Logik werde ich aber aus Stabilitätsgründen irgendwann sukzessive in den TWS und seine LE überführen.

NR ist sehr schlank, aber ultramächtig. Nodes können jederzeit auch selbst gecodet werden.

NR allein deckt aber meiner Meinung nach durch den flowbasierten Ansatz noch nicht alle Usecases ab, aber ist sehr nahe dran.

Das erst einmal laienhaft von mir.

TANTEEDIT war da.

[Dragonos2000]

Danke, Kai. Hintergrund meiner Frage/meines Interesses ist, dass ich mich nicht in zu vielen solcher Lösungen/Projekte verzetteln möchte. Aktuell habe ich OpenHAB lediglich für die Alexa-Funktionalität implementiert und plane dorthin meine aktuelle SmartVISU zu migrieren. Ich möchte halt nicht zig. Container für alle möglichen Sonderfälle laufen haben und beäuge gerade NR dahingehend, ob es für meinen Bedarf eine noch bessere Alternative als OpenHAB sein könnte...

[tws88_user]

Hi Jochen. Das verstehe ich gut. Siehe meinen Zusatz in der Antwort oben.

Was du befürchtest, ist sicher berechtigt. Ich habe auch ein System aus drei Systemen gerade aufgebaut. Aber nur, weil der dem Menschen innewohnende Hang zur Trägheit leider auch bei mir ausgeprägt ist.

Ich kann kein JS coden, will aber alles ideal und maximalflexibel steuern können - oder noch genauer, maximalflexibel immer und zu jederzeit eine Anwendung für meine Problemlagen und Demands bauen können. Da brauche ich die einfachen Lösungen, aber halt auch die immer stärker zu managende Sensorinfrastruktur, die bei mir über drei Systeme verteilt ist:

KNX
1-Wire
Zigbee

Zu Zigbee hier zu Hause ein Beispiel: Ich fahre tierisch darauf ab, mit einem Aquara-Cube durch Drehen des Würfels die Musiklautstärke meines Sonos-Systems zu verändern. Tappe ich zweimal auf den Würfel, wird die Musik gestoppt, lasse ich ihn zur Seite schnellen, gibt es den nächsten Song usw.

DAS macht ein Chinasensor. DER will aber auch gern an eine Chinacloud funken. DAS wiederum will ich nicht. Und nun?
Universeller Zigbee-Stick mit Adapter in IoBroker, der mir Kommunikationsobjekte bereitstellt (bspw.: "Es hat jemand doppelt auf mich getippt, oder mich nach links gedreht, ich sende für dieses Ereignis eine 1"), die ich in Node Red in einem Flow/Logik verwursten kann (also bspw. gib nun ein TRUE weiter an das Kommunikationsobjekt des SONOS-Adapters für "STOP") und los geht es. Der Stick spricht direkt mit den Sensoren. Das Gateway für die Chinacloud kommt nicht in mein Heimnetz, bzw. ich brauche das Gateway nicht einmal zu kaufen.

Das alles geht mit vielen weiteren Beispielen so.

Der TWS kann hier die hochwertige, leistungsfähige und stabile sowie top-supportete Host-Plattform, die Sensorinfrastruktur, extrem guter Datensammler für meine Sensorik sowie jetzt auch genialer Logikeditor sein. So ein Pi oder Arduino ist schnell an seinen Grenzen.

Wenn zukünftig immer mehr in MQTT übersetzt wird, wird das ganze noch leistungsfähiger und man kann sich vielleicht aufwändige Frontendlösungen der Community sukzessive mehr sparen.

[gbglace]

Genau mein Gedankengang. NR ist wirklich mit den flows, recht einfach zu bedienen. Als Logikeditor hat der TWS aber eben einen auch sehr mächtigen Mechanismus. Wenn der TWS sich dann noch auf Basis MQTT eine recht universelle Objektschnittstelle gönnt, lässt sich in der Kombi enorm viel erschlagen.

Was man als Visu dann am Ende nutzt ist wieder eine andere Frage. Ob nun NR Dashboard oder CV oder TWS-Instant oder EDOMI oder OH usw.
An der Stelle bin ich recht genügsam. Aber einfache Systemintegration finde ich spannend und wichtig. Und es scheint mir auch für Elabnet einfacher, nicht alle Anbindungen selbst kreieren zu müssen.

[Sun1453]

Ich habe heute mal die :rpi Version auf meinen TWS 950 installiert. Beim Aufruf der Oberfläche erhalte ich folgende Meldung:

Verwenden einer nicht unterstützten Version von Node.js

Eine Weitere Frage. Node Red hat keine Anmeldeabfrage. Ist das so gewollt? So kann ja jeder mit der Adresse des TWS dort Änderungen machen.

Danke schon mal für eure Antworten.

[gbglace]

Wer hier noch nichts installiert hat aber es mal ausprobieren möchte.

Es gibt jetzt eine aktualisierte Version von Node-red und damit auch offizielle Docker für Arm-Architekturen.

Versionsstand damit jetzt 1.0 bei Node-red. Passt doch gut zum ersten finalen Stabilen TWS-Release demnächst.

Infos aus der Presse:
https://www.heise.de/newsticker/meldung ... 43442.html

[Sun1453]

Hier gibt es aber soviele ARM Varianten:

https://nodered.org/docs/getting-starte ... variations

Welche ist die passende für den TWS 950?

Danke schonmal.

[gbglace]

Das sollte jeweils der vorletzte in den Blöcken sein.
Laut Katalog haben die TWS 9xx einen 32 bit ARMv7 installiert.
Der oberste ist jeweils ist für die 2000-er TWS.

Ansonsten würde ich dann die minimal Images nehmen, weil es muss ja in dem Docker nichts weiter programmiert werden was dann noch Python als Entwicklungsumgebung bedürfen würde.

Was nun der Unterschied zwischen NodeJS 10 oder NodeJS 12 ist kann ich dir nicht sagen, ausprobieren funktionieren sollte beides.

Bin aber kein Experte, aber aus meiner Sicht macht das so Sinn.