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] UMFRAGE: Welche beiden Leistungsmerkmale als nächstes

Eure Wünsche und Phantasien
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

Was wünscht Ihr Euch für die nächsten Leistungsmerkmale (Max. zwei Antworten)

Umfrage endete am Sa Jun 19, 2021 6:30 pm

Modbus als Server ("Slave", kann damit andere Modbus Geräte emulieren und damit auch aktives Gateway sein)
2
1%
MQTT Client (inkl MQTT Broker)
52
28%
UDP / TCP (für Datenaustausch mit anderen Servern / SPS usw)
15
8%
Web-API / Rest-API (Datenaustausch über Web-Schnittstellen)
25
13%
DMX (als Objektsystem und nutzbar auch mit Desktop-Server)
20
11%
Timberwolf Lighting Enginge (Mutli-Protokoll Licht Szenencontoller)
22
12%
Zeitschaltuhr (einfach einstellbar)
38
20%
IFTTT Cloudintegration
0
Keine Stimmen
Amazon Echo ("Alexa")
8
4%
Apple Homekit ("Siri")
7
4%
 
Insgesamt abgegebene Stimmen: 189


Smart Jeanie
Reactions:
Beiträge: 64
Registriert: Mo Sep 10, 2018 3:10 pm
Hat sich bedankt: 92 Mal
Danksagung erhalten: 68 Mal

#51

Beitrag von Smart Jeanie »

Nachdem ich mich via Modbus mit den wichtigsten Geräten im Haus werde unterhalten können (nochmals danke dafür), ist das letzte große Gewerk das Thema LICHT.

Die geplante Licht-Installation besteht aus Leuchten an DALI-Lichtschienen und weiteren (dimmbaren) Leuchten, die mit verschiedenen Spannungen angefahren werden.
Ich kann derzeit noch nicht erkennen, ob und wie ich den TWS einsetzen kann, um die entstehende Lichtinstallation schlank und flach zu halten, in dem ich mir z.B. Steuereinheiten und Gateways ersparen könnte.

Deshalb weiß gerade auch nicht, für welches Feature ich jetzt stimmen müsste - vermutlich die Light Engine. Ich würde mir jedoch wünschen, dass die neuen Features zunächst bestehende Lücken in der Gebäudetechnik schließen. Ob ich den Modbus Server benötige, kann ich derzeit auch noch nicht beurteilen.
Für mich liegt der Fokus meines TWS ganz klar im Immobilien-Management (fest verbaute Technik) und weniger im Mobilien-Management (Stereoanlagen, Reciever, Rasenmäher etc.). Sprachsteuerung des Gebäudes kann ich mir auch gut vorstellen. Für mich kommt jedoch nur eine offline-fähige Umsetzung in Frage oder eine, hinter der keine große Datenkrake steckt.
Markus

TWS 950Q #268, Software-Stand V3.5x, nicht in Verwendung

benzcity
Reactions:
Beiträge: 102
Registriert: Mi Mär 06, 2019 10:26 pm
Wohnort: Grafenau
Hat sich bedankt: 87 Mal
Danksagung erhalten: 73 Mal

#52

Beitrag von benzcity »

Ich hab mich für DMX und Lighting Engine entschieden weil das damals die Funktionen waren die mich zum Kauf bewegt haben.
Das jetzt auch so langsam die LED Stripes alle in die Lichtvouten kommen wäre es schön die von Anfang an auch voll steuern zu können.
Grüße Björn
TWS950, timberwolf320, VPN offen, Reboot erlaubt -> Wolf momentan nicht online

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

#53

Beitrag von StefanW »

Verehrte Foristen,

vielen lieben Dank für Eure Rückmeldungen, hier ein paar Anmerkungen dazu:

1. TWS als Modbus Server (aka "Slave")

Wir sind erstaunt, dass nun für das Leistungsmerkmal des TWS als Modbus Server so wenig Interesse gibt, weil in der Diskussion bisher hatte sich das anders angefühlt.

