ElabNET Technik Forum

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.

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.

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

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.

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.

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

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.

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.

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

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