Device Tracker

[alpha520098]

Describe the feature

It would be nice if there was a entity that could take the in the distance and the bearing so this could be plotted onto a map:

so you could see excatly where the heading and the distance would be.

Home Assistant version

No response

Integration version

No response

Acknowledgements

• [X] I have searched this repository and API Repository to see if the feature has already been requested.
• [X] This featre request is sepecific to the HA Integration.
• [X] I have written an informative title.

[dxmnkd316]

This is a really clever idea. I know it can be in bad form to do this, but I really like this and would like to see this at some point.

One thing to consider is capping the number to the nearest 10 storms. Or something like that. But I would be happy with anything here.

That said I wonder if there's a way to implement this using templates in HA Core.

[cloneofghosts]

Looks like this one got missed as well. Just to be clear you're looking to plot the distance/bearing on a map to visualise which way a storm is heading?

I'm not totally sure what is 100% possible in HA so will defer to @alexander0042 to see if this would be possible

[dxmnkd316]

I assume that's what the OP is saying.

I think it would be one of those things where you'd use the device_tracker and map functionality. You can give a device_tracker entity GPS coordinates. The hard part would be the directional heading.

You can give it an icon that changes based on the severity or threat. Perhaps "mdi:weather-hail" or something like that for hail as an example.

Edit: I think this would be hugely beneficial since mapping API requests tend to be extremely expensive in terms of credits per call. Aeris for example is a huge cost depending how big the map is and what layers you want. Just storm tracking would require a storm layer, a basemap map layer, and additional roads or boundary layers each each with a different cost. See here: https://www.xweather.com/docs/maps/getting-started/accesses

It could look something like this:

[alpha520098]

Spot on, this is exactly what is required.

[alexander0042]

Sorry for never replying to this, was focused on getting some critical historic data stuff working. The good news is that I got this working using the excellent virtual devices add on! I wrote it up as I was doing it, so let me track that down

[dxmnkd316]

Sorry for never replying to this, was focused on getting some critical historic data stuff working. The good news is that I got this working using the excellent virtual devices add on! I wrote it up as I was doing it, so let me track that down

I'll be interested to see what you make of this. I've been playing around with this idea by using the Aeris API to get the closest storms and adding GPS to them. I haven't had a ton of time to work through how to do it but glad you found the virtual devices.

I think my biggest issue is going to be how to call this efficiently in terms of API accesses. Trying to find a balance of update vs. quota cap is going to be tricky. I'm wondering if something like triggering the storm location API to start calling hourly when there's a severe watch issued or every 15 mins during a warning. Not sure. I know this is somewhat off topic, but again, i'll be curious to see where you go with this. Thanks!

[alexander0042]

Depending on how many locations you're trying call for at once, the default 15 minute call should fall well within the free tier, so hopefully that's ok!

The way I got it working was to create a virtual_tracker.yaml file, which when loaded with that integration provides a virtual device that can move around to show the nearest storm on a map. The file is pretty basic, with these contents:

version: 1
devices: 
  Test Device_Tracker:
   - platform: device_tracker

Then, I made a new automation using this yaml:

alias: Storm Device Move
description: ""
mode: single
triggers:
  - entity_id:
      - sensor.pirateweatherc_nearest_storm_distance
    trigger: state
  - entity_id:
      - sensor.pirateweatherc_nearest_storm_bearing
    trigger: state
conditions: []
actions:
  - variables:
      current_lat: "{{ state_attr('zone.home', 'latitude') | float * (pi / 180) }}"
      current_lon: "{{ state_attr('zone.home', 'longitude') | float * (pi / 180) }}"
      distance_km: "{{ states.sensor.pirateweatherc_nearest_storm_distance.state }}"
      direction_deg: "{{ states.sensor.pirateweatherc_nearest_storm_bearing.state }}"
      earth_radius_km: 6371
      direction_rad: "{{ direction_deg | float * (pi / 180) }}"
      new_lat: >-
        {{ (asin(sin(current_lat | float) * cos(distance_km/earth_radius_km) +
        cos(current_lat | float) * sin(distance_km/earth_radius_km) *
        cos(direction_rad))) * (180 / pi) }}
      new_lon: >-
        {{ (current_lon | float + atan2(sin(direction_rad) *
        sin(distance_km/earth_radius_km) * cos(current_lat | float),
        cos(distance_km/earth_radius_km) - sin(current_lat | float) *
        sin(new_lat))) * (180 / pi)  }}
  - target:
      entity_id: device_tracker.test_device_tracker
    data:
      gps:
        latitude: "{{ new_lat }}"
        longitude: "{{ new_lon }}"
    action: virtual.move

It assumes

1. Your Pirate Weather integration is named "pirateweatherc".
2. The units for the integration are in si
3. Your device tracker is called "test_device_tracker"

The automation is triggered every time the nearest storm distance or bearing changes, and calls a service to update the location of the device tracker, giving me a map that looks like this:

I'm very open to adding this directly into the integration somehow; however, it would be a little bit of work. The data is definitely there, but because device trackers look reasonably complex, it's not a trivial thing.

[dxmnkd316]

nice work!

I'll be traveling for work this week so i'll have some downtime in the hotel to take a look this week hopefully.