Referencing a Computed Attribute in another Computed Attribue (and use of copyAttributes settings)

OK, so I have a new use case where we want to alarm on Teltonika io381 value being 1. This is a very simple example, and does not factor in the main computed attribute we have for customised alarm handling. We're just assessing logic here so I'll keep things simple. Here's the basic parameter assessment logic which will trigger the SOS alarm:

(io381 != null && io381 == 1) ? "sos" : null

We have another Computed Attribute which we use for monitoring the state of the vehicle Immobiliser. To ensure the state is in every record, we use the following setting in our traccar.xml:

<entry key='processing.copyAttributes'>Immobiliser</entry>

This computed attribute and its state in every position record works very well. However, what we want to do is only trigger that SOS alarm when the value of our Immobiliser attribute is a specific string value and the io381 parameter equals 1, for example:

(io381 != null && io381 == 1 && Immobiliser == "Vehicle Disabled") ? "sos" : null

I note that earlier requests for similar functionality appeared not possible, but what impact would the following have on the request:

<entry key='processing.computedAttributes.lastAttributes'>true</entry>

Or even using the priority field for computed attributes?

I will add that the error we see is that it says the Immobiliser attribute is undefined.

Attribute copying happens after computed attribute processing, so you can't rely on it. What you can do is use last value from the computed attributes. Once you enable it, you should use lastImmobiliser value.

Thanks Anton. For a custom attribute named Immobiliser, what would the correct "last" version of that be?

lastImmobiliser? Or will this bork because it's already capitalised.

Evaluate if Immobiliser exists, if yes use it, if no use last.

Good idea, laserman.

OK, the basic assessment works:

(io381 != null && io381 == 1 && lastImmobiliser == "Vehicle Disabled") ? "sos" : null

Now to add the handling as recommended by the Laserman (heh) and add it to our existing custom alarm handler computed attribute