Test Adapter google-sharedlocations2
-
@bommel_030
Hm.. also die Probleme beim Einloggen bzw. dass der Cookie dann nicht geht, kann ich nicht nachvollziehen... :-/
Irgendwie kann ich auch gerade nicht nachvollziehen, warum der Adapter ständig versuchen sollte einen neuen Cookie zu holen. Das darf er eigentlich nur, wenn er es seit dem letzten Versuch einmal geschafft hat, die Positionen abzurufen. Hm... Ich hab mal eine neue Version gemacht, die das explizit loggt. Bitte mal mit Debug-Logging da rein gucken.Die "Länge" ist aktuell, wie viele Cookies der Adapter gelesen hat. Früher war das mal die Länge des Strings, wo alle hintereinander ausgeschrieben waren. Es reichen zum Einloggen aber die drei "richtigen" Cookies (vermutlich reicht sogar "der" richtige eine Cookie). Ich filter das aber aktuell nicht und behalte einfach alle, die Google schickt, damit man da nicht in Probleme mit Anpassung läuft.
Ansonsten löscht die 0.3.3 jetzt auch die Cookies vom Browser, wenn man den Cookie-String löscht um sich gezwungen mit Username + Passwort einzuloggen. (hab ich hier zum testen genutzt ;-) - keine Ahnung, ob das bleibt. ).
-
@bommel_030
Hm.. also die Probleme beim Einloggen bzw. dass der Cookie dann nicht geht, kann ich nicht nachvollziehen... :-/
Irgendwie kann ich auch gerade nicht nachvollziehen, warum der Adapter ständig versuchen sollte einen neuen Cookie zu holen. Das darf er eigentlich nur, wenn er es seit dem letzten Versuch einmal geschafft hat, die Positionen abzurufen. Hm... Ich hab mal eine neue Version gemacht, die das explizit loggt. Bitte mal mit Debug-Logging da rein gucken.Die "Länge" ist aktuell, wie viele Cookies der Adapter gelesen hat. Früher war das mal die Länge des Strings, wo alle hintereinander ausgeschrieben waren. Es reichen zum Einloggen aber die drei "richtigen" Cookies (vermutlich reicht sogar "der" richtige eine Cookie). Ich filter das aber aktuell nicht und behalte einfach alle, die Google schickt, damit man da nicht in Probleme mit Anpassung läuft.
Ansonsten löscht die 0.3.3 jetzt auch die Cookies vom Browser, wenn man den Cookie-String löscht um sich gezwungen mit Username + Passwort einzuloggen. (hab ich hier zum testen genutzt ;-) - keine Ahnung, ob das bleibt. ).
@Garfonso
Ich kann mir auf die Cookies auch keinen Reim machen...
v0.3.3 konnte mit Benutzername/Passwort keinen (für Google akzeptablen Cookie) holen. Manuell Cookie geholt, Adapter läuft.
Nach 2h Cookie abgelaufen, er kann keinen neuen holen, versucht es weiter bis Google wegen Sicherheitsbedenken sperrt.
Hab es leider erst zu spät mitbekommen. Google entsperrt, wieder mit manuellem Cookie gefüttert, seitdem läuft er jetzt gut 1 Woche.In der Zeit hat er einige 500er Fehler überlebt, mehrfach den abgelaufenen Cookie erneuert, Chromium Update über die Konsole überlebt und sich nach sogar nach einem ioBroker-Absturz eigenständig mit frischen Keksen versorgt...
-
Aktuelle Test Version 0.3.2 Veröffentlichungsdatum 9.02.2026 Github Link https://github.com/Garfonso/ioBroker.google-sharedlocations2 google-sharedlocations gibt es ja schon länger und hat das große Problem, dass der alte Login nicht mehr ging und jetzt mit Cookie herumkopiert werden muss, aber der läuft immer ab und mäh … :-/
@david-g. kam auf die grandiose Idee, ein Skript zu erstellen, das mit puppeteer (einem "ferngesteuerten" Browser) einen neuen Cookie holt und für den Adapter nutzbar macht. Das brachte mich auf die Idee, das einfach in den Adapter zu gießen. Damit der auch mal die Chance auf das Repository hat und um Altlasten loszuwerden, habe ich heute einfach von 0 angefangen. Vielen Dank für die Idee. :-)
Wie nutze ich den Adapter?
Ähnlich, wie der alte Adapter auch. Alte Nutzer also gerne überspringen. Man sollte für den Adapter einen neuen Google-Account anlegen. Also einen extra für ioBroker. Mit diesem Account teilt man dann den Standort von allen anderen Accounts, deren Position man gerne überwachen möchte.
Die Nutzerdaten vom ioBroker-Google-Account trägt man im Adapter ein und fertig.
2FA & Cookie
Wichtig: Aktuell wird kein 2FA unterstützt. Da der Account aber nur für ioBroker genutzt werden soll, ist das zu verkraften. So geht es sehr bequem. Wer das aber unbedingt 2FA möchte oder aus anderen Gründen keinen Benutzernamen / Passwort in der Config eintragen möchte, kann einfach Benutzername und Passwort leer lassen. Dann muss man weiterhin den Cookie von google.com/maps manuell kopieren und im Datenpunkt
info.currentCookieseintragen.
Der Adapter ist nun auch so gebaut, dass er einen Cookie, der dort eingetragen wird, automatisch übernimmt. (Wenn man den state leer macht, versucht er sich auch erneut mit Benutzer und Passwort einzuloggen, wenn vorhanden).Puppeteer & Ressourcen
Puppeteer ist ein kompletter Browser. Insofern muss man auf einem Raspberry Pi oder so beim ersten Start schon was länger rechnen, bis was passiert. Ich hoffe, es klappt überhaupt. Der Browser wird auch wieder beendet, wenn das Einloggen geklappt hat. Wenn der Cookie abgelaufen ist, wird wieder versucht, den Browser zu starten.
Status
Es funktioniert. :-) Mal sehen, wo überall noch kaputtgeht … Es ist das Werk von einem Tag. Viel Spaß beim Testen.
0.1.0
Fences und places habe ich auch wieder implementiert. Sollte ähnlich sein, wie vorher. Sonst habe ich einiges umgebaut und auch etwas Cookie-Behandlung optimiert. Mal sehen, ob er sich jetzt nicht so oft neu einloggen muss. Oder ob überhaupt noch alles funktioniert. Hust ;-)
0.2.0
Chrome speichert jetzt Daten. Mal sehen, ob ihm das hilft. Außerdem schaut der Adapter erst einmal, was Chrome so aus dem Cookie macht und ob das schon reicht, um die Locationdata wieder abrufen zu können.
0.3.x
Hab intern viel am Cookie geändert. Aus Usersicht gibt es jetzt den State
info.forceRefreshWithBrowser, den man auftruesetzen kann. Dann startet der Adapter den Browser und liest den Cookie daraus aus.
Außerdem scheint der Refresh jetzt deutlich besser. Man kann den Adapter jetzt auch ohne User/Passwort in den Settings relativ gut nutzen. Vielleicht geht sogar 2FA, wenn man den Cookie in den State reinkopiert. Gerne mal jemand testen.@Garfonso
Super, dass du dich um den Adapter kümmerst.Edit: Nach dem 3. Versuch hat es jetzt einfach so funktioniert. keine Ahnung, warum es zunächst den Fehler gab. Jetzt läuft die Sache erst mal. Ich beobachte. Vielen Dank!
Ich hab jetzt mal getestet (unter Windows) und bekomme allerdings folgende Fehlermeldung:2026-03-09 15:24:40.580 - info: google-sharedlocations2.0 (6680) starting. Version 0.3.3 (non-npm: Garfonso/ioBroker.google-sharedlocations2#861d3ca3b6b823f42e232d261e612220ab634de9) in C:/ioBroker/lonwolf/node_modules/iobroker.google-sharedlocations2, node: v22.21.0, js-controller: 7.0.7 2026-03-09 15:24:40.623 - debug: google-sharedlocations2.0 (6680) Loaded 0 cookies from state. 2026-03-09 15:24:40.624 - debug: google-sharedlocations2.0 (6680) No cookie found in states, trying to log in to get new one. 2026-03-09 15:24:40.625 - debug: google-sharedlocations2.0 (6680) Trying to refresh cookie by loading Google Maps with existing cookie in Browser. 2026-03-09 15:24:40.625 - debug: google-sharedlocations2.0 (6680) Starting browser. 2026-03-09 15:24:43.037 - debug: google-sharedlocations2.0 (6680) browser started, opening new page. 2026-03-09 15:24:45.277 - debug: google-sharedlocations2.0 (6680) Loading Google login page to refresh cookie. 2026-03-09 15:24:50.482 - debug: google-sharedlocations2.0 (6680) Waiting for page to load, currently waiting fixed 5 seconds, because network never gets idle for maps 2026-03-09 15:24:56.034 - info: google-sharedlocations2.0 (6680) Trying to login to Google to get new cookies. 2026-03-09 15:24:56.034 - debug: google-sharedlocations2.0 (6680) Starting browser. 2026-03-09 15:25:00.589 - debug: google-sharedlocations2.0 (6680) browser started, opening new page. 2026-03-09 15:25:01.197 - debug: google-sharedlocations2.0 (6680) going to google login page. 2026-03-09 15:25:05.681 - debug: google-sharedlocations2.0 (6680) waiting for login / maps page to load (fixed 3 seconds timeout) 2026-03-09 15:25:08.689 - debug: google-sharedlocations2.0 (6680) filling in username. 2026-03-09 15:25:09.774 - debug: google-sharedlocations2.0 (6680) clicking user next button. 2026-03-09 15:25:10.140 - debug: google-sharedlocations2.0 (6680) waiting for network idle before filling password 2026-03-09 15:25:14.094 - debug: google-sharedlocations2.0 (6680) filling in password. 2026-03-09 15:25:44.104 - error: google-sharedlocations2.0 (6680) Error in puppeteer: Timed out after waiting 30000ms 2026-03-09 15:25:44.104 - error: google-sharedlocations2.0 (6680) The step puppeteer failed was: filling in password.Eine Idee, woran das liegen könnte? -
Ich habe den Adapter gerdae installiert, um das Cookie Problem zu beheben:
google-sharedlocations2.0 2026-03-24 04:41:50.548 error The step puppeteer failed was: undefined google-sharedlocations2.0 2026-03-24 04:41:50.548 error Error in puppeteer: Failed to launch the browser process: Code: 127 stderr: /home/iobroker/.cache/puppeteer/chrome/linux-146.0.7680.153/chrome-linux64/chrome: error while loading shared libraries: libatk-1.0.so.0: cannot open shared object file: No such file or directory TROUBLESHOOTING: https://pptr.dev/troubleshootingChatGPT konnte helfen
sudo apt update sudo apt install -y \ libatk1.0-0 \ libatk-bridge2.0-0 \ libcups2 \ libxcomposite1 \ libxdamage1 \ libxrandr2 \ libgbm1 \ libasound2 \ libpangocairo-1.0-0 \ libpango-1.0-0 \ libgtk-3-0 \ libnss3 \ libxss1 \ libxtst6 -
H Homoran verschob dieses Thema von Tester am
-
H Homoran verschob dieses Thema von ...nicht in offiziellem Repo am
-
Hi @garfonso,
mit Version 0.3.5 beobachte ich folgendes:
Manuell gesetzter Cookie funktioniert (Shared Locations werden gelesen)
Im Betrieb erscheint regelmäßig (ca. alle 10 Minuten):Failed improving cookie: 429429 entspricht ja "Too Many Requests", daher wirkt es so, als würde Google den Aufruf von https://myaccount.google.com drosseln bzw. blockieren. Das Pollen der Koordinaten funktioniert dabei weiterhin.
Wenn ich die Cookies im State lösche, startet der Login-Versuch und läuft in den oben von dir beschriebenen Timeout beim Passwort-Schritt (weil Session schon angemeldet). Danach werden jedoch keine passenden Cookie-Daten gefunden.
Sollten in diesem Fall nicht trotzdem verwertbare Cookies vorhanden sein, wenn bereits eine eingeloggte Session erkannt wird?
-
Hi @garfonso,
mit Version 0.3.5 beobachte ich folgendes:
Manuell gesetzter Cookie funktioniert (Shared Locations werden gelesen)
Im Betrieb erscheint regelmäßig (ca. alle 10 Minuten):Failed improving cookie: 429429 entspricht ja "Too Many Requests", daher wirkt es so, als würde Google den Aufruf von https://myaccount.google.com drosseln bzw. blockieren. Das Pollen der Koordinaten funktioniert dabei weiterhin.
Wenn ich die Cookies im State lösche, startet der Login-Versuch und läuft in den oben von dir beschriebenen Timeout beim Passwort-Schritt (weil Session schon angemeldet). Danach werden jedoch keine passenden Cookie-Daten gefunden.
Sollten in diesem Fall nicht trotzdem verwertbare Cookies vorhanden sein, wenn bereits eine eingeloggte Session erkannt wird?
Hm... stimmt... was ist da denn passiert? kopfkratz Es scheint auch kein wirkliches Rate-Limit zu sein. Im Browser kann ich die Seite aufrufen. Die mag irgendwas an dem Aufruf nicht... Puh. Keine Ahnung, was da jetzt groß anders sein soll, als an dem Aufruf mit axios.
Naja. Ich habe eine 0.3.6 auf den Weg gebracht, die das erstmal deaktiviert und dafür den Browser alle 24h einmal startet (ab Adapter-Start). Oder sollte man da lieber einen Zeitpunkt einstellen können oder so? Im Grunde kann man das auch extern per Skript triggern durch den State
info.forceRefreshWithBrowser.Wenn ich die Cookies im State lösche, startet der Login-Versuch und läuft in den oben von dir beschriebenen Timeout beim Passwort-Schritt (weil Session schon angemeldet). Danach werden jedoch keine passenden Cookie-Daten gefunden.
Welchen state hast du genau gelöscht? Wenn du
info.currentCookieslöschst, sollte er alles wegwerfen und auch dem Browser sagen, er soll seine Cookies löschen, und dann geht auch Login mit User & Passwort, eigentlich. kopfkratzDas Problem mit dem Login-Versuch ist sonst, dass Google sich gemerkt hat, welcher User eingeloggt war, den da als Knopf anzeigt, aber der Code das Eingabefeld sucht. Ich hab es irgendwie bisher nicht geschafft den Knopf sicher zu identifizieren und drauf zu klicken... ich dachte, ich hätte was, aber das scheint nicht stabil zu gehen.
Daher kommt halt der Timeout beim Suchen nach dem Eingabefeld. Ich hab es jetzt so umgebaut, dass er dann, wenn das passiert, die Cookies vom Browser löscht und mit Benutzername und Passwort neu einloggt. Das geht in jedem Fall (solange die konfiguriert sind).
Der Cookie im Browser ist in dem Fall jedenfalls nicht verwertbar. Den Cookie vom Browser einfach zu verwenden für einen Request versucht der Code immer zuerst.Ultimativer Lovelace Leitfaden: https://forum.iobroker.net/topic/35937/der-ultimative-iobroker-lovelace-leitfaden-dokumentation
Lovelace UI Beispiele: https://forum.iobroker.net/topic/35950/zeigt-her-eure-lovelace-visualisierung
-
Hm... stimmt... was ist da denn passiert? kopfkratz Es scheint auch kein wirkliches Rate-Limit zu sein. Im Browser kann ich die Seite aufrufen. Die mag irgendwas an dem Aufruf nicht... Puh. Keine Ahnung, was da jetzt groß anders sein soll, als an dem Aufruf mit axios.
Naja. Ich habe eine 0.3.6 auf den Weg gebracht, die das erstmal deaktiviert und dafür den Browser alle 24h einmal startet (ab Adapter-Start). Oder sollte man da lieber einen Zeitpunkt einstellen können oder so? Im Grunde kann man das auch extern per Skript triggern durch den State
info.forceRefreshWithBrowser.Wenn ich die Cookies im State lösche, startet der Login-Versuch und läuft in den oben von dir beschriebenen Timeout beim Passwort-Schritt (weil Session schon angemeldet). Danach werden jedoch keine passenden Cookie-Daten gefunden.
Welchen state hast du genau gelöscht? Wenn du
info.currentCookieslöschst, sollte er alles wegwerfen und auch dem Browser sagen, er soll seine Cookies löschen, und dann geht auch Login mit User & Passwort, eigentlich. kopfkratzDas Problem mit dem Login-Versuch ist sonst, dass Google sich gemerkt hat, welcher User eingeloggt war, den da als Knopf anzeigt, aber der Code das Eingabefeld sucht. Ich hab es irgendwie bisher nicht geschafft den Knopf sicher zu identifizieren und drauf zu klicken... ich dachte, ich hätte was, aber das scheint nicht stabil zu gehen.
Daher kommt halt der Timeout beim Suchen nach dem Eingabefeld. Ich hab es jetzt so umgebaut, dass er dann, wenn das passiert, die Cookies vom Browser löscht und mit Benutzername und Passwort neu einloggt. Das geht in jedem Fall (solange die konfiguriert sind).
Der Cookie im Browser ist in dem Fall jedenfalls nicht verwertbar. Den Cookie vom Browser einfach zu verwenden für einen Request versucht der Code immer zuerst.@garfonso
OK, ich hab jetzt mal die 0.3.6 installiert. Automatisches Einloggen klappt nach wie vor nicht (s.u.). Ich habe jetzt mal das Cookie wieder manuell gesetzt und beobachte.Welchen state hast du genau gelöscht? Wenn du info.currentCookies löschst, sollte er alles wegwerfen und auch dem Browser sagen, er soll seine Cookies löschen, und dann geht auch Login mit User & Passwort, eigentlich. kopfkratz
Ja, genau.
2026-04-27 14:12:04.511 - info: google-sharedlocations2.0 (17644) Current cookies state was cleared, trying to obtain new cookies. 2026-04-27 14:12:04.511 - debug: google-sharedlocations2.0 (17644) Converted cookie string to 0 cookies. 2026-04-27 14:12:04.512 - info: google-sharedlocations2.0 (17644) Trying to login to Google to get new cookies. 2026-04-27 14:12:04.512 - debug: google-sharedlocations2.0 (17644) Starting browser. 2026-04-27 14:12:05.894 - debug: google-sharedlocations2.0 (17644) browser started, opening new page. 2026-04-27 14:12:06.713 - debug: google-sharedlocations2.0 (17644) Force login enabled, clearing cookies and local storage. 2026-04-27 14:12:06.721 - debug: google-sharedlocations2.0 (17644) going to google login page. 2026-04-27 14:12:10.716 - debug: google-sharedlocations2.0 (17644) waiting for login / maps page to load (fixed 3 seconds timeout) 2026-04-27 14:12:13.722 - debug: google-sharedlocations2.0 (17644) Trying to click on username, if user was logged in before. 2026-04-27 14:12:13.740 - debug: google-sharedlocations2.0 (17644) No user element found, filling in username. 2026-04-27 14:12:14.524 - debug: google-sharedlocations2.0 (17644) clicking user next button. 2026-04-27 14:12:14.834 - debug: google-sharedlocations2.0 (17644) waiting for network idle before filling password 2026-04-27 14:12:16.880 - debug: google-sharedlocations2.0 (17644) filling in password. 2026-04-27 14:12:46.892 - error: google-sharedlocations2.0 (17644) Error in puppeteer: Timed out after waiting 30000ms 2026-04-27 14:12:46.893 - error: google-sharedlocations2.0 (17644) The step puppeteer failed was: filling in password. 2026-04-27 14:12:49.500 - debug: google-sharedlocations2.0 (17644) Cannot poll positions, no cookies available! -
Hoppla,
heute kam per Mail die Mitteilung, dass Google einen verdächtigen Login-Versuch blockiert hat. Anschließend musste ich mich per 2FA anmelden, obwohl ich das für den Account generell abgeschaltet habe.
Ich habe immer mehr den Eindruck, dass das mit dem automatischen Einloggen kaum zu stemmen ist. Evtl. wäre es der bessere Ansatz, wenn sich der Adapter auf das Halten/Erneuern der Cookies ohne neuen Login konzentriert. Was meinst du?
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren AnmeldenSupport us
581
Online32.8k
Benutzer82.8k
Themen1.3m
Beiträge