Messwerte oder Stati in CometVisu anzeigen?

[netfriend]

Nee, diese Meldung habe ich noch nicht gesehen.
Die Buslast habe ich mittels ETS-Busmonitor geprüft. Die liegt im Normalfall im einstelligen Bereich. Außer CV wird neu gestartet und alle Werte gelesen, dann steigt diese für 1-2 Minuten an und sinkt dann wieder ab. Sieht für mich soweit normal aus.

Gerade kam bei F5 diese Meldung:

Screenshot 2024-12-17 111320.png

beim nächsten F5 ist die Meldung nicht mehr aufgetaucht. Es wurden wieder alle bereits geladenen KNX-Werte entfernt, in der F12-Entwickleransicht sehe ich nun massenweise r?-Kommunikation. Auf dein meisten pages der CV füllen sich die Werte nun wieder.
Auf der ersten Seite jedoch bleiben alle Werte weg und es erscheint diese Meldung:

image.png

[Chris M.]

Die ganzen "r" sind normal - jedes davon ein eines oder mehrere KNX Bus Pakete die an die CV geschickt werden.
Wenn nach etwas Ruhe am Bus auch mal ein abgebrochener kommt, dann ist das auch normal. Da gab's dann einen Time-Out und der bricht den ab um ihn sauber neu zu starten.

Die Meldung so ist leider kaum zu entziffern, da bitte die (wenn sie wieder kommt) als Absturzbericht senden. Dann gibt's da eine Übersetzung für uns wo das wirklich im Code passiert ist

[Chris M.]

Nun würde ich gerne in mein bestehendes visu_config.xml als zweites Backend MQTT aufnehmen. Soweit ich gelesen habe, sollte es mit der CV 0.13.x möglich sein, KNX und MQTT parallel zu nutzen.
Ich habe google befragt, die CV-manual-Seiten gelesen, aber so richtig schlau bin ich nicht geworden. Gibt es hierfür ein Bespiel comet_visu.xml, wo ich mir ansehen kann, wie das prinzipiell funktioniert?

So, hier ein kurzes Beispiel wie das mit der Pure Struktur funktioniert (also für das Pure- oder auch Metal-Design):

<?xml version="1.0" encoding="UTF-8"?>
<pages backend="mqtt,knxd" backend-mqtt-url="wss://timberwolf1234.local/proxy/mqttws/ws" username="test" password="testpw" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" lib_version="9" design="pure" xsi:noNamespaceSchemaLocation="../visu_config.xsd">
  <meta>
    <plugins>
    </plugins>
    <mappings>
    </mappings>
    <stylings>
    </stylings>
    <statusbar>
    </statusbar>
  </meta>
  <page name="Start">
    <switch>
      <label>MQTT switch</label>
      <address transform="MQTT:number" qos="1" retain="true">mqtt/switch</address>
    </switch>
    <switch>
      <label>KNX Switch</label>
      <address transform="DPT:1.001" mode="readwrite">12/7/1</address>
    </switch>
  </page>
</pages>

Hier gibt es aber noch einen Bug, der wird mit diesem Pull Request behoben: https://github.com/CometVisu/CometVisu/pull/1421

Mein Setup (insb. der TWS) hat gerade irgend ein sehr komisches Performance-Problem, so dass ich nur sehr langsam testen kann. Daher kann ich gerade nicht sagen ob und wie das mit den HTTP-Headern, die bei korrekter Docker-Container-Config gesendet werden, noch etwas einfacher konfiguriert werden kann.

[Chris M.]

Ach ja, ob das Backend "knxd" oder "mqtt" für die jeweilige Adresse verwendet wird, wird anhand der Transform entschieden "MQTT:..." -> mqtt und "DPT:..." -> knxd.

Für eine Config der Tile-Struktur läuft das etwas anders, da würde man eher etwas brauchen wie:

      <cv-switch>
        <cv-address slot="address" transform="DPT:1.001" backend="knxd">12/7/1</cv-address>
        <span slot="primaryLabel">Schalter 2 knx</span>
        <span slot="secondaryLabel">Ein/Aus</span>
      </cv-switch>
      <cv-switch>
        <cv-address slot="address" transform="MQTT:number" backend="mqtt">mqtt/switch</cv-address>
        <span slot="primaryLabel">Schalter 1 mqtt</span>
        <span slot="secondaryLabel">Ein/Aus</span>
      </cv-switch>

