Entwicklung node-red-contrib-loxone für node-red

**svethi** · 04.03.2017, 09:48

Das hört sich ja alles toll an, doch wie es immer so schön ist, um so flexibler es wird, desto aufwendiger und unüberschaubarer wird die Umsetzung. Hier im Forum sind auch viele Leute, die von Programmierung keine Ahnung haben. Leute, die Linux und Raspberry etc. nur mal irgendwo gehört haben. Das Loxberry Projekt wurde in Leben gerufen um genau solchen Leuten Zugang zu Funktionen zu ermöglichen, die nicht auf "normalem" Weg erreichbar sind. Viele davon schaffen es dann mit der Anleitung gerade einmal die SD zu schreiben und den Loxberry zu booten. Ab dann können sie einfach über eine GUI Ihre Daten eingeben und es läuft im besten Fall alles. Dabei musste sich die Leute nicht um Eingänge, Ausgänge und Logiken kümmern. Klar, damit ist es sehr eingeengt und kann nur das, doch genau das war hier das Ziel des Loxberry. Mit Node-Red oder IOBroker oder was es da sicher sonst noch wo gibt, hat man hohe Flexibilität doch dafür kennt das "System" keinen Baustein in der Loxone und deren Zusammenhänge. Alles muss sich hier selbst "hart" erarbeitet werden. Ein Programmierer, der in einem dieser "System" "zu Hause" ist und gerne damit arbeiten möchte, warum nicht. Auch ist sicher eine Implementierung in den Loxberry möglich, doch wenn es Erfolg haben soll, dann dürfte es auch keine weiter Benutzeroberfläche geben. Auswahl von Bausteinen etc. müsste im Loxberry stattfinden. Auch das ist sicher möglich, macht aber den Weg bis hin zum Plugin noch viel aufwendiger, wenn ich das richtig verstehe. Mit den Plugins, die es jetzt schon gibt, die in sich geschlossen sind und nur für diesen Zweck so einfach wie möglich umgesetzt wurden, gibt es schon ständig Supportanfragen weil die Anleitung nicht gelesen und befolgt wird, weil nicht im Forum gelesen wird, etc. ich sehe das als schwierig umsetzbar an.
Wie schon gesagt, es ist alles toll und wenn man sich damit auskennt und tagtäglich damit arbeitet auch einfach umzusetzen. Warum also nicht verwenden. Gerne. Wir diskutieren im dev.loxberry gerade die ganze Zeit, wie bei den Einstieg in die Pluginprogrammierung vereinfachen könnte. Dieser Weg ist sicher toll, macht aber nach meiner Meinung noch mehr Verwirrung.

Eine Frage und Bedenken habe ich dann aber auch noch. pmayer Du verwendest die Websocketverbindung ... Diese ist dann auch permanent geöffnet? Hat das schon einmal einer gemacht? Ich kann mir gut vorstellen, dass die Websocketverbindung auch mal zusammen bricht. Auch stellt sich die Frage wie viele Verbindungen Loxone da zulässt. Hier ist man ja auch limitiert.
Du hast auch die Modbusthematik angesprochen. Wenn Du da nun so ein hochflexibles System anbietest, mit dem Du den MiniServer quasi Zweckentfremdest, könnte ich mit vorstellen, dass Loxone das auch zu unterbinden versucht.

Gruß Sven

**pmayer** · 04.03.2017, 12:40

Hi.

Holger_kausch genau das ist mein Anliegen ;-)
Mit dem node für node-red hast du geanau die Möglichkeit von der du sprichst, da io.broker node-red intregriert: http://www.iobroker.net/?page_id=4284&lang=de
Im schlimmsten Fall muss man in node-red programmieren aber die meisten Dinge kann man einfach so zusammen "stecken". Hier erklärt einer der Entwickler von node-red das Ganze mal in 5 Minuten: https://www.youtube.com/watch?v=vYreeoCoQPI

svethi Vielen Dank für deine ausführliche Rückmeldung. Insgesamt sehe ich das ähnlich wie du. Node-red ist sicher kein Werkzeug für Leute die gerade so eine SD-Karte bespielt bekommen. Allerdings lese ich immer wieder, dass jemand sich ein eigenes Script schreibt was dann über einen Virtuellen-Ein-/Ausgang an den miniserver irgend etwas meldet.
Und wenn jemand mit Loxone-Config zurecht kommt sehe ich für node-red gute Chancen... ;-)

Aktuell ist es so, dass ich per Drop-Down im Editor die Geräte, die aus der Loxone-Strukturdatei gelesen werden, auswähle und dann mit Daten aus node-red beschicke oder lese. Sieht man in dem Bilder hier https://www.loxforum.com/forum/faqs-...6396#post86396 bzw in der Beschreibung auf github. Könnte sogar ein Video machen, wie das mit dem "wiring" geht.

