[FTUI3] new Departure für FTUI3

Begonnen von mr_petz, 06 April 2021, 14:57:39

Vorheriges Thema - Nächstes Thema

mr_petz

Hi @all,

Ich habe jetzt das Departure für FTUI3 zusammen mit OdfFhem nochmal optimiert und neue Features hinzugefügt.
Danke OdfFhem für die gute Zusammenarbeit... :D
Ein Pull requests auf GitHub habe ich bereits angestoßen, hänge es aber nochmal hier an.
Hier die vorläufige Demo bis setstate es übernommen hat:

Ist jetzt im Git mit drin...
Demo

Neuerungen Stand 12.05.2021:

  • interval heisst nun getinterval zum holen neuer Daten aus fhem
  • refreshlist für statische Listen hinzugefügt zur Aktualisierung der Abfahrtsliste ohne neue Daten zu holen
  • Timer werden jetzt an die volle Minute der Uhrzeit angepasst
  • automatisches entfernen bei gesetzten refreshlist der abgelaufenen Abfahrten
  • depscroll + deptxtlength zum scrollen per click bei überlangen Haltestellennamen im Richtungsfenster
  • automatisches scrollIntoView in die oberste Zeile
  • switch zum umschalten zwischen Minuten und Uhrzeit hinzugefügt
  • mixedmode als Standardanzeige min>60 wird zur Uhrzeit (durch setzten von depmin oder deptime wird mixedmode deaktiviert)
  • depminsize für min> beim mixedmode (wird durch gesetzten depmin oder deptime deaktiviert)
  • optional nextday (Taganzeige) für mixedmode oder depmin oder deptime bei Zeiten nach Mitternacht

