Teltonika FMC003 – IO 246 / 252 never trigger alarms (decoder reads only 1 byte, device sends 2-byte values)

Hi,
I’m using a Teltonika FMC003 and noticed that AVL IDs 246 (tow) and 252 (power cut) never generate alarms in Traccar.

In the device payload those IO values are always sent as 2-byte values, e.g.:

F6 00 0D
FC 00 0D

But TeltonikaProtocolDecoder reads these as one unsigned byte only:

b.readUnsignedByte() > 0

So the first byte is always 0, and the alarm never triggers.

Is this intentional for FMC00x devices, or should these IO IDs be treated as multi-byte values (e.g., using readValue)?

Thanks.

Do you have the documentation for it?

These work fine for me. Your "Model" for the Device in Traccar must match one of the models supported by the version of Traccar you are using. I don't believe FMC003 is in the list or you need to create your own Custom Attribute.

Change the model to FMC130 and see if they decode properly.

The latest version of the decoder will correctly interpret any models starting with "FM" but it is not in a production release yet (not even 6.10).

Hi Kaldek,

Exactly what I found - thanks! I just add FMC003 on 6.10 locally and compiled it.

	var fmbXXX = Set.of(
                "FMB001", "FMC001", "FMB010", "FMB002", "FMB020", "FMB003", "FMB110", "FMB120", "FMB122", "FMB125",
                "FMB130", "FMB140", "FMU125", "FMB900", "FMB920", "FMB962", "FMB964", "FM3001", "FMB202", "FMB204",
                "FMB206", "FMT100", "MTB100", "FMP100", "MSP500", "FMC125", "FMM125", "FMU130", "FMC130", "FMM130",
                "FMB150", "FMC150", "FMM150", "FMC920", "FMC003");

Also found that if you configure an alarm as Custom Attribute it override the "normal" alarm notifications - addAlarm() function return correctly but somehow the alarms set by this function get "deleted" before DB storage.

So for my case I just change a little bit the 66 register inside protocol decoder as FMC003 don't have any Battery Level alarm:

        register(57, fmbXXX, (p, b) -> p.set("hybridBatteryLevel", b.readByte()));
        //register(66, null, (p, b) -> p.set(Position.KEY_POWER, b.readUnsignedShort() * 0.001));
        register(66, null, (p, b) -> {
            // 1) Read and save power voltage
            double power = b.readUnsignedShort() * 0.001;
             p.set(Position.KEY_POWER, power);

            // 2) Ignition read on IO 11 - already on position
            Boolean ignObj = p.getBoolean(Position.KEY_IGNITION);
            boolean ignition = ignObj != null && ignObj;

            // 3) "motion": read on IO 24
             boolean moving = p.getSpeed() > 0;

            // 4) Logical
            if (power < 12.2 && (!ignition || !moving)) {
                p.addAlarm(Position.ALARM_LOW_BATTERY);
            }
        });
        register(67, null, (p, b) -> p.set(Position.KEY_BATTERY, b.readUnsignedShort() * 0.001));

Thanks

Cheers

Good to hear. There are quite a few attributes that still need to be mapped in the decoder, and the FT series of trackers are in the middle of being released as well, so the decoder will need a bunch of work soon even just for that.

The FT series slightly tweak the attribute IDs for some of the Teltonika parameters and add some new features.

Just wondering will the FMC003 make its way into a future release ?

Name it an FMC130 in the model field, it will work fine.

You'll just need to create Custom Attributes for the OBD elements if you want those.

Great Thanks I shall give that a shot :-)

Note that 6.11 now fixes model recognition.

Future changes will be needed for more attributes to be automatically computed (use custom attributes for now), and the pending release of the new FT series hardware will also require that the regular expression includes matching of the new "FT" prefix, as well as the following changes as noted by Teltonika:

https://wiki.teltonika-gps.com/view/AVL_ID_differences_between_FMB_and_FT_platforms

Hi Kaldek,

Do you know if with 6.11 the custom attributes (as alarm) still "clear/override" all the alarm's returned by the addAlarm() in protocol?

Thanks

Cheers

If you write it in a way that it clears the value, then yes.

I was writting like this:

Attribute: Alarm

power < 12.2 && (!ignition || !motion) ? "lowBattery" : null

It works well - but even when this condition in not true the rest of the alarms set by addAlarm() in protocol didn't work.

Any suggestions to improve te condition?

Something like this:

power < 12.2 && (!ignition || !motion) ? "lowBattery" : (alarm ? alarm : null)

It works as long as the condition is FALSE — good!
But it doesn’t work when it’s TRUE: no matter which alarm I set using addAlarm() in the protocol, the "batteryLow" alarm still appears at the top.
I’ve tried setting the priority of this custom attribute to 20, and I’ve also marked both "Tow" and "Power Cut" alarms as “Priority” in the Extra dropdown (inside Notifications menu), but without success.

Any suggestion?
Maybe anyway to turn the custom attribute alarm as "not persistent"?

You're way deeper than me. We have lots of plans to modify the code but are super busy so we've just done everything in Custom Attributes and using priorities.

For example we have some of the pre-release FTC models, so we need to map io800 to power. We map io800 to power, multiplying it by 0.001 as a high priority, then we have the alarm for low power as a lower priority:

power ? (power < 10 ? "lowPower" : null) : null

When the next position record arrives and the power attribute is greater than 10 volts, the alarm self clears.