How to handle zero value positions in lastLocation() (or in OutdatedHandler)?
We already load the last saved position from the database when the device connects, so getLastLocation() is not limited to the current session.
Your log suggests the initial 0x0200 report contains zero coordinates, which then become the last known location. Have you tried enabling filter.zero?
The problem here is that the devices are designed such that, if Wi-Fi networks are detected but there is no previous GPS location data after a reboot, the location is sent as a "zero location" in addition to the Wi-Fi data. However, it is important that the Wi-Fi data be forwarded, so I cannot simply filter out all zero locations.
Would it be possible that, with "zero location" in the incoming data, the system always retrieves the last valid non-zero location instead of just the most recent ones, which could also be zero?
That would effectively mean that no zero locations would ever be saved, except perhaps during the very first connection between the device and the server when there is no record at all in the database. Does that make sense to you?
-- Cheers, Nils
Note:
There is a corresponding test case:
verifyDecode(decoder, binary(
"7e0210000704546000231900884f2606180229579c7e"),
position(Checks.ATTRIBUTES).attribute(Position.KEY_BATTERY_LEVEL, 79));
If this is changed to this one (not limited to Checks.ATTRIBUTES), it fails:
verifyDecode(decoder, binary(
"7e0210000704546000231900884f2606180229579c7e"),
position().attribute(Position.KEY_BATTERY_LEVEL, 79));
-- Cheers, Nils
You can try using coordinates filter.
Is there something like filter.skipLimit for coordinates.filter ? With coordinates.filter I already run into the problem that a device started with zero locations and never left that position.
If not, would it make sense to submit a pull request for settings like coordinates.filter.skipLimit and/or coordinates.filter.skipAttributes?
No, it doesn't make sense. What would that parameter do? Something like zero filter would make more sense.
With coordinates.filter.skipLimit I had in mind that coordinates are not replaced by last position if last position is older than XYZ. This would avoid devices to be freezed at some location when using coordinates filter. Do I confuse things maybe?
Yeah, what you're saying doesn't really make any sense. If you have newer valid position, Traccar will already use it.
Does lastLocation only use the last VALID location?
No. It uses the latest cached position, even if valid=false or its coordinates are zero.
So, would it make sense to have a setting that tells the coordinates.filter and/or lastLocation to only use the last VALID location?
Well, I think it might make sense. But I don't think it solves your problem.
Let's see. For now, I have solved the problem partially on the receiving frontend system. It does not update location data if coordinates are zero, but uses other data like battery level for updating records. This at least solves my initial problem, but fills the Traccar DB with a lot of invalid positions. An alternative could be a conditional "filter but forward" option, so I could use the additional information like battery level but do not fill up the Traccar DB with invalid positions. Not sure ... just thinking out loud to get feedback and better ideas.
Dear Traccar Friends.
I have devices that send zero value location data upon registration and then they continue with hibernation battery reports to let the server know about battery level while the device is stationary.
My problem is that the JT808 decoder handler for these Hypernation Battery Reports (0x0210) in the JT808 decoder uses
lastLocation(). If there hasn't been a valid location in the current session yet, all locations are initially set to zero.I’m now considering whether it would be a valid option for the handler for 0x0102 (registration) to check the database (Storage) to retrieve the last position from the database, so to speak. However, this would require modifying the OutdatedHandler, as far as I could see, which is no longer specific to the JT808 protocol.
I'd appreciate any advice before I open a PR for a change.
-- Cheers, Nils