[Aufruf] Neuer Adaper Google-Sharedlocations

[nik82]

@david-g

Ja ich weiß nicht, ich denke wenn der alle 5 Sekunden einen ping macht, dass es schon eine gewisse unnötige Netzwerk belastung ist.
Der TR-64 Adapter hab ich auch im Einsatz, ging mir aber auch zu langsam.
Also ich bin mit Tasker sehr zufrieden, geht bei mir einwandfrei...

[David G.]

@nik82

Tasker ist auch klasse.
Hab ich sehr viel drüber am laufen (eine Zeit lang sogar das ganze geofencing).

Die Frage ist was @maxpd erreichen möchte.
Geht es um die reine Anwesenheitserkennung oder soll ggf schon die Heizung eingeschaltet werden wenn er in 5km zu Hause ankommt.

[maxpd]

@david-g

Jawoll, also von unterwegs 5km vorm Ziel soll tatsächlich schon die Heizung hochfahren. Klappt nicht immer.
Nur wird man auch begrüßt wenn man die Tür reinkommt und es werden Einbruchsszenarien ausgeführt.

Begrüßung erfolgt oft erst beim Dritten Durchlauf durch den Flur.
Einbruch wird gemeldet, sobald eine Tür geöffnet wird, obwohl man schon seit 5 min zu Hause ist.

Handys anpingen hab ich über Ping und tr-64 Adapter schon integriert, bringt aber nichts, weil das Handy sich nicht direkt mit WLAN verbindet, wenn Display aus ist. Da kann das schon mal paar Minuten dauern.

Der Fence ist auf 250m gestellt, was selbst beim zu Fuß heimkommen ein zu kurzer Zeitraum zu sein scheint.

Tasker hab ich vor 10 Jahren intensiv genutzt und irgendwo noch die ProVersion. Ich probiere dann per Intervall Standort abzufragen, kann mir aber vorstellen, dass das den Akku leerzieht. Der langt so schon keinen Tag

[Jan1]

@maxpd
Eine Anwesenheitserkennung über den Adapter hier kannst vergessen, da je nach Handy ab und an mal das Ding in Google ca. 500m weiter weg geortet wir, obwohl es sich kein mm bewegt hat. Da müsste dann der Fence für "zu Hause" auf 500m erweiter werden, was Quatsch ist. Liegt aber nicht am Adapter, da der ja nur das abholt, was Google liefert und das wiederum nur das was das Handy macht. Frauchens Honer bleibt z.B. zu Hause während mein Samsung eben ab und an mal einfach wo anders wäre.
Dann kommt noch dazu, das Google das nicht in Echtzeit macht und wenn Du mit dem Auto bis vor die Haustür fährst, Google meist noch 5 km weg ist.
Hier hilft nur ne Kombination aus BWM, Ping und Geodaten um die echte Position der zu prüfenden Personen auswertet.

[David G.]

@maxpd

Interessant,

habe genau die selbe Kombination.
Ping und den shared locations Adapter.

Habe den Radius auf 300m. Das macht bei mir von der Straßenführung her Sinn.

Hatte jetzt in ca 10 Monaten 2 Fehlalarme.

[maxpd]

@jan1 Das ist was ich mache
Ping und GPS bislang, BMW hab ich nicht

Zudem werte ich nur ERgebnisse mit Genauigkeit < 100m aus.

[Jan1]

@david-g
Wie geschrieben, manche Hndys verhalten sich auch noch etwas seltsam und somit hauts bei einem sehr gut hin und beim anderen etwas schlechter. Hätte ich zwei mal das Honor hier, würde das schon wesentlich besser laufen. Die Apfel Dinger sind da wohl, wie immer noch mieser, was man hier im Forum zwecks WLAN Erkennung so liest
Fakt, je mehr Geräte überwacht und je mehr DPs dazu verwendet werden, desto genauer wird der Spaß.

Über GPS und Google ist eben kostenlos und somit muss man mit der etwas trägeren Standort Übermittlung zufrieden sein. Hier spielt aber auch noch ne große Rolle, ob das Handy im Auto überhaupt GPS hat, oder nur über die Sendemasten geortet wird. Bei Frauchen ist das meist sehr schlecht, bei mir wieder recht gut, da mein Handy an der GPS Dachantenne mit dranhängt.
Viele Faktoren, viele Möglichkeiten

[maxpd]

Also owntracks ist raus. Abfrage auf 900s bei Stillstand und 30 Sekunden bei Bewegung aktiviert. 5h und nur zu Hause. 16 % akku werden von owntracks verwendet. Nicht akzeptabel.
Dann noch tasker probieren.

