ElabNET Technik Forum

Hallo Chris,

Chris M. hat geschrieben: ↑Mi Mär 31, 2021 4:46 pmDer TWS sollte einen Broker mitbringen, dieser per Web-Sockets (ws://...) und v.a. auch per Secure Web Sockets (wss://...) unter Verwendung des TWS-Zertifikats erreichbar sein.

Danke, guter Hinweis auf die zusätzliche Web-Sockets-Schnittstelle, wird berücksichtigt

Frage 1: Wie kommt die Cometvisu an die Influx-Daten, bleibt hier der bisherige Weg?

Im Moment denken wir an den Mosquitto als Broker, muss das noch hinsichtlich Web-Sockets prüfen, aber nehme an, dass der das auch kann. Es wäre interessant zu wissen, mit welchen Broker Ihr die Tests macht?

Frage 2: Ist die Version MQTT 3.1 ausreichend für die CV?

Chris M. hat geschrieben: ↑Mi Mär 31, 2021 4:46 pmAber eigentlich sehe ich MQTT wesentlich wichtiger im Bereich, den TWS für weitere Kundenschichten attraktiv zu machen, welche die kein KNX haben aber endlich eine extrem stabile Basis für die Heimautomatisierung wollen (und nicht die ständig abrauchenden SD-Karten am RPi)

Siehst Du da wirklich einen Markt? Weil RaspI und SD-Karten sind billig, eine stabile Appliance kann bei den Makern nie konkurrieren

lg

Stefan

StefanW hat geschrieben: ↑Mi Mär 31, 2021 8:19 pm Frage 1: Wie kommt die Cometvisu an die Influx-Daten, bleibt hier der bisherige Weg?

Ja, die MQTT Schnittstelle ersetzt nur die KNX Kommunikation (den "CometVisu Client" um technisch exakt zu sein), weitere Kommunikation, wie die zu Influx, bleibt wie sie ist.

StefanW hat geschrieben: ↑Mi Mär 31, 2021 8:19 pm Im Moment denken wir an den Mosquitto als Broker, muss das noch hinsichtlich Web-Sockets prüfen, aber nehme an, dass der das auch kann. Es wäre interessant zu wissen, mit welchen Broker Ihr die Tests macht?

Frage 2: Ist die Version MQTT 3.1 ausreichend für die CV?

Die Tests laufen mit dem aktuellen Mosquitto Docker-Container (eclipse-mosquitto:latest). Ja, der kann WebSockets. Ja, 3.1 ist ausreichend.
Die von der CometVisu interne MQTT Bibliothek ist übrigens Paho, falls das von Interesse ist.

StefanW hat geschrieben: ↑Mi Mär 31, 2021 8:19 pm

Chris M. hat geschrieben: ↑Mi Mär 31, 2021 4:46 pmAber eigentlich sehe ich MQTT wesentlich wichtiger im Bereich, den TWS für weitere Kundenschichten attraktiv zu machen, welche die kein KNX haben aber endlich eine extrem stabile Basis für die Heimautomatisierung wollen (und nicht die ständig abrauchenden SD-Karten am RPi)

Siehst Du da wirklich einen Markt? Weil RaspI und SD-Karten sind billig, eine stabile Appliance kann bei den Makern nie konkurrieren

Nicht für den ersten Kontakt. Aber wenn die Karte 2-3x abgeraucht ist kann ich mir schon vorstellen, dass das Interesse steigt. Und per Foren-Beiträge dürfte sich dann hoffentlich auch bei Neueinsteigern rumsprechen, dass eine stabile Appliance langfristig besser ist und somit mehr Zeit für den Spaß (die Automatisierung) lässt, in dem das nervige (System-Administration) und gefährliche (WAF) bei einer eigenen Bastel-Lösung vermieden wird.

Das gilt sicher nicht für 100% der Maker, aber ein paar dürfte es schon überzeugen

Es gibt im KNX-UF diverse Threads mit Beiträgen wo Bastler dann doch irgendwann auch mal auf eine gefestigte Umgebung wechseln. Einfach die Wartbarkeit unabhängig der eigenen Person wiegt irgendwann mal schwerer als der Preis für die HW.

Das stimmt. Mich hat auch die stabile Hardware und die gute Software inkl OS mit Wartung vom Hersteller zum Kauf des TWS mitbewogen.

Neben anderen Vorzügen.

Hallo Zusammen,

auch für mich wäre die Licht-Thematik noch ein zentraler Punkt. Ich plane die Beleuchtung im Haus via DMX umzusetzen. Mit den Hutschienen-Modellen ist das ja bereits möglich. Daher könnte ich noch etwas Geduld mitbringen. Wenn's etwas bequemer als mit dem DMX_Test-Modul in der Custom-Logik ginge, wäre das aber vermutlich fehlersicherer (bei so unkonzentrierten Zeitgenossen wir mir).
Wenn ich irgendwann mal dazu komme, wollte ich auch eine stufenweise animierte Treppenbeleuchtung umsetzen. Je nach Möglichkeiten der Light Engine hilft mir diese dabei oder eröffnet sogar noch Features, an die ich bisher noch gar nicht gedacht habe.
Ich könnte noch ein paar Datenblätter zu den von mir eingesetzten DMX-Decodern anhängen, aber wirklich viel hilfreiches für den TWS steht da nicht drin.

Kurz zusammengefasst: Für mich wäre es vorerst "nur" wichtig, wenn sich das DMX-Universum ins Look&Feel des TWS einreiht und so die Einbindung ins Gesamtkonzept vereinfacht. Wenn die DMX-Objekte im DOS dann noch ausfindbar werden, macht es die Fehlersuche vermutlich auch deutlich einfacher.
Zusätzliche Feature (Dimmer, Fader, RDM,...) könnten dann noch warten, zumal sie ja oftmals bereits jetzt schon via (Custom-)Logik umsetzbar sind.

Vielen Dank.
Viele Grüße aus Sachsen.

Tobias

Hallo Stefan,

StefanW hat geschrieben: ↑Fr Mär 26, 2021 5:34 pm 1. TWS als Modbus Server (aka "Slave")
Entweder diese Möglichkeiten wurden noch nicht verstanden oder werden tatsächlich nicht benötigt?

nein war mir nicht bewusst. Gebraucht wird es natürlich, denn ich möchte einen 'Energiemanager' realisieren und WR damit steuern.
Als 'Energiemanager' kann ich mir https://github.com/OpenEMS als Container in Docker vorstellen.
Oder ist angedacht das als Custom Logic zu realisieren?

Dringlicher für mich ist aber MQTT und ZSU.

lg
Klaus