ElabNET Technik Forum

Das hat weniger mit der Logik als mit der Universal Objectverwaltung den Dispatcher zu tun, denn der öffnet die Tür in die Welt. Und der soll ja vor der Logik in den Roll-Out.
Und es braucht in der Dockerumgebung passende Inhalte die dann auch diese Objekte konsumiert. Und jenes hat ja so auch noch keiner gebaut, da die bisherigen Lösungen immer einfach sich nen eigenen eibd/knxd genommen haben und das auf den Bus geschrieben haben. Ich denke an der Stelle entsteht dann noch der richtige Aufwand. Und an der Stelle muss dann die Community a bisserl in die Tasten hauen. Stefan wird das mit Sicherheit nicht eingeplant haben, die hier derzeit genutzten Docker alle auf die Objektschnittstelle umzubauen.
Vor-/Nachteil solcher Anpassungen, der Docker ist dann halt schon ein echter TWS-Softwarebaustein da so einer auf ner anderen Umgebung dann keinen Sinn mehr macht.
Aber die Welt der vielen Docker ist ja damit nicht weg, weil der TWS wie man sieht ja auch die eibd/knxd basierten Kommunikationswege beherrscht.

Sorry wenn ich da so ein wenig mahnend schreibe, da ich von der Art Programmierung keine genügende Ahnung habe bin ich halt voll von anderen abhängig und sehe daher noch nicht so schnell die Docker alle im TWS Objektschnittstellendesing. Wobei ich schon überrascht war wie schnell es ging, bis hier die ersten Lösungen auf den bisherigen Zustand TWS vorgeführt würden. Das hatte keine Woche nach Versand der ersten größeren Mengen Server gedauert.

Und an einigen Stellen braucht es noch ein paar Anpassungen am Netzwerktraffic wie ich bei einigen Dockerkonstruktionen in den Beiträgen lesen konnte, aber das sind nun Laienhafte Vermutungen meinerseits.

Es muss ja keine dedizierte TWS / Docker Schnittstelle. Etwas generisches (REST, MQTT) kann allgemein genutzt werden und wäre nicht nur für Docker sondern auch für andere Systeme geeignet. Auch ohne das besonders Hand an den Container für eine TWS Integration angelegt werden muss.

Guten Morgen Alex,

alexbeer hat geschrieben: ↑Fr Mär 15, 2019 12:34 amDer Vorgeschmack macht Lust auf mehr!

Ja, auch für uns, wir haben da großen Spaß daran, die Kiste richtig zum Fliegen zu bringen.

alexbeer hat geschrieben: ↑Fr Mär 15, 2019 12:34 amIst mit dieser Version des Logikmoduls schon möglich auf den Inhalt von eigenen Docker Containern zuzugreifen?

Jein. Das Logikmodul hat damit nichts zu tun, das kann mit jedem Objekttyp arbeiten.

Wir unterscheiden Technologien, Subsysteme und deren Objekte.

Technologien sind KNX, 1-Wire, DMX usw. Die Subsysteme sind bei KNX zum Beispiel die KNX_Interfaces im Applikationsmode. Bei DMX werden die Subsysteme die jeweiligen Universes sein usw. Jedes der Subsysteme hat dann auch seine Objekte. Bei KNX sind es die mit der ETS angelegten Universalobjekte, bei DMX dann die Leuchtmittel, bei 1-Wire führt jede Regel zu einem Objekt.

Logik ist ebenfalls eine Technologie mit dem Subsystem "Logikengine". Jede Übergangsstelle von oder nach "außen" bildet einen Logikpunkt (das sind auf dem Bild die kleinen Kästchen an der Grenzlinie der Logikzelle) eingehend wie ausgehend. Diese Logikpunkte bekommen ebenfalls eine Objektnummer, die sich aus der Nummer der Zelle und der Nummer des Logikpunktes zusammen setzt, also zum Beispiel "LE-84-I3" (Logikengine, Logikzelle 84, der Eingang I3).

Über den Dispatcher (Verteiler) lassen sich nun alle Objekte miteinander verknüpfen, also 1-Wire mit KNX mit Logikobjekten der Logikpunkte mit DMX, mit Zeitreihen (jede Zeitreihe ist ein Zeitreihenobjekt) mit was auch immer noch kommen mag.

