neues Modul: TRAFFIC - google maps directions

Begonnen von jmike, 27 Juli 2016, 10:51:23

Vorheriges Thema - Nächstes Thema

Naboo

Zitat von: Amenophis86 am 29 September 2017, 12:00:36
Gibt es hier schon etwas Neues, zumindest was die lange Fehlermeldung im Log unterbindet (abgesehen vom Verbose Level)?

Hi All, erstmal von mir auch ein Danke für das Modul, ich verwende es schon recht lange, ist wirklich super!

ich hab zwei Traffic Devices 1x Driving und 1x Transit - bei mir tritt der Warnings "Fehler" im Log bei sogut wie jeder Abfrage des Devices mit Transit TravelMode auf - ich hab mal versucht die Werte nachzuvollziehen und bin zu folgender Theorie gekommen:

Kann es sein dass (seit 05.07.2017) Google bei einer Strecke die keine Verspätung hat, einfach auch keinerlei Rückgabewerte wie "delay" und "duration_in_traffic" mehr ausgibt?

Ich hab mal zwei Screenshots meiner deviceReadings angehängt - der Screenshot mit Delay funktioniert prima (ist eine Strecke auf der sogut wie immer Stau´s vorhanden sind, daher gibt´s hier auch nie irgendwelche Warnings im Log) - beim Screenshot ohne Delay (ist eine Zugstrecke mit sehr wenigen Verspaetungen) fehlen die Readings (eben seit 5.7.17) und die ETA wird auch nicht ausgegeben (wegen des fehlenden Delay Werts?) -> imho hier ständig Warnings im Log File...

Kann dies das "Problem" sein? - bzw. kann das jemand von euch nachvollziehen?

Danke und lg, Markus


Gunther

Danke erstmal für das colle Modul. Habe es erst heute entdeckt.

Gibt es irgendwo eine Erklärung zu den Readings, ohne dass ich alle Posts hier durchlesen muss?
Das Wiki und die commendref helfen mir zu meinen Readings nur bedingt weiter.

Ich habe z. B. folgende:
  2017-11-07 21:58:25   delay           0 min
     2017-11-07 21:58:25   distance        18,0 km
     2017-11-07 21:58:25   duration        26 Minuten
     2017-11-07 21:58:25   duration_in_traffic 23 Minuten
     2017-11-07 21:58:25   eta             22:21:03
     2017-11-07 21:58:25   state           0 min
     2017-11-07 21:58:25   status          OK


Ich hätte nun erwartet, dass duration_in_traffic die Zeit mit verkehr ist und daher länger als duration.
Habe ich einen Denkfehler?
FHEM@Proxmox@Nuc: TabletUI als User-Interface (4 Wandtablets) / IOs per ser2net gekapselt
Homematic: Heizung, Fenster, Bewegung | Jeelink: Temperatur | Z-Wave: Bewegung, Temperatur | FS20: Temperatur, Fenster | Viessmann-Heizung eingebunden

Amenophis86

Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

ChrisW

jemand eine idee wie ich es hinbekomme das immer ein genauer Weg genommen wird ? Da manchmal einen anderen Weg über Landstraße genommen wird und die Zeiten dann nicht mehr Stimmen.
Raspberry PI3 mit allem möglichen.

MadMax-FHEM

Zitat von: ChrisW am 08 November 2017, 18:13:51
jemand eine idee wie ich es hinbekomme das immer ein genauer Weg genommen wird ? Da manchmal einen anderen Weg über Landstraße genommen wird und die Zeiten dann nicht mehr Stimmen.

Schau dir mal das Attribut waypoints an...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

jmike

Zitat von: Naboo am 06 November 2017, 16:40:48
Kann es sein dass (seit 05.07.2017) Google bei einer Strecke die keine Verspätung hat, einfach auch keinerlei Rückgabewerte wie "delay" und "duration_in_traffic" mehr ausgibt?

...
Kann dies das "Problem" sein? - bzw. kann das jemand von euch nachvollziehen?

Hi Markus.
Kann ich leider nicht nachvollziehen. Bei mir werden immer alle Readings aktualisiert soweit ich sehen kann.
Wenn sich das breiter Verteilt, muss ich das definitiv im Modul abfangen.


