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