CometVisu maximale Anzahl GAs?

[Fry]

Hallo zusammen,
ich schreibe gerade meine komplette Visu-Oberfläche neu, diesmal unter Einsatz von mehr Icons (bisher mehr Text), und ich möchte nochmal einen Versuch machen, die gesamte Visu in eine XML zu packen - sie lädt dann zwar länger, dafür geht es danach schneller. Und man kann die schönen Navbars nutzen (habe ich bisher ebenfalls nicht getan).

Dabei erzeuge ich die XML-Datei nicht per Editor, sondern per Perl-Skript, da die Struktur doch etwas verschachtelt und aufwendiger ist, und eine algorithmische Erzeugung letztlich viel einfacher ist, als sich die Sachen zusammenzuklicken.

Nun habe ich zwei Probleme, die vielleicht sogar miteinander verwandt sind.

1. Ab einer bestimmten Zahl von GAs zeigt die Visu gar keine Daten mehr an. Zumindest kommt es mir so vor: bei 1327 address-Tags (Lese+Schreib-GAs zusammen, natürlich viele Doppelungen) wird NIX von den Daten mehr angezeigt, bei etwas weniger (1157) funktioniert noch alles. Ist das Problem bekannt, und wie löst man das? Ich vermute ein Timeout oder eine Längenbegrenzung bei der GA-Abfrage. Wie macht ihr das?

2. Beim Laden fragt die Visu die GAs offenbar mit einem einzigen Read-Request ab. Dadurch dauert es "ewig", bis überhaupt was angezeigt wird, selbst wenn die konkrete Page, die man aufgerufen hat, nur wenig Daten enthält. Wie kann man das heilen (am besten wäre es, die Visu würde gar nicht immer geladen sondern im Browser-Cache verbleiben, auch zwischen Sessions und über Stunden hinweg)?

Für Input bezüglich der Visu-Gestaltung wäre ich auch dankbar. Habe da nicht so viel Erfahrung...

Danke für Tipps, Fry

PS. Anbei einen Screenshot meines (vorläufigen) Visu-Entwurfs, damit ihr die Struktur seht. Die Seiteninhalte stammen aktuell noch vom alten Entwurf, auch die werden noch überarbeitet. Die Anzahl der GAs wird aber mehr oder weniger gleich bleiben.

PS2: Edit: die Zahl der GAs oben war viel zu hoch angegeben.

[Fry]

Bin der Sache etwas näher gekommen... es gibt einen Haufen Meldungen der Form

2015-01-12 16:38:37: (mod_cgi.c.1319) cleaning up CGI: process died with signal 11
2015-01-12 16:39:37: (mod_cgi.c.601) cgi died, pid: 17816
2015-01-12 16:45:24: (mod_cgi.c.601) cgi died, pid: 31765
2015-01-12 16:46:21: (mod_cgi.c.601) cgi died, pid: 1866
2015-01-12 16:47:26: (mod_cgi.c.1319) cleaning up CGI: process died with signal 11
2015-01-12 16:48:19: (mod_cgi.c.601) cgi died, pid: 7022
2015-01-12 16:49:16: (mod_cgi.c.601) cgi died, pid: 9218
2015-01-12 16:50:16: (mod_cgi.c.601) cgi died, pid: 11581
2015-01-12 16:51:16: (mod_cgi.c.1319) cleaning up CGI: process died with signal 11
2015-01-12 16:51:39: (mod_cgi.c.601) cgi died, pid: 14734

in /var/log/lighttpd/error.log.

Hat jemand eine Idee, wie man das beheben kann?

[Chris M.]

Nun, da hast Du die aktuelle Grenze des Backends erreicht - und bist damit der erste!

