maximale Anzahl an Gruppenadressen?

[arteco]

Hallo zusammen,

gibt es vielleicht eine (ggf. auch ungewollte) Beschränkung auf eine maximale Anzahl von Gruppenadressen in der CometVisu? Bis 533 Adressen (siehe erstes Bild) ist bei mir alles ok. Wenn ich an "beliebiger" Stelle in der visu_config.xml eine weitere Adresse (534) hinzufüge gibt es bereits ein Phänomen, das Fenster-Icon zeigt die Zahl 8754 statt einer Grafik an (siehe Bild zwei oben links) und bei einer weiteren Adresse (535) werden keinerlei Werte mehr angezeigt, wie im letzten Bild zusehen ist. Auch die Bedienung der weiteren Elemente wie switch oder slide etc. funktionieren dann nicht mehr. Wenn ich die zusätzlichen (neuen) Gruppenadressen auf bereits existierende Adressnummern ändere ist wieder alles ok, da die maximale Anzahl wieder 533 beträgt - es liegt als nicht an den neuen Einträgen bzw. einem Syntaxfehler.

Ich hoffe, dass dazu jemand eine Idee hat, da ich noch mindestens 100 Gruppenadressen zur Steuerung weiterer Klimaanlagen in den Räumen benötige?

VG
Tommy

PS: sowohl mit 0.9.0 wie auch mit 0.10.2 (ein Update hat also leider nicht geholfen)



533.png534.png535.png

[jolt]

Welches Backend nutzt du?

[arteco]

Welches Backend nutzt du?

einen https://www.zotac.com/at/product/mini_pcs/aq01 mit Debian 3.16.7-ckt2-1 (2014-12-08) x86_64 und eibd, sowie rddtool - oder was meinst?

[jolt]

Okay das sollte passen. Mit dem OpenHAB Backend gibt es nämlich Probleme wenn zu viele Items konfiguriert sind. Ist hier aber nicht das Problem.

[peuter]

Naja, es könnte aber die selbe Ursache haben. Offensichlich ist hier auch der HTTP-GET Request zu lang durch die vielen Adressen. siehe z.B. für Apache:
http://httpd.apache.org/docs/2.2/mod...mitrequestline

arteco Welcher Webserver läuft den auf deinem Server?

[makki]

Bewusst ist/war es sicher nicht, aber ich würde auch spontan drauf tippen: das man da in ein Limit läuft (mehr als 500+xx Updates hielt ich da vielleicht einfach für insane
Ich tippe allerdings nicht auf Apache-POST sondern
#define MAX_POSTSIZE 10000
in eibread-cgi.c

Sollte sich also einfach fixen lassen, war halt vermutlich eine gefühlte DoS-Protection, whatever..

Makki

[peuter]

Die CometVisu Read-Requests sind ja GET requests und keine POST requests, daher vermute ich mal, dass MAX_POSTSIZE hier weniger zum Tragen kommt.

[makki]

Puh, hmm, das ist zulange her, aber eigentlich hatte ich genau deswegen glaube ich mal POST dafür angedacht
Aber auch das lässt sich ja ändern, dem Backend sollte das egal sein..

Makki

[arteco]

Welcher Webserver läuft den auf deinem Server?

... es läuft "lighttpd" jedoch finde ich in der "/etc/lighttpd/lighttpd.conf" nichts mit "LimitRequestLine" - suche ich an der falschen Stelle?

[peuter]

... es läuft "lighttpd" jedoch finde ich in der "/etc/lighttpd/lighttpd.conf" nichts mit "LimitRequestLine" - suche ich an der falschen Stelle?

Ja klar, das Beispiel war ja für Apache nicht für lighttpd. Für den finde ich keine vergleichbare Option. Vielleicht diese hier: "server.max-request-field-size"? Klingt aber auch nicht so ganz passend.

[makki]

Tobias hat natürlich recht, hab jetzt nachgesehen: es ist ein GET, da läuft man in limits (was vorhersehbar war und vorhergesehen wurde; aber einfach nirgends angeschlagen ist, daher bisher "egal")
Im Prinzip sollte man auf POST umstellen statt den Webserver zu befummeln IMHO, es sollten nur minimale Änderungen notwendig sein ([C] der kürzeste IT-Witz: "ich mach das noch schnell")

Im Backend ist POST eingebaut (aber eben mit der max size 10k, die man auch mal überdenkenken kann, da war ich halt teils auf ARM7 mit 16MB RAM unterwegs..)
Anyway, man müsste beides synchron umstellen, im (CV)Frontend am besten erstmal konfigurierbar, backend testen, ggfs. fixen (ich glaube aber das es einfach geht, hatte ich anno schnuff ziemlich sicher getestet, sonst hätte ich es nicht in den Source geschrieben..)

-> Also Bug/FR aufmachen in CV *und* knxd (sollten am besten verlinked sein).
Das Problem ansich halte ich aber für sehr einfach lösbar, bin nur gerade knapp an Zeit und bin da relativ raus..

Grüsse Makki

[Chris M.]

Den CV Client (also der Teil, der beim User im Web-Browser läuft) auf POST umzustellen ist ziemlich sicher kein größeres Problem. Ab der 0.11 sollte da eine Config-Option die zwischen GET und POST umschaltet auch leicht machbar sein.

Bzgl. eibd / knxd habe ich aktuell das Problem, dass ich den nicht leicht testen kann - mein Versuch das per Docker schön zu kapseln und so aktiver testen zu können ist im Thread https://knx-user-forum.de/forum/proj...-12-l%C3%A4uft versandet...

[arteco]

... schade, dann habe ich wohl ein nicht lösbares Problem.

[peuter]

Du kannst ja mal versuchen den lighttpd durch einen Apache zu ersetzen und die o.g, Konfigurationsoption zu nutzen. Vielleicht gehts ja damit.

[Chris M.]

Und lösbar ist es. Wir brauchen nur noch jemanden, der dazu kommt es umzusetzen

Übrigens: für Installationen mit richtig vielen GAs gibt es seit Anfang an im CometVisu Protokoll die Möglichkeit über Filter den Datentransfer pro Request auf ein paar Byte zu reduzieren.
Der Grund warum das (noch) nicht implementiert ist: bisher haben wir es nicht gebraucht, da niemand an die Grenzen gekommen ist...