ElabNET Technik Forum

Abgetrennt von: viewtopic.php?f=73&t=1895

Sind die Pläne zu MQTT schon soweit, dass sie hier im Forum diskutiert werden können? Ich habe versucht mich da ein wenig einzulesen und finde den Ansatz total klasse.
Mache mir gerade Gedanken, wie ich z.B. die gerade diskutierten System-Objekte in meiner Visu (hier CometVisu) angezeigt bekäme.
Da wäre es ja echt top, wenn der TWS einen MQTT-Server (sprich: MQTT-Broker) bereitstellen würde und die CometVisu als Backend einen MQTT-Client hätte.
Dann wäre es doch so, dass die CV nicht mehr über den eibd/knxd mit dem TWS kommunizieren müsste, sondern direkt via MQTT und die CV somit die TWS-Objekte direkt abonnieren könnte, oder?
Habe ich da einen gedanklichen Fehler?

Das Prinzip hast Du so korrekt verstanden.

Einziges Detail wäre das die CV dann immernoch nicht direkt auf TWS Objekte reagieren würde, da für den TWS auch ein solches MQTT-Objekt quasi was gleichrangiges wie ein KNX-Objekt ist. Die IP-Schnittstelle durchs LAN aber ungleich flinker als der KNX-Bus ist und inhaltlich je "Telegramm" mehr als die 14byte Text enthalten sein kann.

Eine MQTT Schnittstelle ist für die CV aktuell in Diskussion.

