[FTUI3] new Departure für FTUI3

[mr_petz]

@mr_petz

Die css-Datei hat sich gegenüber gestern nicht geändert. Trotzdem nochmal bereitstellen?
gilt für das js-Modul und heisst nur, dass elementMinutes ausschließlich am Ende der fillList-Routine gesetzt wird - ohne Berücksichtigung...

Ok Missverständnis... hat sich dann erledigt.

[OdfFhem]

@mr_petz

Aus nachher wurde dann doch viel später ...

Ich habe mich mal mit dem Wert für die Anzeige beschäftigt und folgenden Vorschlag:
- Festlegung eines Refrenzdatums (bei sich aktualisierender list gemäß Reading ; bei statischer list gemäß aktueller Zeit)
- falls deptime gewünscht und Anlieferung von Uhrzeiten (Wert wird 1:1 übernommen)
- ansonsten Berechnung des darzustellenden Wertes
- ein berechneter Minutenwert passt sich dem Darstellungszeitpunkt an ("Ausblenden", falls Wert in der Vergangenheit liegt bzw. wird mit fortschreitender Zeit kleiner)
- die auskommentierten Stellen sind nur zum Probieren enthalten ...

Module hochgeladen; diesmal der Vollständigkeit halber beide - css hat sich aber eigentlich nicht geändert.
... wenn die Module aus dem Beitrag entfernt werden können, bitte kurz Bescheid geben.

[mr_petz]

Danke hab es....

[mr_petz]

@OdfFhem

Ich habe jetzt mal noch bissl getestet und geproggt. Sorry hatte nicht viel Zeit...
Ich konnte das addieren der Zeit jetzt auch nachvollziehen und abstellen. (Minuten werden jetzt auch kleiner mit fortschreitender Uhrzeit)
Bei deiner Anpassung würde ich "nur" die Ref.Zeit vom timestamp des Reading übernehmen.
Da würde ich dann nur dateFromString und getReadingID importieren. setstate sagte mal, dass wenn alles im Code ist, eine bessere performance zu erwarten ist...
Danke dafür.
Jetzt zum offlinetesten lasse ich erstmal einen timestamp ins localStorage speichern. (wird dann abgeändert)
In dieser Version ist es egal ob time oder min vom Reading kommen.
Es ist auch egal ob deptime oder depmin gesetzt ist.
Nach erreichen/überschreiten der Abfahrtszeit wird DEP in die entsprechende Reihe "in Min" / "Zeit" gesetzt.
Also bei beiden steht dann DEP.
Nachteil hier wäre bei einem time Reading, dass bei einer Abfahrt nach 00:00Uhr und es ist noch nicht 00:00Uhr hier auch DEP stehen würde. Müsste ich erst (muss ich noch) wieder ne neue Berechnung machen...
Das DEP macht natürlich nur bei einer statischen (manuellRefresh) Liste sinn.
Des Weiteren habe ich da einen separaten intervalTimer als Attribute integriert um die statische Liste zu aktualisieren und den "Effekt ->DEP" zu sehen wenn gewünscht.
Wenn du es gern testen möchtest bevor ich weiter mache, würde ich die Version hier anhängen. Sag einfach Bescheid.
Danke und Gruß

Edit Angehängt...
Es ist halt doch ein Nachteil die Abfahrt in time zu bekommen. lässt sich so ohne weiteres nicht unterscheiden wenn "DEP"...
Muss man das array "zerpflücken"...
Es fliegen auch noch paar Sachen raus die unnütz sind. Die sind nur zum testen drin...
Ich musste auch zusätzlich ein time setzen, sonst würden sich immer Zeit und Minuten bei depmin und deptime in die quere kommen...

[OdfFhem]

@mr_petz

Teste ich gerne ...

Anmerkungen:

• 
  DEP zu dominant und steht klar im Vordergrund; eigentlich sollte der Eintrag in den Hintergrund treten oder vielleicht sogar ganz verschwinden
  
• 
  Funktionalität á la Attribut maninterval finde ich nicht schlecht; den Namen eher "schwierig", da es mit manuell eigentlich nichts zu tun hat. Ich habe eine Seite mit z.B. 6 Abfahrten im Einsatz; 4 davon werden in einem bestimmten Tagesabschnitt im 5 Minutentakt aktualisiert; die restlichen 2 durch manuelle Bedarfsaktualisierung. Für alle 6 gilt, die eingefrorenen Werte sollen die Nutzer auf dem Laufenden (minütliche Aktualisierung der Anzeige) halten ...
  