Diese Verknüpfungen des Dispatchers werden mit dem DOS vorgenommen, das ist das große Lila-Fenster in dem man die Verknüpfungen angibt. Dieses erscheint in allen Editoren, bei denen es um Objektzuweisungen geht. Man kann es damit auch an vielen Stellen verändern und anpassen.

Ob also jetzt irgendwas mit der Logik verknüpft werden kann, liegt nicht an der Logik, sondern ob es dafür eine Technologie mit einem Subsystem und verknüpfbare Objekte gibt.

alexbeer hat geschrieben: ↑Fr Mär 15, 2019 12:34 amKonkret: über den Ubiquiti Controller Containerviewtopic.php?f=25&t=204&p=1524&hilit=Ubiquity#p1524 möchte ich die Anwesenheitsüberwachung von WLAN Clients überwachen.

Für den Austausch mit Containern haben wir heute - hier und jetzt - nur den eibd und damit KNX. Also wenn Du etwas hier und heute über den Dispatcher mit der LE verknüpfen willst, dann musst in jedem Container den eibd / knxd starten und über GAs und pber damit verknüpfte KNX-Objekte komunizieren.

Im Laufe der Zeit, werden wir weitere Schnittsellen zur Verfügung stellen die generisch genutzt werden kann, der Capt´n hat es schon beschrieben, also MQTT, REST. ModBUS usw. Damit steht dann die Welt offen, nicht nur im Docker sondern mit so ziemlich allem, was es gibt.

lg

Stefan

Vielen Dank für die ausführliche Erklärung. Ich hoffe das in die Theorie verstanden zu haben. Als IT-affiner Nicht-Entwickler freue ich mich schon, wenn hierzu ein KB-Eintrag wächst und gedeiht.

Das Objektkonzept ist bereits im Leitfaden grundsätzlich erklärt.

https://wrgt.news/Leitfaden


lg

Stefan

Kleiner Erfolgs Bericht von meiner Wenigkeit.

Ich als Super DAU der auch mal das Korn findet, ohne Anleitung und ohne Englischkenntnisse mit Überlegung an die Logik rann.
Ohne dass ich im Forum nach irgendwelchen Anleitungen oder Beschreibungen gesucht habe, wurde meine Frau im WC überrascht.

Zum ersten mahl seit 20 Jahren leuchtet die Spiegellampe .

Die Überraschung für meine Frau war groß, sie stellte mir was zu trinken rein und ging,
nach gefühlten 10 sec. Speicherte ich meine erste Logik auf dem TW.

Weitere 20 sec. Hörte ich meine Frau aus dem WC schreien „ seit wann leuchtet das Spiegel Licht ?“
Antwort von mir „ seit 10 Sekunden “

Und das war die Bestätigung für mich das auch ein DAU wie ich mit ein wenig Hirn Schmalz mit dieser Oberfläche klarkommt.
Das ist ja fast ge…. als ein Waschelpropankompott

Hirn einschalten
Kleine Fehler machen
Denken das müsste geändert werden
Noch mal probieren
Tags hinzugefügt (wichtig !!! wusste gar nicht für was man sowas benutzt, hilft bei der Logik immens )
Hirn zum zweiten mal einschalten
Siehe da, nach ca. 10 min und einigen kleinen Fehlern die erste Logik fertig

Nun eine Frage
WARUM gab’s den Timberwolf nicht schon vor 20 Jahren?
Hätte mir einiges an KNX Geräten gespart

Der Timberwolf ist so ein ge…. Gerät

Wenn man ein wenig damit verbringt und spielerisch lernt und seine Fehler macht um zu lernen,
weiterhin den Nutzen sieht ist er allemal sein Geld wert und schnell wieder eingespart.

Mfg
eib-eg

Das hast du echt schön geschrieben! Der TWS bringt bei mir nach 10 Jahren KNX auch wieder richtig laune um es noch ein bisschen besser und schöner zu machen!

LG
Hiele

StefanW hat geschrieben: ↑Fr Mär 15, 2019 8:49 am
Für den Austausch mit Containern haben wir heute - hier und jetzt - nur den eibd und damit KNX. Also wenn Du etwas hier und heute über den Dispatcher mit der LE verknüpfen willst, dann musst in jedem Container den eibd / knxd starten und über GAs und pber damit verknüpfte KNX-Objekte komunizieren.

