ElabNET Technik Forum

Hallo Liebe TWSler


Besteht die Möglichkeit ein UDP in für MQTT einzubauen?

somit könnte man von vielen Geräten (z.B.: Loxone Miniserver, ESP,..) oder Raspberry Projekten ganz einfach Daten per UDP an den TWS senden

z.B.:
$socket = fsockopen("udp://10.0.0.94:1884"); Der Port müsste halt von TWS vorgegeben werden

fwrite($socket, "publish RPI/Wetterstation/AusenTemp $Var1");
fwrite($socket, "publish RPI/Wetterstation/AussenFeuchte $Var2");

Im TWS MQTT sollten die Topics dann automatisch angelegt werden und stehen dadurch allen anderen Ein/Ausgängen oder der Visu zur Verfügung

LG Peter

Hallo Peter, @PeterB

da bist du aber bei MQTT nicht an der richtigen Adresse. Das gehört nämlich hier her: viewforum.php?f=82. Wir hatten das Thema auch schon und das ist dann was für die Ausbaustufe des Merkmals. Erstmal gibt es um den anderen Weg um Daten bei Quellsystem abzufragen und später dann in die Gegenrichtung das man Daten von anderen Systemen empfangen kann und auswerten.

Hmmm ja da muss Ich aber dann wider alles händisch eingeben und dann erst recht ans MQTT System schicken wenn Ich es in der Visu abgreifen möchte.

wenn aber der" UDP In" automatisch im MQTT System angelegt und angezeigt wird erspart man sich an haufen Arbeit und vom MQTT kann Ichs ganz einfach hinsenden wo ich will mit nur einem Klick an KNX z.B. wenn der KNX Ausgang schon angelegt ist.

Ich schick von irgendwo fwrite($socket, "publish RPI/Wetterstation/AusenTemp $Var1") an den TWS und kann in der Visu mit PI/Wetterstation/AusenTemp den Wert abgreifen ohne nur einen Klick im TWS

oder Ich muss in der HTTP/Rest api einen Subsystem anlegen dann im Resourcen Manager einen Api Server hinzufügen und dann noch ein Resource....selbiges mit MQTT erst dann kann ICh diese beiden Resourcen miteinander verknüpfen und in der Visu verwenden

@PeterB

Also der Reguläre Weg wäre

HTTP API mit Subsystem und Resourcen und dann mit dem Dispatcher auf MQTT was du natürlich mit Subsystem und dem ganzen angelegt hast.

PS: Beachte der TWS ist nur ein Client bei einem MQTT Broker. Der TWS an sich ist kein MQTT Broker. Der MQTT Broker wird entweder als Container per Portainer auf dem TWS installiert oder ist auf einen anderen Geräte wie NAS oder Server im Heimnetz oder gar als Cloud Service im Internet installiert.

Also wenn du mir irgend einem Script wie Loxberry schon auf MQTT bist und mit einem Broker verbunden, dann brauchst du Comet Visu oder andere nur mit dem bestehenden Broker verbinden und die Daten holen.

Warum ist eigentlich Standartmässig kein MQTT Brocker am TWS?

Ja, Das bedingt aber wider ein zusätzliches Gerät in der Kette

@PeterB
Also der Broker ist nicht in der Grundsoftware enthalten, sondern als Docker Container auf dem Timberwolf zu installieren.

Siehe Anleitung hier

Also kein weiteres Gerät nötig, aber Installation auf Docker des TWS.

Ja das weiß Ich, die Frage war warum er nicht schon in der Grundsoftware enthalten ist?

Natürlich ist da dann noch ein weiteres Gerät notwendig wenn Ich Daten direkt per UDP in den TWS MQTT Docker Brocker bringen möchte, oder kann der das ?

Weil MQT im TWS nicht das Kernsystem ist. Das ist die quasi Objekt Verwaltung und der Dispatcher im TWS.

Wenn der TWS nun noch einen integrierten MQTT Broker bekommt, dann wäre das eine parallele Funktion wie der Dispatcher.

Das "Problem" ist nicht die Konstruktion der Subsysteme und der Dispatcher, sondern das die Visu eben gar kein direktes Subsystem des TWS ist sondern ein eigenes MQTT Subsystem . Dadurch kann man nicht irgendwie Mal direkt sagen KNX Objekt an Visu-Knopf, REST-API Signal an Visu Objekt. Sondern KNX an MQTT und dann in CV eine Verbindung auf das MQTT.

