Hi, thank you for your patience — I followed up with our team and wanted to share what they confirmed. I've consolidated their detailed answer here so it's easier to work through, but let me know if you'd like more depth on any part. ### Heartbeat behavior For a GO9 operating in normal Sleep Mode, the firmware documentation describes the following behavior: - When the vehicle ignition is turned off, the device enters Sleep Mode. - The device sends a heartbeat approximately every 30 minutes for the first 72 hours. - After 72 hours, the heartbeat interval changes to approximately every 23 hours. (<a href="http://support.geotab.com" target="_blank">support.geotab.com</a> (<a href="https://support.geotab.com/en-GB/go-devices/installation/doc/firmware" target="_blank">https:&#x2F;&#x2F;support.geotab.com&#x2F;en-GB&#x2F;go-devices&#x2F;installation&#x2F;doc&#x2F;firmware</a>)) This behavior should be understood as the normal GO9 Sleep Mode behavior. Other conditions can affect the heartbeat cycle, including Low Power Mode, device-disabled mode, low-voltage conditions, device family, and firmware version. For example, Low Power Mode is separately documented as reducing heartbeats to every 23 hours. (<a href="http://support.geotab.com" target="_blank">support.geotab.com</a> (<a href="https://support.geotab.com/help/mygeotab/device-management/device-statuses-and-settings/device-modes" target="_blank">https:&#x2F;&#x2F;support.geotab.com&#x2F;help&#x2F;mygeotab&#x2F;device-management&#x2F;device-statuses-and-settings&#x2F;device-modes</a>)) ### 1. When does isDeviceCommunicating become false? isDeviceCommunicating is not determined by checking whether a heartbeat arrived at one exact scheduled time. For a standard GO device, the current MyGeotab server logic evaluates the timestamp of the latest available status, GPS, or fault data: - If the last stored state is driving, the server uses an approximately 10-minute communication threshold. - If the last stored state is stopped, the server uses an approximately 24-hour communication threshold. Accordingly, if a device has entered the 23-hour heartbeat cycle and then loses power, the server does not simply wait for one specific expected heartbeat and immediately mark the device offline. It evaluates whether the latest received data has exceeded the applicable server-side communication threshold. The value can therefore be understood as an elapsed-time assessment from the latest qualifying data. The result may become visible when the next API request, UI refresh, or server health evaluation occurs. The public device-status guidance describes an hourly health-check evaluation, so the observed transition can occur somewhat after the nominal threshold—for a standard GO device, approximately 24 hours after the last qualifying data, plus the evaluation delay. (<a href="http://support.geotab.com" target="_blank">support.geotab.com</a> (<a href="https://support.geotab.com/community/sdk-api/sdk-api-other-general/2540/how-long-does-geotab-s-cloud-infrastructure-logic-behind-the-heartbeat-data-element-waits-before-sending-a-disconnected-status-message-via-api-for-go09-devices-without-backup-battery" target="_blank">https:&#x2F;&#x2F;support.geotab.com&#x2F;community&#x2F;sdk-api&#x2F;sdk-api-other-general&#x2F;2540&#x2F;how-long-does-geotab-s-cloud-infrastructure-logic-behind-the-heartbeat-data-element-waits-before-sending-a-disconnected-status-message-via-api-for-go09-devices-without-backup-battery</a>)) The server-side property also uses the latest status&#x2F;GPS&#x2F;fault timestamp; it is not limited to a dedicated heartbeat record. Other device families and configurations may use different thresholds, so the exact result depends on the device model, firmware, and enabled modes. ### 2. How is “stationary” defined? There are two related concepts to distinguish. For platform trip and stop recognition, MyGeotab documents a stop as occurring when: - the ignition is turned off; or - the vehicle remains below approximately 1 km&#x2F;h for more than 200 seconds. Stops shorter than 200 seconds while the ignition remains on—for example, waiting at a traffic light—are not recorded as stops in trip history. (<a href="http://support.geotab.com" target="_blank">support.geotab.com</a> (<a href="https://support.geotab.com/help/mygeotab/reports/safety-reports/idling-time" target="_blank">https:&#x2F;&#x2F;support.geotab.com&#x2F;help&#x2F;mygeotab&#x2F;reports&#x2F;safety-reports&#x2F;idling-time</a>)) This explains the 200-second behavior mentioned in the discussion. However, it should not automatically be interpreted as the complete firmware rule for every heartbeat mode. For the GO9 heartbeat schedule specifically, the firmware documentation describes the transition into Sleep Mode in terms of the ignition being turned off. The device may determine ignition using engine data, a three-wire ignition connection, or trip-tracking&#x2F;two-wire logic. Depending on the vehicle and installation, this can involve RPM, road speed, voltage changes, or accelerometer-based movement detection. (<a href="http://support.geotab.com" target="_blank">support.geotab.com</a> (<a href="https://support.geotab.com/en-GB/go-devices/installation/doc/firmware" target="_blank">https:&#x2F;&#x2F;support.geotab.com&#x2F;en-GB&#x2F;go-devices&#x2F;installation&#x2F;doc&#x2F;firmware</a>)) Therefore, “stationary” should not be interpreted as GPS position simply remaining unchanged. ### 3. What resets the 72-hour stationary period? The firmware release notes document a fix to restore the normal 30-minute heartbeat period after the device enters the 23-hour heartbeat cycle and a subsequent ignition-off event occurs. (<a href="http://support.geotab.com" target="_blank">support.geotab.com</a> (<a href="https://support.geotab.com/es-ES/go-devices/installation/doc/firmware-notes" target="_blank">https:&#x2F;&#x2F;support.geotab.com&#x2F;es-ES&#x2F;go-devices&#x2F;installation&#x2F;doc&#x2F;firmware-notes</a>)) Based on that documentation, if the vehicle is stationary for more than 72 hours, the ignition is turned on, and the vehicle is then turned off again, the device is expected to restart the normal heartbeat sequence after the new ignition-off event— approximately 30-minute heartbeats for the first 72 hours, assuming normal Sleep Mode and firmware that includes this behavior. A READY-state transition by itself is less certain. Whether READY is treated as an ignition event depends on the vehicle's signals and the device's ignition-detection method. A READY transition that is not recognized as an ignition-state change should not be assumed to reset the heartbeat cycle. Similarly, Low Power Mode or other special device modes may override the normal Sleep Mode behavior. ### Summary For a standard GO9 in normal Sleep Mode: - The 30-minute heartbeat period applies for the first 72 hours after entering Sleep Mode. - The heartbeat then changes to approximately every 23 hours. - isDeviceCommunicating is a separate server-side assessment based on the age of the latest qualifying device data and the device's stored driving&#x2F;stopped state. - A missed heartbeat does not necessarily cause an immediate disconnect indication at the exact expected heartbeat time. - A subsequent recognized ignition cycle is expected to restart the normal heartbeat sequence, while a READY-only transition requires device- and vehicle-specific confirmation. To confirm the behavior for a particular vehicle, we would need the device model, serial-number prefix, firmware version, ignition-detection method, and whether Low Power Mode, High Frequency Update, or another special mode is enabled. Feel free to reach out if you have any other questions. We are here to help. Have a great day! Eishi FUN