Ich nutze die gleiche Websocket Bibliothek die auch von von der homebridge-loxone (https://github.com/Sroose/homebridge-loxone-ws bzw. http://www.loxwiki.eu/display/LOX/homebridge-loxone) verwendet wird. Diese lib (https://github.com/alladdin/node-lox-ws-api) sendet ein keepalive an den Websocket. Anhand der Zeit die der Miniserver zurück gibt kann man darüber sogar eine Aussage über die Qualität der Verbindung treffen. Siehe https://www.loxone.com/dede/wp-conte...ver.pdf?x48792, lezte Seite "Handling an active connection".
Es wird nur eine Verbindung pro Miniserver genutzt, in der man sich authentifiziert und worüber die komplette Kommunikation abgewickelt wird - einer der Vorteile eines geöffneten Websockets ;-) Zuerst hatte ich die Websocket-Verbindung selbst implementiert mich aber dann doch für die bereits fertige library entschieden.
Ich bin der Meinung, dass ein Miniserver nicht über das Internet (wenn dann nur über VPN) erreichbar sein sollte. Im lokalen Netz sollte es keine Verbindungsprobleme geben.

Das Modbus Beispiel war nur eines von vielen. Ich schalte hier zu Hause zum Beispiel gerade mit Loxone Tastereingängen (Switch-Modul) Hue-Lampen an und aus.
Auch kann ich dadurch die Loxone endlich in mqtt holen und Beispielsweise darüber komplett mit meinen homematic/Max!-Geräte über homegear (gibt noch andere Wege, https://www.homegear.eu/index.php/Main_Page) kommunizieren. Die optischen homematic Funk-Fenstersensoren, zum Beispiel, sind für Nachrüster auf jeden Fall interessant, wobei man natürlich diskutieren kann ob sicherheitsrelevante Geräte überhaupt per Funk angebunden werden sollten oder nicht.

Ich möchte den Miniserver nicht zweckentfremden... nur den Leuten eine Möglichkeit geben von node-red aus mit ihm zu sprechen. Wenn ich das hinbekomme sind der Phantasie keine Grenzen gesetzt.

Vielen Dank für Eure Antworten. Gerne mehr, ich werde versuchen alle zu beantworten.

Ich würde mich unheimlich freuen, wenn sich Leute zum Testen, für strukturelles Input oder vielleicht zum Mitentwickeln finden würden.

Danke,
Patrik

**Christian Fenzl** · 04.03.2017, 13:27

Ich finde das Thema sehr spannend.
Beim MS wird es für die Allgemeinheit, so finde ich, erst interessant, wenn einem Arbeit durch Function-Nodes, so wie in Loxone Funktionsbausteinen, abgenommen wird.

Dafür waren wir bereit, für Loxone zu bezahlen, weil es Funktionsgruppen fertig gibt. Sonst hätten hier alle FHEM und jeder programmiert sich die Funktionen selbst zusammen.

Wenn ich an Integration des Miniservers denke, dann denke ich an Aufbereitung des Loxone-XMLs (wie ich das im Stats4Lox-Import schon mache), an ein UI zur Verbindung von dezidierten MS-Bausteinen an andere Hard-/Software, z.B. auch an eine einheitliche Schnittstelle, um Meldungen vom MS in einheitlichem Format an Kommunikationsgeräte zu übergeben (Stichwort TTx - Text-To-x, also Sprache, Anzeigen, an unterschiedliches Equipment wie TV, Kodi, LMS, Sonos, E-Mail, Push-Notification).

Die Kommunikation mit dem MS stellt nicht die große Herausforderung dar, aber das, was herauskommt, möglichst generisch und trotzdem einheitlich weiterzuverarbeiten, und der Benutzer soll dafür fünf Mausklicks brauchen :-)

Das versucht derzeit LoxBerry, wenn auch noch sehr spezialisiert, und noch ganz ohne Schnittstelle ZWISCHEN den Plugins. Es ist noch so wie die 30 Apps am Handy, die untereinander nicht kommunizieren (können).

**pmayer** · 04.03.2017, 13:42

Hi Christian,

auch da bin ich bei dir. Die Automatismen, die Loxone in den Bausteinen nachzubauen wäre sehr sehr anspruchsvoll und genau die sind es ja die Loxone stark machen. Mit der Anbindung an node-red erhällt man, genau wie bei LoxBerry eben nur generischer, die Öffnung der Loxone-Welt in jede Richtung.
LoxBerry bringt ja auch schon die passenden Automatismen für diese Anbindungen (z.B. TTS) mit, wenn ich es richtig verstanden habe.

