[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.

OdfFhem

@setstate

Die Dateien rund um departure fehlen in controls_ftui.txt ...



@mr_petz

Zitat von: mr_petz am 09 April 2021, 21:47:41
Oder sollen wir hier weiter die Erweiterungen erarbeiten und setstate übernimmt diese dann?
Ich fände schon gut, wenn man in diesem "Betreff" weiterhin über Probleme/Erweiterungen zu diesem Thema sprechen würde und Du als Modulautor die Fäden in der Hand behälst. Durchgeführte Änderungen müssen aber irgendwann auch den offiziellen Weg über @setstate finden; ansonsten kann sie ja keiner so richtig nutzen ...

mr_petz

#16
@setstate

Ich habe mal im ersten Post eine neue Version auf Grundlage deiner angepassten im Git hochgeladen.
Im css stimmten die Spalten nicht ganz und in der js habe ich den refreshButton wieder mit dem event versehen.
Ich kenne jetzt das bind(this) nicht wie du es hattest... Da fehlt mir dann schon noch das wissen dazu...
ok hab den prototype.bind() durchgelesen... Weiss nur nicht wie man da den vom popup-target lösen kann..

Du könntest auch das example mit in die Demo nehmen. Kannst ja auch die "dummy"list wie ich da nehmen:
list='[["U8","Vaihingen","3"],["U12","Dürrlewang","5"],["U8","Ostfildern","6"],["U3","Vaihingen","6"],["U12","Hallschlag","7"],["U3","Plieningen","9"],["U8","Vaihingen","12"],["U12","Dürrlewang","14"],["U8","Waldau","15"],["U3","Vaihingen","16"],["U12","Dürrlewang","19"],["U8","Waldau","21"],["U3","Vaihingen","25"],["U12","Dürrlewang","26"],["U8","Waldau","28"],["U3","Vaihingen","30"]]'

Danke und Gruß

mr_petz

@OdfFhem

Ich habe es jetzt geschaft mit der 2.Spalte (Denke ich). Unter Firefox geht es.
Durch
max-width: 0px;
funktioniert der overflow.
Kannst mal bitte unter Chrome testen.
Habe es im ersten Post hochgeladen..
In dieser Version ist erstmal der switch rausgenommen...

OdfFhem

@mr_petz

Ich hab's mal unter Chrome auf dem Tablet bzw. Desktop (s. Screenshot) getestet - funktioniert prima.


Hinweis: Die Zeitspalte wird aktuell mit "Clock" beschriftet. Richtig ?

mr_petz

Prima danke. Was du auch für lange Liniennamen hast :D
Clock hat setstate angepasst...

OdfFhem

@mr_petz

Ich hatte auch mal die bind-Schreibweise aktiviert und getestet, aber das Event wird beim Refresh nicht vernichtet - Popup geht also immer mit auf.

Recherche ergab u.a. folgende Anmerkung seitens SELFHTML:
Zitat
Es soll nicht verschwiegen werden, dass dieser Ablauf (Methode bind seit ECMAScript 5) mit neueren JavaScript-Features besser lesbar wird. Mit einer Pfeilfunktion ...

mr_petz

txtsize für die liste hinzugefügt. siehe 1.Post ;)
musste erst sicher gehen, das die 2.Spalte hinhaut.

OdfFhem

@mr_petz

Da habe ich wohl was verpasst, denn der Beitrag mit der txtsize war für mich eben noch ganz neu.

Ich habe dann ein wenig getestet und eigentlich funktionierte alles mit txtsize wie erwartet - sehr praktisch.


Beim Blick in die css-Datei stellte ich fest, dass auch eine CSS-Variable --departure-txtsize benutzt werden kann.
Es war aber vorherzusehen, dass die CSS-Variable keine Chance hat, da die txtsize-Property immer einen Wert hat und damit auch immer gewinnt.

Definiert man in der eigenen css-Datei --departure-txtsize z.B. mit dem Wert 200%, dann gilt:
--> Verwendet man kein txtsize-Attribut, ist die resultierende font-size 13px und nicht 200%.
--> Verwendet man ein txtsize-Attribut, entspricht die resultierende font-size dem übergebenen Wert

Belegt man die txtsize-Property in der js-Datei mit undefined vor und passt das Modul so an, dass die Property nur angewendet wird, wenn das Attribut txtsize tatsächlich verwendet wurde.
--> Verwendet man kein txtsize-Attribut ist die resultierende font-size nun 200% (gemäß CSS-Variable).
--> Verwendet man ein txtsize-Attribut, entspricht die resultierende font-size dem übergebenen Wert

Hat man jetzt weder eine CSS-Variable noch ein txt-Attribut definiert, dann fehlt in der css-Datei noch die Festlegung eines "Rückfallwertes"; dieser entspricht in Deinem Fall 13px.

