UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[DISKUSSION] [v3.2] UDP IN Future Request

Wissen, Planung & Diskussion zur MQTT Unterstützung im Timberwolf Server.
Stellt uns hier Eure MQTT Projekte und Ideen vor.
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
Benutzeravatar

Ersteller
PeterB
Reactions:
Beiträge: 160
Registriert: Mo Jan 31, 2022 4:21 pm
Hat sich bedankt: 5 Mal
Danksagung erhalten: 35 Mal

[v3.2] UDP IN Future Request

#1

Beitrag von PeterB »

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
Zuletzt geändert von PeterB am Mi Feb 23, 2022 9:26 am, insgesamt 1-mal geändert.
Modellreihe 35xx (3500) Timberwolf ID:695 (3500) vpn aktiv reboot möglich
:angry-banghead: 5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys

Sun1453
Reactions:
Beiträge: 1849
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 1541 Mal
Danksagung erhalten: 788 Mal

#2

Beitrag von Sun1453 »

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.
Zuletzt geändert von Sun1453 am Mi Feb 23, 2022 8:46 am, insgesamt 1-mal geändert.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
Benutzeravatar

Ersteller
PeterB
Reactions:
Beiträge: 160
Registriert: Mo Jan 31, 2022 4:21 pm
Hat sich bedankt: 5 Mal
Danksagung erhalten: 35 Mal

#3

Beitrag von PeterB »

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
Modellreihe 35xx (3500) Timberwolf ID:695 (3500) vpn aktiv reboot möglich
:angry-banghead: 5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys

Sun1453
Reactions:
Beiträge: 1849
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 1541 Mal
Danksagung erhalten: 788 Mal

#4

Beitrag von Sun1453 »

@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.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
Benutzeravatar

Ersteller
PeterB
Reactions:
Beiträge: 160
Registriert: Mo Jan 31, 2022 4:21 pm
Hat sich bedankt: 5 Mal
Danksagung erhalten: 35 Mal

#5

Beitrag von PeterB »

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

Ja, Das bedingt aber wider ein zusätzliches Gerät in der Kette
Modellreihe 35xx (3500) Timberwolf ID:695 (3500) vpn aktiv reboot möglich
:angry-banghead: 5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys

Sun1453
Reactions:
Beiträge: 1849
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 1541 Mal
Danksagung erhalten: 788 Mal

#6

Beitrag von Sun1453 »

@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.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
Benutzeravatar

Ersteller
PeterB
Reactions:
Beiträge: 160
Registriert: Mo Jan 31, 2022 4:21 pm
Hat sich bedankt: 5 Mal
Danksagung erhalten: 35 Mal

#7

Beitrag von PeterB »

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 ?
Modellreihe 35xx (3500) Timberwolf ID:695 (3500) vpn aktiv reboot möglich
:angry-banghead: 5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#8

Beitrag von gbglace »

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.
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

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7632 Mal
Kontaktdaten:

#9

Beitrag von StefanW »

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
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.

Sun1453
Reactions:
Beiträge: 1849
Registriert: Do Feb 07, 2019 8:08 am
Hat sich bedankt: 1541 Mal
Danksagung erhalten: 788 Mal

#10

Beitrag von Sun1453 »

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.
Gruß Michael

Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
Antworten

Zurück zu „MQTT“