When are computed attributes executed?

Can anyone tell whether the computed attributes are executed before or after ProtocolDecoder?

Here's an example: in TeltonikaProtocolDecoder.java we have the following code:

register(30, fmbXXX, (p, b) -> p.set("faultCount", b.readUnsignedByte()));

What this code does is to read io30 key, rename it to faultCount and save it in the positions table as faultCount. The oi30 key is not recorded in the database.

If I need to run a computed attribute for io30, should I run it like:
io30 ? io30 : null
or should I run it as:
faultCount ? faultCount: null

After obviously.

Then the teltonika protocol needs correction, I will create a request on Github.

Why does it require correction?

It's incomplete on several levels creating issues, especially if we need to compute custom attributes:

For example:

register(252, fmbXXX, (p, b) -> {
            p.set(Position.KEY_ALARM, b.readUnsignedByte() > 0 ? Position.ALARM_POWER_CUT : null);
        });

io252 can have values 0 meaning powerRestored and 1 meaning powerCut.

The code above rewrites the io252 to alarm only if the value is 1 and skips it entirely if the value is 0.
So we are missing the powerRestored alarms and which is worse, we cannot use the computed attributes to capture the event because it's has been already rewritten...as you just confirmed.

Further to that, the fmbxxx list of devices is incomplete and some of the keys like 81, 82, 83, 84, 85, 87, 89, 90 are only valid if there is CAN adapter used in combination with the FMBXXX device.

Reference: https://wiki.teltonika-gps.com/view/FMB003_Teltonika_Data_Sending_Parameters_ID

io247, i.e. the accident IO can have values from 1 to 8 and the protocol only decodes it as alarm: accident

This commit should be reverted entirely or all of it corrected:
https://github.com/traccar/traccar/commit/cd1ce7c3e89d12f59339ccd2676d7c2bfc1596cf

It adds the LV CAN elements which are only available if using an additional CAN reader, i.e. the standalone FMBXXX devices report that data with different IOs.

And the 4 alarm edits are all messed up.

OK, feel free to send PRs.

I will thanks.

Question, if we decode a given IO as alarm, does it log an alarm event in the same way as with computed attributes?

Fix applied with new PR.

When editing protocols, especially a complex and confusing protocols like Teltonika, people should try to refrain from making changes that only suit their particular use case.

Based on my experience with hundreds of Teltonika devices, the decoder can be definitely improved but even I am reluctant to commit changes that might end in messing up the incoming data for everyone else.