Clarification on heartbeat intervals and isDeviceCommunicating behavior

Hi Geotab Community,I'm integrating with the MyGeotab API using JSON-RPC over HTTP POST to:https://my.geotab.com/apiv1​I would like to know the server-side timeout for MyGeotab API requests.Specifically, does MyGeotab terminate API requests after a fixed amount of time on the server side, API gateway, or backend?For example, if I call methods such as:AuthenticateGet for DeviceGet for LogRecordGet for StatusDatais there a documented maximum request processing time before the server returns an error or closes the connection?I checked the MyGeotab API documentation, but I could not find a clear statement about the server-side timeout value for /apiv1.Any official reference or guidance would be appreciated.Thanks!

What is the server-side timeout for MyGeotab API (/apiv1) requests?

Hello,We are developing a system that periodically retrieves vehicle data using the MyGeotab API (mainlyLogRecordandStatusData).To design our data collection and polling strategy properly, we would like to understand how frequently these data points are generated by GO devices and stored in the Geotab database.Specifically, we would like to know the trigger conditions and typical update frequency/interval for the following data:LogRecord.LatitudeLogRecord.LongitudeLogRecord.SpeedIsDeviceCommunicatingIsDrivingDiagnosticPositionValidId / DiagnosticPositionValidAtDeviceIdDiagnosticBatteryVoltageIdDiagnosticIgnitionIdDiagnosticRawOdometerIdDiagnosticStateOfChargeId (Code: 2118)DiagnosticParkingBrakeIdDiagnosticElectricVehicleChargingStateIdDiagnosticOnBoardChargerAcInputVoltageId (Code: 3290)aFGR6Q9guoUeiaAZI1fD6oQ (Code: 2659)DiagnosticOutsideTemperatureIdaCiOQmMpe702NzD3cVCx4oA (Code: 3255)az2JRiedliES6bw7pEe_UZg (Code: 3256)anZTfpLFXgUq_iOB1Q-S9oA (Code: 3268)aiC3laRAhVEOzOSvicbN9og (Code: 3254)For example, we are trying to understand things like:Are these diagnostics reported periodically (e.g., every few seconds/minutes), or only when the value changes?Are they triggered by specific events (e.g., ignition change, distance traveled, charging state change, etc.)?Are there documented intervals or thresholds for when GO devices send these values to the server?If there is documentation that describes the recording logic or reporting frequency for these diagnostics, we would greatly appreciate being pointed to it.Thank you in advance for your help.

