Neues FTUI Widget - Departure

Begonnen von setstate, 27 Januar 2016, 15:51:08

Vorheriges Thema - Nächstes Thema

sbiermann

Hi,
jetzt funktioniert er wieder. Der ÖBB Provider wurde umgestellt auf eine andere Technologie innerhalb der Lib. Daher musste ich den erst anders ansprechen damit es wieder funktioniert. In dem Zuge habe ich auch gleich geschaut welche anderen Provider noch eine Sonderbehandlung benötigen und habe dieses ergänzt. Hoffentlich ändert sich da jetzt nicht so schnell wieder was. Wer von euch die Öffi App auf dem Handy hat, wird vermutlich die vielen Updates der letzten Tage erlebt haben...

Zum Abschluss noch eine kleine Bitte, in Zukunft die URLs nur vollständig angeben. Ich musste eben erst eine ganze Weile suchen bis ich eine gültige Id für den ÖBB Provider gefunden hatte mit der ich testen konnte.

Viele Grüße
Stefan

australien

raspberry pi3
signalduino, Shelly1, Shelly2, Sonos, Unifi
Amazon Fire Tablet 7 | Noname Android Tablet 10"

kalle86

#257
Hi Stefan,

seit dem 11.11 funktioniert der link bei mir auch nicht mehr. Ich vermute mal das dort auch was umgestellt wurde!?

https://transport.stefan-biermann.de/publictransportapi/rest/station/suggest?q=Berliner-Platz&provider=Gvh

--> Provider Gvh not found or can not instantiated...


und hier mit der id:
https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=25006000&provider=Gvh

--> SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data


wäre toll wenn du das kurzt mal checken könntest   ;D

Danke und VG
Kalle

sbiermann

Hi Kalle,
ja der Provider hat auch eine neue Sonderbehandlung bekommen. Clevererweise habe ich da in der Behandlung noch einen kleinen Bug eingebaut gehabt. Der ist jetzt behoben und eine neue Version der REST-Schnittstelle läuft.

Die beiden Links funktionieren nun wieder.

Viele Grüße
Stefan

kalle86

Hi Stefan,
Vielen Dank das du soviel Arbeit in dieses Modul investierst :-)

Leider kann ich die Daten über FHEM immer noch nicht abrufen. Die JSON verlinkung klappt aber wieder!
Hat sich in der Formatierung der JSON irgendwas geändert?

Das bekomme ich in der Logfile nun ausgegeben:
2018.11.23 21:29:54 5: myDeparture: get called with Berliner-Platz
2018.11.23 21:29:54 5: myDeparture: get found option Berliner-Platz in attribute get01Name
2018.11.23 21:29:54 4: myDeparture: get will now request Berliner-Platz, no optional value
2018.11.23 21:29:54 4: myDeparture: AddToQueue adds get01, initial queue len: 0
2018.11.23 21:29:54 5: myDeparture: AddToQueue adds type get01 to URL https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=25006000&provider=Gvh, no data, no headers, retry 0
2018.11.23 21:29:54 5: myDeparture: HandleSendQueue called, qlen = 1
2018.11.23 21:29:54 4: myDeparture: HandleSendQueue sends request type get01 to URL https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=25006000&provider=Gvh, No Data, No Header
timeout 30
2018.11.23 21:29:54 5: HttpUtils url=https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=25006000&provider=Gvh
2018.11.23 21:29:54 5: HttpUtils request header:
GET /publictransportapi/rest/departure/FHEM?from=25006000&provider=Gvh HTTP/1.0
Host: transport.stefan-biermann.de
User-Agent: fhem
Accept-Encoding: gzip,deflate
Content-Length: 0
Content-Type: application/x-www-form-urlencoded

2018.11.23 21:29:55 3: myDeparture: Read callback: Error: https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=25006000&provider=Gvh: empty answer received
2018.11.23 21:29:55 4: myDeparture: Read callback: request type was get01 retry 0, body empty
2018.11.23 21:29:55 5: myDeparture: ExtractSid called, context get, num 01
2018.11.23 21:29:55 4: myDeparture: CheckAuth decided no authentication required


Hast du eine Idee woran das liegen könnte?

VG
Kalle

sbiermann