Mit den sehr kleinen Anpassungen wurden alle durchgespielten Fälle sauber dargestellt.

Ausführungen sind - wie immer - nur Hinweise, Anregungen, ...



Abschließend noch eine Frage: Gibt es noch Hoffnung für switch oder wartest Du auf eine beigesteuerte Lösung? Oder ist das Modul im jetzigen Zustand final ?

mr_petz

#23
@OdfFhem

Danke für die Rückmeldung bzgl. txtsize.
Ja habe ich vergessen umzuschreiben. mache ich noch. Edit: erledigt..

Zum switch.
Da stecke ich noch fest an dem setzen aller Attribute gleichzeitig, denn dann haut das irgendwie mit der Anzeige und Umschalten des Icon nicht hin. (zu viele Variablen die man da checken muss)
Ich hatte ja die Version schon gepostet wo kein deptime oder depmin gleichzeitig zu den gleichzeitig gesetzten Attributen switch und manuell gesetzt werden darf.
Du kannst hier aber gern deinen Vorschlag zeigen. Mir ist nur wichtig dass depmin, deptime, switch und manuell weiterhin als seperat aktivierbare Features bleiben.

depmin ist hier für mich relevant, weil ich direkt von der webAPI die Daten ziehe und per Zeit bekomme/umrechne. siehe hier:
https://forum.fhem.de/index.php/topic,48255.msg1058924.html#msg1058924

Edit:
Könntest du bitte den Anhang testen bzgl switch? Ich weiss im Moment nur nicht was bei einem man. Refresh mit neuen Daten passiert.
Kann ich erst heute Abend testen...


mr_petz

Ok hab es getestet und sollte mit allen Varianten funktionieren..
Du kannst bitte auch nochmal testen bevor ich es für alle hochlade.
Jetzt sollten wir nur noch passende Icons erstellen oder lassen die wie sie sind..??

OdfFhem

#25
@mr_petz

ich hatte Deine ganz neuen Module eben mal runtergeladen und auch ein bisschen getestet - scheint soweit zu funktionieren.

Nicht lange davor hatte ich Deinen Stand von heute morgen runtergeladen, mir näher angeschaut und (wunschgemäß) einen Lösungsvorschlag erarbeitet. Einfach der Vollständigkeit halber lade ich diesen Stand mal hoch; Du kannst ihn Dir ja mal anschauen ... wenn die Module wieder aus dem Beitrag entfernt werden können, kannst Du ja mal kurz Bescheid geben,

Die switch-Icons finde ich übrigens gar nicht so schlecht - vor allem für den ersten Entwurf.

mr_petz

#26
Danke ich hab es...

Edit:
... auch getestet.
Danke erstmal fürs proggen/unterstützen ;)
Ich kann jetzt nur nicht unsere beiden Varianten bewerten was besser/schlechter funktioniert oder programmiert ist..
Eins kann ich aber sagen, deins sieht einfacher zum Nachvollziehen aus.
Mir ist aber jetzt beim testen aufgefallen dass bei mir mit deiner Version meine standardmäßige Uhrzeit vom reading umgeswitcht wird zu min, obwohl ich nur switch gesetzt habe. Sprich ich müsste immer deptime und switch zusammen setzen, obwohl ich ja schon deptime autom. von fhem habe wie oben beschrieben... Also so:
https://forum.fhem.de/index.php/topic,48255.msg1058924.html#msg1058924
Gut die Icons bleiben dann erst mal so.
Weiss nicht ob du deine Variante noch meiner Gegebenheit anpassen kannst. Wenn ja würde ich es wieder testen und übernehmen.
kannst zum testen auch das als list so wie es ist nehmen:

list='[["S1","Schöna Bahnhof","20:52"],["S2","Dresden Flughafen","20:54"],["S1","Meißen S-Bf. Triebischtal","21:07"],["RB71","Neustadt Bahnhof","21:11"],["S1","Bad Schandau Nationalparkbahnhof","21:22"],["S1","Meißen S-Bf. Triebischtal","21:52"],["S1","Schöna Bahnhof","22:11"],["S1","Meißen S-Bf. Triebischtal","22:07"],["RB71","Neustadt Bahnhof","22:11"],["S1","Bad Schandau Nationalparkbahnhof","22:21"],["S1","Meißen S-Bf. Triebischtal","22:37"],["S1","Bad Schandau Nationalparkbahnhof","22:51"],["S1","Meißen S-Bf. Triebischtal","23:07"],["S1","Bad Schandau Nationalparkbahnhof","23:21"],["S1","Meißen S-Bf. Triebischtal","23:37"],["S1","Dresden Hauptbahnhof","00:07"],["S1","Bad Schandau Nationalparkbahnhof","00:34"],["S1","Dresden Hauptbahnhof","00:37"],["S1","Meißen S-Bf. Triebischtal","04:37"],["S1","Schöna Bahnhof","04:51"],["S2","Dresden Flughafen","04:54"],["S1","Meißen S-Bf. Triebischtal","05:07"],["S1","Bad Schandau Nationalparkbahnhof","05:21"],["S2","Dresden Flughafen","05:24"],["S1","Meißen S-Bf. Triebischtal","05:37"]]'

