Teltonika Attribute sent with value of zero treated as null?
To add to this, the Teltonika tracker is being forced to send the current value of io381 in all position records, so it's not a source device issue.
Something doesn't add up here. Your expression won't give this error, even if the attribute is missing.
You're right Anton - I was supposed to add that for that warning to generate I had removed the null check to make sure that it wasn't just the Teltonika tracker failing to send io381. I am sorry for causing confusion here.
Maybe let's take it back to basics and provide a simpler example. Should the following example be computed appropriately if the attribute was sent by a teltonika tracker? If not, what is wrong with this JEXL that stops the value of zero from being computed?
io381 == 1 ? "Authorised" : io381 == 0 ? "Inhibit" : null
This attribute example is defined as a String.
It should work fine if the attribute is present, but it will give the error when it's missing. The exact error you're getting.
Hmmm. OK, frustrating! I'll have to gather way more logs.
OK I've managed to generate two logs in sequence where the only change was me grounding out DIN2 (io381) on the Teltonika tracker. No other logs arrived from this tracker in this time.
Ground Sense = 1
00000000000000788e01000001998ef672e00156949f8ee9501b8f001b00ac0e0000017d0014000b00ef0100f00100150400450100010000b30000b40000ed02010700017c00017d01000600b5000b00b6000700423a040018000000ced07000430fea000200f10000c546027c014bd04a0001004e000000000000000000000100001f8a
Grounse Sense = 0
00000000000000788e01000001998ef69dd80156949f8ee9501b8f001b00ac0e0000017d0014000b00ef0100f00100150400450100010000b30000b40000ed02010700017c00017d00000600b5001100b6000700423a010018000000ced07000430feb000200f10000c546027c014bd04a0001004e00000000000000000000010000c1a6
The first trace has 17d01 whereas the second trace has 17d00. They're both quite deep into the trace; it's not the first "17d" in the trace but the second one.
So, data received, but still treated as null. Here is the Computed Attribute used for the above two logs. For the second log, the value of the attribute was "Foo", indicating Traccar decided it was null.
io381 ? (io381 == 1 ? "Authorised" : io381 == 0 ? "Inhibited" : null) : "Foo"
It's not treated as null. It's treated as "falsy" value, which is absolutely expected.
OK so this is a JEXL thing. Right, so since I suck at JEXL and my pathetic attempts at asking LLMs to give me a non-falsy example are rubbish, do you have an example that would work?
I'm going to take that as a No.
OK I had to use OpenAI o1-mini and paste in the entire code of ComputedAttributesHandler.java to get an understanding (not being a coder here), of what the limitations are on JEXL within Traccar.
The following JEXL works correctly to handle "falsy" values.
(io381 == 1) ? "Authorised" : (io381 == 0 ? "Inhibit" : null)
we use it only for door open alerts using the door sensor that grounds when door is open, how are you using it for immobilizer ?
It's connected to an IGLA 100 which uses a ground pulldown for authorisation. So, we connect it to DOUT1 for the ground pulldown, and monitor the status with DIN2 set to Negative Input (which converts DIN2 from Teltonika io2 / Traccar in2 to raw io381).
This way we can see the state of the IGLA Authorisation and how that was driven with a tweaked version of the computed attribute:
(io381 == 1 && out1 == 0) ? "Bypassed" :
(io381 == 1) ? "Authorised" :
(io381 == 0) ? "Inhibit" :
null
If io381 is 1 but out1 is 0, then we know the authorisation was from our (hidden) bypass switch.
The benefit of this compared to our other immobiliser methods is for customers where a wire cut would be a massive warranty issue. IGLA CANbus immobilisers only tap the CANbus wires; no wires need to be cut for relay intercepts.
thats a good setup, i have considered fmc150 so that i don't have to find and cut door sensor wire to know door status, fmc has can reading and can read directly from car computer, your setup is good i like it i considered similar setup in the past but i never got much information about Igla for some reason i think they are very expensive? i dont have prices , i run my tracking business in south America in ecuador. this igla is a good setup avoid cutting wires near the steering wheel where everyone looks and probably tap into a CAN lines. like by transmission or something
Hi Byron, it honestly depends. I started my business using my own immobiliser harness design, and it works very well. Just relays.
IGLA prices vary - IGLA 100 is quite cheap but it really depends and vehicle coverage can be inconsistent in whether it can remotely kill a running engine. The way that IGLA disables each vehicle is also wildly different, depending on that manufacturers CANbus messaging. Some vehicles won't start at all, others will start and then stall. Some even need a secondary relay or pulsing of the start/stop button. Integration with IGLA is currently all analogue but I am working with IGLA directly to see if we can integrate the new Teltonika FTC305 with the IGLA immobiliser, as they can communicate over the vehicle CANbus. Specifically there I'm talking about the IGLA 200 series, which are much more capable and flexible than the IGLA 100. They are also a lot more expensive however.
With my native system, I access the manufacturer websites for the wiring diagrams (I pay for this) and find a circuit I can intercept which will reliably stop the engine without triggering the Check Engine Light. So far I've been 100% successful and the behaviour is consistent on every vehicle regarding the fact that the engine just stops. I use the FMC130 almost exclusively.
For tracking the state of various digital systems on the car, I would use the FMC150 especially as it now auto detects the vehicle with the new firmware.
So in the ongoing work of adding all the teltonika "parameters" correctly into Traccar 's Teltonika Decoder and eventually submitting a pull request for this, we have noticed that paramters sent with a value of zero are treated by Traccar as "null".
Here's the raw data for Teltonika io381 (Teltonika "Ground Sense", which is just an inversion of DIN2 from voltage detection to ground detection) as a computed attribute that is linking its use to an immobiliser. Note that we had to stuff another "Inhibit" on the end because Traccar just sees the io381 value as null.
Here's the log warning:
But here is what Traccar says for that relevant position record:
So I am really not sure what is going on here.
FYI the Teltonika decoder change here will be to also consider io381 as just another source for Input 2 from Teltonika devices.