• 
  Verwendung von maninterval="60".
  - Anlieferung aus FHEM in Minuten und Anzeige in Minuten --> keinerlei Änderungen zu sehen, es flackert nur.
  - Anlieferung aus FHEM in Minuten und Anzeige in Zeit --> Änderungen sichtbar.
  - Statische Angaben in Minuten und Anzeige in Minuten --> Änderungen sichtbar.
  - Statische Angaben in Minuten und Anzeige in Zeit --> Änderungen sichtbar.
  - Statische Angaben in Zeit und Anzeige in Minuten --> Änderungen sichtbar; Zeiten für frühestens Morgen trotzdem DEP.
  - Statische Angaben in Zeit und Anzeige in Zeit --> Änderungen sichtbar; Zeiten für frühestens Morgen trotzdem DEP.
  
• 
  Wofür ist localStorage? Wird ja nirgendwo nochmals benutzt. Wieso wird bei automatischem refresh kein neuer Zeitstempel gesetzt? Besser würde man diesen Zeitstempel zentral in der fillList-Routine (via Parameter resetTime, o.ä.) und nicht "überall" setzen.
  
• 
  Der Sinn von this.Mode hat sich mir noch nicht erschlossen. Die Daten "sagen", was sie liefern und this.depMode sagt, was draus werden soll. Mehr muss man eigentlich nicht wissen ...
  
• 
  Wichtig in meinen Augen: ein (kleiner) Block kümmert sich um die Umrechnung von Eingangswerten in DatumZeit-Werte, ein anderer(,kleiner) Block um die Formatierung von DatumZeit-Werten für die Anzeige. Code wird deutlich kompakter ... und übersichtlicher ...
  

Klingt vielleicht schlimm, ist aber alles nur als Anmerkung zu verstehen und erzwingt natürlich keinerlei Änderungen.

[mr_petz]

@OdfFhem
Danke fürs testen und für´s Feedback.

DEP zu dominant und steht klar im Vordergrund; eigentlich sollte der Eintrag in den Hintergrund treten oder vielleicht sogar ganz verschwinden

man kann hier auch wie du "-" bei minuten oder "--:--" bei Zeit nehmen oder das konfigurierbar machen???

Funktionalität á la Attribut maninterval finde ich nicht schlecht; den Namen eher "schwierig", da es mit manuell eigentlich nichts zu tun hat.  ...

Ja, das soll auch nur für eine statische Liste fungieren  mit Benutzung des manrefresh. Ich hatte das so verstanden, dass du eine statische Liste von 00:00Uhr bis 23:59Uhr hast.
Der Name war frei von der Leber weg benannt. Wie wäre statinterval?
Zum holen aktueller Daten sollte man dann lieber interval nutzen oder?

Verwendung von maninterval="60".
- Anlieferung aus FHEM in Minuten und Anzeige in Minuten --> keinerlei Änderungen zu sehen, es flackert nur.

wie gerade vorher beschrieben...

- Statische Angaben in Zeit und Anzeige in Minuten --> Änderungen sichtbar; Zeiten für frühestens Morgen trotzdem DEP.
- Statische Angaben in Zeit und Anzeige in Zeit --> Änderungen sichtbar; Zeiten für frühestens Morgen trotzdem DEP.

steht noch auf der Agenda... bei Daten in Minuten ist es recht einfach. Daten in Zeit ganz schwierig..

Wofür ist localStorage? Wird ja nirgendwo nochmals benutzt. Wieso wird bei automatischem refresh kein neuer Zeitstempel gesetzt? Besser würde man diesen Zeitstempel zentral in der fillList-Routine (via Parameter resetTime, o.ä.) und nicht "überall" setzen.

Hatte ich im Beitrag oben schon gesagt dass das nur hier zum testen ist, weil ich jetzt hier keine Verbindung zu fhem habe um den timestamp als referenz vom reading zu holen. Ich integriere da deine Lösung.

Der Sinn von this.Mode hat sich mir noch nicht erschlossen. Die Daten "sagen", was sie liefern und this.depMode sagt, was draus werden soll. Mehr muss man eigentlich nicht wissen ...