OdfFhem

#27
@mr_petz

ZitatMir ist aber jetzt beim testen aufgefallen dass bei mir mit deiner Version meine standardmäßige Uhrzeit vom reading umgeswitcht wird zu min
Mir war bisher nicht klar, dass die angelieferten Daten die initiale Darstellung vorgeben; bei mir war dies immer die Restanzeige - wohl wie bei FTUI2 üblich.

Aber durch die neue Erkenntnis habe ich den Lösungsvorschlag noch ein wenig angepasst und jetzt wird quasi bei fehlender Vorgabe durch depmin bzw. deptime eine automatische Vorgabe anhand der angelieferten Daten ermittelt.

Geändertes js-Modul hochgeladen ... wenn das Modul aus dem Beitrag entfernt werden kann, kurz Bescheid geben.


P.S.: Ich hatte noch die Festlegung der Überschrift für die 3.Spalte nach unten gezogen und 3 auskommentierte Zeilen hinterlassen. Falls console.log für den Produktivstand doch bleiben sollte, wäre vermutlich noch der eingestellte Debuglevel zu berücksichtigen.

mr_petz

#28
Ok. habe ich. Teste dann noch..
Ich hole mir halt die Daten direkt über die webapi und nicht wie im wiki stehend von der widgetapi von "transport.stefan-biermann.de".

Edit: Also bei mir scheint es auch zu funktionieren und die Umsetzung gefällt mir.
Ich habe jetzt nicht deine css hier. Könntest du das bitte kurz im Code zeigen wegen der 3.Spalte?
Hättest du noch eine andere Lösung um die Zeit in Minuten umzurechnen (eine kürzere)?
Ich habe halt mit meinen bescheidenen Programmierkenntnissen das nur so hinbekommen...


OdfFhem

@mr_petz

Die css-Datei hat sich gegenüber gestern nicht geändert. Trotzdem nochmal bereitstellen?

ZitatFestlegung der Überschrift für die 3.Spalte nach unten gezogen
gilt für das js-Modul und heisst nur, dass elementMinutes ausschließlich am Ende der fillList-Routine gesetzt wird - ohne Berücksichtigung der zweiten (entfernten) min-Variable aus der Hauptschleife.

Wegen kürzerer Lösung für die Umrechnung der Zeit kann ich nachher mal schauen ...


P.S.: Gesucht wird ja nie die absolut "perfekte" Lösung, eine gut "einsetzbare" reicht meist schon völlig ...

mr_petz

Zitat von: OdfFhem am 14 April 2021, 16:18:19
@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

#31
@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


mr_petz

#33
@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. :D
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

#34
@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.

Zitat
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???

Zitat
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?

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

Zitat
- 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..

Zitat
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.

Zitat
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.

Zitat
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

Zitatman 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.

ZitatJa, 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 ...

ZitatHatte 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.

ZitatWenn 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.

ZitatDeswegen 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.

ZitatMachst 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 ...

ZitatWie 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.
Zitat
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

Zitat von: OdfFhem am 20 April 2021, 21:23:39
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?

Zitat
Ohne localStorage und mit direkter Generierung für this.timeNow sollten die gleichen Verhältnisse gelten.
ja da hast du Recht.

ZitatZeitangaben 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?

ZitatAbsolute 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.

ZitatBei mir weiss ich, dass ich JavaScript nur fürs Hobby nutze ... das aber gerne ...
Machst du gut. ;)

OdfFhem

#40
@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

#41
@mr_petz

ZitatDer 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 ...

ZitatDas 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

ZitatDas 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.

ZitatMachst 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

#42
@OdfFhem
Ich habe mir paar gedanken gemacht...

Zitat von: OdfFhem am 22 April 2021, 07:17:33
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...

Zitat
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:

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

ZitatDa 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 ...

ZitatIch 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 ... ;-)

ZitatDa 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?

Zitat
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)

ZitatEdit: 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

#44
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)

      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;
}
}
}
}

OdfFhem

@mr_petz

Ich habe mir die Überlegung mal angeschaut.

Grundsätzlich ist die Idee der "Ausdünnung" nicht schlecht, wenn man bei der wiederholten Ausführung damit Zeit sparen kann.

