NEUHEIT: Freigegebene Hauptversion V 1.6 ab sofort für alle Modelle des Timberwolf Server verfügbar. Infos: viewtopic.php?f=8&t=2588!

[DISKUSSION] CometVisu --> Anbindung MQTT-Broker Web Sockets

Wissen, Planung & Diskussion zur MQTT Unterstützung im Timberwolf Server.
Stellt uns hier Eure MQTT Projekte und Ideen vor.

Ersteller
Sun1453
Reactions:
Beiträge: 941
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 628 Mal
Danksagung erhalten: 416 Mal

CometVisu --> Anbindung MQTT-Broker Web Sockets

#1

Beitrag von Sun1453 »

Hallo @Chris M. und Elabnet Team,

wie sieht es im einer Umsetzung der Comet Visu Anbindung über MQTT aus. Chris meinte das man dafür Web Sockets bei MQTT benötigt. Damit könnte er eine Verbindung ermöglichen.

Danke schon mal für die Antwort.
Zuletzt geändert von Sun1453 am Mo Jun 15, 2020 12:42 pm, insgesamt 1-mal geändert.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache

Ersteller
Sun1453
Reactions:
Beiträge: 941
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 628 Mal
Danksagung erhalten: 416 Mal

#2

Beitrag von Sun1453 »

Hmm ziemlich ruhig hier. Wohl kein Interesse das man CometVisu ohne Fluten des KNX Busses mit dem TWS betreiben kann. Damit wird Comet Visu bei mir nicht zum Einsatz kommen, denn ich wollte diese auf einen anderen Server TWS 2400 betreiben und diese mit dem TWS 950 über Modbus TCP / MQTT verbinden.
Zuletzt geändert von Sun1453 am Do Aug 06, 2020 2:58 pm, insgesamt 1-mal geändert.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache

StefanW
Elaborated Networks
Reactions:
Beiträge: 4997
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Grafing
Hat sich bedankt: 2359 Mal
Danksagung erhalten: 3688 Mal
Kontaktdaten:

#3

Beitrag von StefanW »

Hi Michael,

wir können einfach nicht auf alles und jedes antworten. Das schaffen wir nicht.

Wir haben schon lange gesagt dass wir CometVisu gerne auf MQTT hätten und daran wird auch gearbeitet. Wir bleiben bei dem Plan, dass wir zuerst Modbus machen, dann DMX dann MQTT usw. Erst dann hat es auch einen Sinn, die CometVisu auf ein neues Protokoll umzustellen, wobei es dabei um mehr als nur MQTT geht, sondern auch Konfigurationsinformationen und Objektinformationen mitkommen sollen. Das ist nicht trivial und ein bisschen Zeit muss man uns auch lassen.

Stefan
Zuletzt geändert von StefanW am Do Aug 06, 2020 3:29 pm, insgesamt 1-mal geändert.
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART der Elaborated Networks GmbH
Support nur über dieses Forum und in individuellen Fällen über support@wiregate.de.
Bitte KEINE PN Impressum und Datenschutzerklärung oben
Benutzeravatar

Chris M.
Reactions:
Beiträge: 688
Registriert: Sa Aug 11, 2018 10:52 pm
Wohnort: Oberbayern
Hat sich bedankt: 126 Mal
Danksagung erhalten: 350 Mal
Kontaktdaten:

#4

Beitrag von Chris M. »

Sun1453 hat geschrieben: Do Aug 06, 2020 2:57 pm Wohl kein Interesse das man CometVisu ohne Fluten des KNX Busses mit dem TWS betreiben kann.
Wie kommst Du darauf, dass die CometVisu den KNX mit Paketen fluten würde?
Hast Du eine Messung wo es ein Problem mit der Paket-Menge auf dem KNX gibt?

Ich kenne keinen Fall, bei dem wir hier jemals an eine Grenze gestoßen wären, aber ich kann ja auch nicht alle Fälle kennen.
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

gbglace
Reactions:
Beiträge: 1938
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 634 Mal
Danksagung erhalten: 722 Mal

#5

Beitrag von gbglace »

