Neues FTUI Widget - Departure

[australien]

sorry, und danke!

hab gerade den Code gecheckt, war als <div> verbaut

[viegener]

Kein Problem - Gern geschehen - dafür sind ja viele hier im Forum da

[Ulm32b]

Ich glaube, Ulm32b ist etwas auf dem Holzweg. Was du willst ist eigentlich Aufgabe einer Automation.
Diese Funktion einen Frontend zu überlassen wird immer unflexibel sein.
Ich denke, dass ein Redesign des Widgets das beste wäre. Holt doch einfach die Daten mit FHEM, berechnet sie, wie ihr sie benötigt und nutzt das Widget nur zur Anzeige

Vielleicht bin ich etwas egoistisch. Mein Szenario ist, dass der mit gesundem Halbwissen ausgestattete Endanwender auch mal ein Vierteljahr nicht den Code anfasst. Dann kommt eine notwendige Änderung. Und sofort danach die Frage: Wie war das noch?
Sich dann in HTTPMOD o.ä. wieder zurechtzufinden dauert und erhöht die Hemmschwelle. Ein Parameter im FTUI-Widget erscheint mir demgegenüber transparenter.

Nachdem sich geklärt hat, dass zukünftig Relationen zwischen beliebigen (direkt verbundenen) Haltestellen geliefert werden, ist der Pflegeaufwand wohl auch viel geringer als zunächst vermutet. Wenn es unterschiedliche Relationen von Interesse gibt, könnte man ja parallel mehrere Departure-Widgets nutzen.

Also haben wir schon einen ziemlich guten Stand, wofür ich den Knowhowträgern sehr dankbar bin. Dass es, gerade im Departure-Widget, noch ein paar Ecken und Kanten gibt, glaube ich auch zu beobachten. Die Aktualisierung beim Aufruf der Seite (Pagebutton) scheint nicht mehr zu klappen, man wartet dann bis zum nächsten Longpoll. Die Spurensicherung ist ja auch schon am Werk.  https://forum.fhem.de/index.php?action=post;quote=694600;topic=48255.165#postmodify

[sbiermann]

So, ich habe mal eine erste Version des Endpunktes bereit gestellt.
Die URL sieht so aus:
https://transport.stefan-biermann.de/publictransportapi/rest/connection/FHEM?from=6906508&to=6930100&product=T&provider=Vagfr&limit=10
und liefert als Ergebnis:

Code Auswählen Erweitern

[["4","Bertoldsbrunnen","1"],["1","Bertoldsbrunnen","4"],["3","Bertoldsbrunnen","5"],["1","Bertoldsbrunnen","10"],["4","Bertoldsbrunnen","11"]]
In meinen Beispiel habe ich vom Freiburger Hauptbahnhof zum Bertoldsbrunnen gewählt. Die Zeiten sollten die Abfahrtszeiten inklusive möglicher Verspätung sein. Zu der URL, die Parameter provider und limit sind optional, wenn man die nicht angibt wird automatisch der Freiburger EFA Server genutzt und die Anzahl der Verbindungen ist auf 10 begrenzt. Der Parameter product kann T=Tram oder B=Bus sein, keine Ahnung ob es da noch andere gibt, hängt wohl vom Provider ab.
Die Anfragen sind sehr teuer (dauern lange) da die angesprochenen Provider die Strecken erst berechnen und dann das Ergebnis zurück liefern und anschließend noch weitere Ergebnisse nachgefordert werden, weil es sonst in der Regel zu wenige sind.

[zobi]

Hmm, also in meinen Tests hat es funktioniert, siehe URL weiter oben. Wie sieht denn die URL aus? Möglicherweise ist die StationId falsch.

Hi,

die Station IDs funktionieren einzeln...

hier ist mein Link:

Code Auswählen Erweitern

https://transport.stefan-biermann.de/publictransportapi/rest/connection?from=129069&to=8000240&product=T

Edit: Muss bei dem from to Link kein eigentlich kein Provider angegeben werden? Oder funktioniert das nur mit einem bestimmten?