1) Die Umrechnung in den absoluten DateTime-Wert - egal ob Zeit oder Minuten (oder unixtime) angeliefert werden - sollte einmalig bei neuen Daten vorgenommen und die dabei ermittelten Daten in einem eigenen Array gespeichert werden.
2) Bei jeder Ausführung prüft die Routine das eigene Array, ob die Abfahrt in der Vergangenheit liegt; wenn ja, wird die entsprechende Abfahrtszeit mit einem leeren String geerdet.
3) Der Anzeigeteil kennt 2 Eingangswerte (leerer Wert oder absoluter DateTime-Wert) und 3 Ausgabewerte (nichts oder deptime oder depmin)
4) Bei "nichts" wird die text-Zuweisung verhindert, ansonsten durchgeführt.

Interessant bei neuen Codeteilen ist aber (fast) immer, dass sie möglichst nur aus dem Notwendigsten bestehen - in der Kürze liegt u.a. die Würze. Richtig beurteilen kann man das vermutlich erst am Ende, obwohl die vielen Schleifen, die ja scheinbar bei jeder Ausführung notwendig sind, jetzt schon nach viel (unnötiger) Laufzeit klingen ...

mr_petz

#46
Teste bitte erst und dann sage deine Meinung. ;)
Durch die 2 for´s leidet mMn nicht die Performance. Habe es auf meinem alten Samsung Tab4 getestet.
manInterval heisst jetzt refreshlist
interval heisst jetzt getinterval
die auskommentierten Zeilen sind zum testen was möglich wäre.
Da könnte man auch ein mixedMode als Attribute einbinden wer es möchte...
Ich denke es ist so flexibler.
noch ne frage zu:

dateFormat(new Date(),'ee')

Da wird mir der korrekte Tag angezeigt. (Di)
mit:

const currentTime = new Date();
dateFormat(new Date(currentTime.getDay()),'ee')

der Do
Was geht da schief und wie kann man das einen Tag hochzählen???
Ich habe erstmal ein neues Array erstellt, damit ich einen Tag hochzählen kann.
Wenn du so zufrieden bist, baue ich noch die extra arrays ein damit ich nicht so "manipuliere" wie du sagst. Ich würde es aber auch so lassen....
Ist wie gesagt der beste weg um Uhrzeit Readings ordentlich einzubinden...

OdfFhem

#47
@mr_petz

dateFormat musst Du immer ein vollständiges Datum übergeben, also in Deinem Fall currentTime.

Das übergebene Format sorgt dann dafür, dass Du den gewünschten String zurückerhälst.


  const currentTime = new Date();

  // const isTime = dateFormat(new Date(currentTime.getTime()),'hh:mm');
  const isTime = dateFormat(currentTime,'hh:mm');
console.log("---isTime---",isTime);

  //const isDay = dateFormat(new Date(currentTime.getDay()),'ee');
  const isDay = dateFormat(currentTime,'ee');
console.log("---isDay---",isDay);

Liefert die aktuelle Uhrzeit und den heutigen Tag


  currentTime.setDate(currentTime.getDate() + 1);
  const isTomorrowDay = dateFormat(currentTime,'ee');
console.log("---xxx.isTomorrowDay---",isTomorrowDay);

Liefert den morgigen Tag

mr_petz

#48
Danke werde ich austesten.
Ich habe es wie gesagt erstmal so gelöst:

const currentTime = new Date();
let weekday = new Array("So", "Mo", "Di", "Mi", "Do", "Fr","Sa");
when = weekday[currentTime.getDay()+1];


Ok ich habe es abgeändert. Funktioniert.
So habe ich mir das alles vorgestellt...
animiertes Gif angehangen...
Edit. 2.gif ist der mixedMode größer 15min wird Zeit angezeigt, ab 15min die Minuten...
Ich habe jetzt auch das Funktionsprinzip des timeFormat und dateTill verstanden. Versuche es so einzubauen um diese diversen min Umrechnung zu beseitigen. Erstmal würde ich es wie es ist lassen...

mr_petz

Ich muss mal pushen. Upgrade auf der ersten Seite. Viele Neuerungen...

LuGu

Zitat von: mr_petz am 12 Mai 2021, 13:35:11
Ich muss mal pushen. Upgrade auf der ersten Seite. Viele Neuerungen...

Vielen Dank für das Bereitstellen des Ergebnisses eurer Fachsimpelei.

Gruß LuGu
FHEM mit RPi3 (Visu über FTUI)
HMCCU mit piVCCU3 / MQTT2 mit zigbee2mqtt

rob

Hallo zusammen.

