neues Modul: TRAFFIC - google maps directions

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

Vorheriges Thema - Nächstes Thema

r00t2

#360
Zitat von: ChrisW am 27 August 2018, 13:19:50
na geil von Umstellung bis jetzt schon ca. 10€ Verbraten .. unglaublich wie teuer das ist ..
Tatsächlich "verbraten" (also insgesamt 210€ im Monat) oder mit den freien 200$ verrechnet?   :-[

Denn wie gesagt: Ich komme mit 2 Traffic Instanzen ohne Schedule auf 5k "Directions" API Zugriffe in 30 Tagen (was ca. 50$ entspricht, die von den freien 200$ abgezogen werden).
Da sind scheinbar gut 20k Zugriffe pro Monat noch möglich, ohne, dass man etwas zahlt.
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

ChrisW

Pro Monat ? Hab gedacht 200 pro Jahr ?
Also ca. 10€ habe ich in den paar Tagen nun verbraucht hab dort Limits gesetzt weil ich dachte man hat nur 200€ / Jahr Free.
Raspberry PI3 mit allem möglichen.

gent

Hi,

auch ich stand gerade vor dem Problem mit der neuen Abrechnung bei den google api's. Folgendes musste ich machen:

1. Einen "Billing Account" anlegen. Der war bei mir zwar schon da, aber es haben ein paar Angaben gefehlt (Rechnungsadresse und aktuelle Kreditkarteninfo)
2. Dem Projekt "FHEM Verkehr" (so heißt das API Projekt bei mir) den Rechnugsaccount hinzufügen

Das hat nun folgende Auswirkungen:

1. Ich habe 300$ Guthaben für 365 Tage Testzeitraum
2. Ich habe jeden Monat 200$ frei für Anfragen über alle API's

Informationen dazu findet man hier:

https://developers.google.com/maps/documentation/directions/usage-and-billing?hl=de

Viele Grüße vom gent
fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

r00t2

Zitat von: ChrisW am 27 August 2018, 18:15:05
Pro Monat ? Hab gedacht 200 pro Jahr ?.
Pro Monat - siehe auch meine Links zuvor.
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

ToM_ToM

Zitat1. Ich habe 300$ Guthaben für 365 Tage Testzeitraum

Was meinst du damit?

Das beißt sich irgendwie mit
Zitat2. Ich habe jeden Monat 200$ frei für Anfragen über alle API's

Zu den 365 Tagen konnte ich bei google nichts finden.

VG, Thomas
Hardware: BananaPi, Busmaster CUL, SanDisk 16GB Ultra SD, 16 GB USB-Stick | Software: Armbian, FHEM 5.8

gent

Hallo Thomas,

also: Die erste Info findest Du hier https://cloud.google.com/maps-platform/pricing/

Dort gibt's auch einen Preisrechner.

Die 300$ bekommst Du, wenn Du Dich - wie bisher auf der GCP (google cloud platform) anmeldest:

https://cloud.google.com/free/

Die gelten aber nur für 365 Tage.

D.h.: Wenn Du mehr als die 200$ directions api Anfragen generierst (siehe Preisrechner oben), dann zahlst Du trotzdem nichts, solange Dein Guthaben von 300$ in den ersten 365 Tagen noch nicht aufgebraucht ist.

Im Grunde genommen ändert sich fast nix gegenüber früher, wo es noch keine "billing" gab. Wenn Du natürlich zig Traffic Devices hattest, die Du jeden Tag jede Minute abgefragt hast, dann fallen da jetzt Kosten an. Also solltest Du das Attribut "upadteSchedule" und die Anzahl an Traffic Devices mal prüfen.

Und: Laut google wird nichts berechnet, wenn Du die Limits überschreitest, bevor Du nicht ausdrücklich zugestimmt hast. Im schlimmsten Fall funktioniert das Traffic Device nicht mehr, aber Du landest nicht in der Schuldenfalle ;-)

Viele Grüße vom gent
fhem auf rPi3 mit USB boot und M2, cul866 (hm), homebridge, FlowerSens, Shelly, Harmony, WemosD1, Sonoff/Tasmota, grafana, mqtt/mosquitto

ChrisW

Danke über den Link steht auch 200 / Monat. Bin mal gespannt..
Wie stelle ich upadteSchedule den ein für 2 Zeitfenster ?
Mo-Fr 6:30-10:00 und 16:00 bis 18:30  das er dort alle 5 Minuten abfragt. Andernfalls reicht mir alle 30 Minuten
Raspberry PI3 mit allem möglichen.

