[Featurewunsch] Webserver

[enertegus]

Hallo,
Updates zum Webserver wurden ja bereits mehrfach geäußert.

Am Frankenstammtisch (https://knx-user-forum.de/knx-eib-fo...h-franken.html) werden wir wohl zum neuen Design unsere Überlegungen präsentieren.

Erste Planungen werden dort vorgestellt. Dringlichster Wunsch: Verwaltung mehrerer Seiten...

Unser Plan:
+ Max. 20 Seiten (d.h. pro Seite im Schnitt 13 Webelemente)
+ verbesserte XY-Grafik
+ Slider Elemente

Die ersten Previews exklusiv am Stammtisch.

Hierzu Kommentare erwünscht...

Michael

[pio]

Aufhebung der Beschränkung auf max. 256 Elemente

[enertegus]

wobei man sich dann schon irgendwann man fragen muss: wozu?
20 Seiten mit insgesamt 256 Schaltknöpfen - der Shifter hat ja jetzt schon bis zu 4 Knöpfe, d.h. selbst der Schaltwahnsinnige kann sich 1024 Schaltungen legen! Dann können die Knöpfe beliebig programmiert werden (dynamisch verändert). Das versteh ich nicht.

[pio]

Es geht mir weniger ums Schalten als ums darstellen.
Ich habe u.a. folgende Eib-GAs (und ich habe mit Sicherheit nur eine kleine Installation):

67x Licht (=67xStatus an/aus und evtl. noch 67x%Dimmwert)
28x Fensterkontakte
13x Jalousien
12x Fussbodenheizung
12x Temperatur innen
4x Temperatur aussen
3x Feuchte
1x Zeit
1x Datum
1x Windgeschwind.
1x Regen
ca. 10 Sperrobjekte
uvm.

Dann will ich noch Temp.-Statistiken haben, Szenen aktivieren, Zentralfunktionen, usw.


Für jeden dieser Punkte brauch ich eine ID (nicht zwangsweise zum Verstellen, sondern zum Zustand anzeigen, z.B. Fekos).
Und dann kostet mich ein simpler Trennstrich zum Verschönern auch noch eine ID?!

Oder hab ich da was falsch verstanden?

[enertegus]

Es geht mir weniger ums Schalten als ums darstellen.
Ich habe u.a. folgende Eib-GAs (und ich habe mit Sicherheit nur eine kleine Installation):

67x Licht (=67xStatus an/aus und evtl. noch 67x%Dimmwert)
28x Fensterkontakte
13x Jalousien
12x Fussbodenheizung
12x Temperatur innen
4x Temperatur aussen
3x Feuchte
1x Zeit
1x Datum
1x Windgeschwind.
1x Regen
ca. 10 Sperrobjekte
uvm.

Dann will ich noch Temp.-Statistiken haben, Szenen aktivieren, Zentralfunktionen, usw.


Für jeden dieser Punkte brauch ich eine ID (nicht zwangsweise zum Verstellen, sondern zum Zustand anzeigen, z.B. Fekos).
Und dann kostet mich ein simpler Trennstrich zum Verschönern auch noch eine ID?!

Oder hab ich da was falsch verstanden?

Trennlinie: muss man keine ID vergeben, zählt aber als Webelement.

Willst Du wirklich jedes Licht über die VISU schalten?
Bei den Fensterkontakten könnte man doch einfach nur ne Anzeige machen: 2 Fenster offen. Dadurch, dass die Buttons ihre Anzeige und Icons ändern können, ist es sowieso möglich mehr als 256 GA zu bedienen.

[MatthiasS]

wobei man sich dann schon irgendwann man fragen muss: wozu?

ich glaube, wir müssen nochmal telefonieren

[enertegus]

ich glaube, wir müssen nochmal telefonieren

Is ja gut, dann von mir aus halt 2048 Elemente...

[Winni]

Hallo zusammen,

nur um den Wunsch der Kollegen zu bekräftigen: Ich habe vor 3 Jahren meinen Merten IC1 gegen den Homeserver getauscht. Dabei war weniger die größere Funktionalität der Grund, als die Limitierung auf 255 Objekte. Ich denke der EibPC hat das Zeug hier in eine Lücke zu springen, denn er vereint eine einfache, schnelle Visu mit der Möglichkeit Logiken zu realisieren zu einem guten Preis. Eine Limitierung auf Seiten oder Elemente sollte man sich jedoch gut überlegen, denn ich denke dies wird einige zurückschrecken lassen (Bis diese Grenze gefallen ist, werde ich mir auch keinen besorgen, obwohl trotz HomeServer Interesse daran besteht).

Gruß
Winfried

[pio]

Willst Du wirklich jedes Licht über die VISU schalten?

Nee nicht unbedingt, aber ich möchte für jeden Raum jede Lampe separat darstellen können und sehen, ob sie noch an od. aus ist.

In einem meiner anderen Threads habe ich mal ein paar screenshots von meiner MicroVis-Visualisierung gemacht, das gibt einen guten Eindruck von dem, was ich brauche.

[pio]

Is ja gut, dann von mir aus halt 2048 Elemente...

Gegenvorschlag: 2 bytes = 65535 (oder so)?

Wo liegt eine sinnvolle Grenze, bevor der EibPC in die Knie geht (z.B. die Zykluszeit vom 1ms gravierend flöten geht)? (Unter gravierend verstehe ich z.B. 5ms, fällt mir aber noch schwer, das für ein SPS-aehnliches System wie den EibPC für KNX-Anwwendungen einzuschätzen)

[JoeHorn]

Gegenvorschlag: 2 bytes = 65535 (oder so)?

Wo liegt eine sinnvolle Grenze, bevor der EibPC in die Knie geht (z.B. die Zykluszeit vom 1ms gravierend flöten geht)? (Unter gravierend verstehe ich z.B. 5ms, fällt mir aber noch schwer, das für ein SPS-aehnliches System wie den EibPC für KNX-Anwwendungen einzuschätzen)

Das ist alles relativ, schneller als 10ms ist gar nicht notwendig, mehr als 100 Telegramme/s sind gar nicht machbar. Ich habe Aktoren, die verschlucken Befehle, wenn mehr als einer alle 100ms kommt. Und Verzögerungen unter 50ms werden von keinem Menschen wirklich wahrgenommen - bis 200ms werden in vielen kommerziellen Anwendungen akzeptiert.
Abgesehen davon wird nur Rechenzeit benötigt, wenn eine Seite aufgebaut und ausgeliefert wird, wie viele verschiedene es davon gibt, spielt dabei erst einmal keine Rolle.

Und bei vernünftiger Programmierung läuft diese Aufgabe als niederpriore Subtask, welche von Zeit zu Zeit einen beschränkten Anteil an der Rechenzeit erhält, wenn gerade nichts wichtigeres ansteht. Dank Linux (

Debian Linux: 2.6.24 -rt1.

) sollte das gehen). Webserver sind nicht besonders zeitkritisch, Webbrowser warten zur Not. Ist doch im Internet nicht anders, sind die Server ausgelastet, dauern Zugriffe eben etwas länger.