Der CometVisu-Client (die JavaScript-Bibliothek, die die Kommunikation übernimmt) so wie die CometVisu-Anwendung (also die Visu an sich) haben eigentlich keine Grenze an GAs.
Aber wenn ich mal in den Code des Backends (also den Server) schaue, dann ist dort bei 1024 ein Limit programmiert (vgl. https://github.com/Makki1/knxd/blob/.../eibread-cgi.c)

=> Ich kann hier erst mal nichts machen, Du musst das Backend mit größeren Buffern übersetzen bzw. übersetzen lassen.

Was mich dabei aber interessiert: sind die ganzen GAs eindeutig oder sind in dieser Nummer Wiederholungen drinnen?
Und dabei interessiert mich v.a. ob die generierte Request-URL (das "r") nur aus eindeutigen GAs besteht. (Einfach mal in dem Netzwerk-Reiter der Debug-Konsole des Browser den Anfrage-String rauskopieren)

Falls nein, könnte ich in der CV-Anwendung was optimieren - ich hatte mir einfach so einen Fall bisher nie wirklich angesehen, da es immer wunderbar funktioniert hat und ich nicht für's Backend zuständig war...

Falls ja: kannst Du abschätzen welche Anzahl an GAs Du maximal brauchen wirst (so auf die nächsten 1-2 Jahre gerechnet...)?

[Fry]

Falls nein, könnte ich in der CV-Anwendung was optimieren - ich hatte mir einfach so einen Fall bisher nie wirklich angesehen, da es immer wunderbar funktioniert hat und ich nicht für's Backend zuständig war...

Falls ja: kannst Du abschätzen welche Anzahl an GAs Du maximal brauchen wirst (so auf die nächsten 1-2 Jahre gerechnet...)?

Also bisher hatte ich die Visu auf fast 50 Einzeldateien verteilt. Darin kamen insgesamt knapp 4000 address-Tags vor, davon 1322 eindeutige GAs, davon 355 mit mode=read und 348 mit mode=write. Der Grund für die vielen Dopplungen waren Übersichtsseiten, so existiert bspw. ein Heizungsregler, Jalousien und Lichtschalter für jeden Raum, aber dann auch noch Übersichtsseiten mit allen Heizungsreglern, allen Jalousien und allen Lichtschaltern im ganzen Haus.

Die neue Visu hatte ich eigentlich vor in ein einziges File zu packen. Leider zeigt CometVisu dann überhaupt nur Daten anzeigt, wenn ALLE GA-Infos vorliegen. Nicht nur die auf der aktuellen page vorkommenden Daten. Kann man das beschleunigen durch "lazy"-Abfrage der GAs?

Danke für Hinweise!

VG, Fry

[Fry]

Weiteres Experimentieren lässt mich folgendes vermuten: die Grenze von 1024 gilt offenbar für die Gesamtzahl aller address-Tags. Obwohl nur 675 unterschiedliche GAs vorkommen, davon auch noch 117 mit mode="write", d.h. eigentlich nur etwas mehr als 500 GAs einzulesen sind, wird bei 1086 address-Tags NICHTS mehr angezeigt.

Wohlgemerkt: fünf Trigger-Buttons zur gleichen GA enthalten fünfmal den gleichen address-Tag, alle mit mode=write. Sollte eigentlich überhaupt keinen Effekt auf Ladezeiten usw haben...

VG; Fry

[ctr]

Ja wenn ein internes Limit gesetzt ist, dann wird es auch nicht mehr werden. Dass das erst bei 1024 *unique* GAs greifen sollte ist klar, aber einfacher als diesen Bug zu fixen, wäre es erstmal das Limit zu erhöhen:

#define MAX_GA 1024 /* max number of GAs */

Probier das doch mal und dann schauen wir weiter.
(Wie Du Dir mal schnell eigene eibread/eibwrite bauen kannst steht hier:
Open Automation / Code / [r2325] /tools/bcusdk/eibd/examples Falls beim Bauen etwas schief geht sag Bescheid, dann aktualisiere ich die Anweisungen)

[Fry]

Punktlandung! Es hat geklappt. Tausend Dank!
VG, Fry

- es sollte m.E. standardmäßig dieses Limit hochgesetzt werden!

[mivola]

2. Beim Laden fragt die Visu die GAs offenbar mit einem einzigen Read-Request ab. Dadurch dauert es "ewig", bis überhaupt was angezeigt wird, selbst wenn die konkrete Page, die man aufgerufen hat, nur wenig Daten enthält.

Das ist mir auch schon aufgefallen. Mit steigender Komplexität der Visu steigt auch die Wartezeit bis Daten angezeigt werden. Bei mir momentan auch ca 10-15sec. Wäre es möglich (als neues Feature) die *unique* GAs einzeln abzufragen und den Wert anzuzeigen? Und dann auch noch die der aktuellen Seite zuerst?

VG
Micha

[Fry]

Noch ein Effekt ist mir subjektiv als wichtig aufgefallen: die address-Tags von trigger-Widgets sollten unbedingt auf mode=write gesetzt werden.

Auch timeouts bei GA-Requests sind möglichst zu vermeiden. Hilft der Visu auch nicht.

Übrigens bin ich (zwei linke Hände bei HTML usw) immer noch nicht drauf gekommen, wie ich im Firefox (mit Web Developer Addon) mir anzeigen lassen kann, welche GAs überhaupt angefragt werden.

Ich würde dem gerne etwas mehr auf den Grund gehen. Die CometVisu ist super, aber die Ladezeiten sind aus den genannten Gründen einfach noch zu lang.

VG, Fry

[MicHau]

Ich hatte im Kopf, dass man das initiale Abfragen beschleunigen kann und habe mal im Code geschaut. Und ich bin auch fündig geworden.

Wenn man an die URL den Parameter "enableQueue=true" anhängt, werden (bzw. sollten) beim ersten Request nur die Adressen der Startseite abgefragt werden. Alle anderen werden in einem separaten Request abgehandelt. Ob das tatsächlich funktioniert, kann ich aktuell nicht sagen und auch nicht ausprobieren. Aber vielleicht hilft es euch schon mal weiter.

[Fry]

Na wenn das so einfach wäre, dann sollte enable=True defaultmäßig aktiviert sein.

[MicHau]

Na wenn das so einfach wäre, dann sollte enable=True defaultmäßig aktiviert sein.

Da stimme ich dir zu.
Hast du es denn ausprobiert? Verbessert es die Situation beim Visu-Start?

Wenn ja, wäre es meines Erachtens angeraten, das als Standard-Verhalten zu verwenden. Ich würde sogar soweit gehen, dass man gar kein anderes Verhalten zulässt, weil es keinen Sinn macht.

Ich halte insgesamt wenig von der Verwendung dieser URL-Parameter. Das kann man meines Erachtens keinem normalen User zumuten, da irgendwelche kryptischen Parameter an seinen Visu-Aufruf dran zu klimpern. Es sollten alle Parameter, wenn es irgendwie geht, in die Config wandern. Wie seht ihr das?

[mivola]

Hast du es denn ausprobiert? Verbessert es die Situation beim Visu-Start?

Also bei meinem Test hat es keinerlei Verbesserung gebracht (lt. Timeline im Chrome Inspector). Die aufgerufene URL die mit "r?" beginnt, unterscheidet sich auch nicht...

VG
Micha

[peuter]

Also bei meinem Test hat es keinerlei Verbesserung gebracht (lt. Timeline im Chrome Inspector).

Da ich glaube das damals verbrochen zu haben, hab ich das mal gefixt (Rev 2331). Ob das nun tatsächlich eine Beschleunigung bringt kann ich leider nicht testen, denn 1. nutze ich openHAB als Backend und 2. habe ich nicht allzuviele Adressen in meiner Config.

Da ich gerade im Code unterwegs war: Es sollten auch mehrfach genannte GAs nur einmal in dem request auftauchen (zumindest laut Programmierung wird hier aus den GAs ein Array mit der jeweiligen GAs als Schlüssel erstellt und da Schlüssel nur einmal vorkommen kann in einem Array, darf es auch keine doppelten geben).

Hast Du hier wirklich doppelte GAs in Deinem request?

[mivola]

Da ich glaube das damals verbrochen zu haben, hab ich das mal gefixt (Rev 2331).

Also bei mir hat das nichts gebracht :-( Die URL mit r? ist immer noch immens lang und die Zeit nicht kürzer geworden.

VG
Micha
PS: ich glaube du hast versehentlich (d)eine config/visu_config_main.xml mit committed?