Der Sinn und Zweck dieses Leistungsmerkmales ist, dass der TWS damit - auf Basis der Profile - jedes andere Modbus Gerät emulieren kann. Damit ist es möglich, den Timberwolf Server als "Man in the middle" zwischen andere - über Modbus direkt miteinander kommunizierende Geräte - zu schalten. Zum einen um den Datenverkehr aufzunehmen und über das Objektsystem zu nutzen und zum anderen um den Datenverkehr zu beeinflussen.

Ein Anwendungsfall dafür ist (Umgehung) der 70% Drosselung des Wechselrichters durch den Zähler. Wenn man nun bei vollen Sonnenschein die 100% nutzen möchte, dann muss man in die gesetzlich vorgeschriebene Begrenzung eingreifen in der Gestalt, dass man die 30% anderweitig im Haus nutzt (selbstverständlich muss man die Kappung auf 70% gegenüber dem Netz einhalten). Man könnte also ein Heizschwert zuschalten, die Waschmaschine starten oder die Tiefkühltruhe in der Mittagszeit entsprechend dem möglichen Ertrag anschalten. Damit ließe sich erzeugte Energie besser benutzen, anstatt die erzeugen Elektronen ungenutzt zu lassen.

Entweder diese Möglichkeiten wurden noch nicht verstanden oder werden tatsächlich nicht benötigt?


2. Einsatz von MQTT

Ich möchte noch darauf hinweisen, dass MQTT nicht nur die Ansteuerung von Geräten oder der Kommunikation mir Node Red und co dienen soll, sondern es dient auch zur Kopplung von mehreren Timberwolf Servern untereinander.

Unter anderem wird damit die Weltenkopplung mehrerer KNX Installationen (oder 1-Wire oder einfach alles was unterstützt wird) über beliebige IP-Datennetze möglich. Das ist ein wichtiger Einsatzbereich, weil bislang kosteten KNX Gateways zur Weltenkopplung mehrere tausend Euro - pro Seite.


3. UDP / TCP für Ansteuerung von Mediensteuerungen

Es wurde mehrmals der Wunsch geäußert, dass man mit dem Leistungsmerkmal UDP / TCP den Wunsch äußert, das damit Mediengeräte (AV Verstärker usw.) angesteuert werden können.

Ich glaube hier liegt ein Missverständnis vor. Praktisch JEDE IP-Kommunikation (von VPNs mal abgesehen) basiert auf UDP / TCP. Nur weil man den ein oder anderen AV Receiver via IP ansprechen kann, bedeutet das nicht, dass mit dem Transportprotokoll auch das spezifische Protokoll der Hersteller oder gar die Logik-Abhängigkeiten der Geräte unterstützt werden können.

Wenn wir von UDP / TCP sprechen, dann meinen wir den in der M2M-Kommunikation üblichen Datenaustausch über sehr einfach geformte Datenpakete die per UDP / TCP versendet werden und zumeist als String oder auch Binär kodiert sind. Dies beinhaltet nicht, dass ein über UDP / TCP transportiertes Protokoll wie Telnet, REST-API usw. unterstützt wird.

Für REST-API haben wir ein eigenes Modul vorgesehen.

Die Unterstützung von AV Receivern ist vermutlich recht speziell. Man müsste das näher analysieren, aber ich wäre nicht überrascht, wenn es hier keinen einfachen generischen Ansatz gibt diese anzusteuern, zumal hier eher komplexere State-Machines zur Anwendung kommen müssen, weil Befehle in einer bestimmten Reihenfolge und mit zeitlichem Abstand abgeschossen werden müssen. Das ist dann für jeden Hersteller unterschiedlich zu handhaben. Ich denke, hier wird man noch untersuchen müssen, wie das gehandhabt werden kann.