[Mundus]

Hi,

ich muss zwei Fragen, die hier bereits gestellt wurden, aufgreifen.

Als erstes habe ich ein Problem mit dem Provider Bahn. Leider wird mein Verkehrsbetrieb nicht unterstützt, kann jedoch ("theoretisch") auf den Provider Bahn ausweichen. Nachdem ich meine Station herausgesucht habe, kommt die Fehlermeldung: EFA error status: INVALID_STATION.
Der Fehler ist reproduzierbar für verschiedene Stationen der Bahn. An dem Beispiel des Hauptknotenpunktes in der niedersächsischen Hauptstadt:
https://transport.stefan-biermann.de/publictransportapi/rest/station/suggest?q=Kr%C3%B6pcke&provider=Bahn
Die Stations-ID ist 614046
Mit diesen Informationen die Seite https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=614046&provider=Bahn aufgerufen und der o.g. Fehler erscheint.
Scheint ein ähnlicher Fehler zu sein, den Zobi in Post #173 bereits geschrieben hat.
Wie kann ich das Problem lösen?

Als zweites ist mir aufgefallen, dass meine anderen Devices- wie u.a. von Viegener am 06.10.2017 geschrieben - nicht aktualisieren wenn ein Departure-Widget eingebunden ist. Gibt es hierfür schon eine Lösung?

Gruß

[Tomatenjoghurt]

Mahlzeit, ich habe gerade noch einen Fehler im Wiki entdeckt:

Dort steht als Beispiellink:
https://transport.stefan-biermann.de/publictransportapi/rest/departureFHEM?from=6930306&provider=Vvs
es müsste allerdings mit einem zusätzlichen Slash zwischen departure und FHEM sein:
https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=6930306&provider=Vvs
Ansonsten wirft der HTTPMOD 404.

Kann das evtl im Wiki noch angepasst werden?

PS: Ich als "Neuling" finde es irgendwie merkwürdig, dass ich mich mit meinen Foren-Daten nicht im wiki anmelden kann 

[Ulm32b]

Ist korrigiert (auch wenn ich mich bisher nur um das Departure im FTUI-Wiki gekümmert hatte). Die Station-ID war offenbar auch falsch gewesen.

Den Account zur Bearbeitung bekommt man schnell bei einem Moderator, siehe Impressum.

[ih-sqeezer]

Hallo zusammen,

mir ist seit ein paar Tagen aufgefallen, dass die Updatefunktion des widgets nicht korrekt bei zwei gleichzeitig angezeigten Departure Widgets funktioniert.
Ich benutze die class "DVB" und lasse mir in FTUI zwei Haltestellen auf dem TAB anziegen. Beim ersten load werden manchmal beide widgets korrekt aktualisiert. Jedoch greift bei einem der widgets immer das auto reload / update nach 60sec nicht. Nun habe ich schon zusätzlich zum FF den Chrome ausprobiert - gleiches Ergebnis, ganz zu schweigen von Fully. Auch ein manuelles Auslösen des widget updates über den refresh buttin widget bringt keine neuen Daten zur Anzeige. Auch ein refresh der gesamten FTUI page bringt keine neuen Daten ins widget. Prinzipiell funktioniert das widget ja. Jedoch nicht mit Updates über einen längeren Zeitraum. In FHEM selbst ist mi aufgefallen, dass die nicht funktionierende HS ebenfalls nach den 60sec keine neuen Daten holt. Jedoch wird bei einem gesamten reload der FHEM page ein update ebenfalls von dieser HS durchgeführt.
Weiterhin habe ich mal beide widgets vertauscht - es wird immer das gleiche widget nicht korrekt aktualiesiert. Hat also nix mit der Position in FTUI zu tun. Auch ein Vertausch in der DEF von FHEM hat das gleiche Ergebnis gebracht. Ich bin etwas ratlos, wovon diese nicht durchgeführte Aktualisierung herkommt.
Der einzige Anhaltspunkt für mich ist, dass die nicht funktionierende HS Umlaute im Namen beinhaltet.