Hallo Kalle,
ich habe noch 2 Fehler gefunden gehabt. Und zwar zum einen das wenn der Provider nicht innerhalb von 15 Sekunden antwortet es einen 500 Fehlercode gab, korrekt ist da aber 504 weil ja das Fremdsystem und nicht die REST-Schnittstelle zu lange gebraucht hat. Der andere Bug war das wenn der Provider keine Daten gesendet hat, ebenfalls ein 500 Fehler gesendet wurde. Richtiger ist aber wenn ein leeres Ergebnis kommt, da die Anfrage ja korrekt war und auch erfolgreich durch geführt wurde. Dementsprechend liefert nun die Schnittstelle ein leeres Ergebnis aus. Ich vermute mal das dies bei dir den Fehler in Logfile erklärt, denn wenn ich jetzt (24.11.18 08:22) die URL https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=25006000&provider=Gvh aufrufe erhalte ich folgende Daten:
[["1","Langenhagen","7"],["1","Sarstedt","8"],["1","Langenhagen","22"],["1","Laatzen, Laatzen","23"],["1","Langenhagen","37"],["1","Sarstedt","38"],["1","Langenhagen","52"],["1","Laatzen, Laatzen","53"],["1","Langenhagen","67"],["1","Sarstedt","68"]

Kann es sein das Nachts keine Linien fahren und daher der Provider nichts liefert?

Viele Grüße
Stefan

kalle86

Hi Stefan,

leider bekomme ich immer noch die gleichen Einträge im Logfile ausggegeben wie im vorherigen Beitrag und FHEM bekommt keine neuen Readings. Um auszuschließen das es nicht an meinem System liegt, bin Ich auf ein vorheriges Backup gegangen wo es noch lief. Leider bekomme ich aber auch dort die gleiche Fehlermeldungen :-/

Die JSON lässt sich aber im Browser öffenen. Habe mal zum Testen die Url aus dem Wiki-Depature genommen. Dort auch das gleiche!!  :(

Hast du noch eine idee?

VG
Kalle


sinus61

Ich bekomme seit dem Serverumzug auch immer "empty answer received", egal ob ich es über HTTPMOD oder das Departure Modul mache.

Oder so:


{ HttpUtils_NonblockingGet({url=>"https://transport.stefan-biermann.de/publictransportapi/rest/departure?from=900175007&provider=Bvg&limit=10",callback=>sub($$$){ Log 1,"ERR:$_[1] DATA:".length($_[2]) }})}


ergibt:


2018.11.24 17:22:23 1: ERR:https://transport.stefan-biermann.de/publictransportapi/rest/departure?from=900175007&provider=Bvg&limit=10: empty answer received DATA:0


Wenn ich den gleichen URL im Browser eingebe geht es, auch auf dem Pi direkt über curl kommen Daten. Aus FHEM heraus kommt aber nichts.
Das FHEM ist aktuell, der Pi läuft noch auf Wheezy, ist soweit es geht aber aktuell.

Eine Idee woran das liegen kann?

namor

Hi,

habe exakt das gleiche Problem wie Sinus61!

sbiermann

#264
Holas,
weil schon Rückfragen kamen, ich habe mich nicht gemeldet weil es, meiner Meinung nach, ein Problem von FHEM ist.
Da ich selber das Departure Modul nicht nutze, ist mir selber kein Fehler aufgefallen. Ich habe allerdings die Datenquelle (HTTPMOD) noch eingerichtet. Wenn ich die über FHEM Oberfläche abrufe dann bekomme ich auch den selben Fehler wie Ihr alle. Das Problem ist, mit dem Umzug habe ich den Apache, den ich als Reverse Proxy nutze, so eingestellt, dass er den aktuellen (soweit das mit Ubuntu 18.04 LTS möglich ist) empfohlenen Sicherheitsstandard entspricht (https://www.ssllabs.com/ssltest/analyze.html?d=transport.stefan-biermann.de). Das heißt, es ist nur TLS 1.2 aktiv, alles andere darunter (TLS 1.0, TLS 1.1, SSLv3, usw.) nicht. Anscheinend hat dies zur Folge das HTTPMOD keine Verbindung mehr aufbauen kann, leider wird auch keine Warnung oder sowas geloggt. Ich vermute mal bei mir liegt es daran das ich einen sehr alte Debian Version (Wheezy) als Betriebsystem auf dem Raspi wo FHEM läuft verwende und damit auch eine sehr alte Perl Version. Lange Rede kurzer Sinn, ich habe den Apache so konfiguriert das er nun ebenfalls http unterstützt und nicht mehr nur https. Sprich die Url: http://transport.stefan-biermann.de/publictransportapi/rest/departure?from=900175007&provider=Bvg&limit=10 funktioniert nun und leitet nicht auf: https://transport.stefan-biermann.de/publictransportapi/rest/departure?from=900175007&provider=Bvg&limit=10 um.

Als Lösung bleibt Euch also die Umstellung auf http anstelle von https oder euren FHEM Rechner auf ein aktuelles Betriebsystem zu bringen welches die aktuellen Sicherheitsstandards für https unterstützt.

namor

Holas Stefan,

danke für Deine Mühe. Es geht bei mir leider nicht.
Habe zwar die BASE_URL auf http: umgestellt, das Modul nimmt dennoch die https: Variante.

Über eine reine HTTPMOD Abfrage geht es.

Liegt wohl am Modul bzw. an meinem Wheezy.

Marsupilami

Hallo zusammen,

bin am Verzweifeln.

Problem:


define KVV HTTPMOD none 0
attr KVV get01Name Siemens
attr KVV get01Regex (\[\[.*\]\]).*
attr KVV get01URL https://transport.stefan-biermann.de/publictransportapi/rest/departure/FHEM?from=7000104&provider=Kvv
attr KVV timeout 30


liefert folgendes reading für Siemens zurück:

[["S5","S5 Pforzheim Hbf","0"],["S5","S5 Wörth Badepark","5"],["S5","S5 Söllingen","7"],["S52","S52 Karlsruhe Europaplatz EILZUG","10"],["S5","S5 Karlsruhe Rheinbergstraße","13"],["S5","S5 Söllingen","17"],["S5","S5 Wörth Badepark","23"],["S5","S5 Pforzheim Hbf","27"],["S5","S5 Karlsruhe Rheinbergstraße","33"],["S5","S5 Söllingen","37"]]

mit dem Widget departure möchte ich mir das mittels FTUI anzeigen lassen, das Widget auf dem Tablet ist aber immer leer.

<div data-type="departure" data-device=KVV" data-get="Siemens" data-icon="fa-train" class="DVB"></div>

Wo könnte mein Fehler sein, ich finde bisher keinen ?

Gruß
Siggi




sinus61

Zitat von: sbiermann am 05 Dezember 2018, 21:25:17

Als Lösung bleibt Euch also die Umstellung auf http anstelle von https

Danke, funktioniert wieder. Sowohl mit dem Modul als auch per Httpmod.

namor

Hallo Sinus61

wie geht das bei Dir mit dem Modul???
Bei mir kann ich die URL nicht wirklich ändern.

namor

Erledigt, geht wieder.

unique hatte es mal erwähnt, das Atribut BASE_URL geht nicht.
Man muss die alternative URL hinter dem Intervall angeben.