Habe ich oben auch schon geschrieben. Wenn man die gleichen Berechnungen mit oder ohne depmin/deptime nimmt, dann kommen die beiden sich in die quere wenn man bei Zeit und oder minuten Reading switcht sodass man in beiden (jetzt noch) "DEP" stehen haben möchte.
Ansonsten würde halt immer die abgelaufene Zeit noch stehen bleiben. Ist das so gewünscht?
Deswegen setze ich bei match ":" vom Reading ein time (also this.Mode) um eine zusätzliche Variable zum Vergleich zu haben.

Wichtig in meinen Augen: ein (kleiner) Block kümmert sich um die Umrechnung von Eingangswerten in DatumZeit-Werte, ein anderer(,kleiner) Block um die Formatierung von DatumZeit-Werten für die Anzeige. Code wird deutlich kompakter ... und übersichtlicher ...

Wenn ich nur immer wüste was Kompakt ist . Wie gesagt für mich ist das alles noch Lernmaterial was du mir als Lösungsvorschlag gezeigt hast. Ich muss dann erst nachlesen und nachvollziehen was dahinter steckt und wie es funktioniert. Deswegen wollte ich auch nicht so viele externe funktionen importieren.
Machst du und setstate das auch Beruflich? man könnte es denken

Nagut. Mal sehen was ich hier dann noch mit dem Zeitreading mache was nach Mitternacht ist...

[OdfFhem]

@mr_petz

man kann hier auch wie du "-" bei minuten oder "--:--" bei Zeit nehmen oder das konfigurierbar machen???

Ich würde im ersten Schritt vielleicht wirklich die oben genannten "Platzhalter" nehmen; im zweiten Schritt würde ich dann evtl. versuchen, die abgelaufenen Infos zu überlesen - kennt man ja aus dem täglichen Umgang mit den Anzeigetafeln des ÖPNV.

Ja, das soll auch nur für eine statische Liste fungieren  mit Benutzung des manrefresh. Ich hatte das so verstanden, dass du eine statische Liste von 00:00Uhr bis 23:59Uhr hast.
Der Name war frei von der Leber weg benannt. Wie wäre statinterval?
Zum holen aktueller Daten sollte man dann lieber interval nutzen oder?

Ich würde es auch für nicht statische Listen gelten lassen, da es genügend Haltestellen gibt, bei denen keine minütliche Aktualisierung via FHEM notwendig ist (eine zentrale Haltestelle braucht das, eine dörflliche Haltestelle eher nicht).
Mit dem Attribut würde ich auch eher nur ermöglichen, dass man diesen Effekt aktiviert (ohne Wertangabe - vergleichbar zu z.B. switch) - ich unterstelle einfach mal die Erwartung von minütlicher Aktualisierung. Koppeln würde ich den Effekt dann an das bereits vorhandene Uhrzeit-Intervall, da dies ja sowieso jede Minute aktualisiert wird. Name ist so 'ne Sache: vielleicht "refresh-time" (wegen 3.Spalte) oder "refresh-body" (spätestens interessant beim Überlesen) oder ...

Hatte ich im Beitrag oben schon gesagt dass das nur hier zum testen ist, weil ich jetzt hier keine Verbindung zu fhem habe um den timestamp als referenz vom reading zu holen. Ich integriere da deine Lösung.

Im Grunde will man den timestamp (als Referenzzeit) immer festlegen, aber nur neu festlegen, wenn neue Daten kommen; das heisst bei Änderung von "list". Dort könnte man einen Parameter true an fillList übergeben, durch den dann der timestamp neu festlegt wird. Die beiden anderen Aufrufe von fillList übergeben false und am timestamp ändert sich nichts. Man will ja auch nur die Anzeige neu aufbauen. Mit einem solchen Parameter könnte man das Handling an eine zentrale Stelle ziehen ...
localStorage scheint mir in diesem Zusammenhang überflüssig, da Du ja immer ein neues Datum für den localStorage generierst und es dann sofort in this.timeNow "umspeicherst". Ohne localStorage und mit direkter Generierung für this.timeNow sollten die gleichen Verhältnisse gelten.