jmike

Hi.

Musst jeden Zeitraum einzeln angeben, ggf siehe wiki ;)

attr traffic updateSchedule 6-10 1 300|16-19 1 300|6-10 2 300|16-19 2 300|6-10 3 300|16-19 3 300|6-10 4 300|16-19 4 300|6-10 5 300|16-19 5 300

Und dann eben die Device Def auf: <key> 1800

FHEMAN

#368
Hi, ich habe seit gestern Nacht keine Aktualisierung der Werte delay_min und return_delay_min. Allerdings gibt es nach wie vor eine Differenz aus (return_)duration_min und (return_)duration_in_traffic_min. Timestamp ist so aktuell wie die anderen.
Im Log (Verbose 1) stehen keine Fehler. Verändert habe ich auch nichts.

Hast Du evtl. eine Idee?

Gruß
Ronny

//Nachtrag:
Im Moment sind die ...duration_in_traffic_min Werte sogar niedriger als die ...duration_min Werte.
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

onkel-tobi

Hallo zusammen,

hat ds inzw. jemand geschafft die Karte via push aufs Handy zu senden?

Gruß,
Tobi

jmike

@FHEMAN:  ist das Problem noch akut? Schätze mal nicht...
Das Phänomen, dass man trotz Verkehr kürzere Fahrzeit hat als normal, scheint öfter aufzutreten.
Haben wir hier im Thread auch schon ein paar Mal diskutiert. Ich glaube der Konsens war, dass duration_min ein von Google ermittelter Durchschnittswert ist und duration_in_traffic durch real-time Daten der Handys bestimmt wird.
Unter umständen ist man dann auch mal schneller unterwegs. Genau weiß das aber vermutlich nur Google, die Zahlen gibt das Modul nur weiter.

@onkel-tobi: Ich hatte mal verschiedene Ansätze durchprobiert, aus der Website ein Bild zu machen (html2canvas und so zeug) hat aber leider nicht geklappt und Google hat das derzeit auf den Static Maps nicht angeboten.
Ich werde bei Gelegenheit mal schauen obs da Änderungen gibt, die eine Lösung versprechen.

FHEMAN

Hi jmike,
ich konnte zuletzt keine Probleme mehr feststellen. Anscheinend war das ein temporäres Aktualiasierungsproblem.
Viele Grüße
NUC7i5 | PROXMOX | FHEM 6.2 | 1 HMLAND | 2 UART | HM | LMS | HIFIBERRY | DOORBIRD | BLINK | BUDERUS | HUE | ALEXA | MILIGHT | LUFTDATENINFO | MQTT| ZIGBEE2MQTT | INDEGO | ROBOROCK | SMA | APC | OPENWB

Floriky

