NEWS
Life360 NextGeneration - Latest
-
Moin, was passiert eigentlich, wenn man im Urlaub in einer anderen Zeitzone unterwegs ist?
Bei mir habe ich es aktuell so gelöst, das ich im Script die Zeitzone, sowie den Abreisezeitpunkt beim Hinflug und den vom Rückflug angebe. Entsprechend werden dann die Marker gesetzt, damit es nicht so aussieht, als würde ich mitten in der Nacht in Thailand unterwegs sein. Wenn ich mir dann später die Routen ansehe, dann zeigt der mir die Zeiten der Zeitzone an und nicht die von Berlin.
Oder hat Life360 da eine interne Anpassung, die dann im Adapter übernommen wird?
Gruß, Johannes
@JoJo58 .. das kann ich so gar nicht sagen.
Ich bin bin Heimscheisser und fahre nie in den Urlaub nach dem Motte: "Warum in die Ferne schweifen, wenn das Gute liegt so nah?"
Ich habe mir hier ein kleines Paradies geschaffen (Koi- & Schwimmteich, eigenen Sandstrand usw.)
.. zurück zum Thema. Ich frage Copilot dazu mal und melde mich.
-
Moin, was passiert eigentlich, wenn man im Urlaub in einer anderen Zeitzone unterwegs ist?
Bei mir habe ich es aktuell so gelöst, das ich im Script die Zeitzone, sowie den Abreisezeitpunkt beim Hinflug und den vom Rückflug angebe. Entsprechend werden dann die Marker gesetzt, damit es nicht so aussieht, als würde ich mitten in der Nacht in Thailand unterwegs sein. Wenn ich mir dann später die Routen ansehe, dann zeigt der mir die Zeiten der Zeitzone an und nicht die von Berlin.
Oder hat Life360 da eine interne Anpassung, die dann im Adapter übernommen wird?
Gruß, Johannes
@JoJo58 .. ich habe Copilot dazu gefragt.
Meine Idee bzw. Frage an Copilot war, wenn man eine Tour von 10 bis 18 Uhr in Thailand (Thai-Zeit) macht, was man dann in Thailand vor Ort und später zu Hause angezeigt bekommt
Die Antwort:
Zusammenfassung für Johannes' Forumsfrage:
Kurze Antwort: 10:00–18:00 Uhr in beiden Ansichten ist technisch nicht möglich mit der aktuellen Architektur — dafür bräuchte man die Ziel-Zeitzone zum Zeitpunkt der Aufzeichnung (Life360 liefert das nicht).
Was tatsächlich passiert:
Situation Popup-Zeiten Karte aufrufen während man in Thailand ist 10:00–18:00 Thai-Zeit (Browser-TZ) Gleiche Tour zu Hause ansehen 05:00–13:00 MESZ (Thai-Zeit umgerechnet) Für den Reisefall eigentlich sinnvoll: Vor Ort sieht man die lokale Zeit, zu Hause sieht man den deutschen Äquivalent.
-
@jojo58 ... Ich könnte eventuell bei den kleinen Popups zwei Zeiten anzeigen lassen.
Beispiel:
• Wenn User in unsere Zeitzone unterwegs ist, dann nur unsere Zeit im Popup;
• Wenn User NICHT in unsere Zeitzone unterwegs ist, dann beide Zeiten im Popup; -
@JoJo58 .. ich habe Copilot dazu gefragt.
Meine Idee bzw. Frage an Copilot war, wenn man eine Tour von 10 bis 18 Uhr in Thailand (Thai-Zeit) macht, was man dann in Thailand vor Ort und später zu Hause angezeigt bekommt
Die Antwort:
Zusammenfassung für Johannes' Forumsfrage:
Kurze Antwort: 10:00–18:00 Uhr in beiden Ansichten ist technisch nicht möglich mit der aktuellen Architektur — dafür bräuchte man die Ziel-Zeitzone zum Zeitpunkt der Aufzeichnung (Life360 liefert das nicht).
Was tatsächlich passiert:
Situation Popup-Zeiten Karte aufrufen während man in Thailand ist 10:00–18:00 Thai-Zeit (Browser-TZ) Gleiche Tour zu Hause ansehen 05:00–13:00 MESZ (Thai-Zeit umgerechnet) Für den Reisefall eigentlich sinnvoll: Vor Ort sieht man die lokale Zeit, zu Hause sieht man den deutschen Äquivalent.
Ich habe KI mal gebeten, mir die Logik hinter meinem Script einfach zu erklären, das kam dabei heraus.
In meinen bisherigen History-Skripten ist die Zeitzonenlogik bewusst pragmatisch gelöst, damit die Zeiten in den Routen sauber bleiben. Im Normalbetrieb zuhause läuft alles einfach mit der lokalen Serverzeit, also faktisch mit Europe/Berlin. Wenn wir verreisen, nutze ich zusätzlich ein paar Datenpunkte, über die ich Zeitzone/Aufenthaltsort sowie Datum und Uhrzeit für Hin- und Rückflug vorgebe.
Der Ablauf ist dabei so:
Beim Abflug in Deutschland trage ich Startdatum und Abflugzeit ein und aktiviere die andere Zeitzone bzw. den dazugehörigen Offset. Während des Flugs ist das Handy ohnehin im Flugmodus und sendet keine Positionsdaten. Dadurch entstehen in dieser Übergangsphase keine Überschneidungen oder vermischten Zeitstempel. Erst nach der Landung und dem Wiedereinschalten läuft die Aufzeichnung dann direkt mit der zur Zielregion passenden Zeit weiter. Für den Rückflug funktioniert es genauso: Rückflugdatum und -uhrzeit werden gesetzt, während des Flugs gibt es keine Trackpunkte, und nach der Rückkehr ist wieder alles auf Deutschland bzw. Normalbetrieb eingestellt.Technisch ist das also keine echte Timezone-Behandlung über IANA-Zeitzonen, sondern eine gesteuerte Offset-Logik. Der Offset selbst wird über einen Datenpunkt für Zeitzone/Aufenthaltsort gewählt; das Script rechnet dann die Serverzeit entsprechend um und nutzt diese verschobene Zeit für Tageszuordnung und Zeitstempel. Zusätzlich wird auch der Tageswechsel der History daran angepasst, damit neue Tagesdatenpunkte zum lokalen Tag am Aufenthaltsort passen.
Warum mir das wichtig ist: Bei der Routenaufzeichnung geht es nicht nur um Koordinaten, sondern auch darum, dass die Punkte dem richtigen lokalen Tag und der richtigen lokalen Uhrzeit zugeordnet werden. Gerade an Tagesgrenzen würde es sonst passieren, dass Fahrten im Urlaub noch dem Vortag in deutscher Zeit zugerechnet werden. Durch meine Lösung habe ich in den Routen eine saubere zeitliche Zuordnung, ohne Übergangschaos während der Flüge.
Ich habe das vorher alles über OwnTracks gemacht und da hat es mit dem Offset sauber funktioniert. Da habe ich noch die Zeit Verschiebung manuell in Stunden eingetragen, jetzt wähle ich über einen Datenpunkt die Zeitzone aus. in 2 weiteren DP dann Datum und Abflugzeit und ich habe immer saubere Routen und Zeitmarker.
Keine Ahnung ob du das überhaupt einbauen kannst oder möchtest und falls ja, wie man das am Besten umsetzen kann.
Du hast den Adapter ja schon so weit entwickelt und ich bin wirklich begeistert von deiner Arbeit, daher kommt mir meine Anfrage schon ein bisschen frech vor.
Gruß, Johannes
-
Ich habe KI mal gebeten, mir die Logik hinter meinem Script einfach zu erklären, das kam dabei heraus.
In meinen bisherigen History-Skripten ist die Zeitzonenlogik bewusst pragmatisch gelöst, damit die Zeiten in den Routen sauber bleiben. Im Normalbetrieb zuhause läuft alles einfach mit der lokalen Serverzeit, also faktisch mit Europe/Berlin. Wenn wir verreisen, nutze ich zusätzlich ein paar Datenpunkte, über die ich Zeitzone/Aufenthaltsort sowie Datum und Uhrzeit für Hin- und Rückflug vorgebe.
Der Ablauf ist dabei so:
Beim Abflug in Deutschland trage ich Startdatum und Abflugzeit ein und aktiviere die andere Zeitzone bzw. den dazugehörigen Offset. Während des Flugs ist das Handy ohnehin im Flugmodus und sendet keine Positionsdaten. Dadurch entstehen in dieser Übergangsphase keine Überschneidungen oder vermischten Zeitstempel. Erst nach der Landung und dem Wiedereinschalten läuft die Aufzeichnung dann direkt mit der zur Zielregion passenden Zeit weiter. Für den Rückflug funktioniert es genauso: Rückflugdatum und -uhrzeit werden gesetzt, während des Flugs gibt es keine Trackpunkte, und nach der Rückkehr ist wieder alles auf Deutschland bzw. Normalbetrieb eingestellt.Technisch ist das also keine echte Timezone-Behandlung über IANA-Zeitzonen, sondern eine gesteuerte Offset-Logik. Der Offset selbst wird über einen Datenpunkt für Zeitzone/Aufenthaltsort gewählt; das Script rechnet dann die Serverzeit entsprechend um und nutzt diese verschobene Zeit für Tageszuordnung und Zeitstempel. Zusätzlich wird auch der Tageswechsel der History daran angepasst, damit neue Tagesdatenpunkte zum lokalen Tag am Aufenthaltsort passen.
Warum mir das wichtig ist: Bei der Routenaufzeichnung geht es nicht nur um Koordinaten, sondern auch darum, dass die Punkte dem richtigen lokalen Tag und der richtigen lokalen Uhrzeit zugeordnet werden. Gerade an Tagesgrenzen würde es sonst passieren, dass Fahrten im Urlaub noch dem Vortag in deutscher Zeit zugerechnet werden. Durch meine Lösung habe ich in den Routen eine saubere zeitliche Zuordnung, ohne Übergangschaos während der Flüge.
Ich habe das vorher alles über OwnTracks gemacht und da hat es mit dem Offset sauber funktioniert. Da habe ich noch die Zeit Verschiebung manuell in Stunden eingetragen, jetzt wähle ich über einen Datenpunkt die Zeitzone aus. in 2 weiteren DP dann Datum und Abflugzeit und ich habe immer saubere Routen und Zeitmarker.
Keine Ahnung ob du das überhaupt einbauen kannst oder möchtest und falls ja, wie man das am Besten umsetzen kann.
Du hast den Adapter ja schon so weit entwickelt und ich bin wirklich begeistert von deiner Arbeit, daher kommt mir meine Anfrage schon ein bisschen frech vor.
Gruß, Johannes
-
@JoJo58 .. ich habe Copilot dazu gefragt.
Meine Idee bzw. Frage an Copilot war, wenn man eine Tour von 10 bis 18 Uhr in Thailand (Thai-Zeit) macht, was man dann in Thailand vor Ort und später zu Hause angezeigt bekommt
Die Antwort:
Zusammenfassung für Johannes' Forumsfrage:
Kurze Antwort: 10:00–18:00 Uhr in beiden Ansichten ist technisch nicht möglich mit der aktuellen Architektur — dafür bräuchte man die Ziel-Zeitzone zum Zeitpunkt der Aufzeichnung (Life360 liefert das nicht).
Was tatsächlich passiert:
Situation Popup-Zeiten Karte aufrufen während man in Thailand ist 10:00–18:00 Thai-Zeit (Browser-TZ) Gleiche Tour zu Hause ansehen 05:00–13:00 MESZ (Thai-Zeit umgerechnet) Für den Reisefall eigentlich sinnvoll: Vor Ort sieht man die lokale Zeit, zu Hause sieht man den deutschen Äquivalent.
Mit dieser Bibliothek kann man aus GPS Koordinaten die Zeitzone berechnen
https://www.npmjs.com/package/geo-tzWenn man so eine Bibliothek nicht will, könnte man die Zeitzone grob anhand des Längengrades ermitteln.
Passt zwar da nicht immer für jedes Land, da ja manche Länder leicht abweichende Regelungen eingeführt haben
-
Hallo,
vielen Dank für die tolle Arbeit.
Wenn ich den Adapter starte kommt folgende Warnmeldung:life360ng.0 2026-05-20 15:31:27.665 warn [circles] Life360 API blocked by Cloudflare (HTTP 403). Your server's IP may be rate-limited or flagged. Try increasing the poll interval or check your Life360 token. life360ng.0 2026-05-20 15:31:27.423 info Connected to Life360 cloud services. life360ng.0 2026-05-20 15:31:27.420 info Polling enabled every 60 seconds. life360ng.0 2026-05-20 15:31:27.279 info [Tracker] Route logger disabledInsgesamt funktioniert der Adapter nach meinen Bedürfnissen (Licht an der Aufahrt geht an, wenn ich in den im Adapter eingegeben "my places" fahre) prima.
Was aber nicht mit der App synchronisiert wird, sind "places" von der App. Bzw. stehen diese Orte nicht im Ordner "Places". Benachrichtigungen über Telegramm funktionieren aber, wenn ich die Orte der App (z.B. Arbeit) erreiche.
Ich habe die Adapterversion 1.9.0 installiert.Wie werde ich die Warnmeldung los?
-
Hallo,
vielen Dank für die tolle Arbeit.
Wenn ich den Adapter starte kommt folgende Warnmeldung:life360ng.0 2026-05-20 15:31:27.665 warn [circles] Life360 API blocked by Cloudflare (HTTP 403). Your server's IP may be rate-limited or flagged. Try increasing the poll interval or check your Life360 token. life360ng.0 2026-05-20 15:31:27.423 info Connected to Life360 cloud services. life360ng.0 2026-05-20 15:31:27.420 info Polling enabled every 60 seconds. life360ng.0 2026-05-20 15:31:27.279 info [Tracker] Route logger disabledInsgesamt funktioniert der Adapter nach meinen Bedürfnissen (Licht an der Aufahrt geht an, wenn ich in den im Adapter eingegeben "my places" fahre) prima.
Was aber nicht mit der App synchronisiert wird, sind "places" von der App. Bzw. stehen diese Orte nicht im Ordner "Places". Benachrichtigungen über Telegramm funktionieren aber, wenn ich die Orte der App (z.B. Arbeit) erreiche.
Ich habe die Adapterversion 1.9.0 installiert.Wie werde ich die Warnmeldung los?
2026-05-20 15:31:27.665 warn [circles] Life360 API blocked by Cloudflare (HTTP 403). Your server's IP may be rate-limited or flagged. Try increasing the poll interval or check your Life360 token.
Wie lange nutzt du den Adapter schon? Eventuell zu oft neu gestartet?
Die Meldung bedeutet, dass der Server von Cloudflare (dem Schutzdienst vor der Life360-API) geblockt wurde – meist wegen zu vieler Anfragen in kurzer Zeit (Rate-Limit) oder weil die IP als verdächtig eingestuft wurde.
Hier kann man eigentlich nur Abwarten, bis deine IP wieder freigegeben wird. Darauf habe ich keinen Einfluss.
Das wird auch ein Grund sein, dass du deine Places nicht in den Objekten hast.
Die Config hast du aber passend eingestellt?

