ElabNET Technik Forum

Neues gibt es nicht, der Zustand ist weiterhin: in der aktuellen Entwicklungsversion ist es enthalten und die wesentlichen Funktionen sind gegen einen extra Broker in einem Docker getestet. Wer weiß was er tut kann das direkt auch so nutzen - für eine allgemeine Anwendung reicht es aber noch nicht, da aus Komfort-Gründen unbedingt die Websocket-Kompatibilität im TWS Proxy benötigt wird.
(Der Browser weiß, dass die CometVisu über HTTPS übertragen wird, also muss der Websocket auch Secure kommen. Also muss man dem Broker und dem Browser entsprechende Zertifikate beibringen. Oder den Browser für die Tests dazu bringen auf die Sicherheit zu verzichten. Alles unschön.)

Für weitere Tests und dann dass offizielle Announcement warte ich daher auf die Websocket-Unterstützung im TWS Web Proxy.

Nachtrag:

Alternativ geht natürlich auch, dass der TWS "native" Broker über TLS geschützte Websockets erreichbar ist.
(Das dürfte vermutlich sogar die bessere und kundenfreundlichere Lösung sein)

Hallo Chris,

Chris M. hat geschrieben: ↑So Aug 29, 2021 7:22 pmAlternativ geht natürlich auch, dass der TWS "native" Broker über TLS geschützte Websockets erreichbar ist. (Das dürfte vermutlich sogar die bessere und kundenfreundlichere Lösung sein)

Das hört sich auch entwicklerfreundlicher an, weil die regelmäßige Zertifikatserneuerung für TLS funktioniert ja seit längerem einwandfrei, für den Broker müssten wir das erst noch einbauen.

Danke für den Hinweis

lg

Stefan

@Chris M.
Alles klar. Dann schauen wir mal wenn wir den ersten Test machen können.

Da ich bald eine Comet Visu aufbauen kann, da ich bald einen weiteren TWS als Desktop Variante haben werde, wollte ich nochmal zum Stand der Dinge hier nachfragen.

Zielstellung ist dabei die Daten vom TWS 950 per MQTT an den neuen TWS [Broker im Docker] zu senden und auf dem neuen TWS auch die Comet Visu laufen zulassen.

@StefanW @Chris M. Ich kenne leider nicht den aktuellen Stand daher eine bitte an euch diesem mitzuteilen. Danke euch.

@Sun1453 es ist unverändert so, dass die CV einen Broker braucht, der auf die gleiche Verschlüsselungs-Art wie der Web-Server zu erreichen ist. D.h. bei direktem Zugriff auf die CV sollte der integrierte Broker reichen - hier beschränkt der Browser aber die Funktionen der CV.
Der daher empfolene Zugriff auf die CV setzt den TWS-Proxy zwischen CV und Browser, wodurch der Zugriff auf die CV über HTTPS läuft, also verschlüsselt. Dadurch braucht die CV aber eben auch einen Zugriff auf verschlüsselte Websockets.

Hallo Chris,

alles klar und danke für deine Antwort.

Hallo Stefan,

Wie sieht es mit der Umsetzung der verschlüsselte Websockets seitens euch aus. Habt ihr euch mit dem Thema schon beschäftigen können?

Sorry Michael,

ich habe derzeit keine Zeit um regelmäßige Wasserstandsmeldungen zu allen Vorhaben abzugeben.

Wir wissen von dem Thema und versuchen alles so schnell zu erreichen wie möglich.


Stefan

Chris M. hat geschrieben: ↑Di Mär 02, 2021 8:09 pm Aktuell implementiert sind Nachrichten die als Zahl, String oder JSON vorliegen (JSON macht eigentlich nur lesend Sinn). Außerdem kann beim Senden der QOS und das Reatain-Flag gesetzt werden.

Lieber spät als gar nicht: JSON schreibend benötigt man z.B. wenn man einen Tasmota-IR-Sender zur Steuerung von Klimanlagen benutzt. Da gibt es einen speziellen Nachrichtentyp IRhvac, der JSON-Eingabe bekommt, z.B.

Ich hab's jetzt nicht ausprobiert ob's geht: evtl. kann man aber das ganze auch als transform "MQTT:string" (oder gar als "raw"?) versenden und es kommt dann als JSON an.
Zusammen mit einem Mapping könnte ich mir das dann auch sehr praktikabel vorstellen.

Das geht aber nur so lange gut, wie in dem JSON halt nur ein Wert "dynamisch" geändert werden muss. Bei mehreren schlägt dann sehr bald der Fluch der Dimensionen zu.
Also wenn man ein RGB JSON wie {"r":100,"g":100,"b":100} dynamisch erzeugen möchte. Aber deshalb hab ich auch die ganzen Farben schon als fertigen transform eingebaut