Computed Attribute for Teltonika Alarms for Low power and Low battery - breaks all other alarms
I should say that it seems "obvious" that we're killing the other alarms due to the ": null" at the end of the syntax, but what else can I put there? We tried putting in ": alarm" but it says the variable is undefined.
Can you check if alarm exists then if it does concatenate the string with your other value and a comma?
Like check the value of the alarm? An interesting approach; I wasn't aware multiple alarms could stack.
I'm also not sure the sequence of attribute computation of in-built attributes vs. computed attributes. I'm assuming computed attributes fire first since the in-built ones get nulled out.
This is a complete hack because I used bluelaser's idea and another recent post about alarms and chucked it into ChatGPT 5.2.
It works, but I need a lot of coffee in the morning to get my head around it. Also I'm too tired to format and indent it for now.
( (alarm ? alarm : "") + ((power >= 2 && power <= 10) ? ((alarm ? alarm : "").length() > 0 ? ",lowPower" : "lowPower") : "" ) + ((battery < 3.5) ? ( ( (alarm ? alarm : "").length() > 0 || (power >= 2 && power <= 10) ) ? ",lowBattery" : "lowBattery" ) : "" ) ).length() > 0 ? ( (alarm ? alarm : "") + ((power >= 2 && power <= 10) ? ((alarm ? alarm : "").length() > 0 ? ",lowPower" : "lowPower") : "" ) + ((battery < 3.5) ? ( ( (alarm ? alarm : "").length() > 0 || (power >= 2 && power <= 10) ) ? ",lowBattery" : "lowBattery" ) : "" ) ) : null
I also think ChatGPT has been excessively verbose so for now I'd just treat it as a "this works" rather than "this is elegant".
OK bugger it I just needed to paste it with formatting. Sorry, it's like midnight here.
(
(alarm ? alarm : "") +
((power >= 2 && power <= 10)
? ((alarm ? alarm : "").length() > 0 ? ",lowPower" : "lowPower")
: ""
) +
((battery < 3.5)
? (
(
(alarm ? alarm : "").length() > 0 ||
(power >= 2 && power <= 10)
)
? ",lowBattery"
: "lowBattery"
)
: ""
)
).length() > 0 ? (
(alarm ? alarm : "") +
((power >= 2 && power <= 10)
? ((alarm ? alarm : "").length() > 0 ? ",lowPower" : "lowPower")
: ""
) +
((battery < 3.5)
? (
(
(alarm ? alarm : "").length() > 0 ||
(power >= 2 && power <= 10)
)
? ",lowBattery"
: "lowBattery"
)
: ""
)
) : null
I wouldn't use LLMs for anything JEXL by the way, they mostly spit out garbage. I use this site for testing: https://czosel.github.io/jexl-playground/
Wouldn't it be better to setup the parameters device side though and generate a separate high priority event for each of these?
The parameters in question here for the lowBattery and lowPower alarm aren't something I have the spare Custom Scenarios in Teltonika devices available to configure that. We heavily use Custom Scenarios for other stuff so I won't be consuming two of the three available just for some voltage alarms.
As for LLMs, I don't trust them either, but for the purposes of working towards closure on this post so Anton doesn't need to get involved, it's nice to show progress. I'll tidy it up. We already do a lot of code changes to Traccar for our service, so this is all temporary until we work down our list of priorities and add our own Alarms and Notifications outside of Traccar currently supports.
You don't need custom scenarios, just set the high and low level in the I/O settings in the configurator with the priority set to high.
Teltonika devices used by our customers need the Low Power and Low Battery alarms to work and these are not defined in the Teltonika Decoder. However we understand these are tricky because what constitutes low power differs for a 12v or 24v system, and what constitutes low battery differs across Teltonika models (e.g. the TAT240 has an in-built non-rechargeable 7.2v battery).
So, we have created the following computed attribute called "Teltonika Alarms" which writes strings into the "Alarm" attribute:
This works for these two alarm types, but it kills all in-built alarms handled by Traccar already for teltonika devices such as:
So, what's possible here? Can we tweak this syntax so it doesn't stop other alarms, or does my computed attribute have to be coded to handle all alarms? Handling all alarms in the computed attribute is a problem because the raw attributes used by these are essentially captured by the teltonika decoder and don't appear to be accessible (e.g. io175 for the Geofence alarms, io252 for the Power Cut alarm, etc).