Daher verstehe auch Ich die Limits nicht. Bei Szenenaktoren werden 16Bit als Index verwendet - wohl kaum einer wird so viele Szenenaktoren definieren (jeder davon kann ja noch bis 64 Szenen speichern), aber es beruhig, es zu können.
Es können 500000 Telegramme geloggt werden - das sind einige MByte! Und ein Index größer 16Bit!
Mangelder Speicher und mangelde Rechenleistung können es also eigentlich nicht sein.

Wenn sonstige technische Gründe Limits erzwingen oder zumindes ratsam erscheinen lassen, dann wäre es hilfreich für die Akzeptanz, diese zu erfahren. Wir alle müssen Kompromisse eingehen, das fällt aber leichter, wenn insbesondere die unangenehmen Einschränkungen nachvollziehbar erforderlich sind, und nicht einfach nur willkürlich wirken.
Die Beschränkungen des Webservers erschließen sich wohl nicht nur mir gegenwärtig nicht.

[enertegus]

Gegenvorschlag: 2 bytes = 65535 (oder so)?

Wo liegt eine sinnvolle Grenze, bevor der EibPC in die Knie geht (z.B. die Zykluszeit vom 1ms gravierend flöten geht)? (Unter gravierend verstehe ich z.B. 5ms, fällt mir aber noch schwer, das für ein SPS-aehnliches System wie den EibPC für KNX-Anwwendungen einzuschätzen)