Das Departure Widget gefällt mir sehr 8) 
Die Demo zu Departure auf Github lese ich so, als würden auch Dummy Devices benutzt werden können. Tatsächlich habe ich einen Dummy, welchen ich über eine Hilfsfunktion (myUtils) korrekt befülle. Über diesen stelle ich auch ein Update Kommando bereit.
Führe ich dieses Update Kommando in FHEM aus, wird sauber aktualisiert und schlägt auch bis ins FTUI3-Departure durch. Aus dem Widget heraus kann ich jedoch nicht aktualisieren. Was logisch ist, denn es wird eine Get-Anweisung in der departure.component.js festgelegt:

  requestUpdate() {
    fhemService.sendCommand('get ' + this.get);
  }


Dummy Devices haben im Gegensatz zu Httpmod ja keine get-Anweisung, sondern nur set. Ändere ich testweise diesen Teil in der departure.component.js entspr.:

  requestUpdate() {
    fhemService.sendCommand(this.get);
  }

und passe das Widget so an (nur set einfügen):

    <ftui-grid-tile row="8" col="4" height="6" width="7">
     <header>Departure BUS</header>
      <ftui-departure [list]="mydummy:my_dep_string" getinterval="30" get="set mydummy update" station="Neuland" VVO alternate manuell>
      </ftui-departure>
    </ftui-grid-tile>

... dann kann ich auch aus dem Widget heraus aktualisieren und wäre mit der konkreten FHEM-Anweisung relativ flexibel. Vielleicht wäre dann statt 'get' ein 'cmd' besser/ eindeutiger.

Was meint Ihr dazu?

VG
rob

mr_petz

Hi rob.
Das prüfe ich nochmal ob das so in Ordnung geht.
Hast du aber mal das wie hier:
https://forum.fhem.de/index.php/topic,63114.msg543499.html#msg543499
bei einem dummy probiert bezüglich get?

LG mr_petz

rob

Hi.

An ein cmdalias hab ich garnicht gedacht. War wohl Gedanklich zu kompliziert unterwegs. Kurzerhand getestet: läuft 1A. Dann brauchst eigentl. nicht weiter prüfen.

Danke Dir für Deine flinke Rückmeldung und den Schubser  ;D

VG
rob

mr_petz


LuGu

Hallo mr-petz,

ist es richtig, dass ich bei:

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)

nicht mit den definierten FTUI3 (z.B. primary, secondary usw.) Farben arbeiten kann?
Oder mache ich was falsch?
Würde gerne damit arbeiten, damit bei Themen Umschaltung auch Depature mit umgeschaltet wird.

Gruß LuGu
FHEM mit RPi3 (Visu über FTUI)
HMCCU mit piVCCU3 / MQTT2 mit zigbee2mqtt

mr_petz

#56
Hi LuGu.
Du müsstest so die Farben angeben für zBsp. primary:

bgcolor="var(--primary-color)"


Die einzelnen Farbdefinitionen würden dann so aussehen (ändert sich aber, wenn setstate was ändert):

--gray: #393939;
    --gray10: #1a1a1a;
    --gray15: #272727;
    --gray20: #333333;
    --gray25: #3f3f3f;
    --gray33: #545454;
    --gray40: #666666;
    --gray55: #8c8c8c;
    --gray75: #bfbfbf;
    --gray80: #cccccc;
    --gray85: #d8d8d8;
    --gray90: #e5e5e5;
    --gray95: #f2f2f2;
    --gray-trans: rgba(40, 40, 40, 0.5);
    --red: #db5d3a;
    --red-light: #EE5C42;
    --red-dark: #ad3333;
    --green: #05aaad;
    --green-light: #80d534;
    --green-dark: #365a38;
    --blue: #436D8D;
    --blue1: #20639b;
    --blue2: #173f5f;
    --blue-light: #66aaFF;
    --yellow: #eeca82;
    --yellow-light: #faeaa9;
    --yellow-dark: #deb82e;
    --orange: #f8b13e;
    --white: #ffffff;
    --brown: #bf7a37;
    --black: #111111;
    --fullblack: #000000;
    --violet: #9400d3;
    --violet2: #87606f;
    --transparent: transparent;
    --primary-color: var(--blue1);
    --secondary-color: var(--blue2);
    --success-color: var(--green);
    --info-color: var(--blue);
    --warning-color: var(--yellow);
    --danger-color: var(--red);
    --light-color: var(--gray75);
    --medium-color: var(--gray40);
    --dark-color: var(--gray25);
    --success-danger-color: var(--yellow);
    --cold-color: var(--blue1);
    --hot-color: var(--red-light);
    --cold-hot-mix-color: var(--violet2);
    --primary-contrast-color: var(--white);
    --secondary-contrast-color: var(--white);
    --primary-active-color: var(--white);
    --success-contrast-color: var(--white);
    --info-contrast-color: var(--white);
    --warning-contrast-color: var(--gray20);
    --danger-contrast-color: var(--white);
    --light-contrast-color: var(--black);
    --medium-contrast-color: var(--white);
    --dark-contrast-color: var(--white);
    --text-color: var(--gray75);
    --inactive-text-color: #1e1bcc;
    --view-toolbar-color: var(--gray15);
    --view-toolbar-background-color: var(--white);
    --view-content-color: var(--white);
    --view-background-color: var(--white);
    --view-footer-color: var(--white);
    --page-background-color: var(--fullblack);
    --grid-background-color: var(--gray20);
    --grid-header-color: var(--gray55);
    --grid-header-background-color: var(--gray15);
    --tab-color: var(--gray40);
    --tab-contrast-color: var(--gray20);
    --tab-active-color: var(--primary-color);
    --popup-color: var(--text-color);
    --popup-background-color: var(--grid-background-color);
    --popup-overlay-color: var(--fullblack);
    --popup-header-color: var(--grid-header-color);
    --popup-header-background-color: var(--grid-header-background-color);
    --circlemenu-overlay-color: var(--fullblack);
    --chart-text-color: var(--gray55);
    --chart-text-active-color: var(--white);
    --border-color: var(--gray55);
    --switch-off-color: var(--medium-color);
    --checkbox-off-color: var(--dark-color);
    --slider-track-color: var(--dark-color);
    --slider-handle-shadow: none;
    --slider-handle-border: none;
    --swiper-scrollbar-thumb: rgba(0, 0, 0, 0.5);
    --swiper-scrollbar-track: var(--transparent);
    --swiper-dot: var(--medium-color);
    --swiper-dot-active: var(--info-color);
    --segments-background-color: var(--medium-color);
    --segments-separator-color: var(--dark-color);
    --segments-selection-color: var(--primary-color);
    --segments-selection-contrast-color: var(--primary-contrast-color);
    --segments-hover-color: var(--light-color);
    --segments-text-color: var(--text-color);


