Location tracking via LlamaLab's Automate for Android

I used to use Google Maps location tracking, but recently, it looks like they changed something do with their authentication, and locationsharinglib stopped being able to get the required cookie file automatically. However, I recently found out about LlamaLab’s Automate and I set about creating a flow that could serve the same purpose.

Here’s my flow that will pick up a location change, when you join your home wi-fi, or just a 15-minute interval, and send a bit of JSON to your Home Assistant via a webhook.

When you import it into Automate, you’ll need to tweak the variables that are set in the blocks in the top-left corner of the flow:

  • person - Some identifier for the person who will be tracked. I recommend their name :slight_smile:
  • homeSSID - The SSID of your home network. One of the triggers for a location update is joining your home network so that “arriving home” happens in a timely fashion.
  • homeassistant_internal and homeassistant_external - My router doesn’t allow NAT loopback, so I can’t access my external IP from inside my network, so homeassistant_internal is the web address from inside my LAN, and homeassistant_external is my public duckdns.org address (or the cloud webhook address if you use that). If you don’t have the NAT loopback problem, these can be the same.
  • webhook_id - Whatever your webhook ID is in the automation below.

It also requires a bit of configuration in YAML to set up the device_tracker. The automation here receives the JSON via the webhook and publishes it to MQTT with the topic “location/[person]”. I had to rewrite the JSON here to ensure that some of the values got published as integers. the device_tracker component didn’t like it when they weren’t.

The “original_json” field isn’t necessary, it was just useful to look at when I was debugging things. You may find it useful if you change any elements of the flow or the automation.

The device_tracker then listens for that MQTT topic and that’s it.

automation:
  - id: lat_long_presence
    alias: lat_long_presence
    trigger:
      - platform: webhook
        webhook_id: <YOUR WEBHOOK ID HERE>
    action:
      - condition: template
        value_template: >
          {{ trigger.json.gps_accuracy | int <= 300 }}
      - service: mqtt.publish
        data_template:
          topic: 'location/{{ trigger.json.person | lower }}'
          retain: true
          payload: >-
            {
              "device_time": "{{ trigger.json.timestamp }}",
              "latitude": "{{ trigger.json.latitude }}",
              "longitude": "{{ trigger.json.longitude }}",
              "altitude": "{{ trigger.json.altitude }}",
              "battery_level": {{ trigger.json.battery_level | int }},
              "battery_charging": "{{ trigger.json_battery_charging }}",
              "gps_accuracy": {{ trigger.json.gps_accuracy | int }},
              "provider": "{{ trigger.json.provider }}",
              "trigger": "{{ trigger.json.trigger }}",
              "original_json": "{{ trigger.json }}"
            }

device_tracker:
  - platform: mqtt_json
    devices:
      my_device_tracker: location/<YOUR PERSON ID>

Hope you guys find this useful!

4 Likes

Two reasons why I had to build this solution instead of using a pre-existing one:

  1. I didn’t want to use a cloud solution, both for privacy and speed. Automate can directly post JSON data to my local Home Assistant instance.
  2. Existing solutions where the webhook endpoint can be specified do not know the difference of me being on my home network or not. My lack of NAT loopback would only let my phone hit the webhook when it was either on the local network or not on it – not both at the same time. This is obviously a requirement, because I’m not going to change OwnTracks configuration (for example) every time I leave or come home.

Those were my main reasons for rolling my own solution. I’m curious: what device tracker solutions does everyone else use? Pre-packaged, or roll-your-own?

I used to have a similar approach using tasker to update HA device_tracker entity directly with full set of attributes for the same reasons.

Recently, switched to life360 after getting tired of processing long/latitude for zones away from home, I found life360 really is well-made, much easier for zones and I like the other extra features, check-in, chat, route map, etc…

I don’t have to do any zoning at all – other than define what my home zone is. When the device_tracker receives the lat and long coordinates from the MQTT message, it figures out what zone it is in all by itself. In fact, the ‘state’ of the device_tracker entity is set to the zone it’s currently in (otherwise, it’s simply ‘not_home’).

I still use Google Maps for everything interactive. Just couldn’t depend on it for integrating with HA.

I even use the “useful-markdown-card” to display a Google Maps link:

- type: custom:useful-markdown-card
  content: >
    [Google Maps](https://www.google.com/maps/@[[ device_tracker.your_name.attributes.latitude ]],[[ device_tracker.your_name.attributes.longitude ]],16z)

Just set this up after finally giving up on GPSLogger (my new phone won’t let the background service keep running for more than a couple of minutes) an OwnTracks (updates seem a bit unreliable)

I really like all of the extra attributes available (charging status etc), and I can imagine adding even more, the AutoMate app looks really functional (easy on the eyes as well)

A couple of questions:

I noticed a small delay in one thread (maybe 1:30) by default and another longer one (15 minutes I think). If I understand right the short delay is to compare location changes and the longer one is just running a timer, could you confirm that?

I’ve shortened the delays mentioned above way down to 30 seconds each, and they both seem to get triggered, so they must be independent of each other?

Is the check for home wifi only used to set which IP to log to? NAT loopback works with my router so I’m not using this. Could this be used to set a zone on the HA side (since if I’m on home WiFi I’m very likely at home), and along the same vein, could the location check be ignored if that’s the case?

Just curious if any of this seems possible before I dive into AutoMate farther.

You’re template flow worked perfectly for me by the way!

I’ve since gone with another solution, because I realized after a couple of weeks, that automate was horrible for my battery life.

I never got the built-in OwnTracks component to work because I didn’t want to sign up for an account, but I’ve cobbled together an MQTT solution for the OwnTracks Android app. I can share my automations if you’re interested.

Anyway, in that Automate flow, there are three different ways it can get triggered to send an update:

  1. Location change - when the app thinks you’ve moved beyond the specified range, it’ll send an update.
  2. Wifi connected to “home” - when you connect to your home WiFi SSID, it’ll send an update
  3. “Ping” - make sure to update at least every 15 minutes (that’s the 15 minute delay).

Then the second timer is to try and limit the number of updates by having no two triggers fire within 1:30 of each other. That’s the second, shorter delay.

@SteveDinn I’m having an identical problem - how did you solve with MQTT and OwnTracks? I’ve been attempting to get this to work with Tasker to switch where I publish to depending on if I’m on my home network or not but so far no luck.

Actually I think I got this working - using Tasker and GPS Logger. I couldn’t get GPS Logger to sync my location when on my home network since the certificate is signed for my DuckDNS domain, but I was able to set up a task in Tasker to stop logging with GPS Logger and provide my location when I connect to my home network, and when I disconnect from my home network to begin logging with GPS Logger. Initial testing seems to indicate this is working - using the same device name between Tasker and GPS Logger, Home Assistant reads the update as coming from a single device_tracker.

I have solved this problem by subscribing to Nabu Casa’s service and using a webhook on their side, so it’s always public and reachable no matter where I am.