Messwerte oder Stati in CometVisu anzeigen?

[peuter]

Ändere ich nun meinen Pfad in icons, ist der Fehler weg. Kann ich so lassen, ist halt dann nicht mehr abwärtskompatibel.

Der Pfad hat sich aber schon beim Übergang von 0.11 auf 0.12 geändert

2.) Damit kann ich nichts anfangen:

Kannst Du ignorieren, ist nur eine Warnung, eigentlich eher ein Hinweis.

Inzwischen sehe ich auch die Variablen/Stati/Buttons, also alles vom KNX. Allerdings dauert es mehrere Minuten nach einem Reload.... Bei meinem anderen Raspi mit der CV 0.12.6 (gleiches KNX-IP-Interface) sind es nur wenige Sekunden, wird ja nur refreshed. Hier bei der CV 0.13.x sind manche pages nach dem Reload wieder komplett, manche aber seeeeehr lange nicht. Vielleicht ist aber alles nur so zäh, weil noch was blockiert?

Da kann ich nur mir gefährlichem Halbwissen glänzen (nutze den KNXD selbst nicht), soweit ich weiß merkt der sich den letzten Wert für jede GA, damit er Anfragen schneller beantworten kann. Dazu müssen diese aber während seiner Laufzeit wenigstens einmal gesendet worden sein. Ich weiß nicht ob der einen Read-Request auf den Bus schickt um "die Lücken zu füllen". Es sieht so aus als ob der Cache noch unvollständig ist und deswegen die Seite nur partiell gefüllt werden.

Vielleicht kommt da auch was durcheinander weil beide Container die selbe KNX_PA haben, kannst ja mal testen eine davon zu ändern.

Aber im Grunde müsste das jemand beantworten, der sich mit dem Teil besser auskennt.

[netfriend]

Da kann ich nur mir gefährlichem Halbwissen glänzen (nutze den KNXD selbst nicht), soweit ich weiß merkt der sich den letzten Wert für jede GA, damit er Anfragen schneller beantworten kann. Dazu müssen diese aber während seiner Laufzeit wenigstens einmal gesendet worden sein. Ich weiß nicht ob der einen Read-Request auf den Bus schickt um "die Lücken zu füllen". Es sieht so aus als ob der Cache noch unvollständig ist und deswegen die Seite nur partiell gefüllt werden.

Vielleicht kommt da auch was durcheinander weil beide Container die selbe KNX_PA haben, kannst ja mal testen eine davon zu ändern.

Aber im Grunde müsste das jemand beantworten, der sich mit dem Teil besser auskennt.

Ich habe nun auf einem anderen Raspi, der gerade herumliegt, ein aktuelles Raspbian installiert und nur Docker installiert.
Hier ebenfalls den CV-testing-Container gestartet

Hier läuft nur die CV...Auffällig ist, dass hin und wieder (wenn der Browser geöffnet ist und das Notebook nicht anderweitig benutzt wird) einfach alle Werte fehlen. Das ist mir auch auf anderen Geräten (Smartphone, anderer PC) aufgefallen. Daher denke ich nicht, dass es ein Browser-Problem ist. Diese werden auch nicht nachgeladen.

Nun habe ich -wie weiter oben beschrieben- in die docker-compose.yaml beide Container eingetragen. Mit einem zweiten resource-Pfad, so dass alles komplett getrennt läuft. Die visu_config.xml habe ich dupliziert. Diese sollte ohne Probleme sowohl mit 0.12.6 also auch 0.13.x laufen, oder muss ich hier etwas ändern?

Nun sehe ich, dass nach Starten des Containers in beiden Browser-Tabs zuerst die KNX-Werte fehlen. Nach kurzer Zeit sehe ich diese in der 0.12.6, bei der 0.13.x kommen zwar einige Werte, aber längst nicht alle. Irgendwann erscheint ein roter Hinweis: "Verbindung zum Backend verloren" oder so ähnlich (Screenshot vergessen).

In den Entwicklerwerkzeugen sehe ich folgendes:

image.png

no addresses registered for backend "system", skipping update .... wo muss hier noch eine Adresse angegeben werden? Ich dachte, die comet_visu.xml kann mit der 0.13.x weiter verwendet werden?