Zitat von: Gunther am 07 November 2017, 22:08:23
Ich hätte nun erwartet, dass duration_in_traffic die Zeit mit verkehr ist und daher länger als duration.
Hi Gunther.
Das habe ich auch schon beobachtet und das Modul zeigt einfach das an, was Google liefert.
Meine Theorie ist, duration ist eine art Mittelwert und duration_in_traffic ist anhand von Mobile Daten relativ akkurat. Und wenn so wenig Verkehr ist, dass man schneller ist als der übliche Mittelwert, ist duration_in_traffic sogar schneller als normal.

Aber sicher bin ich mir damit nicht ;)


@ Amenophis86: Hab die neuen Änderungen so gut wie fertig, teste aber noch etwas rum.

Amenophis86

Zitat von: jmike am 21 November 2017, 09:36:32
@ Amenophis86: Hab die neuen Änderungen so gut wie fertig, teste aber noch etwas rum.

Top, ich danke dir :)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

jmike

#292
Hi.

Da ich eine Menge Sachen geändert habe, und den nächsten Release nicht noch weitere Wochen durch meine Tests aufhalten möchte, hier im Beitrag die aktuelle Beta.
Vielleicht finden sich ein paar Beta-tester und wenn bei euch auch alles passt, geht es asap ins SVN.

Wiki und commandref ist auch noch nicht up to date.

Die wichtigsten Änderungen:
- JSON Fehler werden korrekt aufgefangen, und (hoffentlich) mit retry versehen. Das konnte ich nicht zu 100% testen.
- added Dbog_splitFn
- added reading summary
- new attr GoogleMapsFixedMap
- new attr alternatives, new reading alternatives (routen name + duration_in_traffic)
- alternatives displayed on map with lighter&thinner stroke than primary route



Amenophis86

Sehr schön, dann schaue ich mal, ob ich die nächsten Tage zum testen kommen kann. Hab ja immerhin auch einen Wünsch geäußert gehabt :)
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

Amenophis86

Seit ich es installiert habe, hatte ich bisher keine Fehler. Scheint also ganz gut zu laufen.
Aktuell dabei unser neues Haus mit KNX am einrichten. Im nächsten Schritt dann KNX mit FHEM verbinden. Allein zwei Dinge sind dabei selten: Zeit und Geld...

jmike

v1.3.3 ist im SVN und ab morgen per update Verfügbar.

Wie gesagt:
- JSON Fehler werden korrekt aufgefangen, und (hoffentlich) mit retry versehen. Das konnte ich nicht zu 100% testen.
- added Dbog_splitFn
- added reading summary
- new attr GoogleMapsFixedMap
- new attr alternatives, new reading alternatives (routen name + duration_in_traffic)
- alternatives displayed on map with lighter&thinner stroke than primary route


Wiki Update folgt.

...frohes Neues :)

mcfhem

Zu duration_in_traffic heißt es in der Google-Doku:
"duration_in_traffic gibt die Gesamtdauer dieses Abschnitts an. Dieser Wert ist eine Schätzung der Dauer auf der Grundlage gegenwärtiger und zurückliegender Verkehrsbedingungen. Im Parameter traffic_model finden Sie die Optionen, mit denen Sie eine optimistische, pessimistische oder bestmögliche Schätzung anfordern können."
"traffic_model" beeinflusst den im Feld duration_in_traffic zurückgegebenen Wert.

Welche Optionen sind denn im Traffic-Modul hinterlegt? Kann ich die ändern, um so die Ausgabe von duration_in_traffic zu beeinflussen?

MadMax-FHEM

Dazu brauchst du eine "premium google maps api-ID"...
...kostet wahrscheinlich Geld...

Siehe z.B. dort:

https://developers.google.com/maps/documentation/directions/intro?hl=de

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

mcfhem

Ich meinte, was im FHEM Modul hinterlegt ist. Das Reading spuckt doch nur duration_in_traffic aus. Aber welche Annahme ist da hinterlegt?

jmike

Zitat von: mcfhem am 03 Januar 2018, 11:14:46
Welche Optionen sind denn im Traffic-Modul hinterlegt? Kann ich die ändern, um so die Ausgabe von duration_in_traffic zu beeinflussen?

Das Modul nutzt den Wert aktuell gar nicht, d.h. es wird der default "best_guess" verwendet und er ist (aktuell) nicht konfigurierbar.