Transformer un simple SMS en commande domotique eedomus, même sans internet côté téléphone, c’est gagner un canal de contrôle rustique mais redoutablement pratique: un message court, une action claire, un accusé de réception, et un historique exploitable. L’enjeu n’est pas d’installer une option de plus, mais de bâtir une chaîne fiable de bout en bout: format de commande stable, périphériques explicitement autorisés, règles eedomus et macros cohérentes, et surtout un modèle de sécurité qui résiste à la perte d’un mobile ou à une usurpation de numéro. Ce guide se concentre sur le terrain: architecture, conventions de messages, tests, journal d’événements et dépannage pour piloter portail, chauffage ou éclairage sans dépendre d’une application.
- le pilotage par SMS eedomus est une fonctionnalité disponible mais réservée aux comptes eedomus Premium, et aucun périphérique n’est pilotable tant qu’il n’est pas autorisé
- le smartphone peut envoyer des SMS sans data, mais la box domotique doit conserver un accès internet complet car les SMS sont gérés par la plate-forme eedomus
- la syntaxe tolère majuscules, accents et caractères spéciaux, et une erreur renvoie une aide avec la syntaxe et les actions disponibles
- sécuriser passe par l’authentification via utilisateur enregistré, une whitelist de numéros, et des garde-fous pour les actions critiques
- la fiabilité se joue sur les accusés de réception, le journal d’événements, et des tests bout en bout avec scénarios de latence et d’échec
Pourquoi piloter eedomus par SMS et dans quels cas c’est utile
Le pilotage par SMS sur eedomus permet d’envoyer une commande courte depuis n’importe quel téléphone, puis de recevoir un retour: confirmation d’exécution, rappel de syntaxe en cas d’erreur, voire lecture d’un état si vous l’avez prévu via un périphérique eedomus ou une macro. C’est un canal minimaliste: pas d’interface graphique, pas de dépendance à une application, et une tolérance aux variations d’écriture puisque la reconnaissance ignore majuscules, accents et caractères spéciaux.
Son intérêt apparaît dans des situations où la data est fragile ou indisponible. La couverture SMS est souvent plus étendue que la 3g/4g: en zone rurale, un message peut passer quand l’application ne charge plus. À l’étranger, la data peut manquer ou coûter cher, alors que le SMS reste un filet de sécurité. Autre cas concret: des utilisateurs sans forfait data (enfants, personnes âgées) ou des accès ponctuels (voisin, locataire saisonnier) pour qui l’on veut éviter l’installation d’une application et la gestion d’un compte complexe.
Limites à garder en tête: un SMS n’est pas un canal chiffré de bout en bout, la latence peut varier selon l’opérateur, et le pilotage par SMS eedomus repose sur la plate-forme: la box domotique doit disposer d’un accès internet complet pour que cela fonctionne. Le « mode hors ligne » est donc surtout vrai côté téléphone: on peut piloter sans internet sur le mobile, mais pas si la box est coupée du cloud eedomus.
Pour aller plus loin que « allumer/éteindre », on s’appuie sur les règles eedomus, les macros et parfois un script via l’api eedomus pour transformer une commande courte en scénario robuste (temporisation, conditions, double action, retour d’état). Prérequis et architecture : box, passerelle SMS et réseau mobile
Prérequis et architecture : box, passerelle SMS et réseau mobile
Premier point de cadrage: le pilotage par SMS est annoncé comme disponible et il est réservé aux comptes eedomus Premium. Il ne nécessite pas d’ajouter une clé 3g à la box: les SMS sont gérés par la plate-forme eedomus. En pratique, l’architecture « native » est: SMS envoyé au numéro de notifications du compte, traitement côté cloud, puis exécution sur la box domotique via internet, et retour SMS.
Schéma logique du flux:
- utilisateur (numéro autorisé) → envoie un SMS (commande)
- numéro de notifications eedomus → plate-forme (authentification, parsing, routage)
- cloud → box eedomus (exécution sur le périphérique eedomus autorisé, valeur brute 0/100 ou autre)
- plate-forme → SMS de réponse (accusé de réception, aide, erreur)
Alternative terrain, utile quand on vise un traitement local dès réception du SMS: une passerelle SMS basée sur un vieux smartphone recyclé, avec une application de type « SMS Gateway », qui déclenche un webhook vers un script (par exemple PHP) hébergé par la box. L’objectif est l’indépendance vis-à-vis d’internet pour l’interprétation des commandes, avec des exigences pratiques: multi-utilisateurs, restriction aux numéros pré-enregistrés, accusé de réception après exécution, commandes d’action et de consultation, prise en charge de synonymes et commandes multi-mots, et ajout de commandes sans modifier le script via les écrans eedomus. Dans ce montage, le réseau mobile (gsm/4g) sert à transporter le SMS jusqu’au téléphone passerelle, puis le réseau local transporte la requête vers la box.
Comparaison rapide des options:
| Option | Fiabilité | Dépendance au cloud | Coût/complexité |
|---|---|---|---|
| Pilotage SMS eedomus (natif) | bonne si internet box stable | forte | faible, configuration simple |
| Smartphone passerelle + script local | bonne si réseau mobile et lan stables | faible pour le parsing, variable pour l’action | moyenne, maintenance d’un téléphone |
| Modem gsm/4g dédié | variable selon matériel | faible à moyenne | plus élevé, intégration technique |
Pour un guide « fiable sans surprises », on privilégie d’abord la voie native eedomus, puis on ajoute une passerelle SMS locale uniquement si l’objectif est de continuer à interpréter des commandes même en panne internet. Configurer la passerelle SMS et l’accès eedomus sans pièges
Configurer la passerelle SMS et l’accès eedomus sans pièges
Côté eedomus, la configuration se fait au chemin: configuration / box eedomus / configurer / pilotage par SMS. Point souvent oublié: par défaut, aucun périphérique n’est pilotable par SMS. Il faut donc parcourir la liste des périphériques et autoriser explicitement ceux qui doivent répondre. Cette étape est aussi un outil de fiabilité: limiter la surface de commande réduit les erreurs de nommage et les risques.
Ensuite, identifiez le bon numéro de SMS. La méthode la plus sûre consiste à répondre à une notification SMS déjà reçue (par exemple une alerte), ce qui garantit d’utiliser le numéro eedomus associé au compte. À défaut, un numéro « par défaut » est indiqué (06 44 63 07 **), avec l’avertissement qu’il peut changer d’une box à l’autre. Une astuce opérationnelle: envoyer un message au numéro par défaut, la réponse est automatiquement renvoyée par le numéro eedomus réellement associé au compte.
Côté accès, l’authentification repose sur l’utilisateur: l’expéditeur du SMS doit être un utilisateur enregistré sur le compte, et le numéro de téléphone déclaré renforce la sécurité. L’utilisateur principal est automatiquement autorisé; les utilisateurs secondaires doivent être explicitement autorisés. Pour les besoins ponctuels, la gestion d’accès invité est un vrai levier terrain: un utilisateur générique « invité » préconfiguré, dont on change simplement le numéro et la date de validité, permet d’ouvrir un créneau d’accès sans modifier toute la configuration.
Si vous mettez en place une passerelle SMS type smartphone, configurez-la pour éviter les échecs silencieux: whitelist de numéros, webhook avec accusé de réception, et journalisation. Le piège classique est le « message reçu mais non traité » faute de format attendu. Une convention stricte de commandes, plus un script qui renvoie systématiquement un statut (ok/erreur + raison), rend le système déboguable. La box eedomus pouvant héberger des scripts PHP, vous pouvez centraliser parsing, appels à l’api eedomus et retours SMS sans multiplier les dépendances.
Dernier point: ne confondez pas quotas. Les SMS envoyés et reçus dans le cadre du pilotage des périphériques ne sont pas décomptés du quota de SMS; seules les notifications SMS le sont. Définir des commandes SMS robustes : syntaxe, périphériques et réponses
Définir des commandes SMS robustes : syntaxe, périphériques et réponses
Une commande robuste doit être lisible, tolérante, et non ambiguë. La reconnaissance eedomus ignore majuscules, accents et caractères spéciaux: vous pouvez donc standardiser sans craindre « Allume » vs « allume ». Les actions acceptées incluent: éteins/allume, ferme/ouvre, désactive/active, off/on. Elles déclenchent des valeurs brutes 0 ou 100 sur le périphérique eedomus.
Convention terrain recommandée (même si eedomus peut accepter plus simple):
- mot clé fixe pour filtrer: edom ou maison
- action: allume, éteins, ouvre, ferme, active, désactive, on, off
- périphérique: nom court et unique, identique à celui autorisé dans le pilotage par SMS
- option éventuelle: action : n pour valeur brute spécifique
Exemples prêts à l’emploi:
- portail: « maison ouvre portail » puis accusé « ok portail: ouverture lancée »
- éclairage: « maison allume entree » ou « maison off salon »
- chauffage: « maison action : 18 chauffage » si votre périphérique attend une valeur brute particulière; vérifiez les valeurs brutes dans l’onglet « valeurs » du périphérique
- alarme: « maison active alarme » avec une règle eedomus qui refuse l’activation si une porte est ouverte, et renvoie un message d’erreur via macro
Pour limiter les erreurs de nommage, appuyez-vous sur les actions suggérées dans l’écran de pilotage par SMS (même chemin de configuration). En cas d’erreur de syntaxe, eedomus renvoie un message rappelant la syntaxe et les actions disponibles pour le périphérique nommé: exploitez ce retour comme outil de test, pas comme un simple message d’échec.
Accusé de réception: visez des réponses utiles, pas seulement « ok ». Une bonne réponse contient: périphérique, action, et état si pertinent. Avec des règles eedomus, vous pouvez chaîner: commande reçue → macro d’exécution → mise à jour d’un périphérique « statut sms » → notification de retour. Sécuriser le pilotage par SMS : numéros autorisés, secrets et garde-fous
Sécuriser le pilotage par SMS : numéros autorisés, secrets et garde-fous
Le socle de sécurité eedomus est clair: seul un utilisateur enregistré peut piloter par SMS, et le numéro de téléphone déclaré sert de contrôle. Sur le terrain, cela se traduit par une whitelist de numéros à jour et un minimum d’utilisateurs secondaires. Pour les accès temporaires, privilégiez l’utilisateur « invité » avec date de validité, plutôt que de recycler un compte permanent.
Ajoutez un secret applicatif dans le message, surtout si vous passez par une passerelle SMS et un script: un mot clé ou token court en tête (« maison 1234 ouvre portail »). Ce n’est pas une cryptographie, mais un garde-fou efficace contre une commande envoyée depuis un numéro compromis ou mal enregistré. Si vous restez en pilotage natif eedomus, gardez au moins un mot clé de contexte pour éviter qu’un SMS ambigu déclenche une action.
Garde-fous recommandés via règles eedomus et macros:
- limiter les commandes: n’autoriser par SMS que des périphériques nécessaires, pas toute la domotique
- temporisations: exiger deux SMS identiques à moins de 60 secondes pour une action critique (ouverture portail, désactivation alarme)
- double confirmation: « ouvre portail » → réponse « confirmer OUI portail » → exécution
- fenêtres horaires: refuser certaines actions la nuit, ou hors présence
- révocabilité: procédure écrite en cas de perte de téléphone (retirer le numéro de l’utilisateur, expirer l’invité, changer le token si vous en utilisez un)
Enfin, surveillez l’exposition: un SMS peut apparaître sur l’écran verrouillé. Pour les actions sensibles, évitez de renvoyer des informations trop détaillées (adresse, codes, habitudes), et préférez un accusé neutre.
Tester, surveiller et dépanner : logs, erreurs fréquentes et fiabilité
Validez la chaîne en trois passes. 1) test de syntaxe: envoyez volontairement une commande erronée pour vérifier que vous recevez bien l’aide de syntaxe. 2) test d’exécution: commande simple sur un périphérique non critique (lampe), puis vérification de l’état. 3) test de charge réaliste: enchaînez 5 à 10 commandes sur une heure, depuis deux utilisateurs, pour repérer latences et trous.
Points de contrôle:
- journal d’événements eedomus: la commande doit se traduire par un événement sur le périphérique ou la macro
- configuration pilotage par SMS: périphérique autorisé, utilisateur secondaire autorisé, numéro correct
- côté réseau: la box doit avoir un accès internet complet; si le cloud est inaccessible, le SMS peut être reçu mais l’action ne part pas
| Symptôme | Cause probable | Correctif |
|---|---|---|
| SMS non reçu | mauvais numéro de notifications, opérateur, téléphone sans réseau | répondre à une notification reçue, vérifier le numéro associé, retester depuis un autre mobile |
| SMS reçu mais action non exécutée | périphérique non autorisé par SMS, utilisateur non autorisé, box sans internet | autoriser le périphérique, autoriser l’utilisateur secondaire, vérifier la connectivité internet de la box |
| Réponse absente | latence opérateur, erreur de parsing, retour bloqué | attendre puis consulter le journal d’événements, simplifier la commande, tester une commande erronée pour déclencher l’aide |
| Commande mal interprétée | nom de périphérique ambigu, synonymes non maîtrisés | renommer le périphérique (nom court unique), s’appuyer sur les actions suggérées dans l’écran de configuration |
| Besoin d’une valeur autre que on/off | périphérique attend une valeur brute spécifique | utiliser « action : n », vérifier n dans l’onglet valeurs du périphérique |
Pour fiabiliser, standardisez vos noms (sans doublons), documentez 10 commandes maximum, et conservez un « périphérique test » dédié. Si vous utilisez un script et l’api eedomus, loguez chaque requête entrante, l’utilisateur détecté, la commande normalisée, et le résultat, puis renvoyez systématiquement un accusé de réception.
FAQ
Peut-on piloter eedomus par SMS sans connexion internet ?
Le téléphone peut envoyer un SMS sans data, mais la box eedomus doit disposer d’un accès internet complet car les SMS sont gérés par la plate-forme eedomus et l’exécution passe par le cloud.
Quel format de commande SMS utiliser pour contrôler un périphérique eedomus ?
Utilisez une action reconnue (allume, éteins, ouvre, ferme, active, désactive, on, off) suivie du nom du périphérique autorisé. Pour une valeur brute spécifique, utilisez « action : n » et vérifiez la valeur dans l’onglet valeurs du périphérique.
Comment sécuriser le pilotage eedomus par SMS pour éviter une commande malveillante ?
Limitez aux utilisateurs enregistrés, tenez une whitelist de numéros à jour, n’autorisez que quelques périphériques, et ajoutez des garde-fous via règles eedomus et macros (double confirmation, temporisation, fenêtres horaires). En cas de perte de téléphone, retirez le numéro ou expirez l’accès invité.
Pourquoi ma box eedomus ne réagit pas à certains SMS ?
Les causes fréquentes sont: périphérique non autorisé par SMS, utilisateur secondaire non autorisé, nom ambigu, ou box sans accès internet. Le journal d’événements et un test de commande volontairement erronée aident à isoler le point de rupture.
Un pilotage eedomus par SMS fiable se construit comme une chaîne: autorisations minimales, syntaxe stable, réponses explicites, et une routine de test appuyée sur le journal d’événements. Une fois ces bases posées, le SMS devient un vrai plan de secours opérationnel, simple à déléguer et facile à auditer.