Mit node-red-dashboard visualisiere ich übrigens meine Wohnung. Eben auch alles in einer App, aktuell mit Homematic, Max!, EnOcean, Hue, selbgstgebaute MQTT Sensoren und MQTT Aktoren (zB SonOff). Zuräzlich mache ich noch Geofencing über ownTracks, mit Pushbenachrichtigungen über Pushover und binde meinen LogitechMediaServer auch dort ein - Homematic, Max!, EnOcean und Hue über homegear mit MQTT.
Zum Beispiel spreche ich auch über einen node mit der Fritzbox und zeige im Dashboard die aktuelle Auslastung der Internetverbindung an.

Genauso kann man aber eben auch die Loxone-Visu nutzen und ein paar mehrere Welten ansprechen, als die die Loxone zum Glück schon ermöglicht. Die oben genannten Daten/Protokolle ließen sich, wenn der node fertig ist, auch mit Loxone ansprechen.

Eine Sache ist allerdings ganz ganz wichtig: Der node bildet keine Funktionalität ab sondern stellt nur die Verbindung der Welten dar. Wenn man möchste kann man die in node-red oder auf andere Weise implementieren.

Grüße,
Patrik

**Holger_kausch** · 04.03.2017, 14:26

Ich habe vor ein paar Wochen IOBroker entdeck und bin wirklich nur ein normaler Anwender. Trotzdem habe ich es mit Hilfe vom Forum hin bekommen virtuelle
Objekte an zu legen, diese durch Alexa zu steuern und an den Miniserver weiter zu reichen. Wenn jetzt jemand noch eine Schnittstelle zwischen Loxone und IOBroker
bereit stellt, kann es doch nur leichter und besser werden.

**pmayer** · 04.03.2017, 14:40

Hier mal ein kurzes Video, wie es mittlerweile schon funktioniert: https://cloud.codm.de/nextcloud/inde...MioYszBpNPfmkL
(Links: Browser mit Loxone Visualisierung, Mitte: Loxone-Config mit LiveView, Rechts: Browser mit node-red-dashboard)

Das Wiring in node-red hängt als Bild an. Leider liefert der Loxone-Websocket für Zustände des virtuellen Eingangs (active) nur 0 oder 1, erwartet aber, dass man ihm "On" oder "Off" - respektive "Pulse" - übergibt. Daher musste der Change-Node (ocker), der 0 => "Off" und 1 => "On" umschreibt, noch sein.

Aktuell schaffe ich es noch nicht den Taster-Baustein zu schalten. Der mag weder 1/0 noch On/Off.
Wie würde ich diesem zum Beispiel über einen normalen HTTP-Befehl (/dev/sps/...) schalten?

Wichtig: Das ist nur ein Beispiel, wo node-red-dashboard verwendet wird, um die Funktion klar zu zeigen. Ob ich jetzt ein dashboard-Element oder einen (zB) Twitter-Node an den Ausgang hänge ist völlig sekundär.

**svethi** · 04.03.2017, 14:46

Gut, dass Du es nicht falsch verstanden hast. Ich habe mal kurz in die Liste der nodes/flows (muss mich erst noch an die Notierungen gewöhnen) reingesehen und da interessante Sachen entdeckt. Je länger ich darüber nachdenke, fallen mir da Anwendungen ein. Spannend wäre z.B. eine Kommunikation zwischen den Plugins. Die meisten Plugins kommunizieren ja mit dem MiniServer. UDP, Webservices usw. Jedes für sich. Über diesen Weg könnte der Loxberry einen einzigen Kommunikationsweg bieten, den dann alle Plugins nutzen können. In diesem Zusammenhang stellt sich die Frage ob man diese Kommunikationsebene nicht sogar direkt in den Loxberry integriert.
Das muss man sich mal in Ruhe ansehen.
Wie sieht denn Deine EnOcean Integration aus?

**pmayer** · 04.03.2017, 14:52

Super Gedanke svethi - ich mag aber nicht beurteilen was alles in LoxBerry geht. Hatte bisher noch nicht die Zeit mir das anzugucken.

Ich habe nur ein EnOcean Gerät: Eltako FUD61-NPN mit dem ich meine Deckenlampe im Wohnzimmer schalte/dimme.
Zur Anbundung nutze ich den USB300 USB-Stick an einem RaspberryPi.