Kann dieses Phänomen jemand nachvollziehen? Bzw. gibt es bereits bekannte Probleme mit dem widget, sofern es auf einer page zwei Mal aufgerufen wird?

Update:
Ich habe bemerkt, dass das widget neue Daten von FHEM anzeigt, sobald in FHEM neue Daten reinkommen. Demnach muss es an FHEM selbst liegen und nicht am widget. Meine config habe ich mal mit angehangen.

Update 2:
Ich habe seit der widget v.1.53 in Fully ein Problem mit der Anzeige der Daten im widget - es bleibt leer. In allen anderen browsern funktioniert die Datenanzeige korrekt.

Danke und beste Grüße,
Ingo

[Ulm32b]

Ich kann bzw. muss dieses Verhalten bestätigen. Bei mir sind es 4 Departure-Widgets, von denen 2 beim Aufruf der Seite aktualisiert werden, die beiden anderen erst beim nächsten longpoll.

(Nur) Eines der beiden Widgets trägt einen Umlaut im Namen.

[mazze2000]

Hallo FHEM´ler
Respekt für die Arbeit, die ihr in dieses Widget steckt!
Leider funktioniert es bei mir nicht.
Die Datenquelle schein richtig zu funktionieren. Die Readings erscheinen und sehen auch richtig aus.
Im Widget erscheint jedoch nur der Stationsname...

Hier mein html Teil:
<div data-type="departure"
   data-device="VierGrenzen"
   data-get="Vier Grenzen"
   data-icon="fa-bus"
   data-interval="60">
</div>

Mein get01name: Vier Grenzen
Mein Device heißt VierGrenzen

Ist mit Sicherheit nicht die beste Bezeichnung aber sollte doch dennoch funktionieren oder nicht?
Das Leerzeichen habe ich testweise mal nur einen Bindestrich ersetzt - jedoch ohne Erfolg.

Hat da jemand einen Tipp für mich?

LG Matze

[setstate]

Ich kann bzw. muss dieses Verhalten bestätigen. Bei mir sind es 4 Departure-Widgets, von denen 2 beim Aufruf der Seite aktualisiert werden, die beiden anderen erst beim nächsten longpoll.

(Nur) Eines der beiden Widgets trägt einen Umlaut im Namen.

Bei mir funktionierten nur 2 von 3. Es lag an "Straße". Mit "Strasse" funktioniert es.

[ih-sqeezer]

Hallo zusammen,

ich denke ich habe das Problem bei mir gelöst. Meine nicht funktionierende HS hatte ein Umlaut (ä) im Namen. Diesen habe ich im attr get02Name in "ae" umgeändert. Demzufolge habe ich ebenfalls das data-get im widget ebenso angepasst.

=> auf einmal funktioniert das Update wie gewollt aller 60sec in fhem und im FTUI. Getestet im FF & Chrome. Im Fully wird das auto-update immer nur einmalig nach einem kompletten page reload ausgeführt. Danach bleibt es stumm

Zum Thema "ss" anstatt "ß":
Dies habe ich bei mir schon immer überall mit "ss" geschrieben. Dies löste jedoch nicht das auto update Problem. Es lag definitiv am Umlaut.

Grüße,
Ingo

[Ulm32b]

Ich konnte nun eindeutig nachvollziehen, dass sowohl ein Umlaut als auch ein ß im Namen des readings den refresh bei Aufrufen der Seite (pagebutton) verhinderten.
Eine entsprechende Empfehlung wurde in die Doku aufgenommen.

Gleichzeitig möchte ich hier anregen, dass die Identität des angezeigten Widgettitels und des Readings aufgehoben wird, d.h. dass der Titel im Frontend unabhängig festgelegt werden kann, z.B. durch das Attribut data-title. Damit werden Verrenkungen bei der Rechtschreibung vermieden.

[setstate]

Anregung übernommen:

data-title für den Station-Name. Wenn nicht angegeben, wird data-get angezeigt.