EDIT:
Wenn Cloudflare den Zugriff auf die Life360-API blockiert (HTTP 403), werden nicht nur Circles, sondern auch alle anderen API-Daten wie „Places“ (Orte) nicht mehr korrekt abgerufen. Das bedeutet:
Die vom Life360-Server gelieferten Orte („Places“) können nicht synchronisiert und im Adapter aktualisiert werden.
Im ioBroker-Objektbaum erscheinen dann keine oder veraltete Places.
Eigene, lokal im Adapter definierte „Custom Places“ sind davon nicht betroffen, aber Cloud-Places fehlen.
Sobald die Sperre aufgehoben ist (z. B. durch längeres Polling-Intervall oder IP-Wechsel), funktioniert auch die Places-Synchronisation wieder. -
2026-05-20 15:31:27.665 warn [circles] Life360 API blocked by Cloudflare (HTTP 403). Your server's IP may be rate-limited or flagged. Try increasing the poll interval or check your Life360 token.
Wie lange nutzt du den Adapter schon? Eventuell zu oft neu gestartet?
Die Meldung bedeutet, dass der Server von Cloudflare (dem Schutzdienst vor der Life360-API) geblockt wurde – meist wegen zu vieler Anfragen in kurzer Zeit (Rate-Limit) oder weil die IP als verdächtig eingestuft wurde.
Hier kann man eigentlich nur Abwarten, bis deine IP wieder freigegeben wird. Darauf habe ich keinen Einfluss.
Das wird auch ein Grund sein, dass du deine Places nicht in den Objekten hast.
Die Config hast du aber passend eingestellt?