[maxpd]

Jetzt wirds ganz abstrus.

Also mit Tasker sinds so 5% Akku. Seit dem Tasker den Standort zieht hab ich ständig "Fehlalarme" wo mein Haus denkt ich bin nicht da. Obwohl ich auf eine Genauigkeit von <60m in einem Fence von 250m prüfe.

Zudem lasse ich mir zum Fehlalarmzeitpunkt Genauigkeit und Standort ausgeben und es ist immer die korrekte Adresse + eine Genauigkeit von 20m.

Ich kapiers nicht.

[MiGoller]

Vielen Dank für das Weiterführen des Adapters, @Garfonso .

Allerdings habe ich noch eine Frage zu den "Fences", auf die ich bislang keine Antwort gefunden habe; wahrscheinlich habe ich diese einfach übersehen. In der Readme.MD habe ich folgenden Hinweis gefunden:

Circularly shaped geofences can be defined in the adapter config. These geofences can be associated with users, i.e. that a state is toogled if the user enters or leaves a geofence.

Kann ich hier nur einen (Google-) Benutzer zu einem Bereich hinzufügen, oder können es mehrere sein? Das wäre für meinen Anwendungsfall praktisch, sonst muss es der Places-Adapter richten.

[Garfonso]

@migoller
du kannst zum einen die Position aus dem Adapter einfach an den places Adapter weiterleiten. Das ist kein Problem (und ermöglicht ggf. auch später den location adapter zu wechseln, falls der dann auch places kann).

Ansonsten kann man in den Instanzeinstellungen im Grunde für die Kombination "GPS Punkt + Radius + Google Nutzer von dem die Location kommt" eine stateId festlegen, die dann mit true/false gesteuert wird. Also, ja, du kannst feststellen, dass ein bestimmter Google Nutzer in einem Bereich ist (bzw. umgekehrt: wenn du wissen willst ob ein beliebiger Nutzer in einem Bereich ist, musst du den für jeden Nutzer festlegen und mehrere states prüfen).

[mrhary]

Hab meine IOBroker neu aufgesetzt, leider funktioniert das mit dem Cookie bei mir nicht mehr! Bekomme immer nur die Meldung Connection failed.

Egal wo ich beim Cookie beginn, kann mir jemand einen Tipp geben?

[Garfonso]

@mrhary
welche Version vom Adapter hast du denn installiert? Versuch nochmal von github.

[Jan1]

@garfonso
Google hat mal wieder was geändert und ich habe eben gerade die GIT Version des Adapter geladen. Im Log steht, dass ein Zeichen des Cookie nicht passt, wobei was soll man da bei copy&paste falsch machen, zumal ich das jetzt auch schon recht oft gemacht habe.

TypeError [ERR_INVALID_CHAR]: Invalid character in header content ["Cookie"]

[Garfonso]

@jan1

Hm.. kann ich bei mir nicht reproduzieren... gibt es davor noch Warnungen?
Ist das die Version 2.1.6 von hier https://github.com/Garfonso/ioBroker.google-sharedlocations?

[mrhary]

@garfonso 2.1.6 von github

[mrhary]

@jan1 TypeError [ERR_INVALID_CHAR]: Invalid character in header content ["Cookie"] ist auch in meinem LOG vorhanden

[mrhary]

Ohne jegliches zutun meiner seits, ist heute früh der adapter wieder aktiv und funktioniert einwandfrei!

[Garfonso]

@mrhary
und davor gab es vom adapter keine Warnungen?

Ohne Informationen, welche Bestandteile des Cookies abgelehnt werden... und von wem... wird das schwierig zu beheben sein. Eigentlich gibt es in 2.1.6 einen Filter, der möglicherweise unerlaubte Bestandteile (das ist auch nicht ganz klar, was erlaubt ist und was nicht) rausfiltert und entsprechend warnt (ggf. aber nur beim Adapterstart einmal).
Irgendwie sieht der Fehler auch so aus, als ob er lokal kommt, also von axios oder der node.js Version lokal abhängt...

Wie sich das selber reparieren kann... hm... ok, der Adapter 2.1.6 speichert sich den Cookie, den der Server zurückschickt und aktualisiert damit den Cookie, den er sendet. Das könnte natürlich teile dann plötzlich gültig machen, wenn die Anfragen durchkommen kopfkratz (was dann aber gegen einen lokalen Fehler spricht?). Komisch... oder ist der Fehler doch an anderer Stelle...