[netfriend]

Danke für die Beispiele - die werde ich mir die nächsten Tage genauer ansehen und probieren.

Mir ist noch aufgefallen, dass bei F5 immer die Page geleert wird, die gerade offen ist. Alle anderen bleiben mit KNX-Inhalten gefüllt, sogar die Seite die beim letzten Refresh offen war (und geleert wurde) enthält nun wieder Daten (wahrscheinlich die, die im CV-Cache vorhanden sind). Vielleicht hilft Dir das bei der Eingrenzung des Problems weiter.

Wenn die rote Fehlermeldung nochmal kommt, drücke ich auf "Absturzbericht senden".

[Chris M.]

Bei F5 wird die Visu neu geladen. Die Infrastruktur und Config kommt vermutlich aus dem Cache, d.h. die kommt sehr schnell - aber eben nicht instantan. Parallel werden alle KNX Daten abgefragt. Da aber der Container ja nicht neu gestartet wurde sind alle Werte, die gerade noch angezeigt wurden, ja im Chache des knxd.
Daher vermute ich, dass diese Wahrnehmung dadurch kommt, dass die Start-Seite nach dem F5 eben noch nicht die KNX Werte hat, die aber bin zum Seitenwechsel eben dann doch gekommen sind.

Der Fix für die parallele Nutzung vom knxd und MQTT ist jetzt übrigens drinnen und sollte nun wie oben beschrieben funktionieren.

[netfriend]

Die Seite wird nie mehr geladen. Der Container läuft seit ungefähr einer Woche. Die CV ist nicht bedienbar. Weil entweder Werte nicht angezeigt werden oder wenn die Anzeige offenbar normal aussieht (wie z.B. ein Toggle-Button für ein Licht), dieser nicht funktioniert.
Gerade eben habe ich wieder eine Fehlermeldung erhalten. Auf dem Smartphone ist 'Absturzbericht senden" leider nicht im sichtbaren Bereich und ein Scrollen im Fehler-Pop-Up nicht möglich.
Sinngemäß lautete die Meldung:
Cannot Ready property of Null (GetNavbarVisible)

Die Nutzung von MQTT parallel werde ich mir erst ansehen, wenn die CV 0.13.x ebenso funktioniert wie die CV 0.12.6. Diese läuft im Container problemlos schon seit über einem Jahr.

[Chris M.]

Ich habe jetzt extra mit dem aktuellen Testing-Container etwas länger getestet und ich kann das Problem nicht nachstellen.

Vorab: inzwischen sind im Testing ein paar Verbesserungen drinnen, die bei unsauberem/falschen Setup vernünftige Fehlermeldungen ausgeben. Evtl. liegt hier bereits ein Problem das nun aufgedeckt wird?

Aber, Annahme, dass Problem besteht weiterhin. Dann müssen wir hier systematisch vorgehen um die Stelle einzukreisen die wohl nur bei Dir auftritt.
Gut wäre es daher die Seiten immer mit einem angehängten "reportErrors=true" an der URL zu öffnen. Also z.B. https://timberwolf.local/proxy/visut...ortErrors=true wenn es die Default-Config ist, oder https://timberwolf.local/proxy/visut...ortErrors=true bei der Demo-Config. Das gilt für einen Test im Browser wie im Smartphone.

Dann: geht die Demo-Config wie erwartet? Kannst Du die Widgets-Bedienen und geben die auch Werte zurück? (Hinweis: die nutzen alle GAs im Bereich von "12/7/...", d.h. wenn Du diesen Bereich in Deiner Installation nicht nutzt, dann kannst Du bedenkenlos da rum klicken. Wenn es einen Konflikt in der Nutzung gibt könnte es zu ungewollten Effekten bei Dir zu Hause kommen und Du solltest besser darauf verzichten)

[netfriend]

Eigentlich hatte ich vor, über Weihnachten und den Jahreswechsel mir die Sache nochmal genauer anzusehen. Hab ich irgendwie nicht geschafft. Auch aktuell habe ich viel um die Ohren und komme nicht dazu.
Ich melde mich wieder, wenn ich nähere Rückmeldung geben kann.