What are the trigger conditions and reporting frequency for LogRecord and EV diagnostics (SOC, charging state, etc.) in MyGeotab?

Hello,I have a question about how EV SOC (State of Charge) data is reported by the GO device.As I understand it, SOC data is typically recorded and sent when the value changes (for example, when SOC changes by about 1%).I am concerned about the following scenario:The device temporarily loses cellular connectivity.During this offline period, the SOC changes (for example due to driving or charging).However, the device cannot send the data because there is no connectivity.Later, the cellular connection is restored.In this situation, will the GO device send the SOC changes that occurred during the offline period once the connection is restored?Also, if the SOC happens to return to the same value as before the connectivity loss (for example, charging and then driving back to the same percentage), is it possible that no new SOC record will be sent?In that case, it seems that MyGeotab might continue to show the old SOC value from before the connectivity loss, even though the actual SOC may have changed during that time.Could you please clarify how SOC reporting works in this situation?Thank you very much.

MyGeotab EV SOC reporting behavior after temporary connectivity loss

Hello Geotab Community,We are currently working on real-time device health monitoring for EV vehicles using the MyGeotab API.Our goal is to detect device failures immediately (for example, if the GO device is unplugged or stops communicating), even when the vehicle is stationary for a long period of time at a charging station.We are reviewing the following properties from the DeviceStatusInfo entity:isDeviceCommunicatingisDrivingWe would like to understand:Can isDeviceCommunicating be reliably used as a real-time heartbeat indicator?Under what conditions would isDeviceCommunicating return false for a device that is actually healthy (for example, EV sleep mode)?What is the recommended best practice for distinguishing between:A device that is offline due to failureA device that is simply not transmitting because the vehicle is stationary or sleeping?We are especially interested in EV use cases where vehicles may remain parked and inactive for extended periods.Any guidance or recommended monitoring approach would be greatly appreciated.Thank you in advance.

Using DeviceStatusInfo for Real-Time Device Health Monitoring in EVs

Hi Geotab Community,I'd like to confirm the maximum number of assets (devices/vehicles) that can be registered in a single MyGeotab database.Is there a hard system limit (technical maximum) for the number of assets/devices per database?Are there any licensing/subscription limits that vary by plan/contract?Where can I check the limit for my own account/contract (e.g., in MyGeotab or in an official document)?Any official references or guidance would be appreciated. Thank you!

Maximum number of assets/devices per single MyGeotab database?

page-user page-user-大地-三浦-2136 template-account-profile page-status-200 theme-harmony user-guest

Company

Title