Der Vorteil für die CV an der Stelle ist, das die wirklich nur Visu ist. Den Bus fluten geht dann nur wenn Du als User wirklich verdammt flinke Finger hast.

Das was da also aus der CV rauskommt muss in der Regel also eh auf den KNX um halt einen Aktor entsprechend zu bedienen.

Anders ist das mit den Lösungen die da Visu und Logik kombinieren, da passiert viel mehr im Hintergrund wo von mir relativ wenig in einen echten Befehl endet.

CV per MQTT wäre dann Knopf drücken, MQTT wandeln und den TWS via LAN ins MQTT Objektsystem aufnehmen dann entweder direkt an KNX raus oder in eine Logik und dann was auch immer draus gemacht. Was direkt auf den KNX geht ist auf dem KNX dann auch nicht mehr davon zu unterscheiden, ob es die CV oder der TWS gewesen ist der da was als Schaltung ausgelöst hat, weil in dem Moment beides die gleiche PA als Absender hat.

Die Frage ist also eher, ist die Kommunikation CV <> KNX via TWS-Tunnel ggf optimierbar. (eibd/knxd)
In der ETS keine Dummy-Applikation für die Visu anlegen zu müssen ist zwar ein Vorteil der MQTT Verbindungsvariante.
Wobei sich das auch für die User relativiert, die für jede GA ein KNX-Objekt im TWS anlegen, da alle auf dem TWS gehosteten CV-Container primär auch auf der gleichen Linie landen wie der TWS selbst. Der ETS Dummy wäre daher einfach nur anzulegen um in der ETS der PA des Tunnels mit der CV auch einen Namen "Visu" zu geben. Das aber funktioniert auch erst richtig gut wenn man dem TWS in der Tunnelverwaltung noch beibringt einzelne IP-Adressen oder so feste Tunnel reservieren zu können, damit bei einem Neustart und schwankenden Reihenfolgen wann der ein oder andere Container oder sonstige IP-Client an der TWS Schnittstelle anbimmelt eben für die CV immer die gleiche PA gillt.

Wenn man das also Mal genauer anschaut wg Performance des KNX soweit absolut kein Grund bei dem Projektschritt in Hektik zu verfallen.
Zuletzt geändert von gbglace am Fr Aug 07, 2020 6:36 am, insgesamt 1-mal geändert.
Grüße
Göran

-- --Timberwolf 2600 Velvet Red-- -- TWS #225 / VPN aktiv / Reboot OK

Robert_Mini
Reactions:
Beiträge: 2748
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 698 Mal
Danksagung erhalten: 1348 Mal

#6

Beitrag von Robert_Mini »

Sehe ich auch so.
Die CV generiert nur Traffic beim Bedienen und hört sonst nur zu.
Es gibt kaum einen Wert, den ich WEGEN der CV zusätzlich schicke.

Und wie Göran gesagt hat, das meiste kommt von der Logikseite. Und das hat der TWS mit seinen Objekten perfekt umgesetzt. Auch der eventgesteuerte Gedanke trägt dazu bei.

Alleine durch den Umstieg vom WireGate zum TWS habe ich nach und nach den Busverkehr halbiert und liege nun nur mehr bei ca. 1/s.

Wichtiger für MQTT sind die Docker. Da habe ich einige GAs am Start, die ich eigentlich nicht am Bus möchte zb Openweather aus NodeRed (zb Forecast in 3h Auflösung für 64h). Das kommt aber mit MQTT am TWS.
CV ist mir da nicht so wichtig, auch weil ich fürchte, dass die Suche in der CV nicht so mächtig sein wird.

Lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / Wiregate-Fan

Ersteller
Sun1453
Reactions:
Beiträge: 941
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 628 Mal
Danksagung erhalten: 416 Mal

#7

Beitrag von Sun1453 »

Hallo zusammen,

meint Post war bitte nicht als Angriff zu werten, sondern ich war echt überrascht, das niemand sich für das Thema interessiert hat. Sollte es anders rübergekommen sein bitte ich das zu entschuldigen.

Ich meinte mit der Sache das wenn man die Visu startet, sich diese ja mit x Telegrammen die ganzen Informationen zusammensucht aus dem KNX System. Ich weis die Visu braucht die Information, aber warum muss das auf KNX passieren.