EDIT:
Wenn Cloudflare den Zugriff auf die Life360-API blockiert (HTTP 403), werden nicht nur Circles, sondern auch alle anderen API-Daten wie „Places“ (Orte) nicht mehr korrekt abgerufen. Das bedeutet:
Die vom Life360-Server gelieferten Orte („Places“) können nicht synchronisiert und im Adapter aktualisiert werden.
Im ioBroker-Objektbaum erscheinen dann keine oder veraltete Places.
Eigene, lokal im Adapter definierte „Custom Places“ sind davon nicht betroffen, aber Cloud-Places fehlen.
Sobald die Sperre aufgehoben ist (z. B. durch längeres Polling-Intervall oder IP-Wechsel), funktioniert auch die Places-Synchronisation wieder.@skvarel Danke für Deine schnelle Antwort.
Ja, die Konfiguration ist so wie in Deinem Bild eingestellt.
Dann warte ich mal geduldig, ob die Warnmeldung irgendwann verschwindet.
Wie schon geschrieben, funktioniert der Adapter für meine Anwendungsanforderungen ohne Probleme. -
2026-05-20 15:31:27.665 warn [circles] Life360 API blocked by Cloudflare (HTTP 403). Your server's IP may be rate-limited or flagged. Try increasing the poll interval or check your Life360 token.
Wie lange nutzt du den Adapter schon? Eventuell zu oft neu gestartet?
Die Meldung bedeutet, dass der Server von Cloudflare (dem Schutzdienst vor der Life360-API) geblockt wurde – meist wegen zu vieler Anfragen in kurzer Zeit (Rate-Limit) oder weil die IP als verdächtig eingestuft wurde.
Hier kann man eigentlich nur Abwarten, bis deine IP wieder freigegeben wird. Darauf habe ich keinen Einfluss.
Das wird auch ein Grund sein, dass du deine Places nicht in den Objekten hast.
Die Config hast du aber passend eingestellt?