Stirbt der Adapter?
Gibt es, wenn der Fehler im log kommt, trotzdem Updates? ggf. auch nur von einem Teil der Daten?

[Jan1]

@garfonso
hier mal das Log im Debug Modus beim Adapter Start:

2022-05-11 16:59:32.540 - info: admin.0 (281919) ==> Connected system.user.admin from ::ffff:192.168.100.16
2022-05-11 16:59:39.185 - warn: admin.0 (281919) Read-only state "google-sharedlocations.0.info.augmented_cookie" has been written without ack-flag with value ""
2022-05-11 16:59:39.277 - info: host.Beelink stopInstance system.adapter.google-sharedlocations.0 (force=false, process=true)
2022-05-11 16:59:39.288 - info: google-sharedlocations.0 (366242) Got terminate signal TERMINATE_YOURSELF
2022-05-11 16:59:39.296 - info: host.Beelink stopInstance system.adapter.google-sharedlocations.0 send kill signal
2022-05-11 16:59:39.293 - info: google-sharedlocations.0 (366242) terminating
2022-05-11 16:59:39.295 - info: google-sharedlocations.0 (366242) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason
2022-05-11 16:59:39.560 - info: admin.0 (281919) <== Disconnect system.user.admin from ::ffff:192.168.100.16
2022-05-11 16:59:39.957 - info: host.Beelink instance system.adapter.google-sharedlocations.0 terminated with code 11 (ADAPTER_REQUESTED_TERMINATION)
2022-05-11 16:59:42.418 - info: host.Beelink instance system.adapter.google-sharedlocations.0 started with pid 367009
2022-05-11 16:59:43.548 - debug: google-sharedlocations.0 (367009) Redis Objects: Use Redis connection: 127.0.0.1:9001
2022-05-11 16:59:43.673 - debug: google-sharedlocations.0 (367009) Objects client ready ... initialize now
2022-05-11 16:59:43.677 - debug: google-sharedlocations.0 (367009) Objects create System PubSub Client
2022-05-11 16:59:43.678 - debug: google-sharedlocations.0 (367009) Objects create User PubSub Client
2022-05-11 16:59:43.742 - debug: google-sharedlocations.0 (367009) Objects client initialize lua scripts
2022-05-11 16:59:43.749 - debug: google-sharedlocations.0 (367009) Objects connected to redis: 127.0.0.1:9001
2022-05-11 16:59:43.782 - debug: google-sharedlocations.0 (367009) Redis States: Use Redis connection: 127.0.0.1:9000
2022-05-11 16:59:43.812 - debug: google-sharedlocations.0 (367009) States create System PubSub Client
2022-05-11 16:59:43.814 - debug: google-sharedlocations.0 (367009) States create User PubSub Client
2022-05-11 16:59:43.851 - debug: google-sharedlocations.0 (367009) States connected to redis: 127.0.0.1:9000
2022-05-11 16:59:44.300 - info: google-sharedlocations.0 (367009) starting. Version 2.1.6 (non-npm: Garfonso/ioBroker.google-sharedlocations#85d8b0a5e1c3eb10986169863c6fd9b3dd271c5d) in /opt/iobroker/node_modules/iobroker.google-sharedlocations, node: v14.19.2, js-controller: 4.0.23
2022-05-11 16:59:44.334 - info: google-sharedlocations.0 (367009) Starting google shared locations adapter
2022-05-11 16:59:44.387 - warn: google-sharedlocations.0 (367009) Invalid character in cookie header: … at undefined. Did you copy the full cookie correctly?
2022-05-11 16:59:44.389 - debug: google-sharedlocations.0 (367009) Polling location every 60s.
2022-05-11 16:59:44.391 - debug: google-sharedlocations.0 (367009) Need to augment cookie.
2022-05-11 16:59:44.437 - debug: google-sharedlocations.0 (367009) Polling locations.
2022-05-11 16:59:44.846 - debug: google-sharedlocations.0 (367009) Response: 200
2022-05-11 16:59:44.848 - debug: google-sharedlocations.0 (367009) New header received.
2022-05-11 16:59:44.851 - info: google-sharedlocations.0 (367009) Error in location data parsing: Error: No location data in response. Cookie expired or no users share their location with you.
2022-05-11 16:59:44.852 - error: google-sharedlocations.0 (367009) Could not parse location data. Probably authentication error. Please check cookie.
2022-05-11 16:59:45.238 - debug: google-sharedlocations.0 (367009) New header received.
2022-05-11 16:59:45.893 - debug: google-sharedlocations.0 (367009) New header received.