Wenn man die gleichen Berechnungen mit oder ohne depmin/deptime nimmt, dann kommen die beiden sich in die quere ...

... Konflikte kann ich keine erkennen ...
Minutenangaben sind immer relative Angaben ... diese müssen nur zum timestamp addiert werden ... fertig.
Zeitangaben sind absolute Angaben und müssen bzgl. timestamp umgerechnet werden. Wenn man unterstellt, dass zum timestamp-Zeitpunkt keine alten Daten geliefert werden, wird bei der Umrechnung ein Vergangenheitswert in die Zukunft katapultiert. Um 20:52 wird also aus 10:27 nicht "abgelaufen", sondern "ist ja (frühestens) erst morgen". Frühestens deshalb, weil es etliche Schnellbusse gibt, die am Freitagabend ihren Dienst einstellen und melden, dass die nächste Abfahrt um 09:15 ist - dies bedeutet aber nicht wirklich morgen, sondern Montag.
Relative Angaben sind eigentlich immer genau. Absolute Angaben klingen genauso, machen aber eigentlich nur Sinn, wenn sie nicht nur eine (datumlose) Zeit liefern, sondern einen datumbehafteten Zeitstempel für die Abfahrtszeit - VVO hat ja z.B. auch einen solchen Wert parat.

Deswegen wollte ich auch nicht so viele externe funktionen importieren.

Externe Funktionen aus z.B. ftuiHelper gehören ja quasi zum Werkzeug für Entwickler. Da bei FTUI3 ftuiHelper sowieso vollständig geladen ist, weiss ich nicht, ob man beim Ausschluss viel spart - da müsstest Du setstate fragen. Ich selbst nutze z.B. gerne den kompletten Werkzeugkoffer, weil man dann den Überblick behält, woher eine eingesetzte Funktion kommt: ftuiHelper.xyz ist verständlicher als einfach nur xyz. Aber muss bzw. kann jeder selbst entscheiden und was man brauchen kann, sollte man auf jeden Fall auch laden.

Machst du und setstate das auch Beruflich? man könnte es denken

Bei setstate kenne ich die Antwort natürlich nicht.
Bei mir weiss ich, dass ich JavaScript nur fürs Hobby nutze ... das aber gerne ...

Wie gesagt für mich ist das alles noch Lernmaterial was du mir als Lösungsvorschlag gezeigt hast. Ich muss dann erst nachlesen ...

Nachlesen ist nie schlecht, aber für den ersten Schritt könnte ich Dir auch die wenigen, relevanten Zeilen der fillList-Routine in einer kommentierte Fassung zur Verfügung stellen, wenn Du willst ...

[mr_petz]

@OdfFhem
Hi.

Nachlesen ist nie schlecht, aber für den ersten Schritt könnte ich Dir auch die wenigen, relevanten Zeilen der fillList-Routine in einer kommentierte Fassung zur Verfügung stellen, wenn Du willst ...

Ja gerne. Damit würdest du mir sehr helfen und ich würde wieder was dazu lernen. 
Bin noch unterwegs. Hätte erst ab Mittag Zeit.
Kurz wegen Handy...

[OdfFhem]

@mr_petz

Mache ich gerne ... vor früher Nachmittag fehlt mir allerdings Zeit und auch Zugriff ...

Hänge ich dann hier temporär an ...

[mr_petz]

Koppeln würde ich den Effekt dann an das bereits vorhandene Uhrzeit-Intervall, da dies ja sowieso jede Minute aktualisiert wird. Name ist so 'ne Sache: vielleicht "refresh-time" (wegen 3.Spalte) oder "refresh-body" (spätestens interessant beim Überlesen) oder ...

Der Uhrzeit intervall ist doch jede sekunde, oder?

Ohne localStorage und mit direkter Generierung für this.timeNow sollten die gleichen Verhältnisse gelten.

ja da hast du Recht.

Zeitangaben sind absolute Angaben und müssen bzgl. timestamp umgerechnet werden. Wenn man unterstellt, dass zum timestamp-Zeitpunkt keine alten Daten geliefert werden, wird bei der Umrechnung ein Vergangenheitswert in die Zukunft katapultiert. Um 20:52 wird also aus 10:27 nicht "abgelaufen", sondern "ist ja (frühestens) erst morgen". Frühestens deshalb, weil es etliche Schnellbusse gibt, die am Freitagabend ihren Dienst einstellen und melden, dass die nächste Abfahrt um 09:15 ist - dies bedeutet aber nicht wirklich morgen, sondern Montag.

