nicedates.js: Hübsche (relative) Zeitangaben mit Longpoll-Support

[peterk_de]

Uh, an die Logfiles habe ich gar nicht gedacht, da ich die selbst nicht verwende. Da sollte natürlich keine Ersetzung passieren, vor allem aber keine falsche.

- Wegen der falschen Berechnung: Mit aktuellen Daten kann ich es reproduzieren, mit dem aktuellen Datumsformat im Filelog kommt die moment.js nicht klar, da es keine ISO-Zeitstempel sind, aber mein Regex zum Suchen von Datumswerten trotzdem matcht.

- Ausschalten für bestimmte Seiten (auch die Logs) geht momentan per Regex (searchScope). Allerdings kann man damit nur eine "Whitelist" definieren, nicht einzelne Seiten ausknippsen ... also im Prinzip geht das schon, nur werden die Regulären Ausdrücke dann ziemlich hässlich ... das könnte ich mal mittelfristig noch verbessern.

Ich würde jedenfalls als Workaround empfehlen, den Datums-Such-Regex in der fhem_nicedates.js zu ersetzen und etwas genauer auf die ISO-Zeitstempel festzuschnüren, wie FHEM sie im Webinterface, aber netterweise nicht in den Logs verwendet. Such in der fhem_nicedates.js mal folgende Zeile (bei mir Zeile 43):

Code Auswählen Erweitern


const timestampRegex = /(\d{4})-(\d{2})-(\d{2}).(\d{2}):(\d{2}):(\d{2})/g;


Und ersetze sie durch:

Code Auswählen Erweitern


const timestampRegex = /(\d{4})-(\d{2})-(\d{2}) (\d{2}):(\d{2}):(\d{2})/g;


Dann sollten die Logfiles von Ersetzungen verschont bleiben. Falls das klappt, baue ich es oben in die Datei ein bzw. mache den Regex mal noch als Parameter User-konfigurierbar.

Ansonsten, Kannst du mir mal noch ein-zwei der uralten und mit falsch berechneten Datum formatierten Logzeilen (ohne aktiviertes nicedates.js oder außerhalb von FHEM direkt aus der Filelog-Datei kopiert) posten? Dann kann ich mal gucken warum der die zwar frisst, aber dann ein falsches Datum ausspuckt.

[ToJu]

Hallo,

Und ersetze sie durch:

Code Auswählen Erweitern


const timestampRegex = /(\d{4})-(\d{2})-(\d{2}) (\d{2}):(\d{2}):(\d{2})/g;


Danke, das löst das Problem bei mir. Bezüglich der alten Logfiles habe ich mich wohl falsch ausgedrückt. Ich wollte damit nur verdeutlichen, dass die angezeigten "Sekunden" nicht annähernd stimmten. Es funktionert mit dem neuen Regex natürlich auch bei alten Logfiles  Danke für die schnelle Lösung.

Achtung: Ich habe noch festgestellt, dass das Datum auch ersetzt wird, wenn man "Edit files" benutzt. Wenn in den dort bearbeiteten Dateien ein entsprechend kodiertes Datum vorkommt, wird es auch ersetzt und später dann "übersetzt" gespeichert. Auch wenn die harte Codierung von Datumsangaben in den Konfigurationen etc. eher selten vorkommen sollte, kann das doch zu erheblichen Problemen führen oder auch Konfigurationen beschädigen. Vielleicht könnte man zumindest diese Seiten auf eine Blacklist setzen oder Eingabefelder allgemein komplett aus dem Übersetzen herausnehmen.

Grüße,
Torben

P.S.: Das Problem bei Edit Files konnte ich sowohl mit dem "default" Editor als auch mit fhem_codemirror.js reproduzieren.

[peterk_de]

Hi ToJu,

danke für den Hinweis. Das hatte ich extra durch Tests verifiziert gehabt, dass genau das nicht passiert ... komisch, vielleicht hat sich da durch die Updates jetzt was geändert. Da werde ich dann wohl doch noch einen Patch bauen müssen, dass er in <text> und <input>-Elementen nichts ersetzt.

Edit: Kann es reproduzieren - Fix dauert etwas.

[ToJu]

Hallo,

gut, es ist ja auch nicht überall so, dass es zu viel ersetzt wird. Wenn man an einem Device einen entsprechenden comment hinzufügt, dann wird das unten in den Attributen zwar ersetzt, wenn ich aber darauf klicke, um es zu editieren, dann wird es nicht ersetzt im Eingabefeld. Das funktioniert also.

Danke nochmals für das hübsche Datum

Grüße,
Torben

[peterk_de]

Achtung: Ich habe noch festgestellt, dass das Datum auch ersetzt wird, wenn man "Edit files" benutzt. Wenn in den dort bearbeiteten Dateien ein entsprechend kodiertes Datum vorkommt, wird es auch ersetzt und später dann "übersetzt" gespeichert. Auch wenn die harte Codierung von Datumsangaben in den Konfigurationen etc. eher selten vorkommen sollte, kann das doch zu erheblichen Problemen führen oder auch Konfigurationen beschädigen. Vielleicht könnte man zumindest diese Seiten auf eine Blacklist setzen oder Eingabefelder allgemein komplett aus dem Übersetzen herausnehmen.