EDIT:
Wenn Cloudflare den Zugriff auf die Life360-API blockiert (HTTP 403), werden nicht nur Circles, sondern auch alle anderen API-Daten wie „Places“ (Orte) nicht mehr korrekt abgerufen. Das bedeutet:
Die vom Life360-Server gelieferten Orte („Places“) können nicht synchronisiert und im Adapter aktualisiert werden.
Im ioBroker-Objektbaum erscheinen dann keine oder veraltete Places.
Eigene, lokal im Adapter definierte „Custom Places“ sind davon nicht betroffen, aber Cloud-Places fehlen.
Sobald die Sperre aufgehoben ist (z. B. durch längeres Polling-Intervall oder IP-Wechsel), funktioniert auch die Places-Synchronisation wieder. -
@skvarel Danke für Deine schnelle Antwort.
Ja, die Konfiguration ist so wie in Deinem Bild eingestellt.
Dann warte ich mal geduldig, ob die Warnmeldung irgendwann verschwindet.
Wie schon geschrieben, funktioniert der Adapter für meine Anwendungsanforderungen ohne Probleme.@Olivbus .. wenn du möchtest, kannst du die aktuelle Latest Version (1.9.1) installieren. Ich habe auf Grund @oliverio seinen Kommentar meinen KI-Assistenten gefragt.
Folgendes kam dabei raus:
Zwei Verbesserungen wurden umgesetzt :
-
Retry-Loops brechen bei CF-Block sofort ab
Bisher wurde bei einem 403 trotzdem bis zu Life360APIDataMaxRetries mal wiederholt – das hat die Sperre aktiv verschlimmert. Jetzt gilt: 403 erkannt → break, keine weiteren Requests. -
300 ms Pause zwischen den API-Calls im Poll-Zyklus
Circles → Members → Places wurden bisher ohne jede Pause direkt hintereinander abgefragt. Jetzt wird zwischen jedem Call kurz gewartet, damit die Requests nicht als burst pattern erkannt werden.
Punkt 1 war noch eine Leiche aus dem ursprünglichen Adapter.
-
-
Herzlichen Dank, das läuft alles wie am Schnürchen :)
Ich hätte noch ein paar Anregungen für Verbesserungen, die zumindest mir etwas helfen würden:- Bei der Kartensicht wäre es hilfreich, wenn ich auf eine Flagge klicke und sehe wann die Person an dem Ort zuletzt angekommen ist oder diesen verlassen hat.
- Neben dem von Life360 übermittelten Namen man selbst einen Alias vergeben kann. Falls gesetzt soll dann dieser z.B. bei der Karte, Benachrichtigung etc. genutzt werden.
- Für die Benachrichtigung wäre es super, wenn der zu sprechende Text zusätzlich in ein Datenpunkten gespeichert wird. Hintergrund: ich nutze keine Alexa und ich möchte auch nicht ständig am Handy Telegram Popups haben. Stattdessen soll über die Sonos bei bestimmten Orten eine Ansage kommen. Ich weiß, dass das mit Blockly lösbar ist, aber dieser Datenpunkt würde es vereinfachen.
Das sind alles nice-to-have Wünsche :) danke @skvarel für deine Einschätzung
-
Herzlichen Dank, das läuft alles wie am Schnürchen :)
Ich hätte noch ein paar Anregungen für Verbesserungen, die zumindest mir etwas helfen würden:- Bei der Kartensicht wäre es hilfreich, wenn ich auf eine Flagge klicke und sehe wann die Person an dem Ort zuletzt angekommen ist oder diesen verlassen hat.
- Neben dem von Life360 übermittelten Namen man selbst einen Alias vergeben kann. Falls gesetzt soll dann dieser z.B. bei der Karte, Benachrichtigung etc. genutzt werden.
- Für die Benachrichtigung wäre es super, wenn der zu sprechende Text zusätzlich in ein Datenpunkten gespeichert wird. Hintergrund: ich nutze keine Alexa und ich möchte auch nicht ständig am Handy Telegram Popups haben. Stattdessen soll über die Sonos bei bestimmten Orten eine Ansage kommen. Ich weiß, dass das mit Blockly lösbar ist, aber dieser Datenpunkt würde es vereinfachen.
Das sind alles nice-to-have Wünsche :) danke @skvarel für deine Einschätzung
Herzlichen Dank, das läuft alles wie am Schnürchen :)
Das freut mich
- Bei der Kartensicht wäre es hilfreich, wenn ich auf eine Flagge klicke und sehe wann die Person an dem Ort zuletzt angekommen ist oder diesen verlassen hat.
Wann die Person angekommen ist, ist bereits drin. Einfach auf den Punkt der Person anstatt auf die Flagge klicken. Ich kann bei der Flagge keine Daten hinzufügen, weil es einfach nur die App- und eigenen Orte sind und sie so keine Verbindung zu den Personen haben.