[peuter]

Ich hab da vom Cache des KNXD geredet nicht vom Browser. Dieser läuft im Container und merkt sich die jeweiligen letzen Werte aller GAs die über den Bus gesendet werden. So kann er die erste Anfrage der Visu schneller beantworten. Deine Beschreibung deutet darauf hin, das hier das Problem liegt.

Die alte Config sollte auch in der 0.13 funktionieren. Die Warnung zum "system" backend kannst Du ignorieren, da geht es um ein rein internes Backend (siehe: https://www.cometvisu.org/CometVisu/...und-funktionen) und die Meldung besagt nur, dass du das nicht benutzt und es somit nichts zu tun gibt.

[netfriend]

Ich habe meinen Fehler gefunden: ich habe das falsche Image geladen!
Anstatt "cometvisu/cometvisu:testing-arm" habe ich "cometvisu/cometvisu:testing" geladen, ich Trottel 😤

[netfriend]

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?

[Chris M.]

Da kann ich nur mir gefährlichem Halbwissen glänzen (nutze den KNXD selbst nicht), soweit ich weiß merkt der sich den letzten Wert für jede GA, damit er Anfragen schneller beantworten kann. Dazu müssen diese aber während seiner Laufzeit wenigstens einmal gesendet worden sein. Ich weiß nicht ob der einen Read-Request auf den Bus schickt um "die Lücken zu füllen". Es sieht so aus als ob der Cache noch unvollständig ist und deswegen die Seite nur partiell gefüllt werden.

Das ist genau richtig.

Wenn ein Container neu gestartet wird, dann hört der knxd ab diesem Moment am Bus zu und legt die neueste Version von jeder gesendeten GA in seinen Cache.
Öffnet nun die CV, so fragt die alle in der Config stehenden GAs beim knxd ab. Was er schon kennt wird sofort geschickt, was er noch nicht kennt wird mit einem Lesetelegramm abgefragt. Sobald Antworten kommen schickt der knxd diese an die CV.

Daher dauert die Daten-Anzeige nach einem Visu Öffnen bei einem frisch gestarteten Container länger, da diese Werte noch nicht im Cache sind. Ab dem zweiten Öffnen geht es dann schneller, wenn in der Zwischenzeit der Cache befüllt wurde.

[Chris M.]

Ich habe meinen Fehler gefunden: ich habe das falsche Image geladen!
Anstatt "cometvisu/cometvisu:testing-arm" habe ich "cometvisu/cometvisu:testing" geladen, ich Trottel 😤

Nö, das war schon richtig. Inzwischen ist der Container ein Multi-Architektur-Container, d.h. Du nimmst nur "testing" und das Programm wählt selber den richtigen für die jeweilige Architektur:
image.png

[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?

Grundsätzlich steht es hier: https://www.cometvisu.org/CometVisu/...-konfigurieren

Ich müsste es aber auch mal besser testen...

[netfriend]

Grundsätzlich steht es hier: https://www.cometvisu.org/CometVisu/...-konfigurieren

Ich müsste es aber auch mal besser testen...

Das hab ich gelesen, aber so ein Beispiel funktionierendes Demo-File ist halt immer was anderes. Da hat man "schnelle Erfolge" wenn man das übernehmen und anpassen kann. Liest man was, versteht man vielleicht was anderes drunter und spielt ewig damit rum ohne dass was geht.

[netfriend]

Nö, das war schon richtig. Inzwischen ist der Container ein Multi-Architektur-Container, d.h. Du nimmst nur "testing" und das Programm wählt selber den richtigen für die jeweilige Architektur:

Dann versteh ich die Welt nicht mehr. Ich habe mit "testing" viel probiert, es hat nicht wirklich funktioniert. Irgendwann kamen Werte - jedenfalls auf einer Page. Alle anderen waren leer, ebenso die Fehlermeldungen.
Seit ich auf "testing-arm" gewechselt bin, geht es seit dem ersten Container-Start. Ich sehe auch keine Fehlermeldung mehr. Wie Du oben geschrieben hast, dauert es eine Weile bis alle Werte da sind. Man sieht auch im Busmonitor die GroupValueReads und eine erhöhte Buslast bis alles da ist. Seitdem läuft es nun seit einigen Tagen ohne Auffälligkeiten - mit meiner docker-compose.yaml und comet_visu.xml.
Kann es sein, dass in dem Multi-Architektur-Container noch irgendwas nicht passt, z.B. mit der automatischen Erkennung der Architektur o.ä?
Würde auch zu der Fehlermeldung passen.

[Chris M.]

testing-arm wir ein sehr alter Container sein (der ist nur nicht gelöscht um keine Systeme kaputt zu machen. Wobei das bei testing eigentlich nicht der Fall sein darf). Du kannst ja mal im Manager auf "Hilfe" und dort auf "Über" gehen um zu sehen, was hier drinnen steckt.

Grundsätzlich kann natürlich immer was kaputt sein, ich glaube es aber bis zum Beweis des Gegenteils erst mal nicht. Was geht denn genau nicht? (Also liegt es an der CV oder am Container?)

[netfriend]

Der testing-arm-Container hat gar kein "Hilfe" im Manger. Der "testing"-Container schon. Scheint wohl wirklich sehr alt zu sein. Wenn ich nun wieder auf den "testing" umstelle, wird folgender Container geladen:

image.png

Nun habe ich nach wie vor Probleme:

1. Container-Start: KNX-Variablen leer, werden mittels GroupValueRead geladen, sieht man auch im ETS-Busmonitor.
2. Nach ein paar Minuten sind alle KNX-Variablen gefüllt, die Buttons haben Funktion, auch die influxDB-Diagramme werden angezeigt. Soweit prima!

image.png
3. Drücke ich nun F5 im Browser, wird die Seite kurz refreshed und es leeren sich alle KNX-Variablen! Das ist schon mal komisch, in CV 0.12.6 ist das nicht so. Aber es wird auch kein GroupValueRead ausgeführt (mit ETS Busmonitor kontrolliert). Die Variablen/Buttons usw. bleiben leer...auch nach Minuten keine Veränderung. Ab da ist CV praktisch tot.

image.png

In den F12 Entwicklereinstellungen sehe ich
image.png

Irgendwann ist folgendes zu sehen:
image.png

Ich habe noch etwas weiter herumgespielt. Beende ich nun den Container und starte diesen neu, ändert das nichts, es bleibt bei 3).
Auch ein Beenden, Container neu pullen und starten verändert nichts.

Auch ein Strg+F5 im Browser verändert nichts. In der CV bleiben die KNX-Werte leer.
Erst ein Cache-löschen in den Browser-Einstellungen (z.B. löschen letzte Stunde) führt dazu, dass es wieder bei 1) beginnt. Wird wieder F5 gedrückt, passiert es wieder wie bei 3) beschrieben.

