Love it! Happy to hear it is useful for you 
I have a small home assistant install where I haven’t installed MQTT yet. I might very well end up installing it, but I did notice that there’s a GPSD integration already built in to home assistant.
I looked at the config.yaml and it seems to be explicitly blocking the gpsd port rather than enabling it. Is there some good reason for that which I’m unaware of? I was thinking if it was enabled it would add functionality for those of us not currently using MQTT without any downside, at least that I can tell.
Thinking about testing this locally by editing the config.yaml and seeing if that works like I think it will. Any feedback is greatly appreciated.
I disabled it by default as it is not needed when using MQTT, but there is an option to expose the port if you like. Just look under network under add-on configuration where you find the following setting:
GPSD Port (default 2947). Disabled by default as it is not needed for MQTT, only if you want to use the GPSD integration, or another use-case where direct connection to GPSD is needed.
This addon requires MQTT so you cannot install it without MQTT, but you can get both
Beta available for testing before the next release
Current Beta is 2026.8.1b9 - should be ready for production!
The next release of GPSD to MQTT is a bigger change than usual, and most of it concerns what happens when things go wrong — a GPS that stops reporting, a broker that isn’t up yet, a dead TCP source. That is exactly the kind of thing I cannot fully exercise on my own hardware, so before I publish it I would like a few people to run the beta.
What is in it:
- The entities now report availability properly. They stay unavailable until a real position has been published, and go unavailable if the GPS source stops reporting, instead of leaving the last known position sitting in Home Assistant as though it were current
- A GPS source that disappears while gpsd keeps running is now detected. This was the one that prompted most of the work — gpsd carries on publishing satellite data with nothing behind it
- Two new options, GPS source timeout and GPS source restart multiplier, controlling how long without a position before the entities go unavailable (default 10 minutes) and how many multiples of that before the add-on restarts to reconnect (default 3)
- Enabling Watchdog on the Info tab now works — the add-on reports itself unhealthy when gpsd stops responding
- The add-on waits for the MQTT service instead of giving up if it starts before the broker, which could previously stop it from starting after a reboot
- The MQTT password is masked in the configuration instead of shown in clear text
- A poor sky no longer flaps the entities in and out of availability
What I would like you to look for. The availability change is the one most likely to look like a regression: if your GPS has a bad view of the sky, or takes a while to get a fix, you will now see “unavailable” where you previously saw a stale position. That is intended, but I want to know if it is too aggressive in practice. Otherwise: does it survive a Home Assistant restart, a broker restart, and unplugging the GPS?
To install: the beta lives in the same repository, so if you already have it added you will find “GPSD to MQTT (Beta)” in the store. It is marked experimental and is a development channel — expect it to change under you.
About entity names. The beta installs as a separate add-on with its own device and its own entities — it will not touch, rename or overwrite the ones you already have. Because both use the same default name, Home Assistant will give the beta’s entities a _2 suffix:
- device_tracker.gps_location_2
- sensor.gpsd_service_sky_data_2
That means your existing automations and dashboard cards will keep pointing at the original entity and will not follow the beta. If you want to test with your own automations, the simplest approach is to stop the stable add-on and run only the beta, so the original entity goes unavailable and you are in no doubt about which one you are looking at. Otherwise just point a test automation or a map card at the _2 entity. You could be forced to run only one if you use a serial device as it would not accept both addons using it at the same time.
I would not rename the beta’s entity to the original name. When you go back to the stable add-on you will have two entities competing for it and will have to untangle it by hand. Rather duplicate automations and point them to the beta for testing.
When you are finished testing, stop the beta and delete its device under Settings → Devices & services → MQTT. Nothing is retained on the broker, so once the device is deleted it will not come back — but until you delete it, it will sit there showing unavailable.
Report anything here or as an issue at Issues · corvy/ha-addons · GitHub. Thank you for helping!