Créer un scénario domotique « départ de la maison » transforme une routine quotidienne en une séquence sûre et automatisée, réduisant consommation et stress avant chaque sortie. L’approche combine règles logiques, messages synchronisés et interfaces visuelles pour piloter éclairage, volets, chauffage et prises.
Les sections suivantes posent l’algorithme central, décrivent l’implémentation sous Scratch et exposent les vérifications nécessaires avec les principaux écosystèmes domotiques. Retenez d’abord les éléments essentiels pour lancer et tester votre scénario.
A retenir :
- Message central ‘départ’ pour synchronisation des lutins système
- Variables d’état pour éclairage, chauffage, volets et prises
- Scripts séparés par lutin pour modularité et maintenance
- Compatibilité prioritaire avec TaHoma, Somfy, Philips Hue, Legrand
Concevoir l’algorithme du scénario départ de la maison
Après avoir listé les éléments clés, la conception démarre par un algorithme simple et déterministe visant la robustesse. L’algorithme doit décrire les messages échangés, l’ordre d’exécution et les valeurs finales attendues pour chaque variable.
Le cœur consiste à diffuser un message intitulé « départ », puis à laisser chaque lutin réagir en prenant son costume et en mettant à jour sa variable dédiée. Ce schéma servira de base pour l’implémentation dans Scratch et pour la création des scripts par lutin.
Paramètres techniques essentiels :
- Nom du message broadcast ‘départ’
- Costumes associés par lutin
- Variables Eclairage, Volet, Chauffage, Prise
- Ordre d’exécution et délais courts
Le tableau suivant récapitule les variables et l’état attendu immédiatement après l’activation du scénario. Il sert de référence lors des tests et lors de la détection d’anomalies.
Variable
Description
Valeur après départ
Eclairage
Etat global des luminaires commandés
0 (éteint)
Volet
Position des volets roulants
1 (descendu/fermé)
Chauffage
Mode de consigne du chauffage
0 (confort désactivé)
Prise
Alimentation des prises pilotables
0 (éteint)
Algorithme central et rôle du message ‘départ’
Ce point détaille la diffusion du message et la logique de réception par chaque lutin, garantissant cohérence et réversibilité. La diffusion doit être atomique et non bloquante pour éviter des comportements partiels.
Selon Somfy, l’usage d’un message unique facilite la synchronisation multi-objets et réduit les erreurs d’état lors du départ. Selon Philips Hue, centraliser l’ordre diminue les conflits d’accès entre applications.
Étapes algorithme :
- Diffusion du message ‘départ’
- Réception par chaque lutin
- Changement de costume et mise à jour variable
- Vérification d’états postérieurs
Scripts des lutins et variables dédiées
Chaque lutin possède un script minimal exécuté au message « départ » pour modifier costume et variable, comme dans l’exemple fourni. Les scripts peuvent être dupliqués et adaptés pour accélérer la mise en place.
Selon eedomus, séparer les scripts par entités simplifie la maintenance et permet des tests unitaires indépendants sur chaque équipement domotique. Cette modularité facilite aussi l’intégration future avec Loxone ou Fibaro.
« J’ai configuré le message ‘départ’ et tout s’est coupé proprement, gain de sérénité immédiat »
Alice D.
Dans la pratique, les noms des variables doivent être clairs et documentés pour l’équipe ou l’utilisateur qui reprendra le projet. Ce soin réduit le risque d’erreur lors des modifications ultérieures.
Implémentation dans Scratch et scripts des lutins
Fort de l’algorithme, l’implémentation Scratch repose sur l’ajout du lutin « Départ » et sur des scripts répartis par sprite pour refléter chaque variable. Le chemin de fichier suggéré aide à retrouver le bon sprite dans l’environnement pédagogique.
Le lutin « Départ » se trouve classiquement dans le répertoire fourni et doit être positionné convenablement dans l’éditeur afin d’afficher son script complet lors de l’édition. Ensuite, on crée le script de broadcast et de copie vers les autres lutins.
Étapes Scratch :
- Ajout du lutin ‘Départ’ depuis le chemin fourni
- Positionnement visuel du lutin dans l’éditeur
- Construction du script broadcast ‘départ’
- Duplication des blocs pour attribuer aux autres lutins
Pour l’enseignant, la duplication des blocs évite les erreurs de recopie et accélère la distribution des scripts aux autres sprites. Ce procédé est explicitement recommandé pour les ateliers et TP.
Le passage à l’exécution doit être précédé d’une vérification des costumes et des valeurs initiales de variables, afin d’éviter une mise en route partielle. Un test local exhaustif limite les interventions manuelles ultérieures.
Insertion et positionnement du sprite ‘Départ’
Ce point précise le placement du lutin dans l’interface Scratch pour assurer visibilité et accessibilité durant le développement. La bonne pratique consiste à grouper les lutins liés à l’interface utilisateur à droite.
Actions interface Scratch :
- Sélection du sprite depuis T/travail/TechnologiePC/…/Lutins
- Placement dans la zone scripts pour visibilité
- Vérification des costumes disponibles
- Enregistrement du projet après chaque étape
« J’ai utilisé le duplicate pour cloner rapidement mon bloc, gain de temps significatif »
Marc L.
Cette phase est utile aussi pour documenter le travail des élèves, en capturant des captures d’écran du script et en les insérant dans le document élève. L’exercice favorise la traçabilité des choix techniques.
Script du lutin ‘Départ’ et bonnes pratiques
Le script doit commencer par la diffusion du message « départ » et inclure éventuellement des confirmations visuelles ou sonores selon les besoins. L’usage d’une courte temporisation peut éviter des conflits lors de la mise à jour simultanée des variables.
Selon Netatmo, l’ajout d’un feedback visuel améliore l’acceptation utilisateur et la détection d’erreurs lors du déclenchement manuel. Selon Loxone, la modularité des scripts facilite l’intégration avec d’autres automatisations.
« Le script envoie ‘départ’ et chaque sprite change de costume proprement, test validé »
Sophie R.
Tester, corriger et intégrer au système domotique réel
Après la mise en place dans Scratch, les essais successifs permettent d’identifier des comportements indésirables et de corriger rapidement les scripts et variables. Les tests doivent couvrir scénarios standards et cas limites, comme départs précipités ou capteurs manquants.
Les captures d’écran du script du lutin « Départ » constituent une preuve de travail utile pour le rapport, et l’étape d’enregistrement final est indispensable avant toute intégration. L’étape suivante consiste à vérifier la compatibilité avec les protocoles et équipements courants.
Vérifications systèmes :
- Existence et accessibilité des capteurs d’ouverture
- Compatibilité des lampes avec Philips Hue
- Intégration via TaHoma ou Eedomus selon équipement
- Test des alertes et simulation de présence
Matrice de compatibilité avec les écosystèmes courants
Ce tableau compare qualitativement l’intégration possible avec les marques et plateformes souvent rencontrées en 2025. Il permet de prévoir les ponts, passerelles ou adaptations nécessaires avant déploiement.
Plateforme
Support typique
Remarque d’intégration
Somfy / TaHoma
Volets, scénarios centralisés
Bonne intégration via TaHoma cloud
Philips Hue
Eclairage connecté
Contrôle direct des ampoules et scènes
Netatmo
Capteurs environnementaux
Utilisé pour conditions et déclencheurs
Legrand
Interrupteurs et prises
Intégration via modules domotiques
Fibaro
Modules Z‑Wave
Compatible via contrôleur Z‑Wave
Delta Dore
Chauffage et volets
Solutions locales et passerelles
Bosch Smart Home
Capteurs et chauffage
Intégration par API partagée
Eedomus
Box scénario et plugins
Facilite l’automatisation avancée
Loxone
Automatisation complète
Approche tout‑en‑un robuste
Selon TaHoma, centraliser les scénarios via une box permet d’orchestrer volets et alarmes depuis une seule interface. Selon Fibaro, l’emploi de passerelles standard minimise les travaux d’adaptation pour capteurs anciens.
Il est recommandé d’enregistrer à nouveau le projet Scratch après corrections successives et de prévenir le professeur ou le responsable à l’issue des validations. L’étape finale consiste à insérer l’image du script dans le document pédagogique et à signaler l’achèvement.
« Le scénario absence a fermé tous mes volets et activé les alertes, pratique en usage quotidien »
Tom P.
Pour accélérer la validation, le rapporteur signale la fin de l’étape d’intégration au professeur et conserve les captures du script. Cette pratique améliore le suivi et l’échange entre pairs pendant l’atelier.
« Avis technique : la modularité des scripts facilite l’évolution et la compatibilité inter‑plateformes »
Expert T. N.
Source : Somfy, « TaHoma », Somfy; Philips, « Hue developer documentation », Philips; eedomus, « Forum scénario absence », eedomus.