Das würde ja bedeuten, dass für Montag über 2880min da stehen würden. Richtig?
Oder wird der Montagsbus dann nicht angezeigt?
Wenn man jetzt umswitcht auf Uhrzeit, dann würde doch auch nur die absolute Uhrzeit stehen. Oder?
Wäre es dann nicht da auch gut ein Wochentag in Kurzform (Mo, Di) auszugeben/anzuhängen?

Absolute Angaben klingen genauso, machen aber eigentlich nur Sinn, wenn sie nicht nur eine (datumlose) Zeit liefern, sondern einen datumbehafteten Zeitstempel für die Abfahrtszeit - VVO hat ja z.B. auch einen solchen Wert parat.

Das habe ich ja jetzt auch durch deine Hinweise und durchs Testen mitbekommen.
Die VVO sendet ja eine UNIX-Zeit. Da könnte ich ja den Wochentag oder das Datum mit ins JSON String schreiben lassen. Dann müsste ich das Array[3] im Modul auswerten. Ich bin glaube nicht der einzige der hier nur die Uhrzeit sich anzeigen lässt und von fhem bekommt.
Gerade wie du beschreibst auf dem "Lande" fahren die Busse im 30min Takt und da wäre eine Minutenanzeige nicht gut.
Ich lasse hier den interval timer laufen.

Bei mir weiss ich, dass ich JavaScript nur fürs Hobby nutze ... das aber gerne ...

Machst du gut.

[OdfFhem]

@mr_petz

Ich habe Deinen Beitrag kurz überflogen, kann aber noch nicht viel dazu sagen, da ich auf dem Sprung bin ...

Aber ich hänge hier schon mal die "dokumentierte Fassung" an ... hoffentlich machen Tabs da keinen Unsinn.
Vermutlich gibt es noch Lücken, aber zumindest ein Anfang.

Wenn Du sie runtergeladen hast ... nehme ich sie wieder raus ...

[OdfFhem]

@mr_petz

Der Uhrzeit intervall ist doch jede sekunde, oder?

Ja, stimmt - habe ich wohl nicht richtig hingeschaut. Sekündliche Ausführung macht aber eigentlich auch nur zu Beginn Sinn, da die Uhrzeit ja keine Sekunden ausgibt. Steht die Sekunde der aktuellen Uhrzeit bei 0, dann Umschalten auf 60 Sekunden-Interval ... spart Ressourcen ... 1x statt 60x pro Minute und das pro Haltestelle ...

Das würde ja bedeuten, dass für Montag über 2880min da stehen würden. Richtig?
Oder wird der Montagsbus dann nicht angezeigt?
Wenn man jetzt umswitcht auf Uhrzeit, dann würde doch auch nur die absolute Uhrzeit stehen. Oder?
Wäre es dann nicht da auch gut ein Wochentag in Kurzform (Mo, Di) auszugeben/anzuhängen?

Für die Anzeigetafel gibt es in solchem Fällen (aus langjähriger Erfahrung) keine einheitliche Lösung - (vermutlich) abhängig vom Verkehrsverbund:
- maximal die nächsten 24 Stunden werden angezeigt
- wenn weiter als 24 Stunden in der Zukunft, dann wird nur der Wochentag angezeigt
- bei Vergangenheit - also wenn eigentlich die Abfahrtszeit schon gewesen wäre, der Bus aber immer noch beim "Erreichen der Haltestelle" ist - blinkt die 0 bis zur Abfahrt

Das habe ich ja jetzt auch durch deine Hinweise und durchs Testen mitbekommen.
Die VVO sendet ja eine UNIX-Zeit. Da könnte ich ja den Wochentag oder das Datum mit ins JSON String schreiben lassen. Dann müsste ich das Array[3] im Modul auswerten. Ich bin glaube nicht der einzige der hier nur die Uhrzeit sich anzeigen lässt und von fhem bekommt.

Angenommen, Du brauchst das FHEM-Device nur für die FTUI-Anzeige, dann würde ich statt Zeit bzw. Minuten, einfach die unixtime als 3.Array-Komponente speichern. Die FTUI-Komponente sollte dann leicht zur Mitarbeit bei derart angelieferten Daten überredet werden können.