Aber wie Werte vom TWS zur CV gehen so oder so immer nur durch eine IP basierte interne, virtuelle Schnittstelle. D.h. hier gibt es keine Limitierung durch den KNX-TP.
Und müssten nicht inzwischen beim KNX auch Pakete > 14 Byte möglich sein? (Hab's aber noch nie ausprobiert, was dann passiert)

Hallo Alex,

alexbeer hat geschrieben: ↑Fr Jan 17, 2020 10:59 pmSind die Pläne zu MQTT schon soweit, dass sie hier im Forum diskutiert werden können?

Ja, bitte.

Wir sind dran. Im Prinzip vom Kern her auch keine große Sache, weil Broker und Clients gibt es zuhauf, aber der Aufwand besteht vor allem in folgendem:

1. Benutzer- und Adminoberfläche, Diagnose usw. für MQTT
Es soll ja alles schön und einfach einstellbar sein, Diagnose usw. und das kostet eine Menge Zeit das herzustellen. Das ist was 90% der Implementierung an Zeit kostet

2. Parsen / Compilieren der Datenstrukturen als Payload von MQTT
MQTT hat kein klares Datenformat. Das ist nicht so wie bei KNX dass es normierte Datenstrukturen (Datenpunkttypen) gibt. Zwar können diese (ähnlich KNX Objekte) sauber in "Topics" strukturiert sein, aber es werden auch gerne Daten in Arrays verschickt, also komplexere Datenstrukturen, wobei hier sehr oft hier json benutzt wird (kann aber auch xml sein). Umgekehrt sind auch die Setups solcher Geräte mit json zu bedienen. Jedes Gerät eines jeden Herstellers ist dabei anders. Woran wir arbeiten ist also, wie man das EINFACH einstellbar macht.

alexbeer hat geschrieben: ↑Fr Jan 17, 2020 10:59 pmDa wäre es ja echt top, wenn der TWS einen MQTT-Server (sprich: MQTT-Broker) bereitstellen würde und die CometVisu als Backend einen MQTT-Client hätte.

Richtig, beides ist geplant bzw. in Diskussion

alexbeer hat geschrieben: ↑Fr Jan 17, 2020 10:59 pmDann wäre es doch so, dass die CV nicht mehr über den eibd/knxd mit dem TWS kommunizieren müsste, sondern direkt via MQTT und die CV somit die TWS-Objekte direkt abonnieren könnte, oder?

Jep, ganz genau

alexbeer hat geschrieben: ↑Fr Jan 17, 2020 10:59 pmHabe ich da einen gedanklichen Fehler?

Nein, alles genau richtig

So ist es gedacht, weil es auch richtig sinnhaft ist.


lg

Stefan

Chris M. hat geschrieben: ↑Sa Jan 18, 2020 11:28 amAber wie Werte vom TWS zur CV gehen so oder so immer nur durch eine IP basierte interne, virtuelle Schnittstelle. D.h. hier gibt es keine Limitierung durch den KNX-TP.

Die CV nutzt den knxd/eibd und damit die KNXnet/IP Tunneling Schnittstelle z.B. des Timberwolf Servers. Der Endpunkt des IP-Tunnels ist der KNX-TP und dort - auf dem TP-Bus - landen die Pakete dann auch. Ich denke schon, dass dies vom Durchsatz her limitiert ist, sollte sich aber leicht prüfen lassen können.

Chris M. hat geschrieben: ↑Sa Jan 18, 2020 11:28 amUnd müssten nicht inzwischen beim KNX auch Pakete > 14 Byte möglich sein? (Hab's aber noch nie ausprobiert, was dann passiert)

Unser Stack kann zwar extendet Pakete über den Tunnel handeln, aber die Datenstrukturen des Stack selbst liegen bei einem Payload von 14 Byte.

lg

Stefan

Chris M. hat geschrieben: ↑Sa Jan 18, 2020 11:28 am Eine MQTT Schnittstelle ist für die CV aktuell in Diskussion.

Hallo Chris!

Ist das dann eher MQTT oder mittels GA (=eibd) oder ähnlich wie bei den Diagrammen je Widget wählbar, ob die Quelle eine GA oder eben MQTT ist?

lg
Robert

Sorry, dass ich den Thread gekapert habe, aber das ist echt spannend!

1. Benutzer- und Adminoberfläche, Diagnose usw. für MQTT
Es soll ja alles schön und einfach einstellbar sein, Diagnose usw. und das kostet eine Menge Zeit das herzustellen. Das ist was 90% der Implementierung an Zeit kostet

So schön die offenen Schnittstellen auch sind und damit die Komplexität aus der Applikation genommen wird, wird natürlich die Komplexität nur verschoben und zwar in die Schnittstellen.
Daher finde ich es sehr gut, dass ihr euch Gedanken zum Monitoring und Fehlerhandling macht.
Das fehlt einfach bei vielen anderen Lösungen - auch in denen großen Paas Lösungen.

Hallo Alex,

alexbeer hat geschrieben: ↑Sa Jan 18, 2020 12:03 pmSorry, dass ich den Thread gekapert habe, aber das ist echt spannend!

Na, dann sollten wir halt einen separaten Thread "Diskussion: MQTT-Implementierung im Timberwolf Server" dazu eröffnen. Hab nur gerade keine Zeit zum verschieben, vielleicht kann das ein anderer Admin machen.

alexbeer hat geschrieben: ↑Sa Jan 18, 2020 12:03 pmDaher finde ich es sehr gut, dass ihr euch Gedanken zum Monitoring und Fehlerhandling macht.

Ja, das ist woran wir als erstes denken. Wo sind die Probleme, worüber kann der Kunde fallen, was braucht er für Anzeigen und Rückmeldungen, was können und sollen wir als Diagnose anbieten? Welches Logging wird benötigt? Da steckt nachher 90% des Aufwandes drin.

alexbeer hat geschrieben: ↑Sa Jan 18, 2020 12:03 pmDas fehlt einfach bei vielen anderen Lösungen - auch in denen großen Paas Lösungen.

Ja, es wird immer erst Funktion gebaut, weil es das ist wonach der Kunde sucht. Diagnose, Logging und anderes wird zunächst nicht nachgefragt, das wird erst dann vermisst, wenn etwas nicht geht und man keine Ahnung hat warum und was man nun tun soll.

Ich sehe das bei so vielen anderen (günstigen) Lösungen. Da muss man oft - und jeder Kunde für sich immer wieder - alles im Detail in INI-Files oder php-Strukturen das gewünschte mehr programmieren als einstellen und dann geht es - oder nicht. Diagnose Fehlanzeige.

Das ist nicht, wie unserer Meinung nach ein einfach handhabbares Produkt sein sollte. Allerdings ist auch festzustellen, dass die Interessenten für unseren Server diese Vorteil oft nicht erkennen bzw. wir das auch schlecht erklären können. Weil wenn wir im Katalog / Shop diese Diagnose-Möglichkeiten beschreiben, dann wird das teils als "Marketing-Gewäsch" abgetan oder von manchem angenommen, dass andere Produkte dies wohl auch beinhalten. Nur der Kenner weiß Bescheid, da hat er nur schon das billige gekauft.

Unser Problem ist ein wenig, dass unsere Kunden das zwar absolut schätzen, aber die Interessenten sich am Produktpreis stören bzw. diese Diagnoseinstrumente nicht bezahlen wollen.

Wir überlegen daher, ob man nicht einen Server mit "Eco-Software" anbietet, der zwar alles kann, aber dafür keine Diagnose und Analysewerkzeuge bietet. Nur ist es dann auch irgendwie kein "Timberwolf Server" mehr.... man muss ja auch an das Markenimage denken.

Ich werde Euch aber miteinbeziehen, wenn die Planungen zu den Oberflächen entsprechend fortgeschritten sind. Das dürfte auch die Diskussion erleichtern.


lg

Stefan

StefanW hat geschrieben: ↑Sa Jan 18, 2020 11:53 am

Chris M. hat geschrieben: ↑Sa Jan 18, 2020 11:28 amAber wie Werte vom TWS zur CV gehen so oder so immer nur durch eine IP basierte interne, virtuelle Schnittstelle. D.h. hier gibt es keine Limitierung durch den KNX-TP.

Die CV nutzt den knxd/eibd und damit die KNXnet/IP Tunneling Schnittstelle z.B. des Timberwolf Servers. Der Endpunkt des IP-Tunnels ist der KNX-TP und dort - auf dem TP-Bus - landen die Pakete dann auch. Ich denke schon, dass dies vom Durchsatz her limitiert ist, sollte sich aber leicht prüfen lassen können.

Der eibd/knxd geht auf ein durch den TWS bereit gestellten Tunnel.

Man könnte ja mal schauen ob man hierfür eine eigene Linie nehmen könnte.

Oder es einfach lassen, da ich selbst beim KNX-TP im normalen Betrieb bisher noch nie in eine Geschwindigkeitslimitierung gekommen bin. D.h. mir dieses Problem sehr theoretisch vorkommt.

Robert_Mini hat geschrieben: ↑Sa Jan 18, 2020 11:53 am

Chris M. hat geschrieben: ↑Sa Jan 18, 2020 11:28 am Eine MQTT Schnittstelle ist für die CV aktuell in Diskussion.

Ist das dann eher MQTT oder mittels GA (=eibd) oder ähnlich wie bei den Diagrammen je Widget wählbar, ob die Quelle eine GA oder eben MQTT ist?

Das wäre ein neues Backend.

D.h. Du hast dann die Wahl ob diese CV mit einem eibd/knxd, mit OpenHAB oder eben mit MQTT (über Web Sockets, d.h. entsprechender Broker wird benötigt) sprechen soll. Ein Mischen ist nicht möglich.