Anbei eine korrigierte Version. Magst du die mal testen? Filelogs sollten darin wie gehabt nicht mehr ersetzt werden, der neue Regex ist drin, und nun auch keinerlei Input/Textarea-Felder mehr. Außerdem habe ich das Script-Laden ein Stück weit geändert, so wie es im neuen FHEMweb vorgesehen ist (allerdings noch nicht alles). Haut bei mir überall hin, außer auf der Seite "Everything" (vermutlich ein Timing-Problem). Wenn es sonst keine Probleme gibt damit, aktualisiere ich das Eingangsposting damit.

[ToJu]

Hallo,

mit der neuen Dateiversion treten bei mir die genannten Probleme nicht mehr auf. Auch das Ersetzten im Editor findet nicht mehr statt.
Die Seite "Everything" hatte ich seit Ewigkeiten nicht mehr aufgerufen, die ist mittlerweile etwas groß für meinen Raspberry   Ich habe es trotzdem mal versucht: Bei mir fanden die Ersetzungen nach einiger Zeit korrekt statt.
Vielen Dank für die schnelle Korrektur.

Grüße,
Torben

[KernSani]

keine Ahnung, wo bei mir jetzt was schief läuft, mit der neuen Version, aber das sieht garnicht gut aus...

[peterk_de]

Na man gut, dass ich sie noch nicht ins Anfangsposting geschoben habe Kannst du mal nicedates ausknipsen und nen Screenshot von genau derselben Stelle machen? (Oder noch besser den HTML-Source von der Tabelle posten) ... An dem Regex mit dem ich suche hat sich nämlich genau nur ein Zeichen geändert ... Ist mir so spontan schleierhaft wo das jetzt herkommen kann ...

[KernSani]

Ja, sehr seltsam... irgendwie verpasst er jedem einzelnen DOM-Element jetzt den data-absolute-timestamp...

Ich muss da aber auch nochmal bei mir gucken... das ist nur auf der Tablet-Version (an de ich einiges Gefummelt habe) so. im Standard darkstyle funktioniert es.

Nicedates nicht ausgeknipst, aber alte Version:

Code Auswählen Erweitern

<a href="/fhem?detail=EG_RolladenAZiLinks">EG Arbeitszimmer (Links &amp; Mitte)</a>

Neue Version:

Code Auswählen Erweitern

<a href="/fhem?detail=EG_RolladenAZiLinks" data-absolute-timestamp="EG Arbeitszimmer (Links &amp; Mitte)">vor ein paar SekundenEvor ein paar SekundenGvor ein paar Sekunden vor ein paar SekundenAvor ein paar Sekundenrvor ein paar Sekundenbvor ein paar Sekundenevor ein paar Sekundenivor ein paar Sekundentvor ein paar Sekundensvor ein paar Sekundenzvor ein paar Sekundenivor ein paar Sekundenmvor ein paar Sekundenmvor ein paar Sekundenevor ein paar Sekundenrvor ein paar Sekunden vor ein paar Sekunden(vor ein paar SekundenLvor ein paar Sekundenivor ein paar Sekundennvor ein paar Sekundenkvor ein paar Sekundensvor ein paar Sekunden vor ein paar Sekunden&amp;vor ein paar Sekunden vor ein paar SekundenMvor ein paar Sekundenivor ein paar Sekundentvor ein paar Sekundentvor ein paar Sekundenevor ein paar Sekunden)vor ein paar Sekunden</a>

meine Parameter:

Code Auswählen Erweitern

{"locale" : "de", "mode" : "fromNow","verbose" : "5"}

[peterk_de]

Wenn du data-absolute-timestamp dort nicht selbst gesetzt hast,  dann ist der Such-Regex bei dir wohl kaputt und matcht auf jeden Elementtext, sonst würde das Attribut nicht schon bei Elementen gesetzt werden, die gar keine Zeitstempel enthalten.

Mach mal die JavaScript-Konsole im Browser auf (Element untersuchen / Element in Firebug untersuchen o.Ä.) und poste  mal die Ausgabe nach einem Page-Reload (verbose 5 hast du ja schon gesetzt). Danach mal noch in die JavaScript-Konsole timestampRegex eingeben und Enter, dann gibt er dir aus, was in der Variable drinsteht (meine Vermutung: nicht das was drinstehen sollte - z.B. gar nix)

[KernSani]

Problem gefunden: Es gibt ein weiteres Script, das ebenfalls die globale Variable "attr" definiert... die überschreiben sich dann gegenseitig. Vielleicht "attr" in "nicedatesAttr" o.ä. umbenennen um Konflikte auszuschliessen.

Grüße,

Olli

[peterk_de]

Arrrrrrrr, ich Idiot. Da hätte ich auch selbst drauf kommen können zumal ich das Parameter-Konzept aus anderen Widgets abgekupfert habe, leider samt Variablennamen Wird morgen geliefert.

[KernSani]

Dito

[peterk_de]

So per Definition ist jetzt morgen - hier die gefixte Version, mal gucken ob es hilft Danke fürs Fehlerfinden!!!

[KernSani]

per Definition ist jetzt morgen

So gesehen war ja gestern schon heute, als du "morgen" gesagt hast

hier die gefixte Version

Test muss bis heute abend warten.

Danke,

Oli