Der TWS hat doch die Informationen in meinen Szenanrio bereits vorliegen und kann diese auch über einen anderen Weg in diesem Fall MQTT an die Visu liefern. So handelt sich die VISU nur mit dem TWS die Informationen aus. Auch bin ich von dieser Altlast (eibd/knxd) nicht gerade begeistert.

Ich war gerade froh das der TWS ein ordentlich Zertifiziertes KNX Gerät mit PA ist und nicht wie andere Server einfach nur dumm als Dummy in der KNX Installation hängen. Auch gab es mit dieser nicht zertifizierten Altlast ja schon diverse Probleme. Daher bin ich eher für die Lösung über den TWS wo man auch einen erstklassiken und zugesicherten Support erhält.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache

gbglace
Reactions:
Beiträge: 1938
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 634 Mal
Danksagung erhalten: 722 Mal

#8

Beitrag von gbglace »

Sun1453 hat geschrieben: Fr Aug 07, 2020 8:49 am
Der TWS hat doch die Informationen in meinen Szenanrio bereits vorliegen und kann diese auch über einen anderen Weg in diesem Fall MQTT an die Visu liefern.
Der TWS ist und kann nicht für alle GA der Master sein. Es sollten zwar alle Telegramme bei ihm ankommen aber eine Garantie bei einem restart ist eben wenn die Visu das was sie braucht sich da holt wo der Master des jeweiligen Status ist.

Das eibd/knxd oder der Umgang damit, (Restartverhalten usw.) in der CV ggf optimiert werden kann ist wahrscheinlich wesentlicher. Kann ich aber mangels Nutzung der CV nicht beurteilen ob das in der IST-Version Probleme auf dem Bus macht.

Anders sähe es aus wenn die CV quasi integraler Bestandteil des TWS wäre, aber das ist sie nicht, sie ist eine offene Visu die auch ohne TWS in einer KNX-Anlage funktioniert und weiter funktionieren soll.

Gira und Co. haben da halt einen anderen Weg und andere Entwicklerkapazitäten um sich eine ganz eigene Visu zu bauen.
Zuletzt geändert von gbglace am Fr Aug 07, 2020 11:24 am, insgesamt 2-mal geändert.
Grüße
Göran

-- --Timberwolf 2600 Velvet Red-- -- TWS #225 / VPN aktiv / Reboot OK

Robert_Mini
Reactions:
Beiträge: 2748
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 698 Mal
Danksagung erhalten: 1348 Mal

#9

Beitrag von Robert_Mini »

gbglace hat geschrieben: Fr Aug 07, 2020 11:23 am Gira und Co. haben da halt einen anderen Weg und andere Entwicklerkapazitäten um sich eine ganz eigene Visu zu bauen.
Aber beim Start der Visu würde es mich wundern, wenn nicht auch die Gira-Visu oder EDOMI mal alle GAs nacheinander liest.

Nochwas, vielleicht gibt es da auch ein Missverständnis:
Die CV liest die GAs nur beim Start des Containers (oder ersten Clients, weiß ich grad nicht), danach hat auch sie alle Werte im Speicher und hört auf Veränderungen mit.
D.h. ein temporärer Stard einer zB Handy Visu löst kein erneutes Read auf den Bus aus!!!

lg
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / Wiregate-Fan

Sensej
Reactions:
Beiträge: 630
Registriert: So Aug 12, 2018 9:12 am
Hat sich bedankt: 40 Mal
Danksagung erhalten: 82 Mal

#10

Beitrag von Sensej »

Robert_Mini hat geschrieben: Fr Aug 07, 2020 11:49 am Die CV liest die GAs nur beim Start des Containers (oder ersten Clients, weiß ich grad nicht), danach hat auch sie alle Werte im Speicher und hört auf Veränderungen mit.
D.h. ein temporärer Stard einer zB Handy Visu löst kein erneutes Read auf den Bus aus!!!
Hallo Robert,
genau, ich glaube IOBroker funktioniert genau so.

MfG Juri
TWS 2400 ID: 69 + PBM ID: 728 + TP-UART, VPN offen, Reboot erlaubt
Antworten

Zurück zu „MQTT“