CCU2 Blue Screen nach Firmeware Update

[deimos]

Hi,

ich versuche mich mal an einer möglichen Erklärung: Problem dürfte die veralteten Javascript im Browsercache sein. Großartig verändern die sich nur bei Major Versionssprüngen (also 2.27.x auf 2.29.x oder 2.29.x auf 2.31.x), innerhalb von Minor Versionssprüngen sind da zwar auch mal Änderungen drin gewesen, aber eher kleinere.
Mit der 2.29 würde ja lighttpd als Proxy zwischengeschaltet. Ich vermute mal, dass der jetzt entsprechende saubere Cache-Directiven sendet und das bis 2.27 ohne Proxy nicht der Fall war. Daher wurden die Javascript Dateien von 2.29.x jetzt erstmal richtig gecached und mit dem Wechsel auf 2.31.23 hat das zu Problemen geführt. Sehr wahrscheinlich wird ein direkter Wechsel von 2.29.x auf 2.31.25 auch zu Problemen führen. 2.31.23 auf 2.31.25 aber nicht, weil sich in den Javascripts nichts geändert hat.

Viele Grüße
Alex

[jmaus]

ich versuche mich mal an einer möglichen Erklärung: Problem dürfte die veralteten Javascript im Browsercache sein. Großartig verändern die sich nur bei Major Versionssprüngen (also 2.27.x auf 2.29.x oder 2.29.x auf 2.31.x), innerhalb von Minor Versionssprüngen sind da zwar auch mal Änderungen drin gewesen, aber eher kleinere.
Mit der 2.29 würde ja lighttpd als Proxy zwischengeschaltet. Ich vermute mal, dass der jetzt entsprechende saubere Cache-Directiven sendet und das bis 2.27 ohne Proxy nicht der Fall war. Daher wurden die Javascript Dateien von 2.29.x jetzt erstmal richtig gecached und mit dem Wechsel auf 2.31.23 hat das zu Problemen geführt. Sehr wahrscheinlich wird ein direkter Wechsel von 2.29.x auf 2.31.25 auch zu Problemen führen. 2.31.23 auf 2.31.25 aber nicht, weil sich in den Javascripts nichts geändert hat.

Das sind in der Tat recht gute Hinweise, Alexander. Die Frage wäre nun (und die geht schon länger in meinem Kopf rum) wie hier das allseits bekannte "Browser Cache löschen" Problem umgangen werden könnte. Im Bereiche Webentwicklung fehlt mir da das notwendige tiefere Wissen um jetzt einen Ansatz sofort zu finden damit dieses lästige Browser Cache löschen nicht mehr notwendig ist. Die Frage wäre also als erstes welche genauen Teile der WebUI denn für die Browsercache-problematik verantwortlich ist. Ggf. könnte man das ja durch ändern der URLs (z.B. unter hinzufügen von versionsparametern) dafür sogar das bei einem Versionssprung man den browser cache nicht mehr löschen müsste. Vielleicht hast du ja eine Idee wie ich rausbekommen kann was genau denn im Browser Cache nun landet, dann könnte ich schauen ob ich in der WebUI Anpassungen hinzufüge die dafür sorgen das diese Teile dann bei einem Versionssprung nicht vom Cache geladen werden.

[deimos]

Hi,

eine Variante wurde vor ein paar Tagen ja bereits beschrieben (weiß leider nicht wo und von wem): An die Url der Javascripts ein Url-Parameter mit der Version dranhängen, als z.B.

Code: Alles auswählen

<script src="/myJavascript.js?version=2.31.25"></script>

Und das dann idealerweise auch gleich für CSS mitmachen, da hat man sonst das gleiche Problem.

Zweite Variante:
Im initialen Webserver die Cache-Header korrekt setzten. (also Last-Modified, ETag, Cache-Control: must-revalidate, Expires). Und dann in lighttpd dafür sorgen, dass die Header sauber durchgeleitet werden (macht der normalerweise von alleine, man kann es aber "kaputt" konfigurieren)

