I’m looking at adding a local bus/rail integration, and I’m thinking the easiest thing is going to be to bridge via MQTT. I’d like the map card to show the stops and vehicles. It has a feature where it can show entities from given geolocation platform source. However, it seems like this source must be from a predefined list of platforms which are “geolocation platform sources” (from Geolocation - Home Assistant).
Is this just entirely the wrong direction to be looking in? It looks like most of the geolocation events are expected to be “an event in a fixed place at a given time”. This might make sense for another idea I have (my city has an API which shows city service requests – like rodent sightings!), but maybe isn’t right for moving buses. Will I be better off making a fork/enhancement of the map card for this idea?
Yes, that is meant for entities that are appearing and disappearing depending on an external feed, hence each integration defines a source indicator that you can then use to display related entities on a map.
Is my understanding correct that you are planning to develop an integration or use an existing one? If it’s the former then you can of course create geo_location entities and add a new source attribute.
Likewise you can add static geo_location entities for bus stops for example. An alternative is to add those bus stops as zones with a very small radius. You can manually add zones to the map card.
I was thinking that rather than developing a Home Assistant-specific integration, I would make a generic bridge to MQTT, and then add some Home Assistant stuff (like discovery) to that.
But maybe I really should look at making an integration.
All interesting feeds/APIs I have come across so far that would lend themselves towards building a geolocation integration provide either JSON or XML. I have actually built a variety of integration libraries that you could use as a basis, e.g. aio_geojson_client or aio_georss_client, and extend to suit your specific needs.
The complicated bit here is to extract the data from the external feed/API and I’m not sure if the detour through MQTT is actually helpful. From experience, it’s hard to manage the creation, update and deletion of geolocation entities, hence I built those generic extendable libraries.
So, in this case, it’s the Boston-area MBTA, and I’m using their streaming API. See Streaming | V3 API | MBTA and v3 API swagger docs. This is pretty easy to handle, but it doesn’t really lend itself well to anything built into Home Assistant.
The end result is I want to have a light which changes color based on how close the next bus is. I may also create an actual arrival-time sign panel, but that’s for the future.
You can see that there are a number of things which provide latitude and longitude. It seemed like it’d be nice to also map those.
Thanks, yes, that is different to all integration I have built so far, because I had to manually compare the current and the previous request to find out what’s new, updated or removed. I don’t know of any HA integration that does receive events based on a text/event-stream API. But if you can somehow get that running, then handling the reset and add events is pretty much the same, and update and delete affecting existing entities could be handled with the dispatcher pattern.