neues Modul: TRAFFIC - google maps directions

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

Vorheriges Thema - Nächstes Thema

Gisbert

Hallo jmike,

seit heute vormittag, ca. 10:50 bekomme ich keine updates mehr. Im state steht: OVER_QUERY_LIMIT.

An zu vielen Abfragen kann es eigentlich nicht liegen; ich frage nur engmaschiger ab, wenn bei mir üblicherweise eine Fahrt ansteht. Es gibt noch weitere Strecken, da ist es dasgleiche.

Anbei ein list des Devices.
Internals:
APIKEY ***GEHEIM***
CFGFN ./FHEM/Traffic.cfg
DEF ***GEHEIM*** 7200
FUUID 5c430dcd-f33f-b139-90f8-6b657caa5fad916b
INTERVAL 7200
NAME DormagenNachhause
NR 150
STATE 35 Min.
TRIGGERTIME 1563209176.88166
TRIGGERTIME_FMT 2019-07-15 18:46:16
TYPE TRAFFIC
UPDATESCHEDULE 16-20 1 150
VERSION 1.3.7
OLDREADINGS:
READINGS:
2019-07-15 18:43:47 alternatives -
2019-07-15 08:00:00 average_delay_min 2.5
2019-07-15 10:46:12 average_duration_in_traffic_min 32
2019-07-15 10:46:12 average_duration_min 32.5
2019-07-15 10:46:12 delay_min 0
2019-07-15 10:46:12 duration_in_traffic_min 33
2019-07-15 10:46:12 duration_min 33
2019-07-15 18:43:47 durationtrafficmin 35
2019-07-15 10:46:12 eta 11:19:24
2019-07-15 18:43:47 state OVER_QUERY_LIMIT
2019-07-15 18:43:47 status OVER_QUERY_LIMIT
2019-07-15 10:46:12 summary A1
helper:
GoogleMapsCenter ,
Poly
bm:
TRAFFIC_Attr:
cnt 1
dmx -1000
dtot 0
dtotcnt 0
mTS 15.07. 10:16:04
max 0.000315189361572266
tot 0.000315189361572266
mAr:
set
           DormagenNachhause
waypoints
51.027582, 7.055030
TRAFFIC_Set:
cnt 49
dmx -1000
dtot 0
dtotcnt 0
mTS 15.07. 18:16:14
max 0.000379085540771484
tot 0.00563430786132812
mAr:
HASH(0x555c9feecec8)
           DormagenNachhause
           

Attributes:
GoogleMapsCenter 51.0419249060594,6.942634289062548
GoogleMapsStroke #001aff,6,50,#FF0000,1,100
GoogleMapsTrafficLayer 1
GoogleMapsZoom 12
disable 0
end_address Kuhlmannweg 8, 51375 Leverkusen
icon car
outputReadings min, average
room Mobile,Traffic
start_address 51.081735390574345,6.84137642
stateFormat = 40
"red":"black")}'>[$name:durationtrafficmin] Min.
updateSchedule 16-20 1 150|16-20 2 150|16-20 3 150|16-20 4 150|16-20 5 150|8-16 1 1800|8-16 2 1800|8-16 3 1800|8-16 4 1800|8-16 5 1800
userReadings durationtrafficmin {round(ReadingsVal($name,"duration_in_traffic_min",0)+2,0)}
userattr GoogleMapsCenter GoogleMapsStroke GoogleMapsTrafficLayer GoogleMapsZoom disable end_address icon outputReadings start_address stateFormat updateSchedule userReadings verbose waypoints
verbose 1
waypoints 51.027582, 7.055030


Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

somansch

Hast du bereits dein Google Cloud Konto aktualisiert?

Gisbert

Hallo somansch,

das war's wohl, bei Google Cloud Platform steht jetzt:
Ihre kostenlose Testversion ist abgelaufen, aber mit der Google Cloud Platform kann es weitergehen. Wenn Sie die Dienste weiterhin nutzen möchten, führen Sie bis zum 14. August 2019 ein Upgrade durch.

Wenn ich auf die angebotenen weiteren Informationen klicke, erhalte ich keine eindeutige Aussage, ob der Dienst für mich weiter kostenlos ist.

In der monatlichen Rechnung für Juni steht:
Anzahl: 8242
Betrag: 73,95 Euro,
wobei dieser dann auf Null gesetzt wurde.

Ich frage mich jetzt, ob ich in der Zukunft etwas zahlen müsste. Auf jeden Fall wäre es mir keine 74 Euro per Monat wert.

Wie ist deine Meinung?

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

jmike

Hi Gisbert

Die Meldung OVER_QUERY_LIMIT ist eigentlich recht eindeutig. Entweder zu viele requests pro Sekunde, oder zu viele pro Tag.
Was steht denn bei dir im Google Account? Wie viele API Abfragen hast du denn pro API Key?

Ich werde in der neuen Version noch einen API counter einbauen.
Dann kann man im Device sehen wie viel Querys abgesetzt wurden.

lg

jmike

...Ich hoffe, die Info ist so noch aktuell und akkurat.

Google gibt dir, wenn ein Abrechnungskonto erstellt wurde, ein monatliches Kontingent von 200$ (~177€) kostenlos.
Damit wäre deine aktuelle Konfiguration inkludiert und im Prinzip umsonst.

Nach Registierung gibts noch mal 300$ für alles, was darüber hinaus geht. Zumindest fürs erste Jahr.
Angeblich gibts keine Belastung ohne ausdrückliche Infos seitens Google, darauf verlasse ich mich persönlich aktuell - denn gut und übersichtlich finde ich das Konstrukt nicht wirklich :/

Gisbert

