Issue with custom and this week trip reports
It is probably because of the fast reports option. You can change the threshold in the config.
What would be the recommended threshold to receive the same level of accuracy as today's or yesterday's reports?
Have you read about the configuration parameter? If fast reports don't work for you, you have to set the threshold high enough that they don't get triggered. So it depends on what reports period you're planning to use.
Yes I did. I even checked couple of posts where the fast reports were mentioned. The comments were sketchy at best so those didn't seem to be related. Anyway, I tested and I confirm the issue is due to the default report.fastThreshold.
Aside from that - the fast reports don't seem to work very well right now. I mean, it works but the information is highly inaccurate.
Have you tried optimizing the report speed by adding more indexes in the database for example?
It has nothing to do with database indexes. We already have indexes. It's just limitations on how much data you can process. And that's why fast reports use pre-process data (events in this case). The accuracy depends on your specific use case.
Yes, I know there are indexes and I was asking whether you've already tired to improve those or the current state is the best that can be achieved.
As to the events, I can see now that the fast reports use the device moving and device stopped events to generate the reports which is definitely a better option as compared to checking the positions table.
Do you know why the device moving/stopped events don't accurately represent the actual start/stops? Is there anything preventing to implement the same logic as in the trip reports to those two events?
We already implement the same logic, but there are limitations:
- We cannot account for gaps in data, so the gap configuration is not applied
- Your device has to report the data in the correct order for it to be processed correctly
If we assume the devices report data chronologically (something that can be configured with good quality devices), is the data gap the only holdback that is preventing from accurately tracking the trips start/stop?
That would mean we will be only missing a device stop event every now and then, correct?
However, in the logs that I pulled, the trip start, i.e. device moving is also incorrect, either not recorded as event or a few minutes behind.
I'll look into the code after your feedback, there should be something that can be done to improve the fast reports.
Instead of guessing you can look at the data and see why it's not working correctly.
I did look at the data points, the device moving event has incorrect timing, if recorded at all. If the moving event is supposed to mirror the trips report then the logic probably breaks somewhere. I will need to check the code for that.
You don't need to check the code. You need to check the data.
The Trip Reports when selecting a "custom period" or "this week" appear to have some sort of issue - neither the trip start/end dates are correct, neither the trips themselves.
Selecting "today" or "yesterday" seems to work correctly, see images below.
I have compared against the route report and the data points with speed and motion correctly reflect the trips shown in the "today" or "yesterday" duration. The custom report and this week report appear to show the same wrong information.
Today Report
Yesterday Report
Excel files for analysis:
Trips and Route Exports