Eine unserer Ideen ist, dass wir - ähnlich wie beim WireGate Plugin Container - einen Timberwolf Plugin Container zur Verfügung stellen, der einen MQTT-Client und eine Python-Umgebung (nebst Beispielen) zur Verfügung stellen. Womöglich auch in einer sehr austauschbaren Weise (wie beim Export / Import von Modbus Geräte Definitionen) im App Manager, so dass eine Version für Receiver X über den App-Manager auf Knopfdruck installiert werden kann und MQTT-Objekte zur Verfügung stellt. Weil dann kann die Community sich hier leicht selbst helfen (so wie das bei HS- oder Edomi-Bausteinen der Fall ist).

Smart Jeanie hat geschrieben: Mi Mär 24, 2021 11:09 amFür mich liegt der Fokus meines TWS ganz klar im Immobilien-Management (fest verbaute Technik) und weniger im Mobilien-Management (Stereoanlagen, Reciever, Rasenmäher etc.).
Richtig, das ist auch die Richtung die wir gehen wollen. Generische Unterstützung von vielen Protokollen mit ultraleichter Verkknüpfbarkeit, darauf logische Funktionen und alle Spezialitäten in APPs.

Robosoc hat geschrieben: Mi Mär 24, 2021 6:21 amViele schreiben hier, dass die ZSU auch von der Frau bzw. der Familie bedienbar sein soll - und so wäre es auch mein Wunsch. Das ist für mich ein Grund, warum ich den am Liebsten in der Visu haben wollen würde und das ist in meinem Fall die CometVisu. Um solche Sachen umzusetzen habe ich mir MQTT als Datenaustauschschnittstelle zwischen TWS und Visu gewünscht. Ich würde meiner Familie ungern Zugriff auf die TWS Oberfläche ermöglichen. Die Visu bedient aber ohnehin Jeder und meines Erachtens gehört die Einstellung einer einfachen ZSU auch sowieso in die Visu.
Was GENAU gehört in die Visu? Die Einstellmöglichkeit oder die Engine, welche das Ereignis dann auch ausführt? Soll die VISU zum eingestellten Zeitpunkt das Ereignis auslösen? Läuft die Visu dann auch rund um die Uhr? Oder soll der TWS die Events auslösen, aber von der Visu fernbedient werden?


lg

Stefan
Zuletzt geändert von StefanW am Fr Mär 26, 2021 5:34 pm, insgesamt 1-mal geändert.
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.

Robosoc
Reactions:
Beiträge: 1876
Registriert: Di Okt 09, 2018 9:26 am
Hat sich bedankt: 635 Mal
Danksagung erhalten: 775 Mal

#54

Beitrag von Robosoc »

Ich habe zur ZSU mal eine eigene Diskussion aufgemacht. viewtopic.php?f=9&t=2769
Ähnlich wie wir das ja auch schon zur NAchrichtenzentrale habe.
VG, Sven - TWS 950Q ID:335 & 291, VPN offen, Reboot OK

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

#55

Beitrag von gbglace »

StefanW hat geschrieben: Fr Mär 26, 2021 5:34 pm
Entweder diese Möglichkeiten wurden noch nicht verstanden oder werden tatsächlich nicht benötigt?
Ich denke das haben einige nicht verstanden, warum da diese andere Stufe der Modbus-Kommunikation notwendig ist. Ich allerdings auch nicht.

Gerade das Beispiel mit den Schwellwertauswertungen denke ich geht auch derzeit. Die diversen Zustandsdaten kommen in den TWS rein. Auswertung und Logik liegt im LE. Die zu steuernden Geräte, die aber selbst keine Logik dafür haben, müssen ja beschreibbare Register haben um so ein Heizschwert in der Heizung zu aktivieren. Dieser Informationskanal ist ja dann doch auch mit der aktuellen (Ok nächste IP-Version) gegeben.
Wechselrichter + Stromzähler >> TWS DOS
Temperaturen Wasserspeicher >> TWS DOS

TWS-DOS >> LE >> TWS-DOS >> Heizung schalte Heizschwert an


StefanW hat geschrieben: Fr Mär 26, 2021 5:34 pm Unter anderem wird damit die Weltenkopplung mehrerer KNX Installationen

