A dead zone, a thunderstorm or an unexpected disturbance and promptly a phone call breaks off or a streamed video falters. Everyone knows it, everyone has experienced it. Sometimes a simple change of position is enough, sometimes you have to wait until a storm passes or a malfunction is repaired. It also happens that you have to restart your device.
But how does a rapidM2M module behave in the event of a fault and how can it be reacted to in the Device Logic (DLO)?
There are different modes of how a rapidM2M module establishes connections. Depending on the mode, the rapidM2M behaves slightly differently. Interval, Wakeup or Online – go to the general overview of modes here.
Retry mechanisms in Interval mode
The modem is only switched on when necessary and then attempts to establish a connection. If complete synchronisation with the server cannot take place, the modem is deactivated and a new attempt is started after 2 minutes. After the 3rd unsuccessful attempt, it is aborted. At the next interval, the system tries again to establish a new connection. The counter is only reset after a successful synchronisation.
Retrymechanismen im Modus Wakeup
The modem is permanently switched on and only connects at intervals or when a wake-up SMS is received. Here, too, 3 attempts are made during a connection in order to complete synchronisation with the server. During the attempts, the modem waits again for 2 minutes and is deactivated during this time and thus restarted each time. At the next interval, the system tries again to establish a new connection. The counter is only reset after a successful synchronisation.
Retry Mechanisms in Online Mode
The modem is permanently switched on and maintains a data connection to the server. If this connection breaks unexpectedly, an attempt is immediately made to establish a new connection. Here, too, 3 attempts are started at an interval of 2 minutes. If this does not work, the modem is deactivated and no new attempt is started.
Recognise and respond in the DLO
The Device Logic (DLO) has some functions available for this purpose:
- With rM2M_TxSetMode the connection mode can be set.
- A connection to the server can be initiated with rM2M_TxStart.
- The current status can be queried with rM2M_TxGetStatus.
For a smooth process, the status should be queried cyclically and reacted to if necessary.
| Status | Meaning |
| RM2M_TX_STARTED | an attempt is being made to establish a connection to the server |
| RM2M_TX_ACTIVE | a connection to the server is currently active (e.g. during a synchronisation in Interval mode or constantly in Online mode) |
| RM2M_TX_WAKEUPABLE | the Wakeup mode is active and the device can be woken up by a text message |
| RM2M_TX_RETRY | The rapidM2M is currently between 2 attempts to establish a connection to the server. |
| RM2M_TX_FAILED | means a connection could not be established despite several attempts |
After an rM2M_TxStart, the RM2M_TX_ACTIVE flag is activated first and the DLO knows that the rapidM2M has understood the command correctly. If the flag RM2M_TX_RETRY is received, the DLO does not have to react yet, because the rapidM2M starts a reconnection automatically. Only when the RM2M_TX_FAILED flag is detected should the DLO react accordingly.
How should the DLO best conduct itself?
In interval operation, a connection failure is usually not a big problem, as the relevant data remains stored on the rapidM2M anyway and is thus only synchronised to the server with a time delay. Of course, a new connection can still be established in a timely manner.
In online operation, a failure usually poses greater problems. The control values may not reach the device or the settings may not be accepted. Here, depending on the urgency, it is recommended to already react to the RM2M_TX_RETRY, but at least to RM2M_TX_FAILED and to trigger a reconnection.
