Our devices have flexible integration options to suit a variety of requirements. You control the device data and where it goes. All of these methods are discussed here: Choosing an Integration Strategy
For most options, devices send data to DM's OEM Server - which handles firmware updates, parameter (settings) updates + templates, and debugging. It is the preferred method for the majority of our partners. However the direct to 3rd party integration method comes with the benefit that there are no ongoing monthly fees.
TABLE OF CONTENTS
Set Up - Unlock the Device
For a device to be used in the direct mode, the device must be first 'unlocked'. The need for an unlock is a legacy feature. Prior to July 2020, we charged an unlock fee which has since been dropped - to provide disruptive pricing and the best value for our partners. But the unlock still remains.
To unlock a device, simply select the device(s) to be unlocked in the OEM Server device grid, and then select
Device Operations -> Set Config Only
The following dialogue box will appear:
Make sure Config Only is ticked, and click OK.
You can tell a device has been unlocked by the following:
- The orange 'cloud/server' icon
- The connector column will say <config only>
While the device is unlocked, a connector (for sending data via OEM to the end server using TCP or HTTP) cannot be set. The device can only send data directly to the server set in the next steps. To go back to using a connector (i.e. one of the other integration methods) - just repeat the process but make sure Config Only is unchecked.
Entering your server details
The below Admin Parameter tab needs to be added. This is done by again selecting the device, Parameters -> Edit Admin Parameters. For more detailed steps on this see OEM Server - Getting Started
Unlock your device first
If your device is not unlocked, this parameter tab is simply ignored. So unlock your device first!
So we enter:
- Non OEM Server - the DNS or IP of your server.
- Non OEM Server TCP Port - your port
- OEM Connection Period (days) - how often the device will reconnect back to OEM for firmware or param updates - see the next sections.
- The other parameters should be left on defaults, unless we want to manage the parameters directly from our server. Encryption should not be enabled unless we know what we are doing, and have contacted DM about implementing the protocol on the end server side.
When in the direct mode, we still retain access to log in to OEM server and use the UI. There is still no monthly fee. So we can easily have the device send data directly to our server, and reconnect daily, weekly etc for updates. In general, once we have deployed, these updates should be rare. So it generally does not make sense to go through the effort setting up management of parameters from a 3rd party server, which is complex.
So this leaves our ways to manage parameters as:
- Use the OEM UI, and have the device check in either
- Periodically (as set in the parameters above)
- On command by sending it an SMS - #*,OEM - see SMS Commands
- On command by sending an async message (downlink) from the end server - see the integration documents (DM Support can supply if you don't have these)
- On command by setting the correct flag in your hello response (very likely less effort than iii)
- Via the OEM WebAPI - and the same check in periods above. We can make a call to the API to set a parameter template, and then either wait for the device to check in or use ii, iii or iv to prompt it.
- Directly from your end server - as detailed in the integration documents - more complex and should only be done if there are specific requirements needing this.
Firmware updates can only be managed via 2 methods:
- Via the OEM server - the device must connect back to OEM, it can't be handled from a 3rd party server
- Via our Wired Provisioning Tool - but this requires physical access to the device, and the tool will only update to the latest FW version bundled with the tool (not always the latest available in OEM).