Sicher nicht für alle EFH Privat-User relevant, aber für die Verwaltung Ferienwohnung usw. nicht schlecht. Gewerbeobjekte auch nicht schlecht.
Mit Sicherheit auch ne Menge Klickerei um alle Objekte anzulegen aber wozu bezahlt man da die Integratoren...
StefanW hat geschrieben: Fr Mär 26, 2021 5:34 pm Wenn wir von UDP / TCP sprechen, dann meinen wir den in der M2M-Kommunikation üblichen Datenaustausch über sehr einfach geformte Datenpakete die per UDP / TCP versendet werden und zumeist als String oder auch Binär kodiert sind. Dies beinhaltet nicht, dass ein über UDP / TCP transportiertes Protokoll wie Telnet, REST-API usw. unterstützt wird.
Wenn ich ehrlich bin habe ich da nicht viel mehr erwartet.
Ein Objekt mit Ziel-IP-Adresse und hinterlegtem String, in dem die ein oder andere Variable die formatiert eingefügt werden kann und mit dem DOS verknüpft. dann ein paar definierte Sendebedingungen. Ich denke viel mehr ist das was die anderen Bausteine bieten auch nicht.

SO kommt ein Quasi KNX-Dimmbefehl ren geht auf einen solches Objekt als Variable Lautstärke und dann geht das per TCP String raus und der AV-Reciever macht dann lauter.

Die ganzen Strings muss man dann schon selbst zusammentippen.

Das kommt dann eigentlich schon dem Prinzip recht nahe wie wir da mal über die Nachrichtenzentrale geschrieben haben. Da ging es auch nur darum Kanäle (hier die TCP / und Ziel-IP-Adresse) und Nachrichten Texte (fixe Textbausteine angereichert um Variablen) zu generieren und loszuschicken.

Eine andere Sache wären halt so ganze Funktionsbausteinmodule Denon-AV-Reciever XY. Da würden dann in einem Baustein die diversen Befehle alle drinenn angelegt werden und man bekommt eine fertige Liste an adaptierbaren KO für den DOS und im Menü noch die Ziel-IP des Recievers. Ja das wäre auch was, wäre aber wohl auch nur eine Zusammenfassung von oben skizzierten Szenarios.

Rückmeldungen vom Reciever wären ja ähnlich des MQTT wohl auch nur eingehende Texttelegramme die dann geparst werden müssen und die Einzelteile dann je Objektdefinition an den DOS gereicht werden.

Womöglich habe ich da auch nur nicht genügend technisches Wissen, aber das Prinzip scheint mir alles sehr ähnlich.
Zuletzt geändert von gbglace am Fr Mär 26, 2021 6:34 pm, insgesamt 2-mal geändert.
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

tger977
Reactions:
Beiträge: 740
Registriert: So Aug 12, 2018 9:25 am
Hat sich bedankt: 205 Mal
Danksagung erhalten: 274 Mal

#56

Beitrag von tger977 »

StefanW hat geschrieben: Fr Mär 26, 2021 5:34 pm 1. TWS als Modbus Server (aka "Slave")

Ein Anwendungsfall dafür ist (Umgehung) der 70% Drosselung des Wechselrichters durch den Zähler. Wenn man nun bei vollen Sonnenschein die 100% nutzen möchte, dann muss man in die gesetzlich vorgeschriebene Begrenzung eingreifen in der Gestalt, dass man die 30% anderweitig im Haus nutzt (selbstverständlich muss man die Kappung auf 70% gegenüber dem Netz einhalten). Man könnte also ein Heizschwert zuschalten, die Waschmaschine starten oder die Tiefkühltruhe in der Mittagszeit entsprechend dem möglichen Ertrag anschalten. Damit ließe sich erzeugte Energie besser benutzen, anstatt die erzeugen Elektronen ungenutzt zu lassen.

