Skip to content

Troubleshooting⚓︎

This page contains common problems and possible solutions. If a problem you encountered is not listed, contact INVERS Support.

Missing heartbeats⚓︎

There are several reasons why the CloudBoxx may no longer send Heartbeats:

Loose wiring or connectors / no power supply / antenna disconnected⚓︎

If the wiring or connectors are loose or disconnected, the antenna has been disconnected, or if there is no power supply anymore, e.g. because the battery is dead or the wiring connectors have been disconnected, it is not possible to connect to the CloudBoxx anymore and all API calls will fail. Therefore, you have to investigate the vehicle locally to check if there are any issues with the connections or the battery.

No network coverage⚓︎

The vehicle is located in a dead spot, underground parking, or another area without cellular connectivity. In this case, it is not possible to access the vehicle via the API or FleetControl. If you want to make sure that the user always has access to the car, please use the Bluetooth functionality of the CloudBoxx.

Suspended SIM cards⚓︎

SIM cards may be suspended if there is excessive number of API calls or events. There is a daily data limit for data usage and fallback commands. If the data limit of the SIM card is exceeded, the SIM card is blocked by the provider to avoid high costs for the data connection. So usually, the SIM card is only blocked if an error occurred. We will be notified about blocked SIM cards and will try to solve the issue to reactivate them. The API calls are usually initiated by the customers backend, so make sure to check your software and workflows as well.

Possible reasons for too many events⚓︎

Key fob and RFID Tag Events are usually caused by interruptions to the key RFID signal. This may have the following reasons:

  1. The key fob has not been pushed far enough into the slot or the key fob is just lying in the glove compartment. In these cases, the reader may still read the RFID signal from time to time which will then generate a key fob or RFID tag read event.

  2. The car uses a keyless entry and go system. The keys for these systems usually send out RFID signals themselves. If these keys use the same frequency or if the RFID signal is very strong, it can interfere with the RFID reader and cause the creation of events.

  3. The RFID signal of the key- or card-holder may be interrupted by the vehicle electronics. In this case, the RFID reader frequently and erroneously recognizes an insertion or removal and creates an event.

Reconnection of the SIM⚓︎

There may be certain cases where the CloudBoxx is not responsive for ten to twenty minutes, which results in a single missing heartbeat. This may happen when:

  1. The car is driving through a dead spot or there is no network coverage for a certain provider.

  2. The SIM triggered an automatic network scan which may also lead to a network switch because there is a better network available. As a part of anti aging, this scan is triggered every 23 hours.

In both cases, the SIM card and the CloudBoxx will ensure that the SIM card reconnects to a different network. In certain cases, this process can take up to twenty minutes. The CloudBoxx will not respond to any API calls nor send events or heartbeats during this time.

CloudBoxx is unresponsive⚓︎

If there is no response from the CloudBoxx, the vehicle is either in a dead zone, the battery of the car may be empty, or the SIM may be blocked. Please make sure in advance that the vehicle is not just standing in a dead spot, such as an underground parking garage.

Usually, you can already identify the cause by checking the status of the CloudBoxx in FleetControl. Open the device’s Inspect screen and check the 24h monitor on the bottom of the screen.

If there are no heartbeats, the CloudBoxx may be in a dead spot, the battery may be empty, or something else may not be working.

If there are a lot of events or API calls, i.e., several thousands in a short time span, it is likely that the SIM has been blocked because of the high data traffic.

You can also check the status of the SIM under Telematic Status. If the SIM is blocked, you should check if there are any issues and resolve them before reactivating it. If you run into any trouble, please contact the CloudBoxx support. The reactivation may only work permanently if all issues have been fixed.

Checking the latest events of the CloudBoxx can also be very helpful for identifying the cause a problem, such as the battery being low. By clicking on an event in the Log Entries, additional information will be shown.

Loss of connection⚓︎

If a CloudBoxx loses its connection completely and can no longer be reached in Fleet Control, please perform the following test:

  1. If possible, check the LEDs of the CloudBoxx before doing any resets or reboots and provide a short video. The red and green LEDs are especially important.

    1. Are they blinking?

    2. Are they blinking fast, circa every second, or slow, circa every five seconds?

  2. If only the cellular connection fails but the Bluetooth module still works, try the following steps.

    1. Connect to the CloudBoxx via the Bluetooth analyzer app and check its status.

    2. Perform a modem test in the menu in the upper right corner of the app.

    3. Take screenshots of all the information and test results.

    4. Once everything is documented, reset the modem, check the modem status again, and take a screenshot of the results.

    5. If the modem reset did not fix the issue, initiate a complete board reset. Check and document the status of the CloudBoxx again afterwards.

  3. Ensure that the wires of the CloudBoxx are still properly connected to the wires of the car.

  4. Send us the screen shots with as much information as possible. Include the serial number of the CloudBoxx as well as the car manufacturer, model, and year of manufacture.

