DeviceStatusInfoSearch diagnostic fallback

HomeCommunitySDK/APIOther/GeneralDeviceStatusInfoSearch diagnostic fallback

DeviceStatusInfoSearch diagnostic fallback

Original Poster

When using the DeviceStatusInfoSearch for Diagnostics, it is possible to call the current value against DiagnosticOdometerAdjustmentId or DiagnosticEngineHoursAdjustmentId against every vehicle in a fleet, but unlike calling StatusData it doesn't appear to self-upgrade the response if ECM data is detected.

For example, using StatusData, if the deviceID has data in DiagnosticOdometerId, calculated from Raw Odometer + Adjustment + Offset, it will automatically provide DiagnosticOdometerId, not DiagnosticOdometerAdjustmentId

let nowISO = (new Date).toISOString()
 
api.call("Get", {
    "typeName": "StatusData",
    "search": {
        "deviceSearch": {
            "id":"b303"
        },
        "diagnosticSearch": {
            "id":"DiagnosticOdometerAdjustmentId"
        },
        fromDate: nowISO,
        toDate: nowISO
    }
}, function(result) {
    console.log("Done: ", result);
}, function(e) {
    console.error("Failed:", e);
});

But using DeviceStatusInfo and the diagnostics array with DiagnosticOdometerAdjustmentId will always include the DiagnosticOdometerAdjustmentId value regardless if the unit as data in DiagnosticOdometerId.

api.call("Get", {
    "typeName": "DeviceStatusInfo",
    "search": {
        "deviceSearch": {
            "id":"bB"
        },
        "Diagnostics": [{
            "id": "DiagnosticOdometerAdjustmentId"
        }]
    }
}, function(result) {
    console.log("Done: ", result);
}, function(e) {
    console.error("Failed:", e);
});

From what I can observe, StatusData always attempts to return the most accurate value source, whereas DeviceStatusInfo doesn't. Is this something I should make a Feedback submission for?

Join the conversation

You need to be logged in to reply to this post and participate in the Geotab Community discussions.

3 Replies

EishiFUN

Geotabber

Hello @AshleyFC-1448 ,

Thanks for bringing this u in our community. I wanted to tag in a couple developers who may know something they can share. If they are busy or unable to help I will see who I can find internally to take a look at this as well. @DarenPorter-1148 @LPPapillon-1145 @TuckerBA-1087

Have a good one!

Eishi FUN

DarenPorter-1148

I'm not 100% certain about the difference in diagnostic results for these calls, so take this with a grain of salt. But first a quick point of clarification.

The rough hierarchy of currency (and therefore "accuracy", but only kind of) of data for the diagnostics is DiagnosticRawOdometerId -> DiagnosticOdometerId -> DiagnosticOdometerAdjustmentId (this community post goes into a bit more detail about what each represents: https://community.geotab.com/s/question/0D52J00008pK4FuSAK). The Adjustment is notably the most current/accurate for a moving vehicle - it accounts for the ECM data, plus any UI adjustments, plus distance calculated from GPS since the last reading, and it can be interpolated. If I understand correctly, having the OdometerId returned to you instead of the AdjustmentId would be a less current/accurate reading in most cases.

That said, I am so far unable to reproduce what you are reporting here. I've run your first StatusData call against a handful of devices spread across multiple production databases, and for each one I get back a DiagnosticOdometerAdjustmentId, not a DiagnosticOdometerId. I wonder if it's possible that `nowISO` was close enough to the time of a DiagnosticOdometerId reading that there was no need to provide an Adjustment, so it just returned the lower-level reading to you.

AshleyFC-1448

Original Poster

Edited by AshleyFC-1448

@DarenPorter-1148 - I'm effectively doing exactly what the Asset/Inventory page currently does with StatusData. The nowISO variable creates the behaviour that occurs when the from date and to date are the same and it should pull the most current data for the requested metric.

From my testing, it seems that StatusData has some logic to pull the more accurate reading, from My Understanding DiagnosticOdometerAdjustmentId is the base odometer from any manual edit on the Asset page, and DiagnosticOdometerId is the calculated odometer value of any data in DiagnosticRawOdometerId + the device's odometer offset value, where an ECM Odometer has been detected and reporting. If there is no ECM Odometer, only the DiagnosticOdometerAdjustmentId value, which I can test with.

If you have any range between from date and to date, it will return just DiagnosticOdometerAdjustmentId.

It's just an interesting quirk that StatusData has this odometer and engine hours correction logic for the response, but the DeviceStatusInfo with a Diagnostic array does not include this logic, even though it's requesting the last reported asset data.

This is more of a question of why there is some return logic behind StatusData and not DeviceStatusInfo's Diagnostic array.

Still have questions?

Learn with Academy Browse documents