Irgendwie klemmt hier etwas, das sich nur durch manuelles Cache-löschen beheben lässt. Sieht auf den ersten Blick so aus, als kommt was durcheinander und CV weiß nicht mehr, welche KNX-Daten schon vorhanden sind und welche nochmal gelesen werden müssen und vor allem was angezeigt werden kann/muss.

Das sind meine Beobachtungen. An der Stelle kann ich wohl nichts mehr machen.
Kannst Du damit etwas anfangen? Oder soll ich noch was probieren?

[Chris M.]

Gut möglich, dass es beim neuen Multi-Backend noch irgendwo klemmt. Ich schau mal, ob ich das nachstellen kann

[Chris M.]

Zwischenstand:
Also, ja, irgend etwas ist in der aktuellen Entwickler-Version während der Startens stark verstopft. Was genau kann ich nicht sagen, da ich immer erst in ein Time-Out von ein paar Minuten laufen muss, bis ich wieder Zugriff auf den Entwicklungs-Konsole bekomme.

[Chris M.]

netfriend nur um sicher zu gehen(*), Du hast nicht zufällig so ein unscheinbares "Uncaught (in promise)" auf der Entwicklerkonsole?
Screenshot_20241217_103805.png


(*) das kommt gerade bei mir, wenn ich es provoziere - da ich einen kaputten B.IQ RTR habe, der den Bus mit Paketen flutet und damit meinen Timberwolf stark beansprucht. Vermutlich ist das der Grund warum es sich bei mir "verstopft" anfühlt.