Edit:
Ich habe gerade einen  Pull requests bei @setstate gestartet.
Wenn der durch ist kannst du es auch mit zBsp. : --departure-bgcolor:var(--primary-color) im css oder style angeben.

LG mr_petz

LuGu

Ok, danke. Ich werde damit mal weiter testen.

Gruß LuGu
FHEM mit RPi3 (Visu über FTUI)
HMCCU mit piVCCU3 / MQTT2 mit zigbee2mqtt

mr_petz

@LuGu
setstate hat es jetzt übernommen.
Du kannst jetzt mit der neuen Version die BG-Farben direkt ansprechen wie ich oben erwähnte..

LG mr_petz

LuGu

Prima, funktioniert.


ftui-departure {
  --departure-bgcolor: var(--primary-color);
  --departure-depcolor: var(--secondary-color);
}

Gruß LuGu
FHEM mit RPi3 (Visu über FTUI)
HMCCU mit piVCCU3 / MQTT2 mit zigbee2mqtt

mr_petz

#60
Zitat von: LuGu am 26 Februar 2022, 17:58:16
Prima, funktioniert.


ftui-departure {
  --departure-bgcolor: var(--primary-color);
  --departure-depcolor: var(--secondary-color);
}

Gruß LuGu
Super.
Hinweis:
Dein Beispiel zielt jetzt auf alle departures.
Du kannst auch eine id oder name verwenden um jedes einzeln anzusprechen.
LG mr_petz

Stonemuc

Und auch hier habe ich mal eine Frage:

Bei mir werden nach abgelaufener "Haltestellenzeit" keine neuen Daten angezeigt, auch nicht wenn ich manuell refreshe. Das Departure Widget bleibt dann leer...woran kann das liegen?
Nur wenn ich das FTUI in einem  komplett neuen Browser öffne, sind die Abfahrtszeiten bis zum Ablauf da....irgendwas mach ich ja sicher falsch

Hier mal mein device:
Internals:
   BUSY       0
   DEF        none 0
   FUUID      5e3069ce-f33f-6467-1371-309f68c0ed063af1
   Interval   0
   MainURL   
   ModuleVersion 4.1.10 - 6.7.2021
   NAME       myDeparture
   NOTIFYDEV  global
   NR         460
   NTFY_ORDER 50-myDeparture
   STATE      ???
   TYPE       HTTPMOD
   value     
   CompiledRegexes:
   HttpUtils:
     NAME       
     addr       https://transport.stefan-biermann.de:443
     auth       0
     buf       
     code       200
     compress   1
     conn       
     data       
     displayurl https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=8005947&provider=Db&limit=5
     header     
     host       transport.stefan-biermann.de
     httpheader HTTP/1.0 200 OK