Da mein Anspruch war, alles in MQTT abzubilden, habe ich das Anfangs FHEM und der FHEM-MQTT-Bridge gemacht.
Ich setze aber für homematic/Max! sowieso homegear ein, dass seit neuestem auch ein enocean-Plugin hat: https://github.com/Homegear/Homegear-EnOcean. Leider ist dort die Doku aber noch nicht existent.
Da ich aber im Forum von homegear recht aktiv bin, hat der Homegear-Entwickler mir kurz unter die Arme greifen können.

Homegear bildet jedes ihm bekannte Gerät in MQTT mit allen bekannten Datenpunkten ab. Somit ist Dimmen/Schalten von EnOcean nur noch ein MQTT-Publish - egal woher (node-red-dashboard, openhab, iobroker, eigener Websocket, etc.)

**svethi** · 04.03.2017, 14:53

Du musst Dir mal die Objekte genau ansehen. Teilweise haben die eigene Action-ID's die dann zum interagieren benutzt werden müssen. Beim Taster weiß ich es jetzt nicht, war aber in der XML ziemlich leicht zu erkennen.

**svethi** · 04.03.2017, 14:59

Ich habe den EnOceanPi drauf und habe mir ein einzelnes C-Progrämmchen geschrieben. Habe gesehen, dass es in node-red auch eine EnOcean Umsetzung gibt. Diese ganzen einzelnen Dinge sind über die Zeit gewachsen und behindern aber oft auch die Zukunft. Sinnvoll wäre es schon, dass alles in einem System zusammenzufassen. Habe auch einen TI Sensortag hier. Da gibt's wohl auch etwas. Mal sehen was da so alles geht.

**pmayer** · 04.03.2017, 15:16

Zitat von svethi

Der Taster muss ja aber verschiedene ID's haben. Tr, O, R und Ausgang. Da musst Du mal nachsehen. An die Lichtsteuerung übergebe ich auch Werte. Da benutzt man den Ausgang. Vielleicht musst Du auch den Ausgang des Tasters nutzen.

Vom Taster Modul bekomme ich nur "active" als Control. Beim Lesen erhalte ich dort 0 oder 1... aber ich finde eben nicht, was ich rein schreibe muss um das Modul zu schalten.
Einfacherweise könnte ich ja einen Virtuellen Eingang an den Trigger hängen... aber das wäre ja nicht ganz im Sinne des Erfinders.

Code:

  '0f4f664e-006b-1946-ffff80982d442be6':
   { name: 'test taster',
     type: 'Switch',
     uuidAction: '0f4f664e-006b-1946-ffff80982d442be6',
     room: '0c48c50a-0290-035a-ffff80982d442be6',
     cat: '0c48c50a-0251-02d4-ffff80982d442be6',
     defaultRating: 0,
     isFavorite: false,
     isSecured: false,
     states: { active: '0f4f664e-006b-1945-ffff415a3137b8e8' } },

Das ist der Auszug für das Taster-Modul aus dem Structure-File.

//edit:
Ahhh... Die Bausteine haben Subcontrols, die entsprechend angesteuert werden. Der Tasterbaustein leider nicht... ich suche weiter... Muss also meine Auswahl im Editor noch um Subcontrols erweitern.

**svethi** · 04.03.2017, 17:55

So, habe es bei einem Taster gerade probiert. /dev/sps/io/namedestaster/On

**pmayer** · 04.03.2017, 17:58

Danke!

Ich hab mir jetzt sehr genau homebridge-loxone-ws angeguckt. Die senden einfach, genau wie du, ein "On" und ein "Off" auf das Switch-Element... https://github.com/Sroose/homebridge...tchItem.js#L76

Auf meiner Seite funktioniert es aber leider nicht. Mit einem virtuellen Eingang kein Problem (On/Off/Pulse)... Vielleicht sitze ich einfach schon zu lange davor

Leider antwortet mir der Entwicklier von node-lox-ws-api nicht... der könnte sicher helfen.
Ist der Entwickler von homebridge-loxone-ws hier im Forum?

**pmayer** · 06.03.2017, 20:14

Ich glaube ich habe es gefunden. Die States sind nur zum lesen der Daten. für die Aktion benötigt man "uuidAction". Im Falle es virtuellen Eingangs sind die aber zufällig gleich. Bin dabei meine Struktur entsprechend anzupassen und SubControls mit einzubaune... melde mich wieder, ob es das war.

**Plus06** · 06.03.2017, 22:22

Hallo Patrick, super Projekt 👍. Ich finde den Weg über MQTT und NodeRed als übergreifendes Instrument absolut richtig. Bitte bleibe weiterhin dran. Werde in den nächsten Wochen meine Infrastruktur/ Architektur überarbeiten und ein NodeRed steht dabei ganz oben auf der Liste. Du hast hier einen neuen Fan gewonnen. Gruß

Entwicklung node-red-contrib-loxone für node-red

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar