Thanks for the update Brent. My attempts with DeviceLink date back 1+ year so I don't have any recent conclusions or findings on the matter. At the time we had looked at the available (outdated) documentation about the migration plan (Geotab 9-10-11), confirmed the Drive app was still relying on TrailerAttachment internally and had not yet transitioned to DeviceLink, and decided to defer further testing until we had more guidance. Great news if an updated plan is coming for integrators.

Certainly a new plan will be coming soon and this new API has not been forgotten. Not all products were ready to fully switch over from vehicles/trailers and TrailerAttachment to an asset-centric approach using DeviceLink in time for the plan that may have been shared previously.

Apologies for the silence on this topic, but we are getting close to releasing the API documentation like I mentioned, and ensuring that we properly dog-food this API in our product to ensure that it works as expected for everyone. I'll make sure to share the documentation link here once it's ready to go.

We'll work on a deprecation plan for TrailerAttachment after it is no longer is use by any native Geotab products, and our partners have had the chance to try out the DeviceLink API and provide any feedback that may come up with early adopters. I'll make sure this is not abrupt or done without notice to our partners.

@JPurv-1275​ and I work on the same team so I can answer on his behalf - the only real problem that we had during our limited testing was that DeviceLinks don't seem to affect the actual attachment of trailers or otherwise be reflected in the Drive App, and their relationship to TrailerAttachments is only one-way (i.e., creating a TrailerAttachment will create a corresponding DeviceLink that describes the same attachment instance, but creating a DeviceLink will not create a TrailerAttachment). Otherwise, the API seems to work well. Documentation would be very nice to have, but DeviceLink and its corresponding objects (like DeviceLinkSearch) have been included in the MyGeotab NuGet SDK for some time now, so we've been able to examine them and infer how they're intended to be used.

+1 to @LPPapillon-1145​'s main point in his original reply on this topic. We have a lot of integrations that rely on the TrailerAttachments API, so we'll be interested in knowing when DeviceLinks become a usable alternative as early as possible. The shorter that transition timeframe is, the more pressure it will put on us to drop other work and focus on upgrading existing integrations to avoid production-impacting issues.

The update is greatly appreciated!

Hi @DarenPorter-1148​, thanks for the additional context! You're right that using the DeviceLink API does not add TrailerAttachments as well, so backwards compatibility is not easily achieved with this set-up. It is likely when you tested that we had not yet started using DeviceLinks in MyGeotab or Drive to determine trailer attachments, so switching the APIs would not have the same effect through the rest of the product.

This is a really good point, and one that I will bring up to our dev team next week for further discussion to ensure that when the documentation is released this is already set up in our product such that if integrators migrate early to the DeviceLink API that it will work throughout the entire product and not only in some areas. I'll get back to you once I learn more on our end.

I'll make sure you and other integrators have as much time as possible to migrate existing integrations away from TrailerAttachments, and once we have a better idea on timeline we'll let you know, but we won't be sharing a timeline until after the DeviceLink documentation is shared and available to everyone to use successfully, and that is our next step for now.