Auf bitte von Mike meine Anfrage aus dem Thread (https://forum.fhem.de/index.php/topic,96062.0.html) hier nochmal:

"Problem":
habe bei jedem Neustart den folgenden Log-Eintrag:

PERL WARNING: Use of uninitialized value $unit in concatenation (.) or string at ./FHEM/98_TRAFFIC.pm line 823.


Antwort Mike:

Zitat von: jmike am 18 Januar 2019, 14:26:12
Hi.

Die Frage wäre vermutlich besser im TRAFFIC Thread aufgehoben (https://forum.fhem.de/index.php/topic,56045.360.html).

Die Meldung ist zwar nicht normal, aber auch unkritisch. Kommt aus einem Logaufruf ab Loglevel 5. D.h. die siehst du normalerweise gar nicht.
Warum du die siehst ist mir nicht 100%tig klar, Verursacher ist auf jeden Fall die DbLog_split Funktion. Um das festzunageln müsste ich jetzt wissen in welcher IF-Abzweigung er sich bei dir befindet.

Kannst ja mal verbose auf 5 stellen, ein update machen und dann alles ausm Log holen was anfängt mit:
TRAFFIC: (<dein-device-name>) TRAFFIC_DbLog_split...

Ansonsten ein paar Tage warten bis ichs nachstellen konnte.
lg

Und Infos von mir:


Zitat von: Floriky am 18 Januar 2019, 15:01:52
AKann ich das irgendwie Verschieben? Sonst zitier ich deine Antwort einfach in dem Thread (sofern das geht).

Also hier das gewünschte Log:


2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event status: OK on device OUT_TRAFFIC_ST_SA
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning status, OK, text
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event eta: 15:19:03 on device OUT_TRAFFIC_ST_SA
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning eta, 15:19:03, time
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event alternatives: L1208 - 21 Minuten on device OUT_TRAFFIC_ST_SA
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning alternatives, L1208 - 21 Minuten, text
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event delay: 0 min on device OUT_TRAFFIC_ST_SA
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning delay, 0 min, text
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event distance: 14,9 km on device OUT_TRAFFIC_ST_SA
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning distance, 14,9 , km
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event state: OK on device OUT_TRAFFIC_ST_SA
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning state, OK, text
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event summary: L1208 on device OUT_TRAFFIC_ST_SA
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning summary, L1208, text
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event duration_in_traffic: 21 Minuten on device OUT_TRAFFIC_ST_SA
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning duration_in_traffic, 21 Minuten, text
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event duration: 21 Minuten on device OUT_TRAFFIC_ST_SA
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning duration, 21 Minuten, text
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event time_to_leave: 9 on device OUT_TRAFFIC_ST_SA
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split auto detect unit for reading time_to_leave value 9
2019.01.18 14:57:53 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning time_to_leave, 9,
...
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event eta: 15:19:24 on device OUT_TRAFFIC_ST_SA
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning eta, 15:19:24, time
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event alternatives: L1208 - 21 Minuten on device OUT_TRAFFIC_ST_SA
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning alternatives, L1208 - 21 Minuten, text
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event status: OK on device OUT_TRAFFIC_ST_SA
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning status, OK, text
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event duration_in_traffic: 21 Minuten on device OUT_TRAFFIC_ST_SA
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning duration_in_traffic, 21 Minuten, text
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event duration: 21 Minuten on device OUT_TRAFFIC_ST_SA
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning duration, 21 Minuten, text
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event distance: 14,9 km on device OUT_TRAFFIC_ST_SA
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning distance, 14,9 , km
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event delay: 0 min on device OUT_TRAFFIC_ST_SA
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning delay, 0 min, text
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event state: OK on device OUT_TRAFFIC_ST_SA
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning state, OK, text
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event summary: L1208 on device OUT_TRAFFIC_ST_SA
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning summary, L1208, text
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split received event time_to_leave: 9 on device OUT_TRAFFIC_ST_SA
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split auto detect unit for reading time_to_leave value 9
2019.01.18 14:58:15 5: TRAFFIC: (OUT_TRAFFIC_ST_SA) TRAFFIC_DbLog_split returning time_to_leave, 9,


Hoffe das hilft dir weiter. Vielen DANK für deine Mühen!

somansch

Hallo,

ich habe seit 2 Tagen permante Logeinträge vom Traffic-Modul:
2019.06.30 21:04:11 1: PERL WARNING: Use of uninitialized value in join or string at ./FHEM/98_TRAFFIC.pm line 626.
2019.06.30 21:04:11 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_TRAFFIC.pm line 627.
2019.06.30 21:04:11 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_TRAFFIC.pm line 624.


gefolgt von:
2019.06.30 20:54:09 1: TRAFFIC: (TrafficMaps_XXX) did not receive duration_in_traffic, not able to calculate delay
2019.06.30 20:54:09 3: deletereading TrafficMaps_XXX error_message : Deleted reading error_message for device TrafficMaps_XXX


Hat jemand das gleiche Problem?

Viele Grüße
Andreas

somansch

Zitat von: somansch am 30 Juni 2019, 21:17:34
Hallo,

ich habe seit 2 Tagen permante Logeinträge vom Traffic-Modul:
2019.06.30 21:04:11 1: PERL WARNING: Use of uninitialized value in join or string at ./FHEM/98_TRAFFIC.pm line 626.
2019.06.30 21:04:11 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_TRAFFIC.pm line 627.
2019.06.30 21:04:11 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_TRAFFIC.pm line 624.


gefolgt von:
2019.06.30 20:54:09 1: TRAFFIC: (TrafficMaps_XXX) did not receive duration_in_traffic, not able to calculate delay
2019.06.30 20:54:09 3: deletereading TrafficMaps_XXX error_message : Deleted reading error_message for device TrafficMaps_XXX


Hat jemand das gleiche Problem?

Viele Grüße
Andreas

Hat sich erledigt. Ich musste das Google Cloud Konto upgraden  ;)