Settings:

  • [ list ]="" ->fhem ListDevice:Reading
  • icon="" ->default=bus (gehen alle icons aus dem Ordner icons)
  • getinterval="" ->Zeit in sec um get zu holen (default=60)
  • station="" ->Name der Haltestelle (default=Haltestelle)
  • bgcolor="" ->Hintergrund der Umrahmung der depliste (default=#898989)
  • depcolor="" ->Hintergrund der depliste (default=#484848)
  • txtcolor="" ->Farbe der Schrift im Rahmen inkl. Uhr und Icon (default=#222)
  • deptxtcolor="" ->Farbe der Schrift in der depliste (default=#222)
  • top="" ->Position von oben des Departure (default=40px)
  • width="" ->Breite des Departure (default=98%)
  • height="" ->Höhe des Departure (default=85%)
  • txtsize="" ->Schriftgröße der Liste änderbar (default=13px)
  • optional zum defaultstyle: DVB, DB, VVO und RVSOE als Attribute
  • deptime ->optional Abfahrtszeit von min in hh:mm als Attribute
  • depmin ->optional Abfahrtszeit von hh:mm in min als Attribute
  • alternate ->optional verschieden farbige Zeilen als Attribute
  • scrolling aktiv in der depliste, wenn Liste zu lang ist ohne sichtbare scrollbar
  • manuell ->optional manueller RefreshButton als Attribute
  • refreshlist als Attribute -> für statische Listen zur Aktualisierung der Abfahrtsliste ohne neue Daten zu holen (default=60)
  • depscroll als Attribute ->zum aktivieren des scrollen per click bei überlangen Haltestellennamen im Richtungsfenster
  • deptxtlength="" -> Einstellbare Textlänge für das scrollen per click bei überlangen Haltestellennamen im Richtungsfenster (default=27)(damit werden nur Namen>27 einzeln scrollbar)
  • switch als Attribute -> zum umschalten zwischen Minuten und Uhrzeit
  • depminsize="" -> in min für Minutengröße beim mixedmode, erst danach wird Zeit angezeigt (wird durch setzten von depmin oder deptime deaktiviert)(default=60)
  • nextday als Attribute -> (Taganzeige) für mixedmode oder depmin oder deptime bei Zeiten nach Mitternacht

Und dann noch der Departure Beispielcode für FTUI3:

<ftui-departure
  [list]="depDummy:HBF"
  icon="train"
  getinterval="30" 
  station="HBF"
  DB
  deptime
  alternate>
</ftui-departure>

Im example-File sind noch mehr Beispiele...

Das Device in fhem ist gleich wie fürs FTUI2 departure_widget.
hier kann man es nachlesen:
https://wiki.fhem.de/wiki/Departure
oder so wie ich es habe erstellen:
https://forum.fhem.de/index.php/topic,48255.msg1058924.html#msg1058924

und wer noch für die BVG eine api sucht, die ist hier zu finden:
https://v5.bvg.transport.rest/api.html
und zwei Bsp. dazu:
https://v5.bvg.transport.rest/locations?poi=false&addresses=false&query=mehringdamm%27
oder:
https://v5.bvg.transport.rest/stops/900000017101/departures?results=5


Anregungen oder Änderungen sind Willkommen.
Falls ich was vergessen habe, dann sagt bitte Bescheid.
Viel Freude damit.

Gruß Thomas

OdfFhem

@mr_petz

zunächst einmal schönen Dank für die neue Fassung. Insbesondere das Scroll-Feature finde ich sehr nützlich. Interessant ist, dass z.B. Chrome den Scrollbar anzeigt, Firefox nicht. Unter welchem Browser hast Du entwickelt ?

Ich hatte noch nicht viel Gelegenheit fürs Testen. Auffälligkeiten gab es aber schon:
- verzichtet man auf ein header-Tag, ändert sich nichts an der Ausnutzung der zur Verfügung stehenden Fläche
- überraschend ist, dass im example-File eine Darstellung mit einer Weite von 110% doch nur 100% belegt; auch 80% Höhe scheint nicht 80% zu sein
- die ganz unten dargestellte Zeit sollte eigentlich nicht der aktuellen Uhrzeit entsprechen, sondern dem Stand der angezeigten Daten - wichtig z.B. bei (relativen) Minutenangaben
- die Breite der Linienspalte ist zu fix, da beim Einsatz von DB-Daten nur ein Teil der Information zu sehen ist

mr_petz

#2
@OdfFhem

Zitatzunächst einmal schönen Dank für die neue Fassung. Insbesondere das Scroll-Feature finde ich sehr nützlich. Interessant ist, dass z.B. Chrome den Scrollbar anzeigt, Firefox nicht. Unter welchem Browser hast Du entwickelt ?
Ich habe mit Firefox entwickelt.
Im Android unter den bekannten FullscreenBrowsern wird die scrollbar auch nicht angezeigt.

Edit: Ich habe was zu Chrome gefunden. Die haben/hatten Probleme mit den "Overlay-Scrollbar-Flag". Die kann man an bzw. ausschalten. ungetestet...
Ich füge das noch mit rein in die css:
::-webkit-scrollbar {
  display: none;
}

Teste oben bitte mal in Chrome die neue Version der css wegen hide scrollbar.

ZitatIch hatte noch nicht viel Gelegenheit fürs Testen. Auffälligkeiten gab es aber schon:
Danke fürs testen.

Zitat- verzichtet man auf ein header-Tag, ändert sich nichts an der Ausnutzung der zur Verfügung stehenden Fläche
sorry, das verstehe ich nicht was du damit meinst. Könntest du das bitte bissl genauer erläutern?

Zitat- überraschend ist, dass im example-File eine Darstellung mit einer Weite von 110% doch nur 100% belegt; auch 80% Höhe scheint nicht 80% zu sein
Die 110% Breite sollten nur das grid ausfüllen. Ansonsten ist immer ein Abstand gewollt.
Bei der Höhe genauso. Das Beispiel soll nur die Benutzerdefinierbarkeit zeigen...

Zitat- die ganz unten dargestellte Zeit sollte eigentlich nicht der aktuellen Uhrzeit entsprechen, sondern dem Stand der angezeigten Daten - wichtig z.B. bei (relativen) Minutenangaben
Sollte da nicht die aktuelle Uhrzeit rein? Ist das nicht beim "alten" widget auch so?

Zitat- die Breite der Linienspalte ist zu fix, da beim Einsatz von DB-Daten nur ein Teil der Information zu sehen ist
Das kommt ja auf die Breite (width) des Departure an. Der overflow wird ja abgeschnitten.

Danke erstmal fürs Feedback. Arbeite aber gern weiter daran, wenn du noch Verbesserungen mir aufzeigst...

OdfFhem

@mr_petz

ZitatTeste oben bitte mal in Chrome die neue Version der css wegen hide scrollbar.
Chrome mit der neuesten Fassung getestet und die Scrollbars sind weg - sehr schön

Zitatsorry, das verstehe ich nicht was du damit meinst. Könntest du das bitte bissl genauer erläutern?
Bei nicht vorhandenem header-Tag fällt auf, dass die Position der Anzeigetafel unverändert bleibt. Hängt aber vermutlich mit der fixen Positionierung zusammen. Ich habe im Screenshot mal width/height von 100% bis zu 50% reduziert und man sieht, dass die Anzeigetafel quasi immer am selben Punkt von oben startet ... 100% sind auch keine 100%, da die Darstellung insgesamt deutlich schmaler/niedriger ist. Daher kommen wohl auch die 110%, so dass man trotzdem die gesamte Breite/Höhe ausfüllen will. Automatisch zentrierte Darstellung wäre vermutlich flexibler ...

ZitatSollte da nicht die aktuelle Uhrzeit rein? Ist das nicht beim "alten" widget auch so?
Kenne ich nur so, dass dort quasi der Zeitstempel der Daten steht. Die Zeit verändert sich nur abhängig von der Aktualität der Daten.
Falls man die "in Min"-Anzeige und keine minütliche Aktualisierung hat, bleibt z.B. eine "5" länger eine "5" und ist der additive Wert zur unten angezeigten Uhrzeit.

ZitatDas kommt ja auf die Breite (width) des Departure an. Der overflow wird ja abgeschnitten.
Hier ist die Frage, ob nicht nur die 2.Spalte abgeschnitten werden sollte, da die 3.Spalte definitiv ungekürzt bleiben sollte und die 1.Spalte eine "wichtige" Information enthält. In der 2.Spalte reichen oft die Anfangsbuchstaben ... sieht man evtl. auch am Screenshot


Interessant wären noch Funktionen für
- die manuelle Aktualisierung der Daten via refresh-Icon
- die manuelle Umschaltung der Anzeige zwischen Zeit bzw. verbleibende Minuten (3.Spalte)
Ebenso interessant
- wäre die beeinflussbare Größe der Schrift - z.B. in einem Popup ...

mr_petz

Zitat von: OdfFhem am 07 April 2021, 19:17:55
Interessant wären noch Funktionen für
- die manuelle Aktualisierung der Daten via refresh-Icon

erledigt ;)

OdfFhem

@mr_petz

Zitaterledigt
Danke, probiere ich nachher aus ...

Bist Du noch an einem der "gewünschten Feature" dran ?
Ich würde nachher ein wenig probieren und evtl. was beisteuern ... gewünscht ?

mr_petz

#6
Bin am css dran. Ich hänge mal den aktuellen Stand an.
Bekomme die Destination Line (2.Spalte) mit dem overflow:hidden nicht hin.
Erste Spalte passt sich der Länge vom list an.
100% sind jetzt 100% wenn du das mit angibst.
Man muss aber bedenken wenn ein <header> gesetzt wird, dann wird der überschrieben...
Du kannst gerne mitarbeiten. Im css bin ich nicht sooo fit...

Den Switch fürs manuelle umschalten von min und zeit mache ich.. Danke

OdfFhem

@mr_petz

Aufgefallen ist, dass der manuelle Refresh keine neuen Daten holt; es wird zwar eine neu berechnete Abfahrtszeit angezeigt - die Daten sind jedoch alt.
Die beiden, angehängten Screenshots bekommen die Daten vom selben Reading; die Anzeige unterscheidet sich aber deutlich ...

Ich habe einige Versuche unternommen, die 2.Spalte abzuschneiden. Ein Weg kürzte partout nicht; ein anderer Weg kürzte, verdichtete aber alle div's auf eine einzige Zeile. Im Grunde scheint es (fast) "aussichtslos" ...

Der nächste Versuch bestand darin, die Schriftgröße zu beeinflussen. Änderungen führten dann zwar zu einer gewünschten Größe, aber es kommt nicht mehr zu einer vollständigen Anzeige. Die Daten werden rechts rausgeschoben ... ohne kontrolliertes Abschneiden scheinbar unmöglich ...

Im letzten (Verzweiflungs)Schritt habe ich mit einer rein tabellenorientierten Darstellung hantiert und das Neue schien erreichbar; aber schon das Scrollen wiederum scheint Probleme zu produzieren ...

Ich habe einfach mal zwei Screenshots angehängt.
- Screenshot__div arbeitet mit einer Tabellenzeile, die mit den div's gefüllt ist (heruntergeladener Modulstand von heute mittag).
- Screenshot__tr_td arbeitet pro Abfahrtsinfo mit einer eigenen Tabellenzeile (ganz anderes Testmodul).
Beide Screenshots zeigen oben die Darstellungen mit 100% bis 50% im Uhrzeigersinn; ganz unten ist eine Popup-Darstellung.
Beide beruhen auf demselben Reading, zeigen aber interessanterweise unterschiedliche Abfahrtszeiten (13:25 würde stimmen).

mr_petz

#8
@OdfFhem

das mit dem manuellen get müssen wir mal genauer Untersuchen. Bei mir sind keine Unauffälligkeiten...
Ich habe auch mal den TimeChancher eingebaut. der ist per "switch" Attribute nutzbar.
Die icons kann man bestimmt noch anpassen..
Ich hänge mal an..
Und Danke fürs css fummeln... ;)

OdfFhem

@mr_petz

Ich habe mal Deinen letzten Modulstand gezogen und ein wenig getestet.

Refresh funktioniert jetzt; fillList wird dabei nur einmal unnötig (in der Regel mit noch alten Daten) aufgerufen, da getReading dazu führen sollte, dass sowieso die list-Property erneuert wird und zu einem fillList-Aufruf mit neuen Daten führt.

Das Problem mit der fehlerhaften Anzeige von "nicht gerade erneuerten" Daten hängt wohl damit zusammen, dass die vom Reading übergebenen Minuten immer bzgl. der aktuellen Uhrzeit addiert werden. Ein Aktualisierungsintervall von z.B. 5 Minuten führt dazu, dass jeder Abruf (F5 im Browser) des unveränderten Readings innerhalb der 5 Minuten zu schwankenden Abfahrtszeiten führt.

Bzgl. switch-Attribut scheint die erste Darstellung nicht immer zu stimmen, da - unabhängig von deptime-Attribut - immer das Uhr-Icon angezeigt wird. Bei Nutzung von deptime-Attribut ist der erste Click ohne "Wirkung" ... fraglich ist noch, ob man im Event nur umschaltet und den Rest der fillList-Routine überlässt, denn ohne Event muss sie ja auch (jetzt schon) mit den Einstellungen zurechtkommen ...

Bzgl. Icons ist noch die Frage, ob ein veränderter Cursor einen sensitiven Bereich sichtbar machen soll ... im css u.a. durch:

  cursor: pointer;


Hat die Abfahrtsübersicht ein popup-target, sorgt ein Click auf z.B. das Refresh-Icon automatisch dafür, dass neben dem Anstoßen von Refresh auch das Popup aufgeblendet wird. Dies kann u.a. verhindert werden durch:

  event.stopPropagation();


mr_petz

#10
@OdfFhem

ZitatDas Problem mit der fehlerhaften Anzeige von "nicht gerade erneuerten" Daten hängt wohl damit zusammen, dass die vom Reading übergebenen Minuten immer bzgl. der aktuellen Uhrzeit addiert werden. Ein Aktualisierungsintervall von z.B. 5 Minuten führt dazu, dass jeder Abruf (F5 im Browser) des unveränderten Readings innerhalb der 5 Minuten zu schwankenden Abfahrtszeiten führt.
Das schaue ich mir zu Hause nochmal an. Bei mir ist alles in Ordnung gewesen. Muss ich mal nachstellen. Woher bekommst du deine Daten?

ZitatBzgl. switch-Attribut scheint die erste Darstellung nicht immer zu stimmen, da - unabhängig von deptime-Attribut - immer das Uhr-Icon angezeigt wird. Bei Nutzung von deptime-Attribut ist der erste Click ohne "Wirkung" ... fraglich ist noch, ob man im Event nur umschaltet und den Rest der fillList-Routine überlässt, denn ohne Event muss sie ja auch (jetzt schon) mit den Einstellungen zurechtkommen ...
Habe ich jetzt angepasst. deptime und depmin darf hier aber erstmal nicht zusammen mit dem manuellen Refresh und switch gesetzt sein. Da arbeite ich noch dran. Wieso willst du eigentlich deptime setzen? Ich habe das in fhem direkt umgemünzt...

ZitatBzgl. Icons ist noch die Frage, ob ein veränderter Cursor einen sensitiven Bereich sichtbar machen soll ... im css u.a. durch:

  cursor: pointer;
Benutzt du eine Maus? weil auf dem Tablet bräuchte es man ja nicht. Kann es aber reinpacken.

ZitatHat die Abfahrtsübersicht ein popup-target, sorgt ein Click auf z.B. das Refresh-Icon automatisch dafür, dass neben dem Anstoßen von Refresh auch das Popup aufgeblendet wird. Dies kann u.a. verhindert werden durch:

  event.stopPropagation();
Ich habe mal die event aus den klammern genommen. sollte auch so gehen und kein target auslösen, oder? (ungetestet)
Habe mit target getestet und wie du gesagt hast, das event.stopPropagation(); mit rein genommen...

Letzter Stand angehängt...

(Hatte heute nicht viel Zeit...)

mr_petz

#11
@OdfFhem

Ich habe mal versucht das Problem mit dem manRefresh nachzustellen. Ist mir Leider nicht gelungen.
Egal ob F5 vom Browser oder per RefreshButton oder umswitche bleiben die Daten entw. gleich oder sie aktualisieren sich auf den neusten Stand wenn verfügbar.
Auch das reading in fhem bekommt nach manuellen Refresh bei mir sofort einen neuen Zeitstempel...
Vielleicht ist dein BrowserCache schuld??? Oder dein fhem Device ist anders als meins.
Ich hänge mal einen Vergleich als Bild an und einen API HTML Code der keinen Bezug zu fhem hat (rechte seite auf dem Bild).

setstate

ich habe mal die Source ins Git übernommen und vorher noch einige Variablen umbenannt und etwas umgeändert.

mr_petz

#13
Zitat von: setstate am 09 April 2021, 21:30:41
ich habe mal die Source ins Git übernommen und vorher noch einige Variablen umbenannt und etwas umgeändert.
Danke setstate. Will ja wie gesagt hier nur unterstützen, auch wenn der Code von mir nicht so... naja.
Könntest du bitte noch den manuellen Refresh separieren bei einem click?
Bei einem popup-target löst der das popup aus und nicht ausschließlich den refresh.
Ist halt ein wunsch von OdfFhem ;)
Wir haben weiter oben schon darüber gesprochen...

Danke und Gruß

Edit:
ps. jetzt könnte ja OdfFhem weiter dran arbeiten wenn er will. Oder sollen wir hier weiter die Erweiterungen erarbeiten und setstate übernimmt diese dann?
soll ich da oben alles raus nehmen?

OdfFhem

@mr_petz

Hatte gestern kaum Zeit, daher gibt es noch Einiges aufzuarbeiten ...

Zitat von: mr_petz am 09 April 2021, 15:16:18
Das schaue ich mir zu Hause nochmal an. Bei mir ist alles in Ordnung gewesen. Muss ich mal nachstellen. Woher bekommst du deine Daten?
Ich habe den Ratschlag zur Datenquelle aus https://wiki.fhem.de/wiki/FTUI_Widget_Departure#Datenquelle entnommen: "Oder man wählt folgenden allgemeineren Weg ...".
Das resultierende Reading hat folgenden Inhalt: [["RE 10203","Osnabrück Hbf","10"], ... ,["S 8","Mönchengladbach Hbf","28"]] und einen Zeitstempel wie z.B.: 2021-04-10 06:04:00.
Die Zeitangaben im Reading sind relative Angaben in Minuten zum Zeitpunkt der Datenermittlung bzw. Zeitstempel.
Die anzuzeigenden, absoluten Abfahrtszeiten wären also 06:14 für Osnabrück bzw. 06:32 für Mönchengladbach.
Für das Nachvollziehen ist wichtig, dass man nicht ständig Datenaktualisierungen vornimmt;
die relativen Angaben in Minuten sowie die absoluten Abfahrtszeiten bleiben also gleich.

- ein "extrem zeitnaher" Aufruf zum Zeitstempel führt zur gewünschten Anzeige von 06:14 bzw. 06:32.
- F5 im Browser nach z.B. 2 Minuten führt zur Anzeige von 06:16 bzw. 06:34.
- F5 im Browser nach z.B. 5 Minuten führt zur Anzeige von 06:19 bzw. 06:37.
- Wert und auch Zeitstempel sollten immer noch mit der Ausgangslage übereinstimmen ... 06:14 bzw. 06:32 wäre folglich immer noch die korrekte Anzeige.

Zitat von: mr_petz am 09 April 2021, 15:16:18
Habe ich jetzt angepasst. deptime und depmin darf hier aber erstmal nicht zusammen mit dem manuellen Refresh und switch gesetzt sein. Da arbeite ich noch dran. Wieso willst du eigentlich deptime setzen? Ich habe das in fhem direkt umgemünzt...
Die Attribute "manuell" und "deptime" bzw. "depmin" haben eigentlich nichts miteinander zu tun. "manuell" legt fest, ob man das refresh-Icon sehen und nutzen will. "deptime" bzw. "depmin" legen fest, ob die Abfahrtszeit absolut oder relativ angezeigt werden soll. Das Attribut "list" erhält Daten mit relativen oder absoluten Abfahrtszeiten.

Unabhängig von den angelieferten Daten sollte die Komponente eine Standardanzeige haben, dann wäre "depmin" - in Anlehnung an FTUI2 - unnötig, da vorgegebener Standard. "deptime" dient ausschließlich zur Festlegung einer abweichenden Anzeige. Umschalten der Anzeige schaltet also einfach nur zwischen "deptime" und <Standard> um. Initial wird aktuell, unabhängig von der gewählten Anzeige, das clock-Symbol dargestellt ...

Ein Eingriff in FHEM ist meiner Meinung nach nicht notwendig, denn wer zwischen den Anzeigen wechseln möchte, muss sich ja sowieso auf die Komponente verlassen.

Im Zusammenhang mit der Anzeige wäre es natürlich noch praktisch,
- wenn die relative Anzeige nicht statisch, sondern einer Art Countdown entsprechen würde
- wenn die absolute Anzeige "zerstört" würde, falls die Abfahrtszeit in der Vergangenheit liegt - "--:--", o.ä.

Überlegenswert wäre auch noch, ob man implementierte "Features" - wie in FTUI2 - nicht grundlegend bereitstellt, aber durch Attribute unterdrücken kann:
- "no-manual" oder "no-refresh", falls das refresh-Icon verschwinden soll
- "no-switch", falls das Umschalt-Icon verschwinden soll

Zitat von: mr_petz am 09 April 2021, 15:16:18
Benutzt du eine Maus? weil auf dem Tablet bräuchte es man ja nicht. Kann es aber reinpacken.
FTUI wird innerhalb des Haushalts auf Smartphone, Tablet und auch Desktop eingesetzt ...

Zitat von: mr_petz am 09 April 2021, 15:16:18
Habe mit target getestet und wie du gesagt hast, das event.stopPropagation(); mit rein genommen...
Funktioniert.