Test Adapter googlefindmydevice V0.1.7
-
Aktuelle Test Version 0.1.7 Veröffentlichungsdatum 05.11.2026 GitHub Link https://github.com/beabel/ioBroker.googlefindmydevice npm https://www.npmjs.com/package/iobroker.googlefindmydevice ioBroker.googlefindmydevice
Liest Standorte von Bluetooth-Trackern (z.B. Chipolo, Pebblebee, alles was im Google "Find My Device"-Netzwerk registriert ist) aus Googles Find Hub / Find My Device aus und stellt sie als ioBroker-Objekte bereit. Telefone und Tablets werden bewusst nicht unterstützt (Details im README).
Voraussetzungen: Node.js >= 22, js-controller >= 6.0.11, Admin >= 7.8.23
Installation: Der Adapter ist seit kurzem im Latest-Repository. In Admin unter "Adapter" dafür oben als Repository Latest auswählen (Standard ist Stable, dort ist er noch nicht enthalten), dann "Google Find My Device" suchen und installieren. Danach Instanz anlegen und starten, dann die geführte Einrichtung in zwei Teilen auf der Konfigurationsseite durchlaufen. Es wird kein Passwort im Adapter eingegeben, nur Werte aus dem eigenen Browser kopiert. Details im README.
Ältere Testversion 0.0.x: Die Objekt-IDs haben sich geändert (Tracker liegen jetzt direkt unter der Instanz, nicht mehr unter
devices).Der bisherige Test-Thread zu den 0.0.x-Versionen (Installation über GitHub): https://forum.iobroker.net/topic/85388/test-adapter-googlefindmydevice-v0.0.x-github . Rückmeldungen bitte ab jetzt hier.
Ich freue mich über Feedback, besonders von Nutzern mit anderen Trackern als Chipolo/Pebblebee, und dazu, ob die Einrichtung verständlich ist.
-
Aktuelle Test Version 0.1.7 Veröffentlichungsdatum 05.11.2026 GitHub Link https://github.com/beabel/ioBroker.googlefindmydevice npm https://www.npmjs.com/package/iobroker.googlefindmydevice ioBroker.googlefindmydevice
Liest Standorte von Bluetooth-Trackern (z.B. Chipolo, Pebblebee, alles was im Google "Find My Device"-Netzwerk registriert ist) aus Googles Find Hub / Find My Device aus und stellt sie als ioBroker-Objekte bereit. Telefone und Tablets werden bewusst nicht unterstützt (Details im README).
Voraussetzungen: Node.js >= 22, js-controller >= 6.0.11, Admin >= 7.8.23
Installation: Der Adapter ist seit kurzem im Latest-Repository. In Admin unter "Adapter" dafür oben als Repository Latest auswählen (Standard ist Stable, dort ist er noch nicht enthalten), dann "Google Find My Device" suchen und installieren. Danach Instanz anlegen und starten, dann die geführte Einrichtung in zwei Teilen auf der Konfigurationsseite durchlaufen. Es wird kein Passwort im Adapter eingegeben, nur Werte aus dem eigenen Browser kopiert. Details im README.
Ältere Testversion 0.0.x: Die Objekt-IDs haben sich geändert (Tracker liegen jetzt direkt unter der Instanz, nicht mehr unter
devices).Der bisherige Test-Thread zu den 0.0.x-Versionen (Installation über GitHub): https://forum.iobroker.net/topic/85388/test-adapter-googlefindmydevice-v0.0.x-github . Rückmeldungen bitte ab jetzt hier.
Ich freue mich über Feedback, besonders von Nutzern mit anderen Trackern als Chipolo/Pebblebee, und dazu, ob die Einrichtung verständlich ist.
@beabel
Installation war verständlich und hat funktioniert, ggf. noch erwähnen, dass zwischen 1 und 2 ein Adpapterneustart notwendig ist (war zumindest bei mir so).
Kopfhörer ignoriert der Adapter ;-) Ist das Absicht, oder kannst du ändern?
Der Adapter an sich läuft:0 tracker(s) found (out of 4 devices in the account).Drei Handys werden beabsichtigt ignoriert, das 4. Device sind die Kopfhöhrer.
-
Hallo @bommel_030,
danke fürs Testen und die Rückmeldung!
Neustart zwischen Teil 1 und 2: Das ist so gewollt, ist aber offenbar nicht deutlich genug beschrieben. Nach "Verbinden" und später nach "Prüfen und freischalten" fragt die Seite, ob du speichern möchtest. Beim Speichern startet die Instanz neu, erst danach ist der nächste Teil aktiv. Ich ergänze das in der Anleitung (README und Konfigurationsseite) mit einem der nächsten Updates.
Kopfhörer: Das ist keine gezielte Sperre für Kopfhörer. Der Adapter übernimmt alle Geräte, die Google mit einer Tracker-Kennung aus dem Find-Hub-Netzwerk liefert. Handys und Tablets haben diese Kennung nicht und werden bewusst ausgelassen. Bei deinen Kopfhörern liefert Google in der Geräteliste offenbar ebenfalls keine solche Kennung, deshalb taucht das Gerät nicht auf. Das ist typisch für Kopfhörer, die nur per Fast Pair verbunden sind und ihren letzten Standort über das Handy melden, statt selbst im Find-Hub-Netzwerk zu sein. Ob das bei deinen so ist, kann ich von hier aus nicht sicher sagen.
Magst du mir Hersteller und Modell der Kopfhörer nennen und ob sie in Googles Find-Hub-App einen Standort anzeigen? Dann sehe ich nach, ob sich da etwas machen lässt.
-
Hi, danke für die Rückmeldung. Sind Anker Soundcore P40i und tauchen in der Find-Hub-App mit Standort auf.
Bin gerade unterwegs, wenn du nen debug-Log o.ä. brauchst wäre das später kein Problem. -
Hi @bommel_030,
danke, das hilft schon. Wenn die P40i in der Find-Hub-App mit Standort erscheinen, kann es sein, dass Google sie in der Geräteliste mit einer anderen Kennung liefert, als der Adapter bisher erwartet.
Dafür gibt es jetzt Version 0.1.3: Sie schreibt im Debug-Log für jedes Gerät, das ausgelassen wird, eine Zeile mit Hersteller, Modell, Gerätetyp und der Art der Kennung. Der Gerätename steht bewusst nicht drin, nur diese technischen Angaben.
So kommst du an die Zeilen:
- Adapter auf 0.1.3 aktualisieren (in Admin unter "Adapter", Repository Latest). Es kann ein paar Stunden dauern, bis die neue Version dort angezeigt wird.
- Bei der Instanz die Protokollstufe (Log-Level) auf debug stellen und die Instanz neu starten.
- Direkt nach dem Start im Log nach "Skipped a device without tracker identifier" suchen. Dort stehen die Zeilen für deine drei Handys und die Kopfhörer.
Poste mir bitte diese Zeilen (die für die Kopfhörer sind die interessanten). Danach kann ich sagen, ob und wie sich die P40i einbinden lassen. Danach kannst du die Protokollstufe wieder auf info zurückstellen.
-
Also, wie es der Zufall so will gab es heute bei den Gebrüdern Albrecht wieder Tracker...
Mitgenommen, eingerichtet und im Adapter hinzugefügt... Der Tracker wird vom Adapter als solcher erkannt, auch mit Modelnamen etc., aber die Standortdaten kann er nicht auslesen...googlefindmydevice.0 2026-10-31 21:14:54.748 warn Location request for "Sharon" failed: Timed out waiting for the location push message. googlefindmydevice.0 2026-10-31 21:14:10.128 debug MCS: could not process push message: Public key is not valid for specified curve googlefindmydevice.0 2026-10-31 21:14:09.818 debug MCS: logged in successfully. googlefindmydevice.0 2026-10-31 21:14:09.747 debug Requesting current location for "Sharon"... googlefindmydevice.0 2026-10-31 21:14:09.743 debug MCS: TLS connection established, sending login... googlefindmydevice.0 2026-10-31 21:14:07.207 debug Registering with Firebase Cloud Messaging for location push notifications... googlefindmydevice.0 2026-10-31 21:13:48.211 debug No location report for "Sharon" yet (none fetched so far, or cache empty). googlefindmydevice.0 2026-10-31 21:13:47.825 debug Skipped a device without tracker identifier: manufacturer=unknown, model=unknown, deviceType=unknown, identifier=5 googlefindmydevice.0 2026-10-31 21:13:47.825 debug Skipped a device without tracker identifier: manufacturer=unknown, model=unknown, deviceType=unknown, identifier=6, phone information present googlefindmydevice.0 2026-10-31 21:13:47.825 debug Skipped a device without tracker identifier: manufacturer=unknown, model=unknown, deviceType=unknown, identifier=IDENTIFIER_ANDROID, phone information present googlefindmydevice.0 2026-10-31 21:13:47.825 debug Skipped a device without tracker identifier: manufacturer=unknown, model=unknown, deviceType=unknown, identifier=IDENTIFIER_ANDROID, phone information present googlefindmydevice.0 2026-10-31 21:13:47.824 debug 1 tracker(s) found (out of 5 devices in the account). googlefindmydevice.0 2026-10-31 21:13:47.190 info starting. Version 0.1.3 in /opt/iobroker/node_modules/iobroker.googlefindmydevice, node: v24.22.1, js-controller: 7.2.5Skipped a device without tracker identifier: manufacturer=unknown, model=unknown, deviceType=unknown, identifier=5Das müssten die Kopfhörer sein. Die beiden Identifier Android meine Telefone, und Identifier 5 das überwachte Telefon vom Kind.
Hilft dir das weiter? -
Hallo @bommel_030,
danke, die Zeilen helfen! Ich habe sie so zugeordnet: Die beiden IDENTIFIER_ANDROID und identifier=6 haben den Zusatz „phone information present“, das sind Handys. Die Kopfhörer sind identifier=5, das ist die einzige Zeile ohne diesen Zusatz. Der Adapter kennt bisher nur die Kennungen 0 bis 2, Google liefert aber inzwischen auch 5 und 6. Die Tracker-ID der Kopfhörer steckt vermutlich in einem Feld, das ich bisher nicht auslese.
Zum neuen Tracker „Sharon“ : Da sehe ich zwei mögliche Ursachen. Entweder liefert der Tracker noch keinen Standort (frisch eingerichtet, noch kein Handy in der Nähe, das ihn gemeldet hat), oder die Push-Antwort wird nicht entschlüsselt. Der Hinweis „Public key is not valid for specified curve“ im Debug-Log spricht eher für Letzteres.
Dafür bereite ich Version 0.1.4 vor, die im Debug-Log zusätzlich die Struktur der Kennungen und die Größen der Push-Nachricht schreibt, ohne Namen oder IDs. Ich sage Bescheid, sobald sie im Latest-Repository verfügbar ist.
Zwei Fragen vorab:
Welcher Tracker ist „Sharon“ genau (Hersteller und Modell wie in der Find-Hub-App)? Zeigt er dort einen Standort an?
Hat sich beim Tracker nach ein paar Minuten und mehreren Versuchen etwas geändert, oder kommt immer derselbe Timeout?Viele Grüße
-
Hallo @bommel_030,
danke, die Zeilen helfen! Ich habe sie so zugeordnet: Die beiden IDENTIFIER_ANDROID und identifier=6 haben den Zusatz „phone information present“, das sind Handys. Die Kopfhörer sind identifier=5, das ist die einzige Zeile ohne diesen Zusatz. Der Adapter kennt bisher nur die Kennungen 0 bis 2, Google liefert aber inzwischen auch 5 und 6. Die Tracker-ID der Kopfhörer steckt vermutlich in einem Feld, das ich bisher nicht auslese.
Zum neuen Tracker „Sharon“ : Da sehe ich zwei mögliche Ursachen. Entweder liefert der Tracker noch keinen Standort (frisch eingerichtet, noch kein Handy in der Nähe, das ihn gemeldet hat), oder die Push-Antwort wird nicht entschlüsselt. Der Hinweis „Public key is not valid for specified curve“ im Debug-Log spricht eher für Letzteres.
Dafür bereite ich Version 0.1.4 vor, die im Debug-Log zusätzlich die Struktur der Kennungen und die Größen der Push-Nachricht schreibt, ohne Namen oder IDs. Ich sage Bescheid, sobald sie im Latest-Repository verfügbar ist.
Zwei Fragen vorab:
Welcher Tracker ist „Sharon“ genau (Hersteller und Modell wie in der Find-Hub-App)? Zeigt er dort einen Standort an?
Hat sich beim Tracker nach ein paar Minuten und mehreren Versuchen etwas geändert, oder kommt immer derselbe Timeout?Viele Grüße
@beabel
Moin,
mit Version 0.1.4 kommen zumindest die Standortdaten für den Tracker an. Typ etc. steht auch richtig im Log.
Werd ihn nachher mal ne Runde ausführen, ob sich der Standort auch ändert...Die Kopfhörer tauchen noch nicht auf, im Identifier steht jetzt aber mehr, siehe Log:
-
-
@mcm1957
Erledigt, danke für den Hinweis.Hallo @bommel_030,
super, dass der Tracker mit 0.1.4 jetzt Standorte liefert, danke fürs Testen! Die einzelne nicht entschlüsselbare Nachricht kurz vor der Antwort in deinem Log ist eine alte Nachricht, die Google bei jedem Start erneut zustellt. Das behebt Version 0.1.5, der Adapter merkt sich jetzt, was er schon bekommen hat.
Zu den Kopfhörern: Die Kennung konnte ich einordnen. Ob Google für sie einen Schlüssel und einen Standort mitliefert, sehe ich noch nicht. 0.1.5 schreibt dazu im Debug-Log zusätzliche Angaben über den Aufbau des Geräteeintrags, nur Feldnummern und Größen, keine Namen oder IDs. Wenn du magst:
Auf 0.1.5 aktualisieren (Repository Latest, es kann ein paar Stunden dauern, bis sie dort erscheint).
oder direkt per npm.
Protokollstufe der Instanz auf debug stellen, Instanz neu starten.
Nach Skipped a device without tracker identifier suchen und die Zeile mit identifier=5 posten. Sie enthält jetzt zusätzlich entry fields: und evtl. id outside the known fields.Danach Log-Level wieder auf info. Danke auch für den Hinweis mit dem Neustart zwischen Teil 1 und 2, der kommt in die Anleitung.
-
@mcm1957
Erledigt, danke für den Hinweis.Hallo @bommel_030,
super, dass der Tracker mit 0.1.4 jetzt Standorte liefert, danke fürs Testen! Die einzelne nicht entschlüsselbare Nachricht kurz vor der Antwort in deinem Log ist eine alte Nachricht, die Google bei jedem Start erneut zustellt. Das behebt Version 0.1.5, der Adapter merkt sich jetzt, was er schon bekommen hat.
Zu den Kopfhörern: Die Kennung konnte ich einordnen. Ob Google für sie einen Schlüssel und einen Standort mitliefert, sehe ich noch nicht. 0.1.5 schreibt dazu im Debug-Log zusätzliche Angaben über den Aufbau des Geräteeintrags, nur Feldnummern und Größen, keine Namen oder IDs. Wenn du magst:
Auf 0.1.5 aktualisieren (Repository Latest, es kann ein paar Stunden dauern, bis sie dort erscheint).
oder direkt per npm.
Protokollstufe der Instanz auf debug stellen, Instanz neu starten.
Nach Skipped a device without tracker identifier suchen und die Zeile mit identifier=5 posten. Sie enthält jetzt zusätzlich entry fields: und evtl. id outside the known fields.Danach Log-Level wieder auf info. Danke auch für den Hinweis mit dem Neustart zwischen Teil 1 und 2, der kommt in die Anleitung.
@beabel
hier ist die Zeile:Skipped a device without tracker identifier: manufacturer=unknown, model=unknown, deviceType=unknown, identifier=5, identifier fields: 2=5,5{2{1:len38}}, id outside the known fields: 36 chars, entry fields: 1{2=5,5{2{1{1:len36}}}},2{1{30:len0},2=1},5:len25,6{1:len118,2=1,3{3:len118}},8=11,10{11{1{1{1:len36},2{1:len25,2=26,9{1:len118,2=1},11=4,15{1=3,2:len122},15{1=1,2:len125},15{1=2,2:len122}},11{6=1},19{1:len60,3=1,4{14:len42},8{1=big}},20:len25,21:len6,33{1=big,2=big},34:len14,40{1=big,2=big}},3{1:len23,2=1,3=1,4=1}}},11:len44,12{1=big,2=big},13:len32 -
Hallo @bommel_030,
danke für die Zeile, damit konnte ich die Kopfhörer einordnen. Ihre Gerätedaten und der Schlüssel liegen in einem anderen Feld als bei den Trackern, deshalb hat der Adapter sie bisher übersehen.
Version 0.1.6 nimmt solche Geräte (Kopfhörer, Lautsprecher und andere Fast-Pair-Geräte mit Find-Hub-Schlüssel) wie Tracker auf:
Auf 0.1.6 aktualisieren (Admin → Adapter, Repository Latest). Die Version kann ein paar Stunden brauchen, bis sie dort erscheint. Oder wie immer wenn es zu lange dauert direkt per npm.
Instanz neu starten. Die Kopfhörer sollten dann in der Gerätetabelle der Konfiguration auftauchen, im Log steht 1 new tracker(s) found, added to the device table. Dabei kann sich die Instanz einmal von selbst neu starten.
In der Tabelle bei den Kopfhörern “Abrufen” einschalten und ein Intervall wählen (zum Beispiel 60 Minuten), speichern.Google liefert nur dann einen Standort, wenn die Kopfhörer kürzlich von einem Gerät gesehen wurden, so wie in der Find-Hub-App. Kommt anfangs nichts, ist das also nicht automatisch ein Fehler.
Sollten die Kopfhörer nicht auftauchen oder kein Standort ankommen, stell bitte das Log-Level auf debug und poste die Zeile mit Tracker: bzw. Skipped a device without tracker identifier: für die Kopfhörer, dazu eventuelle Zeilen mit location answer fields: (nur Feldnummern, keine Inhalte).
Der Hinweis auf den Neustart zwischen Teil 1 und 2 der Einrichtung kommt mit dem nächsten Update in die Anleitung.
Viele Grüße
-
Hallo @bommel_030,
danke für die Zeile, damit konnte ich die Kopfhörer einordnen. Ihre Gerätedaten und der Schlüssel liegen in einem anderen Feld als bei den Trackern, deshalb hat der Adapter sie bisher übersehen.
Version 0.1.6 nimmt solche Geräte (Kopfhörer, Lautsprecher und andere Fast-Pair-Geräte mit Find-Hub-Schlüssel) wie Tracker auf:
Auf 0.1.6 aktualisieren (Admin → Adapter, Repository Latest). Die Version kann ein paar Stunden brauchen, bis sie dort erscheint. Oder wie immer wenn es zu lange dauert direkt per npm.
Instanz neu starten. Die Kopfhörer sollten dann in der Gerätetabelle der Konfiguration auftauchen, im Log steht 1 new tracker(s) found, added to the device table. Dabei kann sich die Instanz einmal von selbst neu starten.
In der Tabelle bei den Kopfhörern “Abrufen” einschalten und ein Intervall wählen (zum Beispiel 60 Minuten), speichern.Google liefert nur dann einen Standort, wenn die Kopfhörer kürzlich von einem Gerät gesehen wurden, so wie in der Find-Hub-App. Kommt anfangs nichts, ist das also nicht automatisch ein Fehler.
Sollten die Kopfhörer nicht auftauchen oder kein Standort ankommen, stell bitte das Log-Level auf debug und poste die Zeile mit Tracker: bzw. Skipped a device without tracker identifier: für die Kopfhörer, dazu eventuelle Zeilen mit location answer fields: (nur Feldnummern, keine Inhalte).
Der Hinweis auf den Neustart zwischen Teil 1 und 2 der Einrichtung kommt mit dem nächsten Update in die Anleitung.
Viele Grüße
@beabel
Kopfhörer werden gefunden, inklusive Standort. Top, danke!
Wenn ich morgen am PC sitze schau ich mir Mal die Datenpunkte genauer an, vielleicht fällt mir dann noch das ein oder andere zum Finetuning ein ;-)
Dann hier oder lieber GitHub? -
Hallo @bommel_030,
super, das freut mich! Danke fürs Testen.
Für Vorschläge zum Feinschliff nimm bitte gern GitHub (https://github.com/beabel/ioBroker.googlefindmydevice/issues), dann geht nichts verloren und ich kann es sauber abarbeiten. Kurze Rückmeldungen wie “geht / geht nicht” gern weiterhin hier.
-
So, erstmal generelles Feedback:
Ich habe 1x Kopfhöhrer und 1x Tracker.
Der Kopfhörer meldet den Standort nur wenn er mit dem Handy verbunden wird und wenn er getrennt wird. Macht technisch soweit Sinn und in der Regel ist ja der Standort interessant an dem er zuletzt verbunden war.
Wenn er längere Zeit verbunden ist, meldet er zusätzlich auch zwischendurch seinen Standort. Nach welchem Intervall ist mir schleierhaft, steht auf jeden Fall in keinem Zusammenhang mit dem Abrufintervall des Adapters. Alles in allem für mich so verwendbar.Beim Tracker sieht es anders aus. Dieser sendet den Standort nur unter zwei Bedingungen:
- wenn mein Handy ist in Bluetooth Reichweite. Dabei ist es egal ob ich die Find My Device App offen habe oder nicht. Im Adapter eingestellten Intervall kommt ein neuer Standort.
- mein Handy ist nicht in Bluetooth Reichweite und ich rufe den Standort aktiv über die Find My Device App ab. Dann kommt beim nächsten Adapterintervall einmalig ein neuer Standort.
Es sieht also so aus, alsob der Adapter beim Tracker nicht aktiv bzw. nicht erfolgreich den aktuellen / zuletzt bekannten Standort abruft. Ich habe heute gegen 12:20 das Auto verlassen, 12:27 hat der Adapter das letzte Mal den Standort aktualisiert. Ich habe dann um 14:20 die Find My Device App geöffnet und nach dem Standort geschaut. Die App meldet letzter Kontakt 14:10. Beim nächsten Adapterdurchlauf (Intervall 15min) um 14:27 kommt wieder der aktuelle Stand.
=> Log-In etc. funktionieren einwandfrei, es wird nur nicht der aktuell / zuletzt bekannte Standort abgerufen. Ob das nun an den Maginon Trackern oder generell am Abruf liegt kann ich noch nicht sagen. Der Spieltrieb hat mich gepackt, UGREEN Tracker sind bestellt, aber noch unterwegs.
Edit:
2 Abrufintervalle später, also 14:57 meldet der Adapter wieder den Standort von 12:27, springt also in der Zeit zurück.... -
Hallo @bommel_030,
danke für die ausführliche Beobachtung, das hilft sehr. Das Verhalten der Kopfhörer ist so von Google gewollt, dazu muss am Adapter nichts geändert werden.
Beim Tracker sehe ich zwei Punkte, die ich mir ansehe: Der Adapter übernimmt bisher jeden Bericht, den Google schickt, auch wenn er älter ist als der zuletzt gespeicherte. Das erklärt den Sprung zurück auf 12:27. Das behebe ich, ältere Berichte überschreiben dann keinen neueren Stand mehr. Außerdem werte ich bisher nur die erste Antwort auf eine Standortanfrage aus. Ich prüfe, ob Google bei Trackern außerhalb der Reichweite weitere Antworten nachschickt. Dann würde der Adapter dieselben Standorte finden wie die App.
Gib bitte Bescheid, wie es mit den UGREEN-Trackern aussieht. Ein Vergleich der beiden Hersteller hilft, die Ursache einzugrenzen.
-
Hallo @bommel_030,
vielen Dank für deine ausführliche und detaillierte Rückmeldung, so genau beschriebene Beobachtungen (mit Uhrzeiten und Vergleich App gegen Adapter) sind für mich Gold wert. Ich bin dir wirklich dankbar dafür.
Dein Fund mit dem Zeitsprung auf 12:27 war aufschlussreich: Der Adapter hat bisher jeden Bericht übernommen, den Google geschickt hat, auch wenn er älter war als der gespeicherte. Das ist in 0.1.7 behoben, ein älterer Bericht überschreibt keinen neueren mehr.
Zusätzlich wartet der Adapter jetzt nach einer Standortanfrage noch bis zu 25 Sekunden auf weitere Antworten von Google und nimmt den neuesten Bericht aus allen. Ob Google bei deinem Tracker außerhalb der Bluetooth-Reichweite wirklich mehr nachschickt, kann ich nicht sicher sagen. Das würde aber erklären, warum die App mehr findet als der Adapter.
Wenn du magst, teste bitte 0.1.7 (Admin → Adapter, Repository Latest, oder direkt per npm). Zum Eingrenzen hilft mir: Log-Level auf debug, dann die Zeilen mit Answer 1 for ..., Answer 2 for ... und Ignoring a report ... posten, am besten wenn du gerade nicht in Reichweite des Trackers bist. Daran sehe ich, ob Google mehrere Antworten schickt und ob der Schutz gegen ältere Berichte greift. Danach Log-Level wieder auf info.
Der Hinweis zum Neustart zwischen Teil 1 und 2 steht jetzt auch in der Anleitung und auf der Konfigurationsseite.
Auf die Ergebnisse mit den UGREEN-Trackern bin ich gespannt. Ein Vergleich der beiden Hersteller hilft sehr bei der Ursachensuche.
Viele Grüße
-
Hallo @bommel_030,
vielen Dank für deine ausführliche und detaillierte Rückmeldung, so genau beschriebene Beobachtungen (mit Uhrzeiten und Vergleich App gegen Adapter) sind für mich Gold wert. Ich bin dir wirklich dankbar dafür.
Dein Fund mit dem Zeitsprung auf 12:27 war aufschlussreich: Der Adapter hat bisher jeden Bericht übernommen, den Google geschickt hat, auch wenn er älter war als der gespeicherte. Das ist in 0.1.7 behoben, ein älterer Bericht überschreibt keinen neueren mehr.
Zusätzlich wartet der Adapter jetzt nach einer Standortanfrage noch bis zu 25 Sekunden auf weitere Antworten von Google und nimmt den neuesten Bericht aus allen. Ob Google bei deinem Tracker außerhalb der Bluetooth-Reichweite wirklich mehr nachschickt, kann ich nicht sicher sagen. Das würde aber erklären, warum die App mehr findet als der Adapter.
Wenn du magst, teste bitte 0.1.7 (Admin → Adapter, Repository Latest, oder direkt per npm). Zum Eingrenzen hilft mir: Log-Level auf debug, dann die Zeilen mit Answer 1 for ..., Answer 2 for ... und Ignoring a report ... posten, am besten wenn du gerade nicht in Reichweite des Trackers bist. Daran sehe ich, ob Google mehrere Antworten schickt und ob der Schutz gegen ältere Berichte greift. Danach Log-Level wieder auf info.
Der Hinweis zum Neustart zwischen Teil 1 und 2 steht jetzt auch in der Anleitung und auf der Konfigurationsseite.
Auf die Ergebnisse mit den UGREEN-Trackern bin ich gespannt. Ein Vergleich der beiden Hersteller hilft sehr bei der Ursachensuche.
Viele Grüße
Test mit der 0.1.7:
Letzte "Sichtung" laut Find my Device 12:59, 13:01 meldet der Adapter neuen Standort (laut Log von 12:58), 13:31 meldet der Adapter neuen Standort (laut Log von 12:59). Erschließt sich mir nicht ganz, weil wenn er um 13:01 den Standort von 12:58 noch nicht ausliest, sollte das nächste Intervall 13:16 ihn schon finden und nicht erst der nächste Durchlauf um 13:30. Evtl. gibt Google da ne Grenze vor wer/was/wann/wie oft...
Log siehe unten. Eine "Answer 2" ist mir bis jetzt aber nicht untergekommen. Er hat seit 0.1.7 aber keine Standort aus der Vergangenheit geholt.
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
515
Online33.1k
Benutzer84.2k
Themen1.4m
Beiträge