Um sich das 'Verlassen' anzugucken, müsste man dann den nächsten Punkt auf der Route nehmen und sich dort die Zeit anzeigen lassen.

Als Beispiel: Hier war ich ca. eine Stunde bei meiner Tochter zu Besuch.- Neben dem von Life360 übermittelten Namen man selbst einen Alias vergeben kann. Falls gesetzt soll dann dieser z.B. bei der Karte, Benachrichtigung etc. genutzt werden.
Das schaue ich mir an. Ist auf jeden Fall möglich
- Für die Benachrichtigung wäre es super, wenn der zu sprechende Text zusätzlich in ein Datenpunkten gespeichert wird. Hintergrund: ich nutze keine Alexa und ich möchte auch nicht ständig am Handy Telegram Popups haben. Stattdessen soll über die Sonos bei bestimmten Orten eine Ansage kommen. Ich weiß, dass das mit Blockly lösbar ist, aber dieser Datenpunkt würde es vereinfachen.
Das ist kein Problem! Werde ich umsetzen.
-
Herzlichen Dank, das läuft alles wie am Schnürchen :)
Ich hätte noch ein paar Anregungen für Verbesserungen, die zumindest mir etwas helfen würden:- Bei der Kartensicht wäre es hilfreich, wenn ich auf eine Flagge klicke und sehe wann die Person an dem Ort zuletzt angekommen ist oder diesen verlassen hat.
- Neben dem von Life360 übermittelten Namen man selbst einen Alias vergeben kann. Falls gesetzt soll dann dieser z.B. bei der Karte, Benachrichtigung etc. genutzt werden.
- Für die Benachrichtigung wäre es super, wenn der zu sprechende Text zusätzlich in ein Datenpunkten gespeichert wird. Hintergrund: ich nutze keine Alexa und ich möchte auch nicht ständig am Handy Telegram Popups haben. Stattdessen soll über die Sonos bei bestimmten Orten eine Ansage kommen. Ich weiß, dass das mit Blockly lösbar ist, aber dieser Datenpunkt würde es vereinfachen.
Das sind alles nice-to-have Wünsche :) danke @skvarel für deine Einschätzung
-
Hallo zusammen,
Ich hab für mich heute auch den Tracker mit ChatGPT etwas weiterentwickelt und ein paar Funktionen ergänzt 🙂
Unter anderem:
- Fokus auf einzelne Personen
- automatischer Zoom auf die ausgewählte Route
- Live-Follow Modus
- Auto-Refresh ein-/ausschaltbar
- ruhigere Kartenansicht bei mehreren Personen
Gerade der Live-Follow Modus gefällt mir richtig gut.
Man wählt oben einfach eine Person aus und die Karte folgt dann automatisch nur noch dieser Person inklusive passendem Zoom.Falls Interesse besteht, teile ich den Code bzw. die Änderungen gerne mit euch 🙂
-
@Olivbus .. wenn du möchtest, kannst du die aktuelle Latest Version (1.9.1) installieren. Ich habe auf Grund @oliverio seinen Kommentar meinen KI-Assistenten gefragt.
Folgendes kam dabei raus:
Zwei Verbesserungen wurden umgesetzt :
-
Retry-Loops brechen bei CF-Block sofort ab
Bisher wurde bei einem 403 trotzdem bis zu Life360APIDataMaxRetries mal wiederholt – das hat die Sperre aktiv verschlimmert. Jetzt gilt: 403 erkannt → break, keine weiteren Requests. -
300 ms Pause zwischen den API-Calls im Poll-Zyklus
Circles → Members → Places wurden bisher ohne jede Pause direkt hintereinander abgefragt. Jetzt wird zwischen jedem Call kurz gewartet, damit die Requests nicht als burst pattern erkannt werden.
Punkt 1 war noch eine Leiche aus dem ursprünglichen Adapter.
@skvarel
Hallo, die Warnmeldung:life360ng.0
2026-05-20 15:31:27.665 warn [circles] Life360 API blocked by Cloudflare (HTTP 403). Your server's IP may be rate-limited or flagged. Try increasing the poll interval or check your Life360 token.war nachdem ich das Node js im Iobroker auf 22 geupdatet habe weg.
Allerdings habe ich weiter das Problem, dass die Life App scheinbar nicht richtig synchronisiert wird.
Places fehlen völlig. Bei people steht bei mir bei disconnected: true und bei isConnectet: false. Trotzdem werden bei people die richtigen Koordinaten, der richtige Batteriestand und der richtige locationName angezeigt. Bei isSharingLocation steht true.
Ich habe die App auf dem Handy gelöscht und wieder installiert, ohne Erfolg.
Den Adapter habe ich auf 1.9.1 geupdatet.Hier noch das Log, wenn ich die Adapterinstanz starte:
life360ng.0 2026-05-21 23:39:43.245 info Connected to Life360 cloud services. life360ng.0 2026-05-21 23:39:43.241 info Polling enabled every 60 seconds. life360ng.0 2026-05-21 23:39:43.046 info [Tracker] Initialized (1 person(s)) life360ng.0 2026-05-21 23:39:42.231 info starting. Version 1.9.1 (non-npm: inventwo/ioBroker.life360ng) in /opt/iobroker/node_modules/iobroker.life360ng, node: v22.22.2, js-controller: 7.0.7 host.debian 2026-05-21 23:39:37.693 info instance system.adapter.life360ng.0 in version "1.9.1" (non-npm: inventwo/ioBroker.life360ng) started with pid 3505507Hast Du eine Idee, woran das liegen könnte?
-
-
@skvarel
Hallo, die Warnmeldung:life360ng.0
2026-05-20 15:31:27.665 warn [circles] Life360 API blocked by Cloudflare (HTTP 403). Your server's IP may be rate-limited or flagged. Try increasing the poll interval or check your Life360 token.war nachdem ich das Node js im Iobroker auf 22 geupdatet habe weg.
Allerdings habe ich weiter das Problem, dass die Life App scheinbar nicht richtig synchronisiert wird.
Places fehlen völlig. Bei people steht bei mir bei disconnected: true und bei isConnectet: false. Trotzdem werden bei people die richtigen Koordinaten, der richtige Batteriestand und der richtige locationName angezeigt. Bei isSharingLocation steht true.
Ich habe die App auf dem Handy gelöscht und wieder installiert, ohne Erfolg.
Den Adapter habe ich auf 1.9.1 geupdatet.Hier noch das Log, wenn ich die Adapterinstanz starte:
life360ng.0 2026-05-21 23:39:43.245 info Connected to Life360 cloud services. life360ng.0 2026-05-21 23:39:43.241 info Polling enabled every 60 seconds. life360ng.0 2026-05-21 23:39:43.046 info [Tracker] Initialized (1 person(s)) life360ng.0 2026-05-21 23:39:42.231 info starting. Version 1.9.1 (non-npm: inventwo/ioBroker.life360ng) in /opt/iobroker/node_modules/iobroker.life360ng, node: v22.22.2, js-controller: 7.0.7 host.debian 2026-05-21 23:39:37.693 info instance system.adapter.life360ng.0 in version "1.9.1" (non-npm: inventwo/ioBroker.life360ng) started with pid 3505507Hast Du eine Idee, woran das liegen könnte?
Places fehlen völlig.
Warum die Places fehlen, wundert mich. Wie viele Orte in der App hast du? Hast du die die Benachrichtigungen in der App aktiviert?

