NEU! UPGRADE IP 11 verfügbar!
NEU! LICHTWIDGET - DPT 7.600 - Logik Manager Update - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/B9MUEJj2
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
NEU! LICHTWIDGET - DPT 7.600 - Logik Manager Update - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/B9MUEJj2
Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Ab sofort kann jeder die neue VISU & IFTTT testen. Info: viewtopic.php?f=8&t=5074
Release V 4 am 15. Juni 2024
Es gibt nun einen fixen Termin. Info: viewtopic.php?f=8&t=5117
NEU! Ausführliches Video Tutorial zur VISU
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
Diskussion: MQTT-Implementierung im Timberwolf Server
Forumsregeln
- Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
- Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
- Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
- Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
-
- Reactions:
- Beiträge: 394
- Registriert: Mi Sep 12, 2018 1:11 am
- Wohnort: NRW
- Hat sich bedankt: 212 Mal
- Danksagung erhalten: 251 Mal
Diskussion: MQTT-Implementierung im Timberwolf Server
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?
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?
Zuletzt geändert von Robert_Mini am Sa Jan 18, 2020 2:12 pm, insgesamt 2-mal geändert.
VG Alex
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit
-
- Reactions:
- Beiträge: 3614
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1272 Mal
- Danksagung erhalten: 1674 Mal
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.
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.
Grüße
Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Göran
#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
-
- Reactions:
- Beiträge: 1194
- Registriert: Sa Aug 11, 2018 10:52 pm
- Wohnort: Oberbayern
- Hat sich bedankt: 237 Mal
- Danksagung erhalten: 857 Mal
- Kontaktdaten:
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)
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)
CometVisu Entwickler - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.
TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache
CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.
TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache
-
- Elaborated Networks
- Reactions:
- Beiträge: 9775
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 4879 Mal
- Danksagung erhalten: 7820 Mal
- Kontaktdaten:
Hallo Alex,
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.
So ist es gedacht, weil es auch richtig sinnhaft ist.
lg
Stefan
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.
Richtig, beides ist geplant bzw. in Diskussion
Jep, ganz genau
Nein, alles genau richtig
So ist es gedacht, weil es auch richtig sinnhaft ist.
lg
Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
-
- Elaborated Networks
- Reactions:
- Beiträge: 9775
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 4879 Mal
- Danksagung erhalten: 7820 Mal
- Kontaktdaten:
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.
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
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
-
- Reactions:
- Beiträge: 3744
- Registriert: So Aug 12, 2018 8:44 am
- Hat sich bedankt: 1171 Mal
- Danksagung erhalten: 2076 Mal
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
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297
-
- Reactions:
- Beiträge: 394
- Registriert: Mi Sep 12, 2018 1:11 am
- Wohnort: NRW
- Hat sich bedankt: 212 Mal
- Danksagung erhalten: 251 Mal
Sorry, dass ich den Thread gekapert habe, aber das ist echt spannend!
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.
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.
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
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.
VG Alex
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit
-
- Elaborated Networks
- Reactions:
- Beiträge: 9775
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 4879 Mal
- Danksagung erhalten: 7820 Mal
- Kontaktdaten:
Hallo Alex,
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
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.
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.
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
Zuletzt geändert von StefanW am Sa Jan 18, 2020 12:40 pm, insgesamt 2-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de
Link zu Impressum und Datenschutzerklärung oben.
-
- Reactions:
- Beiträge: 1194
- Registriert: Sa Aug 11, 2018 10:52 pm
- Wohnort: Oberbayern
- Hat sich bedankt: 237 Mal
- Danksagung erhalten: 857 Mal
- Kontaktdaten:
Der eibd/knxd geht auf ein durch den TWS bereit gestellten Tunnel.StefanW hat geschrieben: ↑Sa Jan 18, 2020 11:53 amDie 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.
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.
CometVisu Entwickler - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.
TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache
CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.
TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache
-
- Reactions:
- Beiträge: 1194
- Registriert: Sa Aug 11, 2018 10:52 pm
- Wohnort: Oberbayern
- Hat sich bedankt: 237 Mal
- Danksagung erhalten: 857 Mal
- Kontaktdaten:
Das wäre ein neues Backend.Robert_Mini hat geschrieben: ↑Sa Jan 18, 2020 11:53 amIst 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?
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.
CometVisu Entwickler - Bitte keine PNs, Fragen gehören in das Forum, damit jeder was von den Antworten hat!
CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.
TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache
CometVisu Fragen, Bugs, ... bitte im Entwicklungs-Forum, hier nur spezifisches für CV<->Timberwolf.
TWS 2500 ID: 76 + TP-UART - VPN offen, Reboot nur nach Absprache