[Hinweis] Preview CometVisu mit MQTT

[Chris M.]

Die Dauer der RC-Phase richtet sich nach der Rate der gefundenen Probleme. Wenn nichts mehr kommt ist's fertig
Kurzfristig kommt die nächste RC, die mir persönlich auch sehr wichtig ist, da dort endlich die flackernden Icons weg sind.
Ich hoffe, dass die MQTT Themen dann in einer weiteren Schleife durch sind - kann das aber überhaupt nicht einschätzen, da ich kein MQTT nutze. Wenn in dieser Schleife auch noch der Feinschliff an der Doku und den Demo-Configs mit drinnen ist gibt's eigentlich keinen Grund für das fertige Release länger zu warten.

Aber wenn z.B. mit MQTT ein Fass aufgemacht wurde dann kann es sich auch ziehen.

[alexbeer]

Hey, das klingt ja großartig!
Was hat euch zu der Designentscheidung

Es geht immer nur ein Backend. Also entweder KNX oder OpenHAB oder (nun neu) MQTT.

geführt?

Ist für eine spätere Version angedacht, diese Restriktion aufzuheben, um z.B. KNX generell als Backend einzustellen, jedoch für einzelne Widgets ein abweichendes Backend zu definieren?
Ich glaube bei einigen Usern einen ähnlichen Anwendungsfall wie bei mir herausgelesen zu haben:

• Generell ist das Haus per KNX zu steuern und der Status zu visualisieren
• Mit den TWS-Möglichkeiten ist es sehr einfach geworden, KNX um andere Protokolle zu ergänzen - Mal eben einen ZigBee Bewegungsmelder hier, was anderes da.
• Über die HTTP-API ist es mit dem TWS sehr einfach geworden öffentliche Daten (Umweltdaten, Verkehrsprognosen, ...) In den TWS zu holen
• Diese zusätzlichen Daten können sehr einfach via MQTT zu Verfügung gestellt werden
• Wünsch (bei mir) wäre nun, einige dieser MQTT Werte zusätzlich zu den KNX Werten zu visualisieren.
• Den Aufwand alle KNX-Daten per MQTT zu publizieren oder Vice versa finde ich wenig charmant

[Chris M.]

Die Design-Entscheidung ist ganz einfach: das Verhalten war schon immer so.

Grundsätzlich spricht natürlich nichts dagegen mehrere Backend-Verbindungen parallel laufen zu lassen. Aber das ist im Code halt bisher nicht vorgesehen.
Wie groß hier der Änderungsaufwand wäre kann ich aktuell nicht beurteilen, klingt aber nicht nach einem Thema das man schnell noch in die 0.12 reinbastelt. Gerade die Backenend-Kommunikation ist sehr zentral, da darf nichts schief gehen, da muss jede Änderung gut abgesichert sein.

[alexbeer]

Danke für die fixe Rückmeldung.
Ich finde so bemerkenswert, was Tobias und du - und weitere hier über Jahre geleistet habt!
Auf die Schnelle etwas kurz vor Schluss "reinbasteln" wird selten gut. Ich würde mich jedoch freuen, wenn ihr nach dem Release intern diskutiert, ob man die Definition des Backends nicht von <Pages> in alle enthaltenen Widgets vererben könnte und zusätzlich auch abweichende Backends in einzelnen Widgets berücksichtigen könnte.

Ich werde jetzt Mal weiter mit dem RC testen.

[peuter]

Da müssen wir gar nicht mehr so viel abstimmen, weil ich das in "teil-fertig" schon in einem größeren Refactoring der CometVisu schon drin habe. Das wird aber sicher noch einige Monate dauern bis das mal im Haupt-Repository landet und dann in dem dann nächsten Release (also kein Thema für 0.12.x). Grob umrissen, wird das so sein, dass man beliebig viele zusätzliche Backends in seiner Config definieren kann, denen man dann jeweils einen eindeutigen Namen geben muss und dann nur noch in der jeweiligen <address ...name="mqtt"> angeben muss, wenn man nicht das default Backend der Config nutzen möchte. Damit hat man dann alle Freiheitsgrade und könnte theoretisch sogar mehrere MQTT-Backends nutzen

[Robert_Mini]

Hallo zusammen!

Finde die Diskussion sehr gut und freue mich über die Rückmeldung von Tobias!
Alex hat das genau richtig getroffen: meine Visu läuft zu 100% über KNX, manches (vielleicht 5-10%) könnte ohne KNX sein. Umgekehrt macht es wenig Sinn 95% über MQTT an KNX zu senden (+Aufwand).

Danke für euer Engagement
Lg
Robert

[pbm]

Habe für den "nur MQTT" Einsatz auch nicht den Anwendungsfall. Als Ergänzung zum KNX Backend wäre das Top!

Ich vermute, dass das den meisten TWS-Nutern so geht, wie bereits von Alex und Robert beschrieben.

[jensgulow]

@peuter Darüber würde ich mich auch sehr freuen - diese Variante trifft genau meine Anforderungen - und wahrscheinlich auch die der meisten user.

[danik]

Ist bei mir auch so, KNX als Backend und was nicht nativ auf KNX ist dann über MQTT. Würde mich über diese Möglichkeit in Zukunft auch freuen.

Gruss
Dani

[Chris M.]

Mit der 0.12.0-RC7 bzw. nun 0.12.0-RC8 (Announcement kommt gleich; Doku und Docker-Image ist bereits vorhanden) habe ich die Einstellungen für's Backend deutlich überarbeitet. Hiermit sollte es der App nun möglich sein sowohl die KNX als auch die MQTT Verbindung zu konfigurieren:

Wie in https://www.cometvisu.org/CometVisu/de/ ... svariablen beschrieben müssen nur die Docker Environment-Variablen BACKEND_KNXD und BACKEND_MQTT korrekt befüllt werden.
(BACKEND_KNXD ist der Nachfolger von CGI_URL_PATH, welches zwar noch aus Kompatibilitätsgründen funktioniert, aber nicht mehr verwendet werden sollte).
In BACKEND_NAME kann man das zu verwendende Backend eintragen, gerade auch wenn mehrere konfiguriert sind.
In Zukunft (also nach(!) dem 0.12er Release) kann so auch leicht ein Multi-Backend-Setup erzeugt werden.

=> Die 0.12er Version ist mit dem alten Setup kompatibel, bietet aber bereits die Möglichkeit das Setup für die Zukunft fit zu machen.