Bei people steht bei mir bei disconnected: true und bei isConnectet: false. Trotzdem werden bei people die richtigen Koordinaten, der richtige Batteriestand und der richtige locationName angezeigt. Bei isSharingLocation steht true.
Das ist bei mir auch so. Ich gucke mal, ob die Datenpunkte überhaupt benötigt werden. Die sind bei mir ewig nicht aktualisiert worden. Die Stammen noch aus dem Ursprungs-Adapter
Hier noch das Log, wenn ich die Adapterinstanz starte:
life360ng.0 2026-05-21 23:39:43.245 info Connected to Life360 cloud services. life360ng.0 2026-05-21 23:39:43.241 info Polling enabled every 60 seconds. life360ng.0 2026-05-21 23:39:43.046 info [Tracker] Initialized (1 person(s)) life360ng.0 2026-05-21 23:39:42.231 info starting. Version 1.9.1 (non-npm: inventwo/ioBroker.life360ng) in /opt/iobroker/node_modules/iobroker.life360ng, node: v22.22.2, js-controller: 7.0.7 host.debian 2026-05-21 23:39:37.693 info instance system.adapter.life360ng.0 in version "1.9.1" (non-npm: inventwo/ioBroker.life360ng) started with pid 3505507Log sieht gut aus.
-
@skvarel
Hallo, die Warnmeldung:life360ng.0
2026-05-20 15:31:27.665 warn [circles] Life360 API blocked by Cloudflare (HTTP 403). Your server's IP may be rate-limited or flagged. Try increasing the poll interval or check your Life360 token.war nachdem ich das Node js im Iobroker auf 22 geupdatet habe weg.
Allerdings habe ich weiter das Problem, dass die Life App scheinbar nicht richtig synchronisiert wird.
Places fehlen völlig. Bei people steht bei mir bei disconnected: true und bei isConnectet: false. Trotzdem werden bei people die richtigen Koordinaten, der richtige Batteriestand und der richtige locationName angezeigt. Bei isSharingLocation steht true.
Ich habe die App auf dem Handy gelöscht und wieder installiert, ohne Erfolg.
Den Adapter habe ich auf 1.9.1 geupdatet.Hier noch das Log, wenn ich die Adapterinstanz starte:
life360ng.0 2026-05-21 23:39:43.245 info Connected to Life360 cloud services. life360ng.0 2026-05-21 23:39:43.241 info Polling enabled every 60 seconds. life360ng.0 2026-05-21 23:39:43.046 info [Tracker] Initialized (1 person(s)) life360ng.0 2026-05-21 23:39:42.231 info starting. Version 1.9.1 (non-npm: inventwo/ioBroker.life360ng) in /opt/iobroker/node_modules/iobroker.life360ng, node: v22.22.2, js-controller: 7.0.7 host.debian 2026-05-21 23:39:37.693 info instance system.adapter.life360ng.0 in version "1.9.1" (non-npm: inventwo/ioBroker.life360ng) started with pid 3505507Hast Du eine Idee, woran das liegen könnte?
-
@olivbus .. kannst du mal bitte die aktuelle Alpha installieren und mir dann den Log zeigen?
Ich habe den Log erweitert:
life360ng.0 2026-05-22 07:26:52.117 info Life360 data: 1 circle(s), 3 Life360 place(s), 8 own place(s), 2 person(s) life360ng.0 2026-05-22 07:26:50.285 info Connected to Life360 cloud services. life360ng.0 2026-05-22 07:26:50.284 info Polling enabled every 60 seconds. life360ng.0 2026-05-22 07:26:50.225 info [Tracker] Initialized (2 person(s)) life360ng.0 2026-05-22 07:26:49.341 info starting. Version 1.9.1 (non-npm: inventwo/ioBroker.life360ng#a19fa28fce15cdb0217ff48493a7a2b95c932eb9) in /opt/iobroker/node_modules/iobroker.life360ng, node: v22.22.2, js-controller: 7.1.2 -
Hallo zusammen,
Ich hab für mich heute auch den Tracker mit ChatGPT etwas weiterentwickelt und ein paar Funktionen ergänzt 🙂
Unter anderem:
- Fokus auf einzelne Personen
- automatischer Zoom auf die ausgewählte Route
- Live-Follow Modus
- Auto-Refresh ein-/ausschaltbar
- ruhigere Kartenansicht bei mehreren Personen
Gerade der Live-Follow Modus gefällt mir richtig gut.
Man wählt oben einfach eine Person aus und die Karte folgt dann automatisch nur noch dieser Person inklusive passendem Zoom.Falls Interesse besteht, teile ich den Code bzw. die Änderungen gerne mit euch 🙂
- Fokus auf einzelne Personen
- automatischer Zoom auf die ausgewählte Route
- Live-Follow Modus
- Auto-Refresh ein-/ausschaltbar
- ruhigere Kartenansicht bei mehreren Personen
Ich schaue mir das mal an. Eventuell kann ich etwas übernehmen ?!
EDIT:
@daniel81 .. ich habe deine 'life360Tracker.js' jetzt zum Testen in meine Alpha eingebaut.
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 Anmelden
