Question: "Any" Event Type?

[Oriondely]

Hello everyone, I'm doing some tests and I found that the node check every 15" the location provided by Life360 and that only "arrive" and/or "leave" events can be used as triggers. What about been able to intercept changing location outside places/zones/circles? Is it possible? Could be implemented? Thanks.

[hepcat72]

Interesting question. Currently, only predefined locations are used as event triggers. Your state changes from going from outside or inside a geofence to inside or outside a geofence. However, the data structure returned by Life360 contains a lot of other data. I haven't dug through it, but I know that the Life360 app itself knows for example, when you are driving and when you're not. It uses that to trigger event notifications like "completed a drive". I suspect that if someone wrote the code, those status changes could be used to emit events from the Life360 node representation in node-red. Maybe crash detection could also be implemented, but I have some concerns...

The reason IMO that Life360 is so reliable compared to other geofence apps I've used is that it doesn't depend on actively seeing the geofence boundary crossing in real time. It's that it keeps track of your last known location status (e.g. you're either inside a geofence or not). It doesn't matter if you lose wifi signal or turn on airplane mode. Once you get your signal back, if your last known geofence status is different from the current status, it triggers the arrive/leave event.

So I think that driving versus not driving could work the same way, but I'm not sure how crash detection would work. If it decides you've been in a crash, when does that status change back from being in a crash state to not being in a crash state?

Regardless, I don't think "any" location could work. There are an infinite number of possibilities. Basing it on location has to be user-defined geofences. But basing it on a change in driving state could work. However, if you end a drive inside a geofence, and you also have an arrival trigger for that location, you would get a node emission for each case, and in order to prevent that, you would have to catch and handle that outside of the node's code.

Also, even though there are possibilities for new features here, I don't have time time or particular interest to implement it. However, I would happily review a pull request.

[hepcat72]

One other complication of having an "any" rule, say based on business locations marked on the Life360 map, is overlapping geofences. Life360 does not handle that well. I've tried it. I used to have a "home" location that had a large geofence (so that AC units would run for a minute or 2 before I walked in the door) and a "home close" location with a smaller geofence (so that I could say, turn on flood lights when I arrive at night). But Life360 only allows a single location status, and when the geofences overlap, your location can randomly trigger arrival/departure statuses between the 2 overlapping geofences.

So if you allowed automatically generated geofences for say, businesses marked on the map, you could potentially end up with overlapping geofences with the same issue I described above.

[Oriondely]

First of all thanks for your answer. The reason why I'm asking this feature is because I was already using it in an old unofficial Home Assistant plugin in the past. All was working correctly but from one day to another it stopped to work (I supposed Life360 made some changes from their side).

At that time I tried also OwnTracks, sending location information via MQTT to my MQTT server, but I found it unreliable, because sometime, for some reason, the application on android device stops working (also disabling android battery optimization, etc etc...). I never had this issue with Life360 application that always worked like a charm, so today I revert back to Life360 after seeing this fantastic NodeRed Life360 plugin.

In my HomeAssistant automations I used also some information such "distance from home" calculating it as difference between my Home coordinates and latitude/longitude info coming from Life360 node (location.latitude & location.longitude) for heating my house (pre-heating functionality when I'm arriving at home from work).... But also "battery", "speed", "isdriving" information could be very useful, but at every change status and not only at arrive/leave event.

I'm also trying to find out if there's a way to use a Life360 unsupported API directly (making a HTTP request directly from NodeRed and getting and managing the raw data), but I'm having some issues using this approach (I receive alway 403 response) I'm referring to these documents found on github: https://krconv.github.io/life360-api-docs/ and https://github.com/kaylathedev/life360-node-api/blob/master/README.md

Anyway, thanks for your support, If should be possible to implement a "generic" event change not base on entering/leaving zone could be beautiful! :-) Thanks.

[hepcat72]

I think I somewhat misunderstood what you were describing. Do you mean you want the raw location data every 15 seconds when outside of a place? If that's correct, what would be the purpose of that? It seems outside of the scope of the intended use for this node, which is intended for home automations...

[Oriondely]

"Do you mean you want the raw location data every 15 seconds when outside of a place?" Yes

"If that's correct, what would be the purpose of that?" Monitoring position, distance from home... For istance if my heating starts to heat apartment when I arrive at home, it's too late.... wich is the intent of use data that's coming from the node that are not updated frequently but only once when I enter/exit an area? (i.e battery, speed,...) ;-)

[Oriondely]

Hello @hepcat72, Some updates from my side: I'm now able, studying your javascript code, to use only Life360 API (directly in NodeRed using standard nodes) to retrieve all the needed information programmatically following these steps:

1. Authenticate to Life360 API and get Bearer Token
2. Get the circle CircleID using the Bearer Token at point 1
3. Get Members information using the Bearer Token at point 1 and the CircleID at point 2

Anyway thank you for your support and work, should be fantastic if your node could directly support this feature: could be useful to other users. Thank you.