Unlike many in the United States, i live in an apartment complex. This shows as a “business address”, preventing me from utilizing virtually all of the underlying services of Mail and Packages. I have switched gears and am utilizing the 17Track integration, but would like to render the packages’ approximate locations using a Map Card.
my tentative idea for accomplishing this is to:
- extract [city, state] location (if available) from the package sensor.
- pass it to a forward-geocoding API service to get lat/long values.
- take returned lat/long values and apply them to a device_tracker entity.
- display the packages’ dummy device_trackers in the map card.
ideally, this would ultimately be an automation fired every time the 17TRACK sensors update the info_text field.
I’ve stumbled upon a Geocoding API called OpenCage that will allow me to parse text queries into lat/long coordinates, as json or geocode_json, so that seems achievable.
i’ve noticed that most of 17track’s sensors have the location field blank, and that what i’m looking for is often buried in info_text. but sometimes it isn’t, i.e.: there is a delay notice (which are pretty common right now), so i may need to keep record of the last successfully parsed location in a text variable.
it seems simple enough to create a device tracker and apply the coordinates to it using device_tracker.see, assuming that this trick still works.
the thing that i’m the most worried about not working consistently is parsing a location from info_text as the formatting is not consistent across carriers and it will likely require a considerable amount of observing ,filtering, parsing, and head-scratching.
does this seem fairly achievable? or does it have any overlooked optimizations that could be added?