Le rpi doit pouvoir à tout moment fournir une donnée à l'arduino pour l'emettre.
Le rpi doit pourvoir réceptionner à tout moment une donnée en provenance de l'arduino
L'arduinoUno doit pouvoir à tout moment fournir une donnée au rpi.
L'arduinoUno doit pourvoir réceptionner à tout moment une donnée en provenance du rpi
L'arduinoUno doit être capable d'émettre et recevoir des données par la radio (433MHz ou 2.4GHz).
bonjour
va voir ça : http://www.mysensors.org/ avec la SerialGateway
C'est exactement ce que tu cherche a faire.
Je viens de me lancer dedans, c'est très bien fait et il y a meme de repetiteurs pour acroitre la porté (pas encore testé)
Ca m'intéresse caape.
Par contre, tu mets quoi de l'autre coté ? (pour les clients) il n'y a que le code de la gateway.
Y a t-il une gestion des erreurs de transmission ?
Merci !
Fl0rian:
Parce que attendre le signal, le rpi ne va pas trop aimer ? J'ai lu que l'arduino était mieux dans cette tâche.
Oui enfin le Raspberry dispose d'un OS multitâches. Donc, si le driver et l'application sont bien écrits, il ne passe pas son temps à attendre le signal, il fait autre chose en attendant.
A toi de t'inspirer de ceux ci pour faire les tiens.
Pour la gestion des erreurs de transmission, il y a possibilité d'avoir un acquittement, mais pas encore testé non plus.
Pour l'instant, je ne suis que sur le module température et pas besoin d'ACK. J'en ai un qui tourne en gros proto et je suis en train de refaire le typon pour miniaturiser. Plus qu'a graver en fait.
J'ai commencé la gestion des volets, mais comme je ne peux travailler dessus que le soir, je mets ça en pause pour les WE ou j'aurais fini mes travaux. J'ai commencé un module de gestion de 32 lampes et 32 inter. Mais pour l'instant, je bute sur le transfert de la config des groupe de lampes. J'ai bien trouvé un truc mais je ne me suis pas encore penché plus que ça.
C'est un protocole encore jeune mais qui évolu plutôt vite d’après ce que je vois, mais pas beaucoup d'info en français et ça me freine un peu. il est déjà supporté par plusieurs solutions domotique comme domoticz ou jeedom. J'utilise domoticz avec son API JSON, ça peut le faire.
fdufnews:
Oui enfin le Raspberry dispose d'un OS multitâches. Donc, si le driver et l'application sont bien écrits, il ne passe pas son temps à attendre le signal, il fait autre chose en attendant.
OK merci. Ce n'est pas facile de s'y retrouver dans cette jungle internet. On lit tout et son contraire... Le driver est la bibliothèque permettant la lecture du signal ?
Le sketch à uploader dans l'arduino pour le paramétrer en GW est "libraries\MySensors\examples\SerialGateway\SerialGateway.ino" ?
Cela permet de réceptionner des données des capteurs ? Qu'en est-il de l'émission à la demande du rpi ?
J'ai le RPi qui fait tourner Domoticz (en dernière version Beta). Dessus est branché un arduino Gateway (GW) par l'USB émulation série (c'est le bon sketch que tu as mis).
J'ai un ATMega328P en stand alone (mais testé aussi avec un UNO au debut) avec un DS18S20 comme capteur de température qui envoi toutes les minutes la valeur de la sonde puis s'endort car fonctionne sur pile.
J'ai testé, mais pas encore réalisé, mon module à base de relais et interrupteurs. Quand j'actionne l'inter, l'ATMega envoi a la GW ce qu'il faut pour prévenir Domoticz qui m'affiche bien le changement d'état.
Si dans Domoticz, je clique sur l'inter, le GW envoi ce qu'il faut a l'ATmega qui fait basculer le relais.
Si ton application est pour de la domotique, ce n'est pas plus compliqué que cela. Si c'est pour autre chose, il va falloir détourner ou substituer l'utilisation de domoticz. le dialogue entre la GW et Domoticz n'est que de la liaison série "lisible". il y a tout d'expliqué sur le site dans la section API : http://www.mysensors.org/download/serial_api_15
Sinon, installe la librairie et regarde les exemples, il y en a plus que sur le site mais c'est moins détaillé, que du code.
A oui merci beaucoup pour cette réponse.
Ce qui me faisait peur était le mode GW -> Sensor
Tout ce que je lis sur le net est toujours dans le même sens : le capteur fournit une température à la GW. Mais jamais dans le sens : la GW prend l'initiative de questionner le capteur sur la température, et le capteur répond.
Tu as un exemple où la GW prend l'initiative ? D'ailleurs, en lisant le sketch SerialGateway.ino je ne vois rien concernant l'émission de données (uniquement la réception avec gw.process());
Pour un capteur, c'est lui qui envoi de façon régulière ses valeurs a la GW.
Pour un actionneur, il attend un ordre de la GW
Un noeud peut combiner les deux, regarde le 2eme exemple de cette page http://www.mysensors.org/build/light
C'est l'exemple que je parlé dans le message précédent.
Rien ne t’empêche d'envoyer un ordre au noeud qui répond avec la valeur du capteur.
Pour tester, le plus simple est de câbler une GW et un noeud. Domoticz existe aussi sous Windows et est plus rapide à installer que sur un RPi mais s'utilise exactement pareil.
Lire le code du SerialGateway ne va pas te donner beaucoup d'info. Ceux des capteurs et actionneurs sont bien plus intéressant. C'est eux que tu va personnaliser a ta convenance. La GW n'est qu'une passerelle entre ne nRF24L01+ et le RPi via l'USB.
C'est pour faire une boite aux lettres connectée pour le moment.
Donc le cas "J'envoie, je m'endors, j'envoie.." me va, mais je pense au futur également.
Dans le 2ème exemple, je ne vois que la partie "émission", et pas la réception :
uint16_t lux = lightSensor.readLightLevel();// Get Lux value
Serial.println(lux);
if (lux != lastlux) {
gw.send(msg.set(lux));
lastlux = lux;
}
Pour la boite aux lettres, le plus dur sera de détecter le courrier et les colis. Avec 2 piles 1.5v, tu pourras tenir plusieurs années sans les changer. Une émission a chaque détection donc 1 ou 2 pour jour, y a les pub en plus du courrier avec un capteur passif (inter sur les portes). Par contre, i faut mettre une antenne extérieur.
on envoie à la GW la donnée avec gw.send(msg.set(state?false:true), true); lorsque c'est demandé, car gw.process reste bloqué tant que pas de demande, c'est bien ça ?
A quoi sert la méthode incomingMessage() ?
Du coup c'est possible de faire :
j'envoie si on me le demande
Si on me le demande pas mais que c'est important j'envoie quand même ?
gw.process() sert a vérifier qu'il y a un message qui arrive et en fait le traitement initial. Si c'est un message pour le noeud, il en fait de transfert a la fonction "incomingMessage()", sinon, s'il fait aussi répétiteur, il fait son boulot de répétition du message dans le bon sens, mais ça, c'est automatique et transparent. Il faut appeler gw.process() le plus souvent possible pour ne pas rater de message.
incomingMessage() est la fonction qui te permet de traiter les message pour le noeud. C'est ici que tu va lancer les commandes de tes actionneurs sur demande de la GW ou renvoyer les données demandé.
j'envoie si on me le demande
Si on me le demande pas mais que c'est important j'envoie quand même ?
Je dirais OUI, on peut tout faire, il suffit juste de programmer comme il faut. Mais il ne faut pas oublier qu'il y a un temps de latence plus ou moins long. Dans Domoticz, quand j'appui sur le bouton physique, il peut changer d'état, à l'écran, 2-3 seconde plus tard voir plus. Mais la demande est traité très vite, c'est juste du au rafraîchissement de la page toutes les 8 sec de mémoires. Si tu gère tout par scripte, ça devrais être quasi instantané ou peu perceptible.
Si c'est toujours pour ta boite aux lettres, ne fait pas sur demande mais envoi régulièrement, tous les 15 min me semble suffisant pour du courrier, l'état de ta BAL, ça te simplifiera ton programme.
Dans ce cas,l'exemple Motion Sensor | MySensors - Create your own Connected Home Experience te sert de base. A la place du PIR, tu mets deux interrupteurs en série, un sur la porte et un sur la trappe. Tu mets 15 min au lieu des 2 plus 2-3 autres petites modifs et ça roule.
C'est là la force de MySensors, c'est que quasi tout est prévu, il suffit d'adapter à ses besoin.
A oui merci.
En fait les exemples qu'ils donnent, on n'est pas obligé d'utiliser le matos mentionné dans l'exemple.
Je pensais que l'exemple motion, il fallait utiliser le PIR HC-SR501 qu'ils mentionnent, car la librairie utilisée reconnaissait uniquement ce capteur. En fait on met le capteur qu'on veut.
Le PIR n'est qu'un détecteur de présence qui indique par un 1 logique sur sa sortie qu'il a détecté quelque chose. Après, si tu mets un interrupteur qui, quand il est fermé, met a 1 l'entrée du NONO, le NONO ne voit que un 1 et ne fait pas la différence.
Par contre, pour les composant plus spécifique, qui ont un dialogue avec un protocole bien spécifique, cas du DS18B20 qui a un convertisseur AN en interne et renvoi une suite d'octets, il faut adapter plus en profondeur le code si tu veux utiliser un LM336 (pas sur de la réf) qui est une sonde de température analogique qui utilise le CAN de l'ATMega.
Si tu sais utiliser un composant avec arduino, il y a un moyen de transférer les données à Domoticz. Il suffit juste de trouver le bon type.
