The OEM Server Getting Started briefly discusses the difference between Since Connected and Since Committed, as viewed in the device grid. If everything is working as normal, these times will line up. 

Connections, Uploads, Firmware & Parameter Updates.

For context, it is useful to know how a typical data upload is handled. 

1. The device decides that it needs to upload (setting dependant, and will be due to things such as input changes, movement, or simply on a timed basis e.g. daily heartbeat)
2. The device connects to the network and OEM - on connecting to OEM, it will send a "Hello Message" - with some basic information (Serial, device type, firmware version etc).
   This is what OEM considers 'connected' and at this point "Since Connected" is set as "Now"
3. The end server responds back to the device with a "Hello Response"
4. The device uploads (commits) data
5. The end server responds back saying it succesfully received all records, with a "Commit Response"
   This is what OEM considers 'committed', at this point "Since Committed" is set to "Now"
6. The device sends a "Version Message" - which tells OEM what it's current FW and parameters are set to. 
7. OEM sends back new parameters and FW if they have been set to update. 

The OEM Device Grid

The OEM device grid colours the columns green, yellow or red, purely based on the time. Simply to highlight potential issues (devices not connecting in for a while) at a glance. 

• Less than 1 day will be green
• 1-2 days will be yellow
• 2 or more days will be red. 

In the above example we can see the first 2 devices are connecting and committing OK. This means that the device is connecting in to OEM (step 2 above), data is being forwarded on to the end platform (i.e. Telematics Guru or a 3rd party platform), and this platform is responding back with the commit response (point 5 above). 

For the 3rd device in the list, this is not the case. 

Devices connecting but not committing + troubleshooting

Given 1-7 above, devices can appear as connecting in OEM, but not committing, due to us reaching step 2 (OEM receives the Hello Message) in the above process, but then something going wrong before we reach step 5 (The end server sending a commit response). This can be due to the following reasons, listed in order of most to least common/likely. 

1. Server Issue (95% of cases)

In general, this is a server issue. Most of the time because the device data is being forwarded to the end platform (TG or another system), but the device isn't actually configured there. For TG users, make sure an asset is created with the right device serial, and enabled - since if not enabled, TG will reject the device. The same scenario will apply to 3rd party platforms in most cases. 

In the case that we are integrating devices into a 3rd party system, there are perhaps errors in parsing the data, sending the right responses, or even the setup of the Connector. We have the following debugging tools available:

• View Server Logs
• View Live Server Logs in the Debug Terminal

These tools will show us the responses from the end server, and any errors. E.g. if we are using the HTTP connector, we will see 200 OK responses (if successful) - or other standard HTTP codes if not. I.e. 401 might indicate we the connector setup has an issue and the correct authorisation details aren't being sent to the end server. 

2. Connectivity Issue

If we are in marginal cellular coverage, we may see issues with committing data. The Hello Message is only the very first part of the connection, and only a few bytes of data. So if the device connects in, and sends the hello message, OEM will mark it as connected. Then should the connection drop before the full upload completes, it will not show as committed. Typically in this scenario, the Server Logs will show "Socket Disposed" in the logs. 

3. Device issue

If the device is in good coverage but struggling to commit, it may be a device issue - this is rare however. 

Troubleshooting

To troubleshoot, we can simply eliminate each issue, in the order above.

1. Determine if the issue affects a handful, or many/all of our devices
   1. If many, perhaps we have an issue with the end server (it is down, not responding etc) - we can check in the Server Logs.
   2. If it is one, check the device is correctly set up in the end platform. 
2. If our device is correctly set up in the end platform and other devices can connect in OK, check the server logs to see the issue. If we see "Socket Disposed" there is a good chance we have a connectivity or device issue. 
3. If our asset is mobile, it is perhaps easiest to just monitor the device in OEM - if it moves to a better coverage area, it will connect in.
4. If we are certain we are in good coverage, we would need to retrieve the device for assessment.

Firmware/Parameter Updates when not committing

As firmware and parameter updates are handled after the device receives a commit response - if it can't successfully commit, firmware and parameter updates won't be applied. 

Set the Connector to "None"

If we have no connector set in OEM, the device will upload data to OEM, which will discard it, and then send the commit response back to the device. So provided we don't have a connectivity/device issue - we can clear the connector if we want to get FW/params through quickly. Note we will lose any data saved on the device.