Im Laufe der Zeit, werden wir weitere Schnittsellen zur Verfügung stellen die generisch genutzt werden kann, [...]

Ich habe mir hier in der Zwischenzeit noch ein paar Gedanken gemacht. Den Ansatz mit generischen Schnittstellen finde ich Klasse. Mit REST wird bestimmt viel gehen. Wie man den KNXd oder EiBD in bestehenden Docker Containern verfügbar machen und auch Information an KNX-Adressen übergeben kann, habe ich nicht verstanden.

Ich suche eine Option, in der verfügbare Docker Container ohne Anpassung verwendet werden können.
Was haltet ihr von folgendem Ansatz:
1. Bestehenden Docker Container zB UniFi via DockerHub o.ä. deployen
2. In einem weiteren Container Node-RED laufen lassen.
3. In Node-RED für das Beispiel mit dem Unifi-Container zB https://flows.nodered.org/node/node-red-contrib-unifi installieren
4. Mit https://flows.nodered.org/node/node-red ... b-knx-easy dann die UniFi Infos in entsprechende KNX-Adressen schreiben.
5. Nun sollten alle Infos im LE zu Verfügung stehen und können da weiter verarbeitet werden.

Bei Punkt 3. Würde ich ganz klar die TWS Community sehen, passende Pakete - ggf über das angedachte Repository - bereitzustellen.
Bei Punkt 4. Könnte ich mir ein ElabNet Paket vorstellen, dass von Node-RED direkt mit TWS-Objekten -ohne KNX Umweg - kommuniziert.

Auf diesem Weg könnten auch externe Infos über dem "Umweg" TWS in Grafana gespeichert werden, ohne Grafana für externen Zugriff zu öffnen.

Wie seht ihr diesen Ansatz? Macht es Sinn diesen Weg weiter zu verfolgen oder gibt es andere Konzepte, die smarter sind?
VG Alex

Hallo Alex,

wir unterstützen nur Ansätze, die keine Abhängigkeit von einzelnen Technologien vorsehen, also z.B. keine Abhängigkeit von KNX.

Der Timberwolf Server soll auch in einer reinen 1-Wire / ModBus / DMX Umgebung einsetzbar sein, in dem es gar kein KNX gibt. Das ist für Euch jetzt vierlleicht nicht so vorstellbar, aber KNX kommt im Ausland deutlich weniger vor, dort ist BaCNET wichtiger. In der Industrie ist Modbus beliebt.

Warum Node-RED? Was bietet in Deinem Szenario Node-RED?

Ich denke dass wir mit MQTT und / oder REST am besten und am universellsten sein können. Aber zunächst machen wir erstmal unsere Objektverwaltung und die Logik fertig.


lg

Stefan

Node-Red ist ja auch nichts anderes was der TWS eben auch sein wird. Halt eine Übersetzung verschiedener Protokolle.
Wenn der TWS MQTT / REST direkt verbinden kann ergibt das mit Node-red keinen Mehrwert. Die Unifi sprechen ja kein Node-Red. Ob nun ein eibd/knxd nach KNX übersetzt oder Node-Red ist ja egal. Kannst auch Edomi oder Openhab, iobroker dafür nehmen.

Sowie der TWS die IoT-Protokolle direkt versteht und verbinden kann sind alle diese Übersetzer dafür überflüssig. Insofern war der Viessmann-Vcontrold Docker genau der richtige Ansatz den bis zur Schnittstelle zum MQTT zu beenden. Nun kann ein beliebiger Docker der MQTT nach KNX übersetzen kann provisorisch zwischen geschalten werden und später aus der Kette einfach rausgetrennt werden um dann das Timeseries Objekt via DOS nicht von einem KNX-Objekt sondern vom MQTT-Objekt befüllt zu werden.

Wenn Du keinen Docker programmieren kannst um ein von dir genutztes System anzubinden (kann ich auch nicht) aber einen Baustein in NodeRed findest, dann kannst ja einfach einen Node-red Docker nehmen, das System einlesen und baw. auf KNX ausgeben und später eben als MQTT ausgeben. Im TWS muss jedenfalls nichts gebaut werden was Node-Red nativ versteht, denn das gibt es im Prinzip nicht ein Node-Red Protokoll.