Notifications with computed attributes stop working after time, require server restart (Traccar 6.9+)

Hello,

I'm experiencing a persistent issue with notifications that are triggered by computed attributes in Traccar 6.9 (also tested in 6.11.1). The problem does NOT occur in Traccar 4.11.

Problem Description

Notifications work correctly for a period of time, then suddenly stop triggering without any errors in logs. Creating a new notification temporarily fixes the issue, but it eventually stops working again. Server restart also temporarily fixes it.

Environment

• Traccar Version: 6.9 (also tested 6.11.1)
• Database: MySQL
• Device Protocol: Meitrack
• Working Version: 4.11 (same configuration works perfectly)

Configuration

Device: Meitrack GPS tracker that doesn't natively report ignition status

Computed Attribute (ID 9):

• Description: on/off meitrack
• Attribute: ignition
• Expression: event == 10 ? false : (event == 2 ? true : lastValue)
• Type: boolean
• Assigned to device

Notifications:

• Type: ignitionOn / ignitionOff
• Always: 0
• Notificators: firebase,web,sms
• Assigned to 507 users and 670+ devices

Observed Behavior

1. Initial State: Notifications work correctly
2. After Time: Notifications stop triggering (no pattern - can be hours or days)
3. Events Still Generate: tc_events table shows events are being created correctly
4. Workaround 1: Creating a NEW notification (new ID) makes it work again temporarily
5. Workaround 2: Restarting Traccar service restores functionality temporarily

What I've Tested

✅ Changed always = 0 to always = 1 → Did NOT fix (still stops after time)
✅ Verified notificators field → Correctly set to firebase,web,sms
✅ Checked events generation → Events ARE being generated in tc_events
✅ Tested on clean Traccar 6.9 install → Same problem occurs
✅ Tested on Traccar 4.11 → Works perfectly (no issues)
✅ Backend: Tested with both original and modified backend → Same issue

Database Evidence

-- Events ARE being generated correctly
SELECT eventtime, type, positionid 
FROM tc_events 
WHERE deviceid = 863 AND type IN ('ignitionOn', 'ignitionOff')
ORDER BY eventtime DESC LIMIT 5;
-- Returns recent events

-- Notifications are configured correctly
SELECT id, type, always, notificators 
FROM tc_notifications 
WHERE type IN ('ignitionOn', 'ignitionOff');
-- Returns: notificators = 'firebase,web,sms'

Have you tried disabling firebase and SMS?

I decided to restart the Traccar service every day (using a cron job), not exactly for the reason you mentioned, but because the devices would freeze and stop sending locations, and restarting the service solved the problem. The downside is that users have to log in again after each restart. But the advantages of restarting the service outweigh this.

@Anton Tananaev No, I have not tried disabling Firebase and SMS. I just did a test now:

Test 1 (Old notification - ID existing):

• Removed Firebase and SMS, left only Web
• Result: Does NOT work

Test 2 (New notification - new ID):

• Created fresh notification with only Web channel
• Result: Currently WORKING (just created it)
• Status: Waiting to see if it stops working after some time

This confirms the issue is related to notification ID caching, not the communication channels themselves. When I create a new notification (new ID), it works immediately regardless of channels. The old notification ID seems to be "blocked" or cached in a failed state.

@Cristian I already restart Traccar daily using cron, but the problem is notifications often stop working after only 6-8 hours. In my previous tests with web+firebase+sms, they would fail within hours.

Current test: Now testing with only Web channel on the new notification. I will monitor if it continues working or eventually stops like the others. I'll update this thread with results.

Question for Anton: Is there a notification state cache that persists in memory that could cause a specific notification ID to stop triggering after some time? The fact that creating a new notification (new ID) immediately works suggests the issue is with how Traccar tracks which notifications have already been sent for each device/event combination.

The computed attribute generates events correctly (visible in tc_events table), but notifications stop triggering even though events are being created. It's as if Traccar "remembers" it already notified for that notification ID and refuses to notify again, even for new events.

Thank you both for your help! I'll report back with the results of this test.

There's no logic that would prevent new notifications.

Actually there is a logic based on the time, but you would see it in the logs.

@Anton Tananaev Thank you for clarifying. I understand there's a time-based logic that should show in logs if it's blocking notifications.

Here's what I'm seeing in my logs when notifications STOP working:

• Events ARE being created: INFO: Event id: XXXXX, time: 2026-01-24 XX:XX:XX, type: ignitionOn, notifications: 0
• Notice: notifications: 0 (should be 1 or more)
• No WARNING or ERROR messages about throttling or rate limiting
• No messages indicating why notifications are being skipped

When notifications ARE working (with new notification ID):

• Same events show: notifications: 1

Question: What specific log message should I look for that indicates the time-based logic is preventing notifications? I don't see any warnings or info messages explaining why notifications: 0.

Can you point me to what the log entry would say when the time-based logic blocks a notification? That way I can confirm if that's the issue or if it's something else.

I can provide full logs from the exact moment when notifications stop working if that would help.

If you see notifications: 0, then it's not a time-based filtering. It means that Traccar couldn't find any notifications for this event.