Hello, I would like to clarify how GO device heartbeat reporting and the <code>isDeviceCommunicating</code> property work. My current understanding is as follows:<ul><li>While the vehicle is driving, the device communicates regularly.</li><li>For the first 72 hours after the vehicle becomes stationary, a heartbeat is sent approximately every 30 minutes.</li><li>After the vehicle has been stationary for more than 72 hours, a heartbeat is sent approximately every 23 hours.</li><li>The Geotab server uses data received from the device to determine whether <code>isDeviceCommunicating</code> should be <code>true</code> or <code>false</code>.</li><li> </li></ul>Could you please confirm whether this understanding is correct and clarify the following points? <h3>1. When does <code>isDeviceCommunicating</code> become <code>false</code>?</h3>If the device stops communicating, how does the server determine when to change <code>isDeviceCommunicating</code> to <code>false</code>? For example, after the heartbeat interval has changed to 23 hours, is it determined as follows?<ul><li>The server changes the value to <code>false</code> when 23 hours have passed since the last heartbeat was received.</li></ul>Or:<ul><li>The server expects a heartbeat at a specific scheduled time and changes the value to <code>false</code> when the expected heartbeat is not received.</li></ul>In other words, if the device loses power, is the disconnection detected a fixed amount of time after the last communication, or can the detection time vary depending on the heartbeat schedule or server-side evaluation timing? <h3>2. How is “stationary” defined?</h3>What exactly starts the 72-hour stationary period? For example, is the vehicle considered stationary based on:<ul><li>vehicle speed becoming zero,</li><li>GPS position no longer changing,</li><li>ignition being turned off,</li><li>or another condition?</li><li> </li></ul><h3>3. What resets the 72-hour stationary period?</h3>If the vehicle does not move but the ignition or READY state is turned on and then off, is the 72-hour stationary timer reset? For example, if the vehicle remains in the same location for more than 72 hours but its power is turned on briefly during that period, will the heartbeat interval remain at 23 hours, or will it return to the 30-minute interval? Understanding these details is important for us when investigating communication failures and interpreting the <code>isDeviceCommunicating</code> value correctly. Thank you in advance for your help.

Thank you for the detailed explanation and for putting the sources together. I understand that there is no publicly documented server-side timeout value for standard /apiv1 requests, and that the 300-second value is a client-side timeout in the Python SDK. I also understand that GetFeed is the exception where a 180-second per-request timeout is documented, and that for LogRecord and StatusData, we should design around result size limits and OverLimitException rather than relying on a specific timeout value. Thank you again for your support.

Hi Geotab Community,I'm integrating with the MyGeotab API using JSON-RPC over HTTP POST to:https://my.geotab.com/apiv1​I would like to know the server-side timeout for MyGeotab API requests.Specifically, does MyGeotab terminate API requests after a fixed amount of time on the server side, API gateway, or backend?For example, if I call methods such as:<ul><li>Authenticate</li><li>Get for Device</li><li>Get for LogRecord</li><li>Get for StatusData</li></ul>is there a documented maximum request processing time before the server returns an error or closes the connection?I checked the MyGeotab API documentation, but I could not find a clear statement about the server-side timeout value for /apiv1.Any official reference or guidance would be appreciated.Thanks!