Auslastung: Es kommt auf die Anzahl der Objekte an.
Die 1 ms garantiert, dass die Telegramme in jedem Fall in die Verarbeitung einlaufen. Dabei ist zu bedenken, dass der Bus einige ms für ein 8-Bit Telegramm braucht. Der HS ist (m.W.) auf begrenzt auf 20 Telegramme pro Sekunde, also alle 50 ms ein Telegramm.

Wenn die Auslastung im EibPC steigt, so dass z.B. 20 ms pro Verarbeitungszyklus benötigt wird, kann immer noch gewährtleistet werden, dass - bezogen auf den KNX Bus - jedes Telegramm in "Echtzeit" verarbeitet wird.

Der Compiler im EibStudio gibt die Objektauslastung an. Bei unseren Tests hier wurden bei Programmen mit ca. 12% der möglichen Objekte (ca. 7800) und einem laufendem Webserver Zykluszeiten von ca. 7ms beobachtet. Wohlgemerkt die Telegramme gehen auch dann nicht verloren, auch wenn der EibPC 40ms brauchen sollte. Da mit der Auslastung die Zykluszeit linear steigt, sollte bei 65000 Objekten immer noch mit 50 ms Zyklus jedes Telegramm verarbeitet werden können.

Es ist gar nicht so leicht 12% Objektauslastung, zu erreichen, weil der Kompiler doppelte Anweisungen erkennt und entsprechend optimiert. Also mit bloßem Copy und Paste geht das quasi nicht.

[pio]

Wenn sonstige technische Gründe Limits erzwingen oder zumindes ratsam erscheinen lassen, dann wäre es hilfreich für die Akzeptanz, diese zu erfahren. Wir alle müssen Kompromisse eingehen, das fällt aber leichter, wenn insbesondere die unangenehmen Einschränkungen nachvollziehbar erforderlich sind, und nicht einfach nur willkürlich wirken.
Die Beschränkungen des Webservers erschließen sich wohl nicht nur mir gegenwärtig nicht.

Ich kann mir noch vorstellen, dass evtl. interne Datenstrukturen aktuell halt "auf 8 Bit beschränkt" aufgebaut sind und eine "einfache" Erweiterung nicht möglich ist, da man die ganzen Strukturen und Verarbeitungsfunktionen komplett anpassen müsste. Das kann einen nicht unerheblichen Entwicklungsaufwand verursachen.

[enertegus]

Ich kann mir noch vorstellen, dass evtl. interne Datenstrukturen aktuell halt "auf 8 Bit beschränkt" aufgebaut sind und eine "einfache" Erweiterung nicht möglich ist, da man die ganzen Strukturen und Verarbeitungsfunktionen komplett anpassen müsste. Das kann einen nicht unerheblichen Entwicklungsaufwand verursachen.

Nein, nichts Technisches nennt es mangelnde Fantasie.

Ursprünglich (bis August) war ja gar kein Webserver drinnen. Dann haben wir mal gesagt - ok halt eine Seite mit 10 Elementen - da wurde ich fast gesteinigt, naja bei 256 Elementen waren die Steine nimmer so groß.

Speicher: Wir allokieren immer alle möglichen Objekte gleich zum Programmstart. Ob tatsächlich 65365 Objekte möglich werden, das zeigt sich dann halt noch.

Dass wir derzeit nur 1 Seite drinnen haben, liegt einfach daran, dass wir nun mal in den Verkauf wollen.

[pio]

Das hatte ich mir fast gedacht und ist nachvollziehbar. Und das ist auch eine gute Nachricht. Das bedeutet nämlich, dass es ganz klar möglich, bloss noch nicht implementiert ist!

Das dürfte vielen Zauderern ein Stein vom Brett fallen lassen ... oder so