Content-Length: 173
Content-Type: application/json
Date: Wed, 23 Mar 2022 07:56:01 GMT
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Robots-Tag: noindex,nofollow,nosnippet,noarchive,notranslate,noimageindex
X-Xss-Protection: 1; mode=block
     httpversion 1.0
     hu_blocking 0
     hu_filecount 1
     hu_port    443
     hu_portSfx
     ignoreredirects 1
     loglevel   4
     path       /publictransportapi/rest/departure/FHEM?from=8005947&provider=Db&limit=5
     protocol   https
     redirects  0
     timeout    30
     url        https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=8005947&provider=Db&limit=5
     sslargs:
   QUEUE:
   READINGS:
     2022-03-23 08:56:01   Uffenheim       [["RB 58117","Treuchtlingen","22"],["RB 58118","Würzburg Hbf","47"],["RB 58119","Treuchtlingen","78"],["RB 58120","Würzburg Hbf","104"],["RB 58121","Treuchtlingen","138"]]
   REQUEST:
     context    get
     data       
     header     
     ignoreredirects 0
     num        01
     retryCount 0
     type       get01
     url        https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=8005947&provider=Db&limit=5
     value     
   defptr:
     readingBase:
       Uffenheim  get
     readingNum:
       Uffenheim  01
     readingOutdated:
     requestReadings:
       get01:
         Uffenheim  get 01
Attributes:
   get01Name  Uffenheim
   get01Regex (\[\[.*\]\]).*
   get01URL   https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=8005947&provider=Db&limit=5
   timeout    30


Und hier mein aufruf in meiner index.html
<ftui-grid-tile row="1" col="15" height="5" width="6" shape="round">
<header>Bahnlinie WÜ-UFF</header>

<ftui-departure [list]="myDeparture:Uffenheim" DB icon="train" getinterval="30" get="myDeparture Uffenheim" station="DB"  refreshlist="30" manuell switch alternate nextday depscroll>
</ftui-departure>
</ftui-grid-tile>

FHEM aus Raspberry PI 3 B+, Haussteuerung auf EnOcean Basis, Tecalor THZ 404eco Wärmepumpe

mr_petz

#62
Hi.
Als erstes solltest du noch das Attribute:

attr myDeparture getDecode UTF-8

einfügen im Device, da deine Sonderzeichen/Umlaute nicht richtig dargestellt werden.

Als zweites. Was passiert in FTUI und Fhem wenn du im Device ein
get myDeparture Uffenheim
ausführst?

Und zum dritten. refreshlist ist nur für statische Listen. Steht auch auf der ersten Seite.
Dadurch wird immer nur die aktuell sichtbare Liste aktualisiert bis nix mehr drin steht und erst am nächsten Tag wieder angezeigt wenn die Zeit ran ist.
getinterval ist hier für dich richtig!
Nimm das refreshlist mal raus und mache mal so:

<ftui-departure [list]="myDeparture:Uffenheim" DB icon="train" getinterval="30" get="myDeparture Uffenheim" station="DB" manuell switch alternate nextday depscroll>
</ftui-departure>


LG mr_petz

Edit: in der nächsten Version werde ich das get Attribut raus nehmen und so anpassen dass man es nur bei Bedarf angeben muss!

Stonemuc

Zitat von: mr_petz am 23 März 2022, 10:30:31
Hi.
Als erstes solltest du noch das Attribute:

attr myDeparture getDecode UTF-8

einfügen im Device, da deine Sonderzeichen/Umlaute nicht richtig dargestellt werden.

Als zweites. Was passiert in FTUI und Fhem wenn du im Device ein
get myDeparture Uffenheim
ausführst?

Und zum dritten. refreshlist ist nur für statische Listen. Steht auch auf der ersten Seite.
Dadurch wird immer nur die aktuell sichtbare Liste aktualisiert bis nix mehr drin steht und erst am nächsten Tag wieder angezeigt wenn die Zeit ran ist.
getinterval ist dann hier richtig!
Nimm das mal raus:

<ftui-departure [list]="myDeparture:Uffenheim" DB icon="train" getinterval="30" get="myDeparture Uffenheim" station="DB" manuell switch alternate nextday depscroll>
</ftui-departure>


LG mr_petz

Oh stimmt...das ist mir noch überhaupt nicht aufgefallen, dass ich das ja die Umlaute falsch drinnen habe.
Wenn ich
get myDeparture Uffenheim
ausführe wird natürlich ganz normal das Reading aktualisiert und im "alten" FTUI funktioniert das alles auch, da werden die Abfahrten im Departure auch angezeigt.

Ich lösch mal den Teil mit refreshlist raus....vermutlich läuft es dann korrekt..

FHEM aus Raspberry PI 3 B+, Haussteuerung auf EnOcean Basis, Tecalor THZ 404eco Wärmepumpe

mr_petz

ps. dein getinterval brauchst du nicht so niedrig setzen, da deine Abfahrtszeiten ja eh im ca. 20min Takt sind und der getinterval in sec gerechnet wird...
LG

