Computed Attribute not evaluated in backend (FMC920/FMC130, in2/io9, Traccar 6.7.3)
Have you linked it to the device?
Yes, the attribute is correctly linked to the device. I verified it from the web interface and also confirmed it exists in the tc_device_attribute table.
In addition, I have another computed attribute on the same device that works correctly, for example:
{
"attribute": "batteryLevel",
"expression": "io113 ? io113 : null",
"type": "number",
"priority": 0
}
This one works without any issues. The problem seems to be specifically related to the computed attribute that evaluates "alarm": "sos".
Here is the attribute I'm using:
{
"attribute": "alarm",
"expression": "in2 == true ? 'sos' : (io9 ? (io9 > 10000 ? 'sos' : null) : null)",
"type": "string",
"priority": 100
}
I suspect that computed attributes that assign to alarm are treated specially by the backend, since they generate events. They might be filtered or ignored depending on the device type, whether the position is valid, or some other internal condition in the processing pipeline.
I would appreciate it if someone from the team or the community has more information about how to debug or force the evaluation of computed attributes of type alarm for Teltonika devices.
Thanks again!
There's no special treatment. Are you sure you don't have multiple alarm attributes that can conflict?
Thank you for the clarification.
Yes, I do have multiple computed attributes that assign to alarm, including some for filtering out false SOS events and others for different GPS protocols.
I’ll share the full list of computed alarm attributes I currently use, in case there's a conflict or processing overlap affecting the Teltonika devices.
Here are the definitions:
{
"id": 4,
"description": "BATERIA TTK",
"attribute": "batteryLevel",
"expression": "io113 ? io113 : null",
"type": "number",
"priority": 0
},
{
"id": 5,
"description": "PLATON LEVANTADO TTK",
"attribute": "alarm",
"expression": "io381 == 1 ? \"door\" : null",
"type": "string",
"priority": 0
},
{
"id": 2,
"description": "POWERCUT TTK",
"attribute": "alarm",
"expression": "power ? (ignition ? (ignition == false && power < 9.3 ? 'powerCut' : null) : (power < 9.3 ? 'powerCut' : null)) : null",
"type": "string",
"priority": 0
},
{
"id": 7,
"description": "SOS FALSO G06L",
"attribute": "alarm",
"expression": "alarm ? (alarm == 'sos' && status ? ((status + '') =~ '^429470' ? 'sos' : null) : null) : null",
"type": "string",
"priority": 0
},
{
"id": 6,
"description": "SOS FALSO GS10",
"attribute": "alarm",
"expression": "type ? (type == 18 ? 'sos' : null) : null",
"type": "string",
"priority": 0
},
{
"id": 1,
"description": "SOS TTK",
"attribute": "alarm",
"expression": "in2 == true ? 'sos' : (io9 ? (io9 > 10000 ? 'sos' : null) : null)",
"type": "string",
"priority": 100
},
{
"id": 3,
"description": "TEMPERATURA1 TTK",
"attribute": "temp1",
"expression": "io72 ? (io72 > 2147483647 ? io72 - 4294967296 : io72) / 10.0 : null",
"type": "number",
"priority": 0
}
]
This would obviously explain the issue. They all conflict. One can add the attribute and other delete it.
Can you tell us the best practice for solving this problem? Would it be to chain everything into a single validation chain? Or use one for each device? Can you give us your valuable feedback?
Using a single attribute is the simplest option.
Hello, thank you for your valuable response. I created this validation chain within a single attribute to perform all the validations you mentioned. Do you think it would work without any problems, or should I make any changes? I appreciate your valuable comments.
{
"id": 1,
"description": "SOS TTK",
"attribute": "alarm",
"expression": "type == 18 ? 'sos' :\n(alarm ? (alarm == 'sos' && status ? ((status + '') =~ '^429470' ? 'sos' : null) : null) : null) ? 'sos' :\n(io381 ? (io381 == 1 ? 'door' : null) : null) ? 'door' :\n(power ? (ignition ? (ignition == false && power < 9.3 ? 'powerCut' : null) : (power < 9.3 ? 'powerCut' : null)) : null) ? 'powerCut' :\n(in2 == true ? 'sos' : (io9 ? (io9 > 10000 ? 'sos' : null) : null))",
"type": "string",
"priority": 100
},
Hello Traccar team and community,
I'm using Teltonika FMC920 and FMC130 devices with Traccar version 6.7.3, and I’ve configured a computed attribute intended to generate an alarm with value "sos" based on the inputs in2 (boolean) and io9 (number).
Here is the JSON used to create the attribute:
{ "id": 1, "description": "SOS TTK", "attribute": "alarm", "expression": "in2 == true ? 'sos' : (io9 ? (io9 > 10000 ? 'sos' : null) : null)", "type": "string", "priority": 100 }Tests through the Traccar web UI work as expected — the expression returns "sos" when in2 == true. However, in the actual production environment:
The computed attribute is not being evaluated or applied to positions.
The attribute is correctly assigned to the device.
The computed attribute is stored in the tc_attributes table.
The device position data includes in2 = true.
No JEXL errors or warnings appear in the logs.
Here is a real example of the position data received:
{ "in2": true, "io9": 140, "power": 27.2, "ignition": true, ... }Despite this, "alarm": "sos" is not being added to the position object.
What I’ve tried:
Verified the expression manually in the web UI (successful).
Simplified the expression to just in2 == true ? 'sos' : null with no result.
Confirmed the attribute is saved correctly and has high priority.
Tried different expression styles including ternary safeguards to prevent evaluation errors.
My questions:
Is there any known change in computed attribute evaluation in Traccar 6.7.3?
Could valid == false or another hidden condition be preventing backend evaluation?
Is there a recommended way to debug whether a computed attribute is being evaluated at runtime?
Any guidance or feedback from the team or experienced users would be greatly appreciated.
Thank you for your amazing work and continued support of the community.