Machst du gut.

Deine Einschätzung stimmt vermutlich - OK, Scherz beiseite.
Für Dich als Modulautor gilt mit Sicherheit dasgleiche und in der Aussage für Dich fehlt mindestens noch ein sehr ...

[mr_petz]

@OdfFhem
Ich habe mir paar gedanken gemacht...

Ja, stimmt - habe ich wohl nicht richtig hingeschaut. Sekündliche Ausführung macht aber eigentlich auch nur zu Beginn Sinn, da die Uhrzeit ja keine Sekunden ausgibt. Steht die Sekunde der aktuellen Uhrzeit bei 0, dann Umschalten auf 60 Sekunden-Interval ... spart Ressourcen ... 1x statt 60x pro Minute und das pro Haltestelle ...

Da ist mir aufgefallen, dass der interval aus den Takt kommen kann. Also nicht mehr synchron mit den Sekunden der Uhrzeit ist. Da müsste man den interval von 60 wieder überwachen...

Für die Anzeigetafel gibt es in solchem Fällen (aus langjähriger Erfahrung) keine einheitliche Lösung - (vermutlich) abhängig vom Verkehrsverbund:
- maximal die nächsten 24 Stunden werden angezeigt
- wenn weiter als 24 Stunden in der Zukunft, dann wird nur der Wochentag angezeigt
- bei Vergangenheit - also wenn eigentlich die Abfahrtszeit schon gewesen wäre, der Bus aber immer noch beim "Erreichen der Haltestelle" ist - blinkt die 0 bis zur Abfahrt
Angenommen, Du brauchst das FHEM-Device nur für die FTUI-Anzeige, dann würde ich statt Zeit bzw. Minuten, einfach die unixtime als 3.Array-Komponente speichern. Die FTUI-Komponente sollte dann leicht zur Mitarbeit bei derart angelieferten Daten überredet werden können.

Ich hätte da einen Vorschlag.
Siehe Code:

Code Auswählen Erweitern


if (list.match(':')){
for (let i=0, l=json.length ; i<l; i++) {
let [deph, depm] = json[0][2].split(':');
let depMin = deph*60+depm*1;
if (depmin<isTimeMin) {
json.splice(0,1);
}else{
break;
}
}
}
Kommt direkt nach dem parsen der jsonList.
Verstrichene absolute Zeiten werden bei jedem fillList() raus genommen.
Das könnte man automatisieren. Am nächsten Tag wären dann alle Daten wieder da für die mit einer statischen Liste...
Da bräuchte man nicht noch extra die unix-zeit ins array mit reinnehmen und auswerten...
Was meinst du?

Dann habe ich mir AnzeigeTafel-ScreenShot´s angeschaut und gesehen, dass bei vielen Zeit und Minuten gemeinsam zu sehen sind.
Also wenn Minuten>60 sind dann wird die absolute Zeit angezeigt. Da könnte man den Switch eliminieren. Was meinst du?


Edit: Und was sagst du zum textscroll unten im anigif? Ich habe in Dresden gesehen, das bei Überlänge der Text scrollt. hier im Beispiel steht der Text ca 60sec. (sieht man hier im gif nicht!) könnte man auch als Attribute aktivieren. Der abgeschnittene Text sieht bissl blöd aus. Oder doch to much?

[OdfFhem]

@mr_petz

Da ist mir aufgefallen, dass der interval aus den Takt kommen kann. Also nicht mehr synchron mit den Sekunden der Uhrzeit ist. Da müsste man den interval von 60 wieder überwachen...

Wird das Intervall immer zu Beginn neugesetzt oder erst nach Ende der "notwendigen" Arbeiten? Im schlimmsten Fall bei jedem Neusetzen die verbleibenden Millisekunden bis zum Beginn der nächsten Minute ermitteln ...

Ich hätte da einen Vorschlag.
Kommt direkt nach dem parsen der jsonList.
Verstrichene absolute Zeiten werden bei jedem fillList() raus genommen.
Das könnte man automatisieren. Am nächsten Tag wären dann alle Daten wieder da für die mit einer statischen Liste...

