LTE connecté, mais SMS en échec : diagnostiquer les alertes et commandes d’un routeur industriel
Le routeur peut joindre un serveur, mais la demande d’état envoyée par SMS depuis votre téléphone reste sans réponse. Ou l’appareil reçoit des messages, alors que ses alertes n’arrivent jamais. Dans les deux cas, une connexion LTE ne prouve pas que les SMS fonctionnent.
Testez séparément la réception, l’envoi, le traitement de la commande et le résultat de l’action pour localiser la panne. Une connexion de données opérationnelle ne répond qu’à la question de la connectivité de données. Les SMS dépendent aussi du forfait SIM, du réseau de l’opérateur actuellement utilisé, du module cellulaire et de la configuration logicielle du routeur. La documentation SMS de Cradlepoint exige un module compatible avec les SMS et une fonction SMS activée. Elle précise que les opérateurs ne garantissent pas la livraison des messages ni des réponses.
Les étapes suivantes concernent les SMS envoyés et reçus par la SIM du routeur. Si une plateforme cloud transmet les alertes via un prestataire SMS, vérifiez plutôt l’événement de la plateforme, la demande d’envoi et l’accusé du prestataire. Ce parcours diffère du service SMS propre à l’appareil.
D’abord, identifier l’étape pour laquelle il manque une preuve
Après l’envoi d’une commande depuis un téléphone, le message doit atteindre l’appareil, puis passer les contrôles d’autorisation et l’analyse de la commande. L’appareil peut alors agir et répondre selon sa configuration. Suivez cet ordre pour ramener « aucune réponse » à une étape précise.
Observation | Ce qui est confirmé à ce stade | Prochain point à vérifier |
|---|---|---|
LTE est connecté, mais le SMS de test est introuvable sur l’appareil | La connexion de données fonctionne ; la réception SMS reste à confirmer | Prise en charge par le forfait et en itinérance, service de réception, module et journaux des messages entrants |
Un message entrant est enregistré, mais la commande n’est pas exécutée | Le message a atteint une étape visible du traitement entrant | Expéditeurs autorisés, authentification, format de commande et journaux de traitement |
L’appareil reçoit des SMS, mais un test direct d’envoi échoue | La réception fonctionne ; le parcours sortant présente encore un problème | Autorisation d’envoi, numéro destinataire, réponse du module et restrictions de l’opérateur |
Un SMS ordinaire peut être envoyé, mais pas une alerte | Le parcours d’envoi de base fonctionne | Présence de l’événement, activation de la règle et exactitude du destinataire |
L’action a eu lieu, mais le téléphone n’a reçu aucune réponse | L’action et la réponse ont des résultats différents | Configuration de la réponse, journal de son envoi et réception sur le téléphone |
Un message introuvable peut simplement ne pas être affiché dans l’interface actuelle. Avant de conclure à un échec de réception, vérifiez les journaux disponibles, la conservation du texte d’origine et la suppression éventuelle des SMS de commande après traitement.
Étape 1 : vérifier l’ensemble SIM, réseau et appareil
Notez le modèle du routeur, celui du module cellulaire, les versions des firmwares du routeur et du module, la SIM active, l’opérateur d’origine, l’opérateur desservant réellement l’appareil et le statut d’itinérance. Sur un appareil double SIM, confirmez quelle carte est utilisée pour le test.
Posez des questions précises à l’opérateur : cette SIM permet-elle de recevoir et d’envoyer des SMS ? Ce service est-il pris en charge sur le réseau d’itinérance actuel ? Existe-t-il des restrictions liées aux numéros, au forfait ou à la compatibilité de l’appareil ? Transmettez les mêmes informations au fabricant pour confirmer la prise en charge des SMS par cette combinaison module et firmware sur ce réseau. L’examen de l’enregistrement auprès de l’IP Multimedia Subsystem (IMS) ou de la configuration opérateur doit découler de ces éléments ; ne reprenez pas sans vérification les paramètres d’un autre appareil.
Si la SIM reçoit des SMS dans un téléphone, cela confirme seulement son fonctionnement dans ce téléphone et dans les conditions réseau du test. Un problème côté routeur reste possible. Un témoignage d’itinérance concernant le Quectel EG25-G décrit un symptôme similaire. Son suivi est essentiel : l’auteur indique que les SMS avaient refonctionné avant l’installation du nouveau firmware, sans que la cause initiale soit établie. Ce témoignage ne démontre donc pas qu’une mise à jour a corrigé la panne.
Si la connexion de données échoue aussi, vérifiez d’abord la connectivité de base avec le guide de diagnostic et de réparation des routeurs industriels, puis reprenez les tests SMS.
Étape 2 : tester la réception et l’envoi avec des SMS ordinaires
Commencez par un texte court qui ne déclenche aucune action, par exemple TEST-001. Assurez-vous qu’il ne correspond à aucune règle d’automatisation existante et que le téléphone l’envoie bien sous forme de SMS. Notez l’heure, le fuseau horaire et le numéro expéditeur, puis recherchez le message sur l’appareil.
Envoyez d’abord du téléphone vers l’appareil et consultez le journal de réception ou la boîte de réception. Utilisez ensuite une méthode prise en charge par la documentation de l’appareil pour envoyer un SMS ordinaire au téléphone de test. Consignez séparément les deux essais. « L’appareil l’a reçu » ne prouve pas qu’il peut aussi envoyer. Pour le test sortant, conservez le statut ou l’erreur renvoyé par l’appareil et vérifiez l’arrivée réelle sur le téléphone. L’acceptation d’une demande d’envoi ne prouve pas la livraison au destinataire.
En cas d’échec de réception, vérifiez l’activation de la réception SMS, le module ou l’interface sélectionné et l’état du stockage des messages. Par exemple, le manuel SMS de MikroTik RouterOS décrit les paramètres de réception, le choix du port, le blocage de la réception lorsque le stockage est plein et l’encodage SMS pris en charge. Ce sont des exemples de points à examiner, pas des réglages ni des valeurs par défaut communs à toutes les marques. Conservez les traces utiles au diagnostic avant de vider le stockage.
Une fois le texte court validé, testez les caractères chinois, les messages longs ou les caractères spéciaux présents dans l’alerte réelle. Vous distinguerez ainsi les problèmes de base d’envoi et de réception des problèmes de format. Consultez la documentation actuelle de l’appareil pour l’encodage et la prise en charge des messages multiparties.
Étape 3 : vérifier l’autorisation, l’analyse et l’action réelle
Après validation des SMS ordinaires dans les deux sens, testez une demande d’état en lecture seule explicitement documentée. Vérifiez le numéro expéditeur autorisé, notamment l’indicatif pays et le format effectivement reconnu par l’appareil. Vérifiez les informations d’authentification, la casse, les espaces et la syntaxe. Ne supprimez ni les restrictions d’expéditeur ni l’authentification pour faire fonctionner un test.
Examinez ensuite trois résultats distincts : la commande a-t-elle été acceptée, l’action a-t-elle réussi et la réponse est-elle arrivée ? Si des journaux de traitement existent, rattachez ces trois résultats au même essai. Si l’appareil ne fournit pas ces éléments, indiquez « non confirmé côté appareil » au lieu de noter un succès.
Testez les redémarrages, les changements de réseau et les autres commandes modifiant l’état pendant une fenêtre de maintenance, avec un moyen préparé pour rétablir la connexion du site. Notez l’état réel avant et après la commande. Sans réponse, vérifiez si l’action a déjà eu lieu avant de décider de réessayer. Des commandes répétées de redémarrage peuvent interrompre à nouveau un appareil déjà rétabli.
Pour les alertes SMS, testez séparément la règle de déclenchement. Utilisez une fonction de test prise en charge ou une condition contrôlée pour suivre « événement présent → règle correspondante → envoi demandé → message reçu ». Un envoi manuel réussi ne valide qu’une partie de cette chaîne.
Étape 4 : tester les coupures que les SMS peuvent couvrir
Si les SMS doivent servir au rétablissement à distance, testez la panne qu’ils sont censés couvrir. La documentation Cradlepoint décrit un accès SMS pouvant rester disponible sans connexion de données active. Cela ne signifie pas que les SMS couvrent toutes les causes de déconnexion.
Avec une personne en mesure de rétablir la liaison du site, consignez le comportement SMS en fonctionnement normal, pendant une interruption contrôlée de la connexion de données et après un redémarrage. Les SMS dépendent toujours de l’alimentation, du module cellulaire et d’un service opérateur disponible. Ils peuvent partager ces points de défaillance avec les données. Un test d’interruption des données ne remplace pas un dispositif de rétablissement en cas de coupure électrique ou de panne du module.
Pour chaque essai, consignez au minimum l’ensemble appareil et firmware, la SIM et le réseau, le contenu de test, les preuves de réception et d’envoi, le résultat de l’action et celui de la réponse. Reprenez les tests concernés après un changement de SIM, de réseau d’itinérance ou de firmware pertinent.
Terminez par un constat permettant à la personne suivante de poursuivre : « Réception validée ; envoi en échec avec l’erreur suivante » ou « Les SMS ordinaires fonctionnent dans les deux sens ; la règle d’alerte ne s’est pas déclenchée ». Transmettez au support ce parcours en échec avec les informations sur l’appareil, la SIM et le réseau. La prochaine étape devient plus claire.
Questions fréquentes
Un routeur industriel connecté à Internet doit-il pouvoir envoyer des SMS ?
La connectivité de données seule ne permet pas de le conclure. Confirmez la prise en charge des SMS par le forfait et le réseau actuel, vérifiez la configuration du module et du routeur et testez séparément réception et envoi. Une connexion de données fonctionnelle ne remplace pas ces résultats.
Pourquoi le routeur reçoit-il des SMS sans pouvoir en envoyer ?
Envoyez indépendamment un message de test court et vérifiez le numéro destinataire, les autorisations d’envoi et le résultat renvoyé par l’appareil. Si un SMS ordinaire part mais pas l’alerte, examinez les conditions de déclenchement et la règle d’alerte plutôt que de poursuivre uniquement les vérifications de réception.
L’absence de réponse signifie-t-elle que la commande distante n’a pas été exécutée ?
Pas nécessairement. La commande peut avoir été exécutée alors que la réponse était désactivée, n’a pas été envoyée ou n’a pas été livrée. Confirmez l’action avec les journaux, l’état de fonctionnement ou une observation sur site. Ne renvoyez surtout pas plusieurs fois des commandes perturbant le service tant que l’état reste inconnu.
Une mise à jour du firmware peut-elle corriger une panne SMS ?
Les notes de version, l’analyse du fabricant ou une validation de la combinaison utilisée doivent justifier cette démarche. Conservez d’abord les traces de panne et la configuration existante, puis suivez la procédure prise en charge par le fabricant. Un témoignage indiquant que les SMS ont « refonctionné plus tard » ne prouve pas qu’une mise à jour en est la cause.
