To take measures in the middle of nowhere and to transmit them to a server, the simplest solution is usually to use a low-power 4G network such as LTE-M or NB-IoT to send them periodically to a server. For example, you could use a YoctoHub-GSM-4G configured to perform HTTP callbacks to a PHP server using VirtualHub for Web. But what if one day the hub stops connecting to the server?
The causes of this kind of problems can be diverse:
- a problem with the power source: faulty battery, dirty solar panel...
- failure due to condensation or oxidation on the electronics
- loss of IP connectivity due to a change in the 4G network
- unintentional change of hub configuration
- a bug that causes callbacks to stop for one reason or another
In the first two cases, the only solution is to intervene on site to bring the device back into service. But for the last three cases, having recovery mechanisms that can diagnose and restart data transmission remotely can sometimes avoid a trip of several hundred kilometers...
Automatic restart
The first method, which has been available for a long time, consists of configuring the YoctoHub-GSM-4G to allow a maximum delay before attempting to establish a network connection to the server. There are two possible scenarios:
- If the hub is to remain permanently powered up between callbacks, we'll settle for a hot restart when the connection to the server can't be established after a specified delay. The delay is configured in the Outgoing callbacks section (Network downtime to reboot).
- If the hub is configured to go into deep sleep after each callback to the server, a Maximum power-on duration must be set in the Wake-up scheduler section to ensure that the hub is switched off in all cases, even if the server cannot be reached, so that it can restart after a cold reboot on the next scheduled wake-up.
Configuration windows for automatic restart
Don't try to combine the two solutions: if the hub reboots before shutting down, it also restarts its deep sleep countdown at start-up, and will never go to sleep!
SMS commands
The new feature in this week's YoctoHub-GSM-4G, which you can obtain by installing firmware 55707, is the ability to send control SMS messages to your hub. This way, if your hub can no longer connect to your server, but can still reach a GSM network, you'll have a chance of getting it back.
Security
For security reasons, only SMS messages from a pre-configured number are taken into account. All others only produce a log message and are automatically deleted. This new setting can be found in the Incoming connections section of the configuration:
The new SMS control setting
Clicking on the edit button opens a configuration and test window:
SMS control configuration interface
This window includes a button for sending a test message to the chosen number, which is doubly interesting. On the one hand, it lets you check that the SIM card supports sending SMS - not always the case with IoT packages. Secondly, it's the easiest way to find out your hub's phone number, as the hub itself has no way of informing you of it: in the vast majority of cases, the number is not stored on the SIM card, and the 4G standard has no command for requesting it from the operator.
With this test message, you can simply reply to the message on your phone with one of the commands below to check that your hub is receiving your messages.
Recognized messages
SMS control only allows the following important operations. Here are the recognized commands:
Ping simply asks the hub to confirm the reception of the message by SMS. If the hub is configured to wake up periodically, it replies when it next wakes up - SMS messages are not received during deep sleep. This lets you know whether the hub is still alive and able to connect to the cellular network.
Trig asks the hub to trigger an HTTP callback as soon as possible. In the event that you have set a too long interval between callbacks to allow callbacks, or programmed a sleep time too soon to allow the hub to callback, this may enable you to regain control of your hub.
Dump xxx.bin asks the hub to dump its current state into the xxx.bin file on flash memory, for further investigation. In cases where the hub is no longer able to establish IP connectivity and you need to reboot it or even intervene on site, this dump will eventually enable Yoctopuce support to diagnose the cause of the problem.
Reset restarts the hub.
Load filename.json asks the hub to reload all its configuration in one go from the local filename.json file. To use this function, you must of course first have created this configuration backup file on the hub, using the button available on this same window, or using the get_allSettings function in the Yoctopuce library, for example. You can then switch your hub to a predefined backup configuration in the event of a problem.
Note that if you need to remotely change your hub's callback configuration or cell configuration, the safest way is to
- predefine the new configuration on another hub, so you can test it beforehand
- then upload the configuration file to the remote hub using the file manager (manage files function on VirtualHub for Web)
- then activate the new configuration in one go with the SMS command Load myconfig.json
Indeed, if you try to change this kind of parameter directly via the VirtualHub (for Web) interface, the hub may cut the callback as soon as the first setting is changed, and not complete the reconfiguration. Using the Load command ensures that all settings are applied in one go.
SMS and IoT portals
As mentioned above, some IoT SIMs do not offer direct SMS access to public cellular networks. However, it may be possible to send and receive SMS messages using the IoT SIM provider's web portal, which ultimately offers the same possibilities for using SMS control. Ask your IoT operator for details specific to your SIM.
If you're not sure which portal sender number to authorize in your YoctoHub-GSM-4G's configuration interface, simply give it a try by authorizing a "random" number. When the portal sends your first ping SMS, you'll see in the YoctoHub logs the phone number from which the "rejected" message originated.
