Test Adapter googlefindmydevice V0.1.7
-
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
553
Online33.1k
Benutzer84.2k
Themen1.4m
Beiträge