[Release] Traccar Proximity Alert: Telegram notifications for device-to-device distance

Hi everyone!

I’m sharing a small self-hosted project I’ve been working on, built to extend Traccar capabilities.

Traccar Proximity Alert allows you to create monitoring tasks between two specific devices in your Traccar instance. It sends a real-time Telegram alert whenever their distance drops below a configurable threshold.

Key Features:

• Web UI (HTTPS): Simple dashboard to manage and monitor active tasks.
• Database-backed: Uses MySQL/MariaDB for a reliable task queue.
• Background Workers: Efficiently polls the Traccar API for position updates.
• Easy Setup: Includes a dedicated installer script for Debian/Ubuntu.

Typical Use Case:

Automatically notify a Telegram chat or group when two vehicles, assets, or mobile devices get close to each other (e.g., a delivery van reaching a mobile depot, or tracking assets proximity).

Quick Start (TL;DR):

Prerequisites:

• OS: Debian/Ubuntu
• Traccar API reachable
• MySQL/MariaDB running on the same host
• Telegram Bot Token required

Installation and Setup:

# 1. Clone the repository (suggested path /opt/)
cd /opt
sudo git clone [https://github.com/pinguyn8/traccar-proximity-alert.git](https://github.com/pinguyn8/traccar-proximity-alert.git)
cd traccar-proximity-alert

# 2. Configure your environment
# Fill in .env data: API, DB, webapp users, password, Linux user, Telegram bot ID, etc.
sudo cp .env.example .env
sudo nano .env

# 3. Run the installer
sudo ./installer.sh

# 4. Check services status
sudo systemctl status proximity_frontend.service proximity_monitor.service --no-pager

# ---
# Once installed, you can access your dashboard and start creating tasks at:
# https://<your-server-ip>:12975
# ---
# GitHub Repository: [https://github.com/pinguyn8/traccar-proximity-alert](https://github.com/pinguyn8/traccar-proximity-alert)

Would it be more efficient to use position forwarding?

You would need to rewrite the control logic and add a listener service for the forwarded data, and so on. Honestly, it's much more convenient to use Traccar's APIs. In terms of network overhead, I don't think there's much of a difference between data forwarding and API requests anyway. Actually, consider that our current logic is set to adjust the API request interval based on distance, whereas position forwarding triggers for every single tracking point.

Thank you for sharing. Good work.

However, I think it could be better to use position forwarding.

Network overhead should not be a major concern, since Traccar position forward per device.

Hey everyone, I’m really curious about the suggestion to use forward positions instead of localhost API requests. I’d love to understand the actual benefits of switching in my specific case.
Currently, I have my API requests dynamically scheduled based on the relative distance between devices—essentially slowing down the polling frequency when they are far apart to avoid unnecessary calculations and resource drain.
One thing I'm weighing is the networking overhead. While I know every HTTP handshake has its own cost, I’m wondering if a ‘persistent forwarding' connection would actually be more efficient than my current scheduled approach, especially when the devices aren't close enough to need frequent updates?
I’m trying to avoid any 'unnecessary work' for the system, so I’d love to hear your perspective on whether moving away from my current rules offers a real-world advantage I might be missing. Thanks for your time and suggestions!

No need to handle API keys.
No issues around edge cases where devices are near the threshold so you need to make many requests.
Immediate updates and notification instead of relying on API query interval.
Can configure per device to forward or not.