Entweder diese Möglichkeiten wurden noch nicht verstanden oder werden tatsächlich nicht benötigt?
Das Zuschalten der Verbraucher geht ja über Modbus Client Leistungsermittlung schon. Vielmehr ging es um die Emulation des nötigen Zählers der dann die dyn. Einspeisebegrenzung bei 70% überhaupt erst ermöglicht. Also ein Ersatz des heute zusätzlich zum Hauszähler nötigen Zählers für den PV-Wechselrichter (da wird dann im Prinzip mit zwei Zählern dasselbe gemessen, heute gibt es nur leider keine direkten EVU Zähler die auch mit einer PV-Anlage direkt sprechen können...) über eine TW Emulation. Damit wird eben wenn man kein Zusatzverbrauch hat oder zuschalten kann trotzdem bei 70% Leistung abgeregelt, wenn jedoch zus. Hausverbrauch anliegt wird eben dieser dyn. Leistungsüberschuss über die 70% hinaus "freigegeben" für zus. PV-Produktion.

Warum habe ich trotzdem nicht dafür gevotet:
- MQTT, DMX, Alexa hat für mich einfach noch höhere Prio/Nutzen und man konnte ja nur 2 Stimmen abgeben...
- Vermutlich benötigt man für die Emulation und Anbindung an den TW wieder Modbus RTU (ich glaube nicht das es über TCP gehen wird, wenn es jemand besser weiß laßt es mich wissen) und damit würde ich dann doch wieder die Modbus Extension die ja auch nicht gerade billig ist benötigen. Das rechnet sich nur für die Zähleremulation dann in keinster weise, da ein Modbus Zähler in ähnlicher Preisdimension liegt. Ich habe ansonsten einfach kein Modbus RTU Anwendungsfall.
Gruß
Andi

TW2500 #440 (ex Timberwolf 2400 #111) mit PBM #124, Support VPN nur auf Anfrage, Reboot bitte nur nach Absprache

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

#57

Beitrag von gbglace »

Ahh, es wird klarer.

Aber da es vermutlich noch einige Jahre dauern wird bis die ganzen Modbusgeräte sich untereinander verstehen werden können, was mir in Anbetracht der teilweise kreativen Datenformate illusorisch erscheint. Sehe ich da auch noch keine Prio drinnen.
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

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

#58

Beitrag von Sun1453 »

Wenn man etwas in Sachen UDP / TCP umsetzten möchte, dann sollte es so in diesem Format sein:

Link

Adresse eintragen
Virtuelle Befehle einfügen
Virtuelle Befehle eingeben

Auch einfach diese Eingabewerte verwenden wie hier.

Hmm was mir auffällt, die haben jetzt auch eine Verbindung zum eKey System bei Loxone.
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 |

eChris
Reactions:
Beiträge: 35
Registriert: Mo Feb 15, 2021 3:29 pm
Wohnort: Raum Köln-Bonn
Hat sich bedankt: 50 Mal
Danksagung erhalten: 8 Mal

#59

Beitrag von eChris »

StefanW hat geschrieben: Fr Mär 26, 2021 5:34 pm Ein Anwendungsfall dafür ist (Umgehung) der 70% Drosselung des Wechselrichters durch den Zähler. Wenn man nun bei vollen Sonnenschein die 100% nutzen möchte, dann muss man in die gesetzlich vorgeschriebene Begrenzung eingreifen in der Gestalt, dass man die 30% anderweitig im Haus nutzt (selbstverständlich muss man die Kappung auf 70% gegenüber dem Netz einhalten). Man könnte also ein Heizschwert zuschalten, die Waschmaschine starten oder die Tiefkühltruhe in der Mittagszeit entsprechend dem möglichen Ertrag anschalten. Damit ließe sich erzeugte Energie besser benutzen, anstatt die erzeugen Elektronen ungenutzt zu lassen.

