casse tête domotique !!

Bonjour,

Voilà maintenant quelques semaines que je travaille sur mon future système domotique pour ma future maison (ça fait passer le temps lol).
Allumer une lumière, un appareil 220v, pas de problème. J'utilise des NRF24L01+ pour ma comm sans fil pour les modules déployés dans toute la maison.

Voilà ce que j'ai prévu:

Serveur - Matériel

  • raspberry pi avec un apache, php, mysql
  • carte arduino UNO connecté en USB (ttyUSB0).
  • un NRF24L01+

Serveur - logiciel

  • Site web pour l'envoi des commandes
  • Un démon perl qui va "poper" les événements en base et exécute les actions correspondantes sur le serial

Modules --> Ne dépasse pas 20€ !!! :slight_smile:

  • arduino "home made" (atmega programmé en uno)
  • un NRF24L01+
  • une carte relai

Mon problème est le retour de communication sur le serial. Admettons que j'envoie une commande d'allumage d'une ampoule.
L'ordre passe par le MC, et est exécuté sur le module qui va bien. pas de prob. Je peux aussi attendre la réponse du module pour faire afficher
sur le site le status de l'ampoule. Jusque là pas de prob.

Mais si j'allume directement en appuyant sur un interrupteur l'ampoule, le message est envoyé au MC serveur, et là, je ne sais pas comment récupérer l'événement.

Le fonctionnement de mon démon est plutôt simple. Une fois lancé, il ouvre le serial ttyUSB0, initialise une connexion mysql, et scrupte en permanence la table evenement
de ma base pour "poper" les événements et exécuter les actions. mais comment puis-je faire pour scruter la table evenement et en meme temps attendre les ordres sur le serial ?

J'ai pensé faire un autre démon pour les ordres retour, mais le tty ne peut être ouvert qu'une seule fois. Je ne veux pas passer par des modules Ethernet pour mes modules. Ca me coûterait un bras,
et ça reviendrait au final aussi cher (un peu moins, mais il n'y aurait plus beaucoup de différence), qu'un système tout fait.

Avez-vous des conseils à me filer ?

J'espère que vous pourrez m'aider dans ma réflexion ....

Si je comprend bien ton problème,

  • Pas de problème pour remonter un état d'interrupteur depuis un module distant vers l'Arduino UNO via les modules RF. DOnc l'Arduino UNO sait tout ce qui se passe sur ton réseau domotique.
    Le problème est de faire remonter l'info vers le serveur Web et la page Web.

Malheureusement, le serveur Web ne peut - a ma connaissance - recevoir des évenements que du navigateur, pas de la liaison série.
Il va donc falloir mettre en place une méthode de scrutation (polling) pour que le PHP viennent interroger régulièrement la UNO pour savoir si des statuts on changé.
Et comme le serveur Web nepeut réagir qu'a des requêtes venant du navigateur, il fa falloir que ce soit coté page web qu tu utilise un Javascript périodique qui viennent faire une requête à un script PHP de ton serveur Web pour interroger les nouveaux statuts.

Autre solution en gardant ton idée de démon : ton démon, cause avec l'Arduino et la liaison série. Mais comme lui seul à ouvert le port série, il faut que le PHP du serveur Web interroge ton démon via une socket TCP par exemple au lieu d'interroger directement l'Arduino.
De même le démon peut aussi envoyer des requêtes HTTP asynchrones vers le serveur Web pour mettre a jour la base de donnée.

Mais il reste que la mise à jour de la page Web ne peut intervenir que sur requête du Javascript de ladite page.
La méthode du démon permet au moins de metter a jour la base de données SQL même si aucun client/navigateur n'est connecté.

Est-ce que je suis clair ?
Ca te semble valide comme approche ?

euh, non, je me suis peut-être mal exprimé. J'ai déjà la méthode pour mettre à jour l'applicatif.

C'est la remonté des infos depuis les modules qui me posent souci car mon démon n'écoute pas le port série en permanence.
Il ne fait que scruter la table evenement de ma base.

Il faudrait que je fasse du multithread sur mon demon perl pour ajouter le "scrutage" de la liaison série pour remonter les retour des modules RF
vers ma base de données.

Pour mettre à jour le site, je fais ça au travers d'un XHR ajax qui vérifie les événements remontés en base :wink:

Ai-je été plus explicite ?

zerr0s:
Il faudrait que je fasse du multithread sur mon demon perl pour ajouter le "scrutage" de la liaison série pour remonter les retour des modules RF vers ma base de données.

Oui c'est ce que je dit dans la 2eme partie de mon message.

arfff. ça devient compliqué dès qu'on touche aux threads lol

J'ai un peu avancer sur mon démon. J'ai laissé tomber le perl car la gestion en multithread n'est pas génial pour me concentrer sur un démon en python.
J'attaque la partie multithreading, mais pour le moment, les threads de test que je crée ne rendent pas la main pour laisser le reste du programme s'exécuter.

Il faut vraiment que j'arrive à lancer un thread qui fonctionnera en parallèle du reste du code et qui utilise des ressources partagés (connexion à la bdd et la liaison serie).

Si quelqu'un a un bout de code d'exemple pour ça, je suis hyper intéressééééééééé :slight_smile:

Faire du multi-threading en PHP ... bof :frowning:

En C tu peux notamment utiliser select() pour pouvoir écouter dans la même boucle une socket et la liaison série.

Non le multithread je le fais sur le démon python. Le php n'est jamais en contact ni avec le démon, ni avec le serial. Les deux ne communiquent ensemble qu'au travers une table d'événements en base.

Il n'y a que le démon en python du coup qui a accès au serial. Le multithread est vachement important sinon les actions de l'utilisateur qui restent en file d'attente mettront du temps à s'exécuter.