Hallo jmike,

danke für die Info; dann wage ich es mal und hoffe, dass es kostenlos bleibt.

Viele​ Grüße​ Gisbert​
Aktuelles FHEM | PROXMOX | Fujitsu Futro S740 | Debian 12 | UniFi | Homematic, VCCU, HMUART | ESP8266 | ATtiny85 | Wasser-, Stromzähler | tuya local | Wlan-Kamera | SIGNALduino, Flamingo Rauchmelder FA21/22RF | RHASSPY | DEYE | JK-BMS | ESPHome

mkriegl

Ich habe auch folgenden Fehler, den ich aber nicht auf die Abrechnung zurück führen kann. Ich nutze den travelMode transit und mir ist nur aufgefallen, wenn ich die Abfrage direkt im Browser mache, dass mir keine duration_in_traffic zurück gegeben wird (weil wahrscheinlich nicht vorhanden). Bei travelMode car wird dies schon zurückgegeben. Fehlt das in der Implementierung?
2019.09.13 08:52:53 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_TRAFFIC.pm line 624.
2019.09.13 08:52:53 1: TRAFFIC: (TrafficGoogleZurArbeit) did not receive duration_in_traffic, not able to calculate delay

jmike

Danke für den report.

Die WARNING kann/werde ich rausmachen mit der nächsten Version, ist nur kosmetisch.

Die zweite Meldung ist, wie korrekterweise vermutet, weil Google einen benutzten Wert nicht zurück gibt. Möglich dass das für "transit" fehlt.
Muss ich mal schauen ob es Sinn macht, die Berechnung bei "transit" komplett auszulassen bzw. die Meldung hochzustufen dass sie nicht unter verbose 1 auftaucht. Soweit alles works-as-designed ;)

Lg

chunter1

Erst mal vielen Dank für das tolle TRAFFIC Modul!
Zum update Mechanismus hätte ich eine Frage:
Ist es richtig, dass das Update IMMER im Raster des im DEF angeführten Intervalls ausgeführt wird und mittels updateSchedule zu bestimmten Zeiten anpassbar ist?
Ich versuche nämlich grade das ganze so zum Laufen zu bekommen, dass er ausschließlich in den updateSchedule Zeiträumen updatet und außerhalb gar nicht.
Wenn ich im DEF als Intervall "0" angebe, scheint das Modul "deaktiviert" zu sein und ignoriert die updateSchedule Zeiträume.
Ich nehme an, dass das so mit dem Modul nicht geht und ich mittels z.B. DOIF ein Update von extern anstoßen muss?

iCure

Gibt es denn keine alternative für diese GoogleAPI geschichte? Von mir wollten sie nach kurzer Zeit 370€ haben, weil anscheinend massiv Trafficabfragen entstanden. Habe dies dann durch den Support nicht zahlen müssen aber halte mich jetzt von der kostenpflichtigen API Geschichte fern. Dafür kenn ich mich damit zu wenig aus.

jmike

Oh. Das sind schlechte Nachrichten zumal ja dann das freie Limit von 360$ auch aufgebraucht war, d.h. >600€ generiert wurde.
Eventuell muss ich das sogar zukünftig im Modul abfangen.
Schade dass Google die APIs nicht auf Abrechnungs-los Konfigurieren lassen.

Wie viele devices mit welchem Intervall hattest du laufen?

schnibberle

Hier noch eine Variante zur Darstellung der Fahrzeiten für alle Pendler denen das mit der Google API zu gefährlich ist bezgl. kosten

define FHEM.Verkehr.HeimArbeit HTTPMOD https://route.api.here.com/routing/7.2/calculateroute.json?app_id=<APP_ID>&app_code=<APP_CODE>&waypoint0=geo!14.382610,10.060540&waypoint1=geo!10.382400,9.246920&mode=fastest;;car;;traffic:enabled 60
attr FHEM.Verkehr.HeimArbeit userattr get01JSON getData reading01JSON reading01Name requestHeader stateFormat
attr FHEM.Verkehr.HeimArbeit reading01JSON response_route_01_summary_trafficTime
attr FHEM.Verkehr.HeimArbeit reading01Name traffictime
attr FHEM.Verkehr.HeimArbeit requestHeader Content-Type: application/json
attr FHEM.Verkehr.HeimArbeit room E-Verteiler
attr FHEM.Verkehr.HeimArbeit stateFormat {sprintf("%02d:%02d:%02d", ReadingsVal($name,"traffictime",0)/3600, ReadingsVal($name,"traffictime",0)/60%60, ReadingsVal($name,"traffictime",0)%60)}


Einfach Account bei her*.com erstellen AppCode , AppID und geo Daten der Waypunkte ändern.
Anschließend bekommt ihr die Fahrzeit als state. Hilfreich für Pendler.

desyer

Hallo zusammen,

möglicherweise könnt Ihr mit bei meinem aktuellen Traffiv Thema helfen:

Link: https://forum.fhem.de/index.php/topic,110418.0.html

Beste Grüß
Desyer

chris303

Hallo jmike,

besten Dank für deine bisherige Arbeit.

Hättest du Lust, die Möglichkeit zu implementieren, den Basis-Updateprozess auszuschalten (vielleicht mit Intervall 0 oder so in der Richtung)? Die Stoßzeiten reichen mir völlig aus und einen unsinnig hohen Wert einzutragen, so wie ich es aktuell "gelöst" habe ist irgendwie doof :-)

Besten Dank und viele Grüße, Chris

jmike

Hi Chris.

Schau ich mir gerne an und mach ein Update/fix für.

Ich hab das Modul auch schon um TomTom Maps erweitert, die sind aktuell noch umsonst.