Pi <-> NFR24 <-> Arduino

[piper]

Bon après des heures de recherche, j'ai trouvé, c'est complètement idiot et très mal documenté :
La fonction setChannel est bien documenté sur Arduino, y est précisé ceci :

entre 0 et 125 mais 0..83 peut être déjà pris par du wifi ou du bluetooth

J"avais choisis 100. Ca fonctionne merveilleusement avec 2 Arduinos ou avec un Arduino et un ESP32 (qui dispose aussi du Wifi et du BT)
Mais radio.setChannel (100) n'a aucun effet sur le Pi (et ne génère aucune erreur)
Un printDetails montre que le canal n'a pas changé.
Mais si je choisis 90, là, le numéro de canal est bien pris en compte. Donc je pense que sur la librairie Python RF24, il y a une limite mal documentée sur les canaux disponibles.

Ensuite : pb de vitesse du bus SPI
En Arduino, il tourne à 8Mhz. J'ai constaté que sur mon Pi, il tourne à 10Mhz par défaut
Les procédures classiques de modification de la vitesse du bus par spidev.spi sont sans effet (surement parce que le constructeur de l'objet RF24 l'utilise en entrée)
Mais en ouvrant le code en C de la bibliothèque Python, j'ai vu que le constructeur de l'objet RF24 accepte en entrée, de manière facultative, la vitesse du bus SPI à utiliser.
Et... Bingo ça cause !

Donc dans mon PI je dois mettre

Code : Tout sélectionner

radio = RF24(PINCSN, 0, 8000000)

Au lieu de

Code : Tout sélectionner

radio = RF24(PINCSN, 0)

Et

Code : Tout sélectionner

radio.setChannel(90)

au lieu de

Code : Tout sélectionner

radio.setChannel(100)

Maintenant , j'ai un autre problème : là c'était l'étude de faisabilité technique de communication basique entre les éléments : s'envoyer une chaîne de caractères.
Mais le contenu des messages ne doit pas être du string mais une structure en C contenant des int et un longint. Ca fonctionne très bien entre mes Arduino et/ou avec l'ESP32 (ils sont codés en C et les structures c'est natif en C, comme en Pascal mais en Python , pas du tout.
Apparemment la bibliothèque pickle (ou struct) de python doit me le permettre. Donc prochaine étape : comprendre comment elles fonctionnent.

[piper]

Voilà, c'est tout bon
En fait c'est simple , la bibliothèque struct contient les méthodes pack et unpack pour créer des paquets collant à mes structures en C côte Arduino
Petit piège : ne pas confondre la taille du paquet avec la taille des données.
La structure contient entre autre 2 bytes, le 1er indique qui envoi le message, l'autre, à qui il est destiné. Ainsi la limite théorique de 6 NRF24L01 devient sans objet. Tout cause sur le même canal en même temps et avec les mêmes adresses (croisées pour le Pi) sans soucis.

Maintenant, plutôt qu'un ESP32 qui interrogeait à chaque fois l'API par internet (ce qui ralentissait la réactivité), j'ai mon Pi qui a les données en cache et le rafraichit régulièrement. Et mes Arduino ont la réponse à leurs demandes dans les 100 ms au lieu de 2-3 secondes avant.
Reste à tester la portée de ces petits composants. J'avais testé en extérieur entre Arduinos, j'arrivais à plus de 30m mais en intérieur, ça va être autre chose.