Mileage loss⚓︎

For the VSS, GPS Position, GPS Speed, and CAN Speed option as mileage source, the total mileage is updated during the ignition on/off and immobilizer lock/unlock events.

So, if there is an unexpected reboot during the trip or a firmware update, the last driven distance since one of the previously mentioned events is lost. Because of this, automatic updates are only executed if the immobilizer is locked and the car is not in use.

If CAN mileage is used as the mileage source, the CloudBoxxes can be restarted or updated anytime.

GPS Position outdated⚓︎

General behavior of the GPS Module:⚓︎

The CloudBoxx will only update its GPS position if the following conditions are met:

  1. The immobilizer is unlocked

  2. One of the following is recognized

    1. Ignition changed

    2. CAN bus activity

    3. Bluetooth connection

If only the immobilizer is unlocked but none of the bottom criteria are met, the CloudBoxx will deactivate the GPS module after one minute to save power.

The CloudBoxx is woken up every 30 minutes to update the GPS position. After a reboot, the CloudBoxx will also update the GPS position once the reboot has been completed. So, if the CloudBoxx does not update the GPS position, either the immobilizer is locked or the CloudBoxx did not recognize any additional activity and put the GPS module into standby mode. It is also possible that there is simply no GPS signal available at the current location.

GPS Position outdated Indicator:⚓︎

This notification simply informs you that the GPS position is not up-to-date and may have changed. The GPS Position is updated every 30 minutes in standby mode, after a (re-)boot of the CloudBoxx, or frequently if the immobilizer is unlocked and the CloudBoxx is not in standby mode.

If an event is created that includes the position, the CloudBoxx will always send the last known GPS position. So, this position may be outdated if the CloudBoxx is in standby or the CloudBoxx does not have GPS reception. This is indicated below the map for the event.

If the time stamp of the last GPS update and the time stamp of the event are within one minute, the system considers the GPS position as up-to date. If the time stamps have a difference between one and five minutes, the system displays a notification stating that the position may be outdated. If the time stamps have a difference of more than five minutes, the system displays a notification stating that the position is outdated.

Immobilizer locked without apparent reason⚓︎

If the CloudBoxx is used with CAN files and there is an error in the file system, the device will sometimes format the file system on its own. During this process all CDF files are deleted. If the car uses an immobilizer that is realized via a starter interruption relay, this relay is deactivated during stopovers to reduce power consumption. Stopovers are recognized when the immobilizer is unlocked but the vehicle displays no activity for one minute. In this case, the immobilizer will be active but the vehicle cannot be started. The status in the events and status requests always shows the code line relay status, which is independent from the status during stopovers. In this case, the status will still be shown as unlocked. In this state, the CloudBoxx is not able to identify the IGNITION_ON event because of the missing CDFs. Therefore, it will not unlock the starter interruption relay. This status can only be changed by sending another UNLOCK_IMMOBILIZER command. Alternatively, a Bluetooth connection to the CloudBoxx also stops the stopover state. In order to solve this issue, the CDFs have to be reinstalled on the CloudBoxx.

We are already working on a fail-safe file system so that the CDFs will not be deleted anymore. Please note that this has not been implemented yet, so the CDFs have to be restored manually.

As a temporary solution, we will monitor the status of the CloudBoxxes so that we are able to restore the CDFs files manually if the CloudBoxx formatted itself.

Central lock status incorrect⚓︎

Central lock status via CAN bus⚓︎

The reason for this issue is that the CloudBoxx gets no feedback from the car whether the doors have actually been locked. So, the CloudBoxx only relies on the last executed command. If the vehicle is open and you send a LOCK_CENTRAL_LOCK command to the CloudBoxx, the central lock status of the CloudBoxx will change from unlocked to locked. However, if the door was still open and therefore the CloudBoxx was unable to lock it, the device cannot recognize this.

The same would happen if you open the door with the CloudBoxx and press the central lock button inside the car. The central lock status of the CloudBoxx would show unlocked even thought the doors of the car were manually locked.