Hello,We are developing a system that periodically retrieves vehicle data using the MyGeotab API (mainlyLogRecordandStatusData).To design our data collection and polling strategy properly, we would like to understand how frequently these data points are generated by GO devices and stored in the Geotab database.Specifically, we would like to know the trigger conditions and typical update frequency/interval for the following data:<ul><li>LogRecord.Latitude</li><li>LogRecord.Longitude</li><li>LogRecord.Speed</li><li>IsDeviceCommunicating</li><li>IsDriving</li><li>DiagnosticPositionValidId / DiagnosticPositionValidAtDeviceId</li><li>DiagnosticBatteryVoltageId</li><li>DiagnosticIgnitionId</li><li>DiagnosticRawOdometerId</li><li>DiagnosticStateOfChargeId (Code: 2118)</li><li>DiagnosticParkingBrakeId</li><li>DiagnosticElectricVehicleChargingStateId</li><li>DiagnosticOnBoardChargerAcInputVoltageId (Code: 3290)</li><li>aFGR6Q9guoUeiaAZI1fD6oQ (Code: 2659)</li><li>DiagnosticOutsideTemperatureId</li><li>aCiOQmMpe702NzD3cVCx4oA (Code: 3255)</li><li>az2JRiedliES6bw7pEe_UZg (Code: 3256)</li><li>anZTfpLFXgUq_iOB1Q-S9oA (Code: 3268)</li><li>aiC3laRAhVEOzOSvicbN9og (Code: 3254)</li></ul>For example, we are trying to understand things like:<ul><li>Are these diagnostics reported periodically (e.g., every few seconds/minutes), or only when the value changes?</li><li>Are they triggered by specific events (e.g., ignition change, distance traveled, charging state change, etc.)?</li><li>Are there documented intervals or thresholds for when GO devices send these values to the server?</li></ul>If there is documentation that describes the recording logic or reporting frequency for these diagnostics, we would greatly appreciate being pointed to it.Thank you in advance for your help.

Hello,I have a question about how EV SOC (State of Charge) data is reported by the GO device.As I understand it, SOC data is typically recorded and sent when the value changes (for example, when SOC changes by about 1%).I am concerned about the following scenario:<ol><li>The device temporarily loses cellular connectivity.</li><li>During this offline period, the SOC changes (for example due to driving or charging).</li><li>However, the device cannot send the data because there is no connectivity.</li><li>Later, the cellular connection is restored.</li></ol>In this situation, will the GO device send the SOC changes that occurred during the offline period once the connection is restored?Also, if the SOC happens to return to the same value as before the connectivity loss (for example, charging and then driving back to the same percentage), is it possible that no new SOC record will be sent?In that case, it seems that MyGeotab might continue to show the old SOC value from before the connectivity loss, even though the actual SOC may have changed during that time.Could you please clarify how SOC reporting works in this situation?Thank you very much.

Hello Geotab Community,We are currently working on real-time device health monitoring for EV vehicles using the MyGeotab API.Our goal is to detect device failures immediately (for example, if the GO device is unplugged or stops communicating), even when the vehicle is stationary for a long period of time at a charging station.We are reviewing the following properties from the DeviceStatusInfo entity:<ul><li>isDeviceCommunicating</li><li>isDriving</li></ul>We would like to understand:<ol><li>Can isDeviceCommunicating be reliably used as a real-time heartbeat indicator?</li><li>Under what conditions would isDeviceCommunicating return false for a device that is actually healthy (for example, EV sleep mode)?</li><li>What is the recommended best practice for distinguishing between:</li></ol><ul><ul><li>A device that is offline due to failure</li><li>A device that is simply not transmitting because the vehicle is stationary or sleeping?</li></ul></ul>We are especially interested in EV use cases where vehicles may remain parked and inactive for extended periods.Any guidance or recommended monitoring approach would be greatly appreciated.Thank you in advance.

Thanks for sharing that — it's really helpful to hear a real-world reference. Knowing there's a database out there with 20,000+ vehicles (active and archived) running without issues is reassuring. Appreciate it!

Hi Eishi, Thank you for your reply and for clarifying this. That's very helpful, and it's good to know there's no practical limit I need to worry about for typical fleet sizes.Thanks again, and I appreciate your support.

Hi Geotab Community,I'd like to confirm the maximum number of assets (devices/vehicles) that can be registered in a single MyGeotab database.<ul><li>Is there a hard system limit (technical maximum) for the number of assets/devices per database?</li><li>Are there any licensing/subscription limits that vary by plan/contract?</li><li>Where can I check the limit for my own account/contract (e.g., in MyGeotab or in an official document)?</li></ul>Any official references or guidance would be appreciated. Thank you!

近期活動

Clarification on heartbeat intervals and isDeviceCommunicating behavior

What is the server-side timeout for MyGeotab API (/apiv1) requests?

What are the trigger conditions and reporting frequency for LogRecord and EV diagnostics (SOC, charging state, etc.) in MyGeotab?