Documentation?
How did you determine that 0x06 is a power cut? The documentation you provided doesn't seem to agree with you.
Oh, let me check. I think I sent you the wrong documentation. Let me get the correct one from the vendor.
I discussed this with the vendor, and they asked me to share the actual protocol document they use. Let me get it and send it to you again.
You're absolutely right - looking back at the document I provided, I don't see where it explicitly defines 0x06 as power cut alarm. I made an assumption based on the pattern I observed in the logs, but that wasn't correct according to the official documentation.
Here are the complete logs from the period where I noticed the status byte change:
2026-03-28 08:00:44 INFO: [T347a42e6: gt06 < 223.123.111.212] 78780a130406040002016457a10d0a
2026-03-28 08:00:44 INFO: [T347a42e6: gt06 > 223.123.111.212] 787805130164c4820d0a
2026-03-28 08:04:15 INFO: [T347a42e6: gt06 < 223.123.111.212] 78780a130406040002016546280d0a
2026-03-28 08:04:15 INFO: [T347a42e6: gt06 > 223.123.111.212] 787805130165d50b0d0a
2026-03-28 08:06:48 INFO: [T347a42e6: gt06 < 223.123.111.212] 78780a130406040002016674b30d0a
2026-03-28 08:06:48 INFO: [T347a42e6: gt06 > 223.123.111.212] 787805130166e7900d0a
2026-03-28 08:07:10 INFO: [T347a42e6: gt06 < 223.123.111.212] 78780a130606040002016752810d0a
2026-03-28 08:07:10 INFO: [T347a42e6: gt06 > 223.123.111.212] 787805130167f6190d0a
2026-03-28 08:08:25 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080818cd02aba3670732250f009501019a0402d9006eea016f90240d0a
2026-03-28 08:08:25 INFO: [T347a42e6: gt06 > 223.123.111.212] 78780512016f208d0d0a
2026-03-28 08:09:37 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080925cc02aba5de073228f4009445019a0402d9006eea017312e80d0a
2026-03-28 08:09:37 INFO: [T347a42e6: gt06 > 223.123.111.212] 787805120173fa600d0a
2026-03-28 08:10:06 INFO: [T347a42e6: gt06 < 223.123.111.212] 78780a1346060400020174d4030d0a
2026-03-28 08:10:06 INFO: [T347a42e6: gt06 > 223.123.111.212] 787805130174d4030d0a
2026-03-28 08:10:38 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080a25cc02aba504073229dc00949f019a0402d900365c0175737d0d0a
2026-03-28 08:10:38 INFO: [T347a42e6: gt06 > 223.123.111.212] 7878051201759f560d0a
2026-03-28 08:10:59 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080a39cc02aba31f07322b9b0e945a019a0402d900365c017678690d0a
2026-03-28 08:10:59 INFO: [T347a42e6: gt06 > 223.123.111.212] 787805120176adcd0d0a
2026-03-28 08:11:28 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080b1bcc02aba49f07323c0f0b9453019a0402d900365c0177fe740d0a
2026-03-28 08:11:28 INFO: [T347a42e6: gt06 > 223.123.111.212] 787805120177bc440d0a
2026-03-28 08:11:58 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080b39cd02aba63107324dc9239453019a0402d900365c0178d1710d0a
2026-03-28 08:11:58 INFO: [T347a42e6: gt06 > 223.123.111.212] 78780512017844b30d0a
2026-03-28 08:12:28 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080c1bcc02aba7c507325fa8259452019a0402d900365c01799d590d0a
2026-03-28 08:12:28 INFO: [T347a42e6: gt06 > 223.123.111.212] 787805120179553a0d0a
2026-03-28 08:12:42 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080c29cc02abaa0707326aea2c943f019a0402d900377e017a30ed0d0a
2026-03-28 08:12:42 INFO: [T347a42e6: gt06 > 223.123.111.212] 78780512017a67a10d0a
2026-03-28 08:13:07 INFO: [T347a42e6: gt06 < 223.123.111.212] 78780a134606040002017b2cf40d0a
2026-03-28 08:13:07 INFO: [T347a42e6: gt06 > 223.123.111.212] 78780513017b2cf40d0a
2026-03-28 08:14:47 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080d35cd02abae9807327509009440019a0402d9003779017ca0100d0a78781f121a031c080e24cc02abb17007327b96009457019a0402d9003779017d25810d0a78781f121a031c080e28cc02abb14f07327c4d109473019a0402d900377c017e08060d0a
2026-03-28 08:14:47 INFO: [T347a42e6: gt06 > 223.123.111.212] 78780512017c02970d0a
2026-03-28 08:14:47 INFO: [T347a42e6: gt06 > 223.123.111.212] 78780512017d131e0d0a
2026-03-28 08:14:47 INFO: [T347a42e6: gt06 > 223.123.111.212] 78780512017e21850d0a
2026-03-28 08:15:03 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080f02cc02abac3d073289791e9485019a0402d900377c017f05e70d0a
2026-03-28 08:15:03 INFO: [T347a42e6: gt06 > 223.123.111.212] 78780512017f300c0d0a
2026-03-28 08:15:07 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080f06cc02abaa5907328af5249496019a0402d900377c0180967d0d0a
2026-03-28 08:15:07 INFO: [T347a42e6: gt06 > 223.123.111.212] 7878051201803f740d0a
2026-03-28 08:15:57 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c080f24cc02ab93ed07329ad6279490019a0402d900377c01819acd0d0a
2026-03-28 08:15:57 INFO: [T347a42e6: gt06 > 223.123.111.212] 7878051201812efd0d0a
2026-03-28 08:16:07 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c081006cc02ab7ffb0732a8c2359493019a0402da0045b20182b6760d0a
2026-03-28 08:16:07 INFO: [T347a42e6: gt06 > 223.123.111.212] 7878051201821c660d0a
2026-03-28 08:16:08 INFO: [T347a42e6: gt06 < 223.123.111.212] 78780a134606040002018334ad0d0a
2026-03-28 08:16:08 INFO: [T347a42e6: gt06 > 223.123.111.212] 78780513018357330d0a
2026-03-28 08:16:40 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c081024cc02ab68a20732b8f3329493019a0402d9006e740184ff520d0a
2026-03-28 08:16:40 INFO: [T347a42e6: gt06 > 223.123.111.212] 78780512018479500d0a
2026-03-28 08:17:08 INFO: [T347a42e6: gt06 < 223.123.111.212] 78781f121a031c081106cc02ab5c050732c1c4169493019a0402d900c340018555e60d0a
2026-03-28 08:17:08 INFO: [T347a42e6: gt06 > 223.123.111.212] 78780512018568d90d0a
| Time | Packet Type | Status Byte | Notes |
|---|---|---|---|
| 08:00:44 | Location (0x13) | 04 |
Normal |
| 08:04:15 | Location (0x13) | 04 |
Normal |
| 08:06:48 | Location (0x13) | 04 |
Normal |
| 08:07:10 | Location (0x13) | 06 |
Status changed to 06 |
| 08:08:25 | Extended (0x12) | - | Additional data packet |
| 08:09:37 | Extended (0x12) | - | Additional data packet |
| 08:10:06 | Location (0x13) | 46 |
Status changed to 46 |
| 08:10:38 | Extended (0x12) | - | Additional data packet |
| 08:10:59 | Extended (0x12) | - | Additional data packet |
| 08:11:28 | Extended (0x12) | - | Additional data packet |
| 08:11:58 | Extended (0x12) | - | Additional data packet |
| 08:12:28 | Extended (0x12) | - | Additional data packet |
| 08:12:42 | Extended (0x12) | - | Additional data packet |
| 08:13:07 | Location (0x13) | 46 |
Status remains 46 |
| 08:14:47 | Extended (0x12) | - | Multiple packets combined |
| 08:15:03 | Extended (0x12) | - | Additional data packet |
| 08:15:07 | Extended (0x12) | - | Additional data packet |
| 08:15:57 | Extended (0x12) | - | Additional data packet |
| 08:16:07 | Extended (0x12) | - | Additional data packet |
| 08:16:08 | Location (0x13) | 46 |
Status remains 46 |
| 08:16:40 | Extended (0x12) | - | Additional data packet |
| 08:17:08 | Extended (0x12) | - | Additional data packet |
Based on the pattern in the logs, I noticed:
04 → 06 at 08:07:1006 → 46 at 08:10:0646 for all subsequent location packetsI assumed this status byte change indicated a power cut event, but you're correct - the documentation I provided doesn't define 0x06 or 0x46 for the Location Packet (0x13) status field.
Let me get the correct protocol document from the vendor and share it with you.
Will share soon.
While we wait for the correct protocol documentation from the vendor, I need a solution for the immediate problem - avoiding repeated events from computed attributes.
Currently, my computed attribute is:
text
charge == false ? "powerCut" : null
This generates an alarm on every position update while charge is false, causing repeated events
How to Avoid Repeated Events in Computed Attributes?
I need a way to generate events only on state change, not on every position update.
You can check previous value.
I'm using Traccar v6.11.1.
Can you please share more detail about how to check the previous value in computed attributes?
I understand that computed attributes are evaluated on every position update and don't have built-in state persistence. How can I track the previous charge state to generate events only when the value actually changes?
For example, I need logic like:
previous_charge != current_charge && current_charge == false ? "powerCut" : null
And similarly for power restored:
previous_charge != current_charge && current_charge == true ? "powerRestored" : null
Any guidance would be appreciated.
Thanks.
I recommend searching. It has been discussed several times before.
Thanks, I think I got it working with this configuration:
<entry key='processing.computedAttributes.lastAttributes'>true</entry>
And this computed attribute:
lastCharge != null && lastCharge != charge ? (charge == false ? "powerCut" : "powerRestored") : null
GT06 Alarm Packets Not Generating Events
Observation:
The GT06 device is sending power cut alarm packets which are visible in the logs, and the charge attribute updates correctly, but Traccar does not create any alarm event.
Log Evidence:
text
78780a13= Location report with status06after13= Alarm status (power cut)Charge attribute updates to false correctly
Expected Behavior:
When Traccar receives a GT06 packet with alarm status (06, 46, etc.), it should generate an alarm event (e.g., alarmPowerCut).
Actual Behavior:
No alarm event is created. Only the charge attribute is updated.
Computed Attribute Workaround - Repeated Alarms
Workaround Attempt:
Since Traccar wasn't generating alarms automatically, I created a computed attribute:
text
Result:
The computed attribute successfully creates alarm events, but it generates them repeatedly on every position update while charge remains false.