We have also experienced that the CAN information about the central lock status is not very reliable for some cars. Some cars only updated the door status on the CAN bus several minutes after the central lock was changed which can negatively influence workflows.

Therefore, we suggest you do not set up workflows based on the CAN information of the central lock status and use the central_lock_last_command instead.

Vehicle does not respond to central lock commands⚓︎

If a vehicle is unresponsive when sending central lock commands, please check that it has not been locked with a remote key. The remote key has a higher priority than the internal central locking system of the car which the CloudBoxx accesses. Therefore, the car has to be unlocked via the remote key before the CloudBoxx will be able to lock and unlock the car again.

Please note that some cars may also lock the doors automatically after a certain time if the car has not been locked by the CloudBoxx or a remote key. In this case, the priority of the automatic lock mechanism is often the same as if the car was locked with the remote key.

So if you run into any troubles with central locking system, please verify that your customer did not use the remote key before closing the doors and that the central lock has not been closed with a spare key. Additionally, if the car uses an auto-lock feature which causes the issue, you can try to deactivate it via your car dealer.

If you cannot resolve the issue, we also offer a wireless key adapter, LoMo, that can be used to trigger the remote key instead of accessing the internal central locking of the car. If you want to use a LoMo, you would have to provide us with one remote key for each car. We will then remove the PCB inside the key and connect it to the LoMo. Afterwards you have to disconnect the wiring for the central lock, Pin 10 and 11 on the CloudBoxx, and connect the LoMo instead. Finally, use SmartControl to lock the central lock. The CloudBoxx will then open and close the car via the remote key.

Smartcard not read by card reader⚓︎

If the CloudBoxx has detected a multi card reader, the card reader firmware version is always shown in the system status in the API. The firmware version will be shown as long as the MCR is still connected and the communication between the CloudBoxx and the MCR is still working.

In order to narrow down the issue, provide the following information:

  1. Is it still possible to read smart cards?

  2. How do the MCR LEDs react if you hold a smart card in front of it?

  3. Do you receive SMART_CARD_READ events? The MCR will send a hardware signal to the CloudBoxx if a RFID card or tag has been read. The CloudBoxx will request the UUID of the RFID card from the card reader and the yellow LED of the MCR will start blinking. So, if the hardware signal does not reach the CloudBoxx, either because it is not sent or not recognized, there can be no communication between the CloudBoxx and the card reader. In this case the firmware version may still be shown in the system status.

  4. Request the system status via the API with GET /system-status. Is the card reader version shown in the response? If the MCR version is included in GET /system-status or the MCR LEDs’ status is included in GET /status, communication with the MCR was successful.

  5. If you send a PUT /status including the LED parameters, is the status code response from the API 200 for OK, 400 for bad request, or 500 for internal error? If the communication with the MCR was unsuccessful, you will always receive an error 500 response. If the CloudBoxx determined that no MCR is connected, you will receive an error 400 response.

  6. Does a software reset via the API solve the issue?

  7. Perform a hardware reset by disconnecting the power supply from the CloudBoxx. Does this solve the issue?

CAN data not read⚓︎

If no CAN data is read, check for the following three criteria:

  1. Is the CAN data even available for the car model you are using?

  2. Are there even CAN files installed?

  3. Check the configuration in FleetControl. Is the mileage and the ignition source set to CAN?

Alternating fuel level values⚓︎

Jumping or alternating fuel level values cannot be avoided completely. While manufacturers usually use algorithms that filter and smooth the fuel data before displaying it in the vehicle’s dashboard, the CloudBoxx uses the sensor data and reports it during events. This data can deviate. Depending on the fuel level sensor used by the car manufacturer, these deviations can have higher or lower margins of error.

The alternating fuel level values can also be a result of the orientation of the car or its acceleration which causes the fuel to move inside the fuel tank. So, during trip the fuel level can differ by up to 15% or more. You will usually not notice this effect since there are no events during a trip. However, if the status is requested frequently during a trip the fuel level will most like oscillate a lot.

Fuel level stuck at 100%⚓︎

A lot of cars show the fuel level at 100% even if the car was already driven for a distance of 50-100 kilometers. This is caused by the 100% threshold being lower that the actual tank size. For example, if the car has a tank size of 50 liters and the 100% threshold is already reached at 45 liters, the fuel level value will stay at 100% and only start to decrease once the fuel level drops below 45 liters.