Je ne sais pas si via le forum, on peut héberger des codes sources et des schémas (pdf, jpg) de branchement pour faire un tuto accessible sur le forum.
L'hébergement gratuit d'images (genre https://www.zupimages.net/) n'est pas une solution pérenne dans le temps.

[jelopo]

Bonjour,

Bravo, ça semblait pas gagné. C'est vrai qu'un tuto serait intéressant.

A+

[domi]

Je ne sais pas si via le forum, on peut héberger des codes sources et des schémas (pdf, jpg) de branchement pour faire un tuto accessible sur le forum.
L'hébergement gratuit d'images (genre https://www.zupimages.net/) n'est pas une solution pérenne dans le temps.

Bonjour,
Pour les téléchargements sur le forum, en dessous de la zone d'écriture, il existe un onglet "Fichiers Joints".

[Artemus24]

Salut à tous.

Tout cause sur le même canal en même temps et avec les mêmes adresses (croisées pour le Pi) sans soucis.

La technique du jeton consiste à autoriser, un périphérique à la fois.
Il suffit de lui donner l'autorisation. Le maitre interroge régulièrement chaque périphérique esclave.
Si tous échanges en même temps, tu risques d'avoir des collisions dans tes trames et d'avoir un ralentissement pour cause de conflit d'accès.

Et mes Arduino ont la réponse à leurs demandes dans les 100 ms au lieu de 2-3 secondes avant.

Le temps de réponse a-t-il de l'importance ?

J'avais testé en extérieur entre Arduinos, j'arrivais à plus de 30m mais en intérieur, ça va être autre chose.

A l'intérieur d'une maison, la pénétrabilité dans les murs depend de la composition de ceux-ci.
Avec mon WIFI de chez SFR, je n'ai aucun problème dans ma maison.
Je l'ai testé avec un ESP32 qui communique depuis mon ordinateur en passant par ma BOX SFR.

Bravo pour la réussite de ton projet.

Tu peux déposer dans le forum des images et des pdf en cliquant sur l'onglet "fichier joint", quand tu cliques sur "répondre".
Quand tu as le chemin exacte vers ton image, il suffit de le placer entre les balises [ img ] ... [ /img ].

Cordialement.
Artemus24.
@+

[piper]

"Le maitre interroge régulièrement les esclaves"

Pour des mesures de données systématiques et régulières oui mais ce n'est pas mon projet.

Dans mon projet, les esclaves poussent les données vers le maitre lorsque cela est nécessaire (évènements).
Et le maitre en réponse leur dit comment les esclaves doivent réagir.
Bien que j'ai vérifié que cela fonctionne, statistiquement, il y a 1 chance sur 1000 000 que 2 esclaves aient à pousser leurs données en même temps. Et si cela se produit, ça fonctionne en FIFO dans mon code et dans le pire des pires des cas, si un esclave n'a pas de réponse au bout d'un certain temps, il va retenter une fois sa chance (non sans allumer avant une LED rouge pour signaler le 1er échec). S'il y a 2ième échec (exception de l'exception), ce n'est pas grave dans mon projet.

[piper]

Merci.
Finalement, j'ai mis ça sur mon blogue perso car un hébergeur gratuit que ce soit des pdf ou des images ou un zip, on ne sait jamais combien de temps ça sera hébergé.
Et puis github, c'est bien pour échanger au sein d'une équipe de de développeurs.
Mon article explique comment faire un contrôle d'accès avec des arduinos et un Raspberry en guise de centrale d'accès à l'aide de NRF24L01
Au passage, j'ai constaté qu'avec le paramètre RF24_PA_MIN (puissance d'émission faible), la portée en intérieur n'était que de quelques mètres.
avec RF24_PA_HIGH, la portée permet de positionner où on veut les Arduinos dans un pavillon classique.
https://blog-info.cd-ii.fr/arduino-controle-dacces/

[Artemus24]

Salut Piper.

Merci pour le lien vers ton blog.
Est-ce développé avec WordPress ?

Lorsqu’un utilisateur passe son badge devant le lecteur, le Arduino lit l’identifiant du badge qui est une suite de 4 nombres entiers entre 0 et 255.

Une suite de quatre nombre compris entre 0 et 255 ressemble fortement à une adresse IPv4.
C'est un nombre que tu choisis ou est-ce physiquement lié à la carte ?

Ex : dans mon cas, chaque personne peut-être autorisée à 8 lecteurs de badge.

Autrement dit, un badge ouvre toutes les portes.
Peux-tu configurer un badge qui ouvre une seule porte entre telle heure et telle heure ?

Au cas où quelqu'un viendrait à dupliquer un badge, as-tu une quelconque sécurité mise en place ?
Quelque chose d'infalsifiable lié au badge et non à la trame JSON que tu envoies.

Si une personne fait plusieurs tentatives d'accès durant un laps de temps très court, qui se solde par des échecs, as-tu pensé à désactiver le contrôle des badge que tu as mis en place ?
C'est l'équivalent du mot de passe que l'on tape disons cinq fois de suite avec erreur. L'utilisateur est alors dans l'impossibilité d'en taper un nouveau.

Comment rentres-tu chez toi si tu as une coupure d'électricité ?

Cordialement.
Artemus24.
@+

[piper]

Code : Tout sélectionner

Comment rentres-tu chez toi si tu as une coupure d'électricité ?

Tu connais les batteries de secours ?
Et le raspberry utilises un cache
Cache qui ne sera pas effacé si l'appel à l'API échoue
De plus, il existe toujours la bonne vielle clé mécanique sur une autre porte du bâtiment.