Erst wenn das Thema Visu noch einen Schritt weiter gebaut wird, dann geht es direkter und ggf etwas automatischer.

Hallo Peter,

PeterB hat geschrieben: ↑Mi Feb 23, 2022 9:26 amwenn aber der" UDP In" automatisch im MQTT System angelegt und angezeigt wird erspart man sich an haufen Arbeit und vom MQTT kann Ichs ganz einfach hinsenden wo ich will mit nur einem Klick an KNX z.B. wenn der KNX Ausgang schon angelegt ist.

Der Timberwolf Server ist ein Multi-MQTT-Client. Er kann mir beliebig bielen MQTT Brokern betrieben werden und entsprechend beliebig viele MQTT Universen aufspannen. Mithin kann er auch zwischen mehreren MQTT Universen übersetzen.

Eine Automatik, dass ein UDP In (oder auch was anderes) direkt in MQTT landet ist damit schwierig, eben weil es mehrere sein können.

Worüber man nachdenken kann, dass es einen Haken gibt "zur Visu" und man dann darüber leicht die Werte in der Visu hat (wie auch immer diese angebunden ist).

PeterB hat geschrieben: ↑Mi Feb 23, 2022 9:26 amIch schick von irgendwo fwrite($socket, "publish RPI/Wetterstation/AusenTemp $Var1") an den TWS und kann in der Visu mit PI/Wetterstation/AusenTemp den Wert abgreifen ohne nur einen Klick im TWS

ich verstehe das schon. Aber der nächste will das dann auch mit 1-Wire und eine anderer mit Modbus. Nun kann man am Timberwolf viele hundert 1-Wire Sensoren anschließen und hunderte Modbus Geräte mit tausenden Register (wir haben ein Modbus Profil einer Siemens Wärmepumpensteuerung, da hat EINE Steuerung schon 2000 Register). Das alles dann jeweils automatisch an die Visu senden? Da ist man dann schnell an der Grenze des handhabbaren. Solche Automatiken würden nur für kleine beschränkte Anlagen genutzt. Der Timberwolf Server wurde durchaus für größeres entworfen.

PeterB hat geschrieben: ↑Mi Feb 23, 2022 12:01 pmJa das weiß Ich, die Frage war warum er nicht schon in der Grundsoftware enthalten ist?

Es ist deshalb kein MQTT Broker in der Grundsoftware enthalten, weil der Aufwand dafür in einem schlechten Verhältnis zum Gewinn für den Kunden steht. Kurz, wir können in der gleichen Zeit andere, wertvollere Software für den Kunden entwickeln.

Der TWS ist ein Multi-MQTT-Client und kann mit beliebig vielen Brokern (und wir empfehlen auch durchaus den Einsatz mehrerer Broker zur Trennung von Systemen). Da hilft ein einzelner lokaler Broker nicht.

Wie im Wiki gezeigt, dauert die Installation eines normalen Brokers unter drei Minuten in Portainer und ist schnell erledigt. Viele Kunden berichten auch, dass sie einen eigenen (oder anderen) Broker benutzen wollen.

Da der Bedarf eher gering erscheint und der Aufwand (auch inkl. Support über zehn oder mehr Jahre aufwändig ist) haben wir bislang entschieden, auf einen lokal vorinstallierten Broker im TWS zu verzichten.

lg

Stefan

StefanW hat geschrieben: ↑Fr Feb 25, 2022 8:19 am Wie im Wiki gezeigt, dauert die Installation eines normalen Brokers unter drei Minuten in Portainer und ist schnell erledigt. Viele Kunden berichten auch, dass sie einen eigenen (oder anderen) Broker benutzen wollen.

Da der Bedarf eher gering erscheint und der Aufwand (auch inkl. Support über zehn oder mehr Jahre aufwändig ist) haben wir bislang entschieden, auf einen lokal vorinstallierten Broker im TWS zu verzichten.

Sehe ich auch als Richtig und Sinnvoll an. Da könnt ihr wirklich eher die Funktionen des MQTT Clients oder anderer Module ausbauen.