Was Du jetzt genau machst, kann ich (noch) nicht erkennen. Denn:
- du manipulierst vermutlich nur das "lokale" Array
- die angegebene Zeit ist keine absolute DatumZeit und so würden auch "zukünftige" Angaben (mit kleinerer Zeit) gelöscht
- eigentlich sollte ein Leeren von "when" reichen und die text-Variablen nur bei befülltem "when" verändert werden
Die Beurteilung erfolgte mit Glaskugel-Unterstützung ...

Da bräuchte man nicht noch extra die unix-zeit ins array mit reinnehmen und auswerten...

Das mit "unixtime" war eigentlich so gemeint, dass Du statt einer datumlosen Zeit die von VVO bereitgestellte, absolute Zeitangabe durchreichst - passiert also auf der FHEM-Seite. Ich dachte, Du ermittelst selbst die datumlose Zeit - oder doch nicht?

Also wenn Minuten>60 sind dann wird die absolute Zeit angezeigt. Da könnte man den Switch eliminieren. Was meinst du?

Das mit den Minutenangaben bei "nahen" Abfahrten und die Zeitangabe bei "fernen" Abfahrten kommt in den von mir benutzten Tarifgebieten auch vor. "Abfahrt eigentlich schon vorbei, Verkehrsmittel aber noch nicht aufgetaucht", dann blinkende 0; "Abfahrt in weniger als 15 Minuten", dann Minutenangabe; "Abfahrt innerhalb der nächsten 24 Stunden", dann Zeitangabe; ansonsten Anzeige vom Wochentag.
Ein Grundraster könnte man sich ja entsprechend ausdenken; der Nutzer würde aber gerne insbesondere das "15-Minuten-Raster" selbst beeinflussen können - 1) Schwellwert in Minuten anpassen (z.B. 60) und 2) Anzeigeart anpassen (z.B. deptime)

Edit: Und was sagst du zum textscroll ...

Grundsätzlich nicht schlecht, wäre aber "augenschonender", wenn nur der Eintrag gescrollt würde, der auch gescrollt werden müsste ...

[mr_petz]

Ich zeige dir meine Überlegung.
Wenn wir die die mit Uhrzeit im Vorfeld kommen schon im Vorfeld umstricken/manipulieren, dann sind wir die Probleme mit Vergangenheit und Zukunft los. Ist bestimmt in dieser Form nicht toll, aber vielleicht könnte man es so in der Richtung machen???
Klar kann ich auch mir die Minuten aus fhem geben/holen, aber es haben bestimmt auch andere die Uhrzeit als list. Ich möchte ja das alle zufrieden sind...

1. wird alles in min umgerechnet
2. wird von hinten("Morgen") alles was <0 ist in +1440 gerechnet
3. wird von hinten wieder mit Attribute deptime alles in Zeit umgerechnet und alles was <0 ist mit --:-- versehen
somit ist Vergangenheit --:-- und Zukunft steht in Zeit oder Minuten.
Der Switch würde so auch funktionieren...
Du könntest das bestimmt besser , aber es soll nur den Verlauf zeigen.
Wie gesagt, ist nur so ein Gedanke.
Die Performance leidet da nur bei Uhrzeit-Usern durch die Schleifen.(Denke ich)

Code Auswählen Erweitern


      if (list.match(':')&&!this.hasAttribute('interval=""')){
for (let i=0, l=json.length ; i<l; i++) {
let timeElement = json[i];
let [dephs, depms] = timeElement[2].split(':');
let depmins = dephs*60+depms*1;
if (timeElement) {
depmins = depmins-timemins;
timeElement.splice(2,1,''+depmins+'');
}else{
break;
}
}
for (let i=json.length-1; i>=0; i--) {
  let timeElement1 = json[i];
if (timeElement1[2]<0) {
let dep = timeElement1[2]*1+1440*1;
timeElement1.splice(2,1,''+dep+'');
}else{
break;
}
}
if (this.hasAttribute('deptime')){
for (let i=json.length-1; i>=0; i--) {
let timeElement3 = json[i];
if (timeElement3[2]>0) {
const time = new Date();
timeElement3.splice(2,1,''+dateFormat(new Date(time.getTime()+timeElement3[2]*60*1000),'hh:mm')+'');
}else{
timeElement3.splice(2,1,'--:--');
break;
}
}
}
}