mr_petz

#65
@setstate @all
Ich habe das get Attribute entfernt und einen Pull request angeschubst. Wenn es jetzt und später noch gesetzt ist, dann ist es nicht schlimm und wird ignoriert.
Das Referenz-Datum habe ich auch noch gefixt.

LG mr_petz

Edit: get muss, wenn der Pull request durch ist, nicht mehr angegeben werden! Bsp:

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

rob

Hallo mr_petz.

OK, das get ist weg.  Das 'list=' im Bsp. holt sich das Reading HBF, richtig?
Wie sage ich im Widget von nun an, welche Funktion in FHEM zur Aktualisierung ausgeführt werden soll?

Vielen Dank und beste Grüße
rob

mr_petz

#67
Hi rob.
Der Pullrequest ist noch nicht durch.
Also get noch drinnen lassen.
Später holt sich departure durch die [ list ] Angabe die Daten und damit wird auch das get genommen und ausgeführt nach deinem eingestellten getinterval.
Hast du einen anderen Befehl zum Aktualisieren der Daten?
Ich habe bis jetzt nur immer gleiche Definitionen gesehen bei list und get.
Wenn dem so ist dass das get ein anderes ist, kann ich es noch optional einfügen.
LG

Edit: Ich habe es jetzt einfach mal als optionales Attribute wieder eingefügt...
Aber wie gesagt, der Pullrequest muss erstmal durch sein.
Das Referenzdatum hat ohne den Request keine Funktion!

rob

Hi.

Danke für Deine flinke Rückmeldung :)
Ja, ich habe tatsächlich mehrere Readings ungleich heißend zu den Update-Befehlen eingebaut.

Ausführlicher
Hab einen Dummy im Einsatz und dort die Befehle "update_bahn" und "update_bus" eingebaut, welcher eine Routine in der MyUtils ausführt und dadurch die passenden Readings im Dummy (Bus | Bahn) aktualisiert werden.
Das normale HTTPMOD Departure lt. Wiki konnte ich leider nicht mehr nehmen, weil die Aufrufe über https://transport.stefan-biermann.de bei mir nicht mehr klappen (ging eine Weile, jetzt nicht mehr). Ich aktualisiere via https://reiseauskunft.bahn.de/bin/bhftafel.exe/. Konstrukt ist leicht erweiterbar und kann mehrere FTUI3-Widgets gleichermaßen bedienen. Eigentlich ähnlich zu HTTPMOD, nur eingedampft auf ein einfaches HttpUtils_NonblockingGet($param);

Das get angeben zu können, fand ich sehr praktisch. Allerdings musste ich ja bereits get über ein cmd-alias abfangen und set ausführen --> mit der neuen Lösung müsste ich dann wohl gemäß Bsp. das "get HBF" im alias analog abfangen.
Nur wegen mir musst das also nicht unbedingt verbiegen :)  - wollte nur die neue Umsetzung gerne verstehen.
Alternativ kann ich auch einen Button ins FTUI3 packen und damit aktualisieren.

Viele Grüße
rob

mr_petz

#69
Moin.
Deine Konstelation kannte ich so noch nicht.
Ich kann auch noch ein optionales set Attribute hinzufügen. Also so:
set="Device value"
Damit wäre dann alles abgedeckt.
LG

Edit: Du könntest es auch wie ich machen. Bisher keine Ausfälle:
https://forum.fhem.de/index.php/topic,48255.msg1058924.html#msg1058924

rob

Moinsen.

Ja, den Post hatte ich bei meinen Recherchen gelesen und fand ihn hilfreich  8). Ich dachte mir halt: wenn ich eh schon myUtils anfasse, mache ich den aufwändigeren Teil nur dort und den Rest möglichst simpel (Dummy). Das HTTPMOD hatte ich auch schon definiert, es hakte noch und wurde mir dann zu oversized. Ist natürlich ein Eigenbau und genau deshalb musst/sollst Du das auch nicht supporten.

Wenn Du die set-Option trotzdem für sinnvoll erachtest, würde ich mich natürlich über diese Extrawurst freuen :) Kann natürlich passieren, dass es mit der Zeit andere User stört/ zu fragen führt.

Vielen Dank und beste Grüße
rob

mr_petz

@rob
Update ist durch.
Es gibt jetzt zusätzlich ein set Attribute und die Referenzzeit ist gefixt.
LG mr_petz

rob


DerFranke

Wie bekommt man eigentlich die Umlaute in den Griff?
https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=3003368&provider=Vgn
zeigt die Umlaute richtig an.

FHEM readings macht daraus zB
["293","Büchenbach/ER Lindnerstraße","26"]

was dann auch logischerweise von Departure so angezeigt wird.

Irgendeine Idee?