Am 12.02.21 um 23:12 schrieb Michael Balzer:
So your vehicle essentially was "off" all the time, which lets me think the location module could have picked the persistent coordinates as the park coordinates on boot. I'll have a look at that tomorrow.
It did, and that's perfectly OK that way. What might be missing there is a check for an undefined "on" status: if a vehicle cannot tell driving from parking, there is no point in checking for position changes while parking. Now it would be simple to skip the theft/flatbed check if v.e.on is undefined, but I've done a quick check on the vehicle modules: in many cases the flag won't be set to false on module init (boot), which would mean the theft alert will be disabled after each reboot, for example from an OTA update, as "v.e.on" remains undefined until the vehicle gets awake. IOW, not testing if v.e.on is undefined is the safe option currently. (Btw, some vehicle modules apparently also won't clear the flag when the code misses the switch-off CAN frame or if the polled bus goes offline.) We could add setting v.e.on to false to all vehicles. To keep a persistent "on" value, it should be done like this: if (!StdMetrics.ms_v_env_on->AsBool()) StdMetrics.ms_v_env_on->SetValue(false); …but I hesitate changing logic in vehicle modules just to catch the case of a vehicle not being able to determine the "on" state. I suggest all vehicle developers check their v.e.on logic before we change this. So that explains how you got the theft alert from the persistent coordinates change when you had no v.e.on support. As you now have that support, your new alert isn't explained by this. Did you find some hint in your "L" log on that case? Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26