NEU! UPGRADE IP 10 verfügbar!
Optimierte Darstellung von VISU Editor und VISU Client - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/8HzePCm3
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 IP 10
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
Optimierte Darstellung von VISU Editor und VISU Client - sowie viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/8HzePCm3
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 IP 10
Jetzt werden alle Fragen beantwortet. Das Video: https://youtu.be/_El-zaC2Rrs
[DISKUSSION] [v3.2] UDP IN Future Request
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: 160
- Registriert: Mo Jan 31, 2022 4:21 pm
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 35 Mal
[v3.2] UDP IN Future Request
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
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
5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys
5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys
-
- Reactions:
- Beiträge: 1868
- Registriert: Do Feb 07, 2019 8:08 am
- Hat sich bedankt: 1576 Mal
- Danksagung erhalten: 808 Mal
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.
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 |
Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
-
- Reactions:
- Beiträge: 160
- Registriert: Mo Jan 31, 2022 4:21 pm
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 35 Mal
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
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
5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys
5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys
-
- Reactions:
- Beiträge: 1868
- Registriert: Do Feb 07, 2019 8:08 am
- Hat sich bedankt: 1576 Mal
- Danksagung erhalten: 808 Mal
@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.
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 |
Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
-
- Reactions:
- Beiträge: 160
- Registriert: Mo Jan 31, 2022 4:21 pm
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 35 Mal
Warum ist eigentlich Standartmässig kein MQTT Brocker am TWS?
Ja, Das bedingt aber wider ein zusätzliches Gerät in der Kette
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
5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys
5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys
-
- Reactions:
- Beiträge: 1868
- Registriert: Do Feb 07, 2019 8:08 am
- Hat sich bedankt: 1576 Mal
- Danksagung erhalten: 808 Mal
@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.
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 |
Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |
-
- Reactions:
- Beiträge: 160
- Registriert: Mo Jan 31, 2022 4:21 pm
- Hat sich bedankt: 5 Mal
- Danksagung erhalten: 35 Mal
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 ?
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
5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys
5 Loxone Miniserver im Gateway/Client Verbund, Extensions: RS485, IR, 1-Wire, DMX
5 Loxberrys
-
- Reactions:
- Beiträge: 3611
- Registriert: So Aug 12, 2018 10:20 am
- Hat sich bedankt: 1268 Mal
- Danksagung erhalten: 1674 Mal
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.
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
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
-
- Elaborated Networks
- Reactions:
- Beiträge: 9771
- Registriert: So Aug 12, 2018 9:27 am
- Wohnort: Frauenneuharting
- Hat sich bedankt: 4878 Mal
- Danksagung erhalten: 7802 Mal
- Kontaktdaten:
Hallo Peter,
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).
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
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).
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.
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.
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: 1868
- Registriert: Do Feb 07, 2019 8:08 am
- Hat sich bedankt: 1576 Mal
- Danksagung erhalten: 808 Mal
Sehe ich auch als Richtig und Sinnvoll an. Da könnt ihr wirklich eher die Funktionen des MQTT Clients oder anderer Module ausbauen.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.
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 |
Timberwolf 950 QL #344 | Mit Internetanbindung | VPN Offen | Reboot nach Absprache | PROD Server
Timberwolf 2500 #602 | VPN offen | TEST Server | Reboot nach Absprache |