Entweder diese Möglichkeiten wurden noch nicht verstanden oder werden tatsächlich nicht benötigt?
Also bei mir wäre das dann in der Tat mangelnde Klarheit, was die Möglichkeiten eines solchen Features betrifft. Was Du da beschreibst, klingt in der Tat super, war mir aber so nicht klar. Ich wüsste allerdings auch nicht, wie ich das dann konkret umsetzen müsste. Allerdings scheint es so zu sein, dass der Wechselrichter im Bestandsbau sich wahrscheinlich nicht über Modbus ansteuern lässt :( Für den Augenblick scheint unsere Wärmepumpe das einzige Gerät zu sein, das über eine Modbus-Schnittstelle im WPM angesteuert werden kann. Und da reicht, wenn ich mich nicht irre, Modbus als Client.
Wenn wir von UDP / TCP sprechen, dann meinen wir den in der M2M-Kommunikation üblichen Datenaustausch über sehr einfach geformte Datenpakete die per UDP / TCP versendet werden und zumeist als String oder auch Binär kodiert sind. Dies beinhaltet nicht, dass ein über UDP / TCP transportiertes Protokoll wie Telnet, REST-API usw. unterstützt wird.
Ich denke, mehr kann man an dieser Stelle auch nicht erwarten. Alles Weitere muss der einzelne Nutzer oder die Community erledigen.
Was GENAU gehört in die Visu? Die Einstellmöglichkeit oder die Engine, welche das Ereignis dann auch ausführt? Soll die VISU zum eingestellten Zeitpunkt das Ereignis auslösen? Läuft die Visu dann auch rund um die Uhr? Oder soll der TWS die Events auslösen, aber von der Visu fernbedient werden?
Ich würde nicht wollen, dass die ZSU in irgendeiner Form an eine Visu gebunden wird. Denn dann ist man darauf festgelegt und wenn man eine andere Visu nutzt, ist der Mehrwert ggf. weg. Die ZSU sollte entweder über die LE realisiert werden oder einen Datenaustausch über MQTT erlauben, so dass man flexibel in der Bedienung ist. Wenn es allerdings die Möglichkeit gibt, dass sich ein Nutzer auf dem TWS einloggt und z.B. nur Zugriff auf eine einfach zu bedienende ZSU hat, dann wäre das für mich auch vollkommen in Ordnung.
Viele Grüße,
Christian
_________________________________________________
>>>TWS 2500S Raspberry Violet & PBM(bestellt) <<<
Benutzeravatar

Zugschlus
Reactions:
Beiträge: 345
Registriert: Di Okt 02, 2018 4:28 pm
Wohnort: St. Ilgen, Baden-Württemberg
Hat sich bedankt: 112 Mal
Danksagung erhalten: 82 Mal
Kontaktdaten:

#60

Beitrag von Zugschlus »

Ich hätte gerne MQTT und/oder UDP:

(1)
Um meine Gosund-Tasmota-WLAN-Steckdosen aus dem TWS/über KNX bedienen zu können. Wunsch wäre, ein KNX-Schaltobjekt mit einem MQTT-Topic verbinden zu können: Wenn eine 1 auf einer mit dem Schaltobjekt verbundenen GA empfangen wird, soll eine 1 an das MQTT-Topic, gehen, bei einer Null eben eine 0. Ein weiterer Wunsch wäre, die Leistungsaufnahme und den "Stromzähler", den die Gosunds über MQTT veröffentlichen an ein KNX-Zählerobjekt weiterleiten zu können, um dieselben Aktionen ausführen zu können wie bei einem Aktor mit Stromzählfunktion (z.B. dem MDT AMS). Das würde ich dann gerne nutzen, um z.B. bei "Waschmaschine braucht keinen Strom mehr" eine "Fertig"-Nachricht per Telegram verschicken zu können.

(2)
Um meine Stromzähler, die im Moment mit Volkszähler ausgelesen werden, auch in den Timberwolf hineinzubekommen (hauptsächlich für Grafana). Den vzlogger kann ich gerne weiterhin benutzen.
--
Marc Haber, St. Ilgen. Freier IT-Berater, Debian Developer.
TWS 950Q #326, VPN auf Anfrage - KNX, 1Wire (13/55/54 Slaves), MQTT, Cometvisu, viel Grafana, ganz ein bisschen Logik.
Antworten

Zurück zu „Feature Requests & Diskussionen Timberwolf Allgemein“