Dritte Variante:
lighttpd gleich die ganzen statischen Sachen ausliefern lassen (also Images, CSS, Javascript). Spart Resourcen und lighttpd setzt Cache-Header normalerweise korrekt (Auch hier wieder, "kaputt" machen ist möglich)

Vierte Variante:
Kombiere 1+3, dann ist man wirklich sauber. Dann noch beim Build ein minify über JS und CSS, dann spart das auch noch etwas Übertragungs- und Renderzeit.

Für Webentwickler ist die Fragestellung absoluter Kinderkram. @Jens: Wenn du da nicht die Ahnung hast, kein Thema, man kann und muss sich nicht überall auskennen. Wenn aber eQ-3 eine Lösung mit Webinterface verkauft, dann sollten sie imho entweder das Know-How inhouse aufbauen oder sich extern einkaufen. (oder alternativ dafür sorgen, dass sich da eine richtige OS Community bilden kann)

Viele Grüße
Alex

[jmaus]

eine Variante wurde vor ein paar Tagen ja bereits beschrieben (weiß leider nicht wo und von wem): An die Url der Javascripts ein Url-Parameter mit der Version dranhängen, als z.B.

Code: Alles auswählen

<script src="/myJavascript.js?version=2.31.25"></script>

Und das dann idealerweise auch gleich für CSS mitmachen, da hat man sonst das gleiche Problem.

Genau so hatte ich mir das vorgestellt und auch auf meiner TODO. Die Frage wäre nun allerdings genau all die stellen in der WebUI rauszubekommen wo genau man so vorgehen müsste. Da könnte ich in der Tat Hilfe gebrauchen weil mir dafür nicht nur teilweise das knowhow sondern auch motivation und zeit fehlt

Zweite Variante:
Im initialen Webserver die Cache-Header korrekt setzten. (also Last-Modified, ETag, Cache-Control: must-revalidate, Expires). Und dann in lighttpd dafür sorgen, dass die Header sauber durchgeleitet werden (macht der normalerweise von alleine, man kann es aber "kaputt" konfigurieren)

Wie du ja weisst wird lighttpd inzwischen als Proxy auch für ReGa eingesetzt und da ReGa nunmal die Webseiten ausliefert müsste lighttpd eben einmal so konfiguriert werden das es diese Header alle erzeugt bzw. man müsste man kontrollieren ob es das nicht bereits tut (wo ich nicht ganz sicher bin).

Dritte Variante:
lighttpd gleich die ganzen statischen Sachen ausliefern lassen (also Images, CSS, Javascript). Spart Resourcen und lighttpd setzt Cache-Header normalerweise korrekt (Auch hier wieder, "kaputt" machen ist möglich)

Das lighttpd die statischen Sachen direkt ausliefert wird so wohl nicht passieren, da eben ReGaHss im Grunde hier der Webserver ist und das jetzt alles in der ReGa umzustellen halte ich für einen zu großen Aufwand. Das muss auch anders gehen

Vierte Variante:
Kombiere 1+3, dann ist man wirklich sauber. Dann noch beim Build ein minify über JS und CSS, dann spart das auch noch etwas Übertragungs- und Renderzeit.

Man kann natürlich viel machen Allerdings wäre der erste schritt erst einmal das Browser Cache Problem komplett zu lösen über den ersten Ansatz (überall ?version=XXXX) parameter hinzuzufügen. Aber genau dafür wäre es hilfreich wenn da mehr als 2 Augen drüberschauen könnten.

Wenn aber eQ-3 eine Lösung mit Webinterface verkauft, dann sollten sie imho entweder das Know-How inhouse aufbauen oder sich extern einkaufen. (oder alternativ dafür sorgen, dass sich da eine richtige OS Community bilden kann)

Ach Mensch, hört doch bitte auf dauernd solche abstrakten Dinge zu fordern oder gar zu erwarten. Einfach mal froh sein das eQ3 überhaupt etwas zur Verfügung stellt und auch Anpassungen die in der Community erarbeitet werden am Schluss irgendwann zurückfliessen. Inzwischen habe ich ja ein recht großes Sammelsurium an WebUI Patches im RaspberryMatic Repo gesammelt (https://github.com/jens-maus/RaspberryM ... tches/occu) und davon werden die meisten in einer der nächsten CCU2 Firmware übernommen werden. Insofern habe hier doch bereits eine Community und wenn wir Dinge für eQ3 erarbeiten können um unsere eigene Hausautomation auch nur ein stückweit zu verbessern dann sollten wir das tun und nicht dauernd den Finger Richtung eQ3 zeigen das die das doch machen sollten oder gar dauernd sagen das die doch aber damit Geld verdienen und deshalb dafür zahlen sollten. Beschweren kann man sich viel, nur ändern kostet eben etwas Anstrengung und in dem Bereich auch etwas selbstloses Herangehen...

[deimos]

Hi,

eine Variante wurde vor ein paar Tagen ja bereits beschrieben (weiß leider nicht wo und von wem): An die Url der Javascripts ein Url-Parameter mit der Version dranhängen, als z.B.

Code: Alles auswählen

<script src="/myJavascript.js?version=2.31.25"></script>

Und das dann idealerweise auch gleich für CSS mitmachen, da hat man sonst das gleiche Problem.

Genau so hatte ich mir das vorgestellt und auch auf meiner TODO. Die Frage wäre nun allerdings genau all die stellen in der WebUI rauszubekommen wo genau man so vorgehen müsste. Da könnte ich in der Tat Hilfe gebrauchen weil mir dafür nicht nur teilweise das knowhow sondern auch motivation und zeit fehlt

Die Anzahl an Javascript Dateien ist ja überschaubar. Dann einfach grep über alle für die WebUI relevanten Dateien und gut ist.
Jetzt kommt es aber ein bisschen drauf an, wie das Build-System bei eQ-3 aussieht, damit man das gescheit automatisieren kann. Das gibt es zig Möglichkeiten, welche je nach Gegebenheit mal besser mal schlechter sind.

Zweite Variante:
Im initialen Webserver die Cache-Header korrekt setzten. (also Last-Modified, ETag, Cache-Control: must-revalidate, Expires). Und dann in lighttpd dafür sorgen, dass die Header sauber durchgeleitet werden (macht der normalerweise von alleine, man kann es aber "kaputt" konfigurieren)

Wie du ja weisst wird lighttpd inzwischen als Proxy auch für ReGa eingesetzt und da ReGa nunmal die Webseiten ausliefert müsste lighttpd eben einmal so konfiguriert werden das es diese Header alle erzeugt bzw. man müsste man kontrollieren ob es das nicht bereits tut (wo ich nicht ganz sicher bin).

Offensichtlich werden die Header nicht korrekt gesetzt, sonst gäbe es ja nicht das Problem. Ohne es mir genau angeschaut zu haben, vermute ich aber eher mal, dass der initiale Webserver das Problem ist und dieser keine sauberen RFC konformen Header erzeugt. Ist einfach so ein Bauchgefühl aus meiner Zeit als ich noch aktiv Webentwicklung betrieben habe.

Dritte Variante:
lighttpd gleich die ganzen statischen Sachen ausliefern lassen (also Images, CSS, Javascript). Spart Resourcen und lighttpd setzt Cache-Header normalerweise korrekt (Auch hier wieder, "kaputt" machen ist möglich)

Das lighttpd die statischen Sachen direkt ausliefert wird so wohl nicht passieren, da eben ReGaHss im Grunde hier der Webserver ist und das jetzt alles in der ReGa umzustellen halte ich für einen zu großen Aufwand. Das muss auch anders gehen

Nö, eigentlich nicht. Man kann ja für einzelnen Unterordner (oder sogar Files) eigene Regeln im lighttpd definieren. Für den Webbrowser wäre das transparent unter der gleichen Url und damit müsste man an der Einbindung nichts ändern. Läuft rein über die lighttpd Config.

Wenn aber eQ-3 eine Lösung mit Webinterface verkauft, dann sollten sie imho entweder das Know-How inhouse aufbauen oder sich extern einkaufen. (oder alternativ dafür sorgen, dass sich da eine richtige OS Community bilden kann)

Ach Mensch, hört doch bitte auf dauernd solche abstrakten Dinge zu fordern oder gar zu erwarten. Einfach mal froh sein das eQ3 überhaupt etwas zur Verfügung stellt und auch Anpassungen die in der Community erarbeitet werden am Schluss irgendwann zurückfliessen. Inzwischen habe ich ja ein recht großes Sammelsurium an WebUI Patches im RaspberryMatic Repo gesammelt (https://github.com/jens-maus/RaspberryM ... tches/occu) und davon werden die meisten in einer der nächsten CCU2 Firmware übernommen werden. Insofern habe hier doch bereits eine Community und wenn wir Dinge für eQ3 erarbeiten können um unsere eigene Hausautomation auch nur ein stückweit zu verbessern dann sollten wir das tun und nicht dauernd den Finger Richtung eQ3 zeigen das die das doch machen sollten oder gar dauernd sagen das die doch aber damit Geld verdienen und deshalb dafür zahlen sollten. Beschweren kann man sich viel, nur ändern kostet eben etwas Anstrengung und in dem Bereich auch etwas selbstloses Herangehen...

Sorry, wenn eQ-3 Hilfe aus der Community haben will, dann müssen sie auch zurückgeben. Ich habe für piVCCU eine Anfrage gestellt, weil ich mir gerne den HmIP-RFUSB anschauen wollte und prüfen wollte, inwieweit der in piVCCU genutzt werden kann. Eine negative Antwort hätte ich verstanden, aber sie haben es nicht mal für nötig gehalten mir überhaupt zu antworten. Mit so einem Verhalten kann man jetzt nicht wirklich erwarten, dass ich dann ihre Hausaufgaben mache.
Und grade die Sachen mit den Javascripts: In den meisten Fällen ist sowas im Build-System besser aufgehoben, da kommt die Community nicht dran. Das mit Patches basierend auf OCCU zu machen, bedeutet im dümmsten Fall eine regelmäßige Anpassung des Patches bei jedem Release. Da habe ich in meiner Freizeit besseres zu tun.
Und wir reden hier ja nicht nur von RaspberryMatic oder OCCU, sondern wir reden von der CCU, für die eQ-3 bezogen auf die Hardware doch einen recht stolzen Preis verlangt. Da kann man als Nutzer schon erwarten, dass das Ding entsprechend entwickelt ist.

Viele Grüße
Alex

[Sammy]

EDIT: das war eigentlich als Antwort auf den Post von dtp auf der vorigen Seite gedacht. War zwischenzeitlich aber länger beschäftigt...

Es kommt natürlich immer darauf an, wo im WebUI Änderungen vorgenommen werden und ob man selber z.B. Geräte hat, die eine veränderte Ansicht, Datenpunkte oder ähnliches haben. Anscheinend wurde diesmal ja einer Stelle etwas geändert, was etwas größere (und vor allem sofort bemerkbare) Auswirkungen hatte.

[jmaus]

Genau so hatte ich mir das vorgestellt und auch auf meiner TODO. Die Frage wäre nun allerdings genau all die stellen in der WebUI rauszubekommen wo genau man so vorgehen müsste. Da könnte ich in der Tat Hilfe gebrauchen weil mir dafür nicht nur teilweise das knowhow sondern auch motivation und zeit fehlt

Die Anzahl an Javascript Dateien ist ja überschaubar. Dann einfach grep über alle für die WebUI relevanten Dateien und gut ist.
Jetzt kommt es aber ein bisschen drauf an, wie das Build-System bei eQ-3 aussieht, damit man das gescheit automatisieren kann. Das gibt es zig Möglichkeiten, welche je nach Gegebenheit mal besser mal schlechter sind.

Build-System? Die Dateien existieren genau so wie du sie im OCCU findest, nicht mehr und nicht weniger. D.h. wenn wir eine Möglichkeit finden die htm Dateien so anzupassen das die javascript includes vom browser cache bei einem update anders gehandhabt werden kann eQ3 den Patch so 1:1 übernehmen. Die Frage wäre eben nun, betrifft das nur die javascript Dateien oder welche Dateien könnten da auch noch im Cache landen die wir mit ähnlichen Methoden auch vor dem Browser Cache Problem schützen könnten?

Wie du ja weisst wird lighttpd inzwischen als Proxy auch für ReGa eingesetzt und da ReGa nunmal die Webseiten ausliefert müsste lighttpd eben einmal so konfiguriert werden das es diese Header alle erzeugt bzw. man müsste man kontrollieren ob es das nicht bereits tut (wo ich nicht ganz sicher bin).

Offensichtlich werden die Header nicht korrekt gesetzt, sonst gäbe es ja nicht das Problem. Ohne es mir genau angeschaut zu haben, vermute ich aber eher mal, dass der initiale Webserver das Problem ist und dieser keine sauberen RFC konformen Header erzeugt. Ist einfach so ein Bauchgefühl aus meiner Zeit als ich noch aktiv Webentwicklung betrieben habe.

Nun, was den Webserver im ReGa selber angeht, so kann ich das bestätigen. Ich könnte natürlich auch dafür einfach mir mal anschauen was notwendig ist damit dieser die richtigen Header ausliefert. Hast du mal ein Beispiel wie genau die auszusehen haben und welche Information da über was drinstecken müsste? Dann könnte ich die Response Header entsprechend anpassen und den internen Webserver etwas konformer machen und wir brauchen den "?version=X.X.X" trick nicht.

Das lighttpd die statischen Sachen direkt ausliefert wird so wohl nicht passieren, da eben ReGaHss im Grunde hier der Webserver ist und das jetzt alles in der ReGa umzustellen halte ich für einen zu großen Aufwand. Das muss auch anders gehen

Nö, eigentlich nicht. Man kann ja für einzelnen Unterordner (oder sogar Files) eigene Regeln im lighttpd definieren. Für den Webbrowser wäre das transparent unter der gleichen Url und damit müsste man an der Einbindung nichts ändern. Läuft rein über die lighttpd Config.

Das ist natürlich in der Tat möglich, würde ich jetzt aber erst einmal nicht so machen wollen und ggf. erst einmal den Webserver im ReGa versuchen entsprechend anzupassen damit der die richtigen Response header zurückgibt die für ein besseres browser cache management notwendig sind.

Sorry, wenn eQ-3 Hilfe aus der Community haben will, dann müssen sie auch zurückgeben.

Übersehe ich was? Die geben doch OCCU zurück und übernehmen sogar patches von mir. Du erwartest jetzt nicht wirklich das die wie Google oder Apple agieren und 100 Entwickler in die OpenSource community loslassen um jeden Drittenwickler den Bauch zu pinseln, oder? Ist halt einfach eine Frage von Ressourcen.

Ich habe für piVCCU eine Anfrage gestellt, weil ich mir gerne den HmIP-RFUSB anschauen wollte und prüfen wollte, inwieweit der in piVCCU genutzt werden kann. Eine negative Antwort hätte ich verstanden, aber sie haben es nicht mal für nötig gehalten mir überhaupt zu antworten. Mit so einem Verhalten kann man jetzt nicht wirklich erwarten, dass ich dann ihre Hausaufgaben mache.

Also als erstes muss ich sagen klingen mir deine Äußerungen hier viel zu pessimistisch und von sich selbst eingenommen. Das finde ich sehr traurig, denn eigentlich hatte ich gedacht wir könnten uns am Usertreffen einfach mal zusammensetzen und offen diskutieren. Wenn du aber alles nur negativ siehst dann wird es da eher schwierig mit dir in Kontakt zu treten oder Kontakt zu den eQ3 Entwicklern zu vermitteln. Und wenn du eine Frage zum HmIP-RFUSB hast, warum stellst du das dann abstrakt in ein Ticket bei eQ3 das dann Support-Mitarbeiter lesen? Ich hätte dir kurzerhand den direkten Kontakt vermittelt zu den eQ3 Entwicklern die schon seit Tag 1 sehr offen für alle möglichen Dinge sind (wenn man selbst offen und geduldig genug ist, versteht sich).

Und grade die Sachen mit den Javascripts: In den meisten Fällen ist sowas im Build-System besser aufgehoben, da kommt die Community nicht dran. Das mit Patches basierend auf OCCU zu machen, bedeutet im dümmsten Fall eine regelmäßige Anpassung des Patches bei jedem Release. Da habe ich in meiner Freizeit besseres zu tun.
Und wir reden hier ja nicht nur von RaspberryMatic oder OCCU, sondern wir reden von der CCU, für die eQ-3 bezogen auf die Hardware doch einen recht stolzen Preis verlangt. Da kann man als Nutzer schon erwarten, dass das Ding entsprechend entwickelt ist.

Dann hast du leider ein falsches Bild davon wie das ganze so organisiert wird und welche Ressourcen eQ3 so zur Verfügung stehen. Schau in das OCCU repository oder in das /www Verzeichnis auf der CCU2 und du weisst genau wie das aussieht, mehr verbirgt sich dahinter nicht und da wird auch bis auf wenige ausnahmen etwas in einem build system zusammengebastelt. D.h. also jegliche Änderung die du unter /www vornimmt und für die du patches bereitstellen kannst wird dann auch so von eQ3 übernommen werden können - größere Magie ist da nicht dahinter. Und die Patches bis zur integration zu pflegen ist jetzt auch nicht wirklich aufwändig. Das kannst du an meinem RaspberryMatic repository sehen. Dort pflege ich die patches auch und das semi-automatisch und ohne großen Aufwand. Vorteil ist, das so eQ3 direkt in die Patches reinschauen kann um diese dann ggf. zu übernehmen (wenn sie sie für sinnvoll erachten). Ich kann also nur nochmal darum bitten nicht so verschlossen zu argumentieren und immer zu versuchen eQ3 den schwarzen peter zuzuschieben. Besser man betreibt da Hilfe zur Selbsthilfe, entwickelt die Änderungen an der WebUI die einem selbst wichtig erscheinen und trägt sie geordnet eQ3 dann vor. Damit bin ich bis jetzt sehr gut gefahren und eQ3 ist mir immer mit Offenheit entgegen getreten.

[jmaus]

Hallo Alexander,

Das lighttpd die statischen Sachen direkt ausliefert wird so wohl nicht passieren, da eben ReGaHss im Grunde hier der Webserver ist und das jetzt alles in der ReGa umzustellen halte ich für einen zu großen Aufwand. Das muss auch anders gehen

Nö, eigentlich nicht. Man kann ja für einzelnen Unterordner (oder sogar Files) eigene Regeln im lighttpd definieren. Für den Webbrowser wäre das transparent unter der gleichen Url und damit müsste man an der Einbindung nichts ändern. Läuft rein über die lighttpd Config.

Das ist natürlich in der Tat möglich, würde ich jetzt aber erst einmal nicht so machen wollen und ggf. erst einmal den Webserver im ReGa versuchen entsprechend anzupassen damit der die richtigen Response header zurückgibt die für ein besseres browser cache management notwendig sind.

Hab mir gerade das nochmal im Chrome Entwicklungsmodus nochmal genauer angeschaut um zu sehen woher die .js Dateien so kommen und war überrascht zu sehen, das die anscheinend in der Tat bereits vom lighttpd ausgeliefert werden und das auch mit ETag und Last-Modified. Siehe:

Und das betrifft auch die .css Dateien. Wenn ich mir hingegen anschaue woher die .htm Dateien kommen dann kommen die anscheinend wirklich aus dem Webserver von ReGaHss:

Die Frage wäre also in der Tat wieso das Browser Cache Problem trotzdem zuschlägt wo doch die .js und .css Dateien anscheinend korrekt über lighttpd ausgeliefert werden.

[deimos]

Hi,

Also als erstes muss ich sagen klingen mir deine Äußerungen hier viel zu pessimistisch und von sich selbst eingenommen. Das finde ich sehr traurig, denn eigentlich hatte ich gedacht wir könnten uns am Usertreffen einfach mal zusammensetzen und offen diskutieren. Wenn du aber alles nur negativ siehst dann wird es da eher schwierig mit dir in Kontakt zu treten oder Kontakt zu den eQ3 Entwicklern zu vermitteln.

Wenn das so rüberkommt, dann tut mir das leid. Ich weiß, dass ich ein sehr guter Entwickler bin (in den Bereichen, in denen ich mich rumtreibe), aber genau so gibt es viele deutlich bessere als mich. Und alles Feedback, welches ich im beruflichen Umfeld bekomme, bestätigt mir, dass ich relativ gut weiß, wo ich mich einsortieren kann.

Ich sehe auch nicht alles pessimistisch. Die Hardware von Homematic finde ich super. Aber bei der Software sind einfach eine Menge an Macken drin. Da mögen sicherlich eine Menge technologischer Schulden drin sein und der Job, den die Entwickler bei eQ-3 haben ist sicherlich aufgrund der Größe der Abteilung und der Menge an Themen schwierig.
Aber man muss auch mal sehen, welcher Preis für die Hardware aufgerufen wird und wie die Selbstdarstellung des Unternehmens ist. Und da entsteht bei mir eine gewisse Erwartungshaltung. Mag sein, dass die falsch ist.

Von meiner Seite aus können wir uns gerne beim Usertreffen zusammensetzen. Und wenn du magst, könntest du gerne mir auch gerne Kontakt zum Produktmanagement vermitteln. Ich hätte da zwei Ideen, welche sicherlich für viele User interessant wären. (Geht in Richtung FBH Steuerung)

Und wenn du eine Frage zum HmIP-RFUSB hast, warum stellst du das dann abstrakt in ein Ticket bei eQ3 das dann Support-Mitarbeiter lesen? Ich hätte dir kurzerhand den direkten Kontakt vermittelt zu den eQ3 Entwicklern die schon seit Tag 1 sehr offen für alle möglichen Dinge sind (wenn man selbst offen und geduldig genug ist, versteht sich).

Überspitzt gefragt: Bist du das Sekretariat der Entwickler?
Ich denke, es ist nicht ganz unverständlich, dass ich die offiziellen Kontaktmöglichkeiten eines Unternehmens nutze, um mit diesem in Kontakt zu treten. Und mag sein, dass meine Erwartungshaltung da wieder falsch ist, aber ich wünsche mir schon, dass ein Support-Mitarbeiter auf eine Anfrage entweder mit "Sorry, ist nicht" antwortet oder es intern weiterleitet, wenn er es selber nicht beantworten kann oder darf.

Wegen der ganzen Caching Sachen: Ich versuch mir das mal anzuschauen und mach einen Patch bzw. gib dir Infos, ob und ggf. was im Rega Webserver angepasst werden müsste. Das kann aber ein paar Tage dauern.

Viele Grüße
Alex

[deimos]

Hallo Jens,

ich habe mir das ganze mal etwas angeschaut:

Die ganzen statischen Sachen der WebUI werden alle bereits rein vom Lighttpd ausgeliefert. Dieser setzt auch korrekt ETag und Last-Modified.
Allerdings werden keine Cache-Control Header gesetzt, was insb. den Firefox dazu bringt JS und CSS recht aggressiv zu cachen.

Ich habe grade einen PR beim OCCU GitHub Projekt eingekippt, welches für JS und CSS entsprechende Cache-Header setzt. Das wird sich aber erst in der übernächsten Version positiv auswirken, weil die Header in der nächsten Version erst gesendet würden, aber der Browser das erst nach einem Forced Refresh mitbekommt, weil er hat das Zeug ja noch von dieser Version im Cache liegen.

Ich war auch etwas erstaunt zu sehen, dass das mit dem Versionsparameter teilweise schon vorhanden ist. Allerdings in mind. 3 verschiedenen Varianten (CCU Firmware Version, JSQuery-Version (auch bei CCU JS Dateien), große Zahl (Unix Timestamp, Hash? Keine Ahnung)). Irgendjemand bei eQ-3 muss sich die Gedanken also schon mal gemacht haben, aber dann leider nicht konsequent beendet haben.

Bevor man das Thema mit den Versionsnummer angeht, sollte man daher in meinen Augen mal diskutieren, auf welche Methode man das vereinheitlicht.

Viele Grüße
Alex