[arduino] Topic Unique blabla @ Arduino

Je ne connais pas ce logiciel, mais en théorie oui bien sûr, on peut stocker une séquence dans l'EEPROM de l'Arduino (EEPROM pas très grand) ou la "téléverser" dans la RAM (jusqu'à la prochaine coupure d'alim, RAM pas très grande non plus) ou stocker sur une carte SD. Après, comme toujours, il faut que le code supporte ça. :o

Aucune idée, par goût je vais partir sur du micropython, et donc via Thonny.
C'est pour ça que ça s'éloigne p-e un peu du sujet :D
 
Mais il me semble qu'on peut utiliser l'environnement Arduino si on fait du C.

je veux pas déranger, on est pas vraiment sur la même chose :)

Tu me fais pas confiance ?  [:-noemie-]

L'I2C commun n'est possible de toute façon que si chaque capteur à une adresse différente ce dont je suppose que ce n'est pas le cas. Sinon on pourrait brancher chaque capteur/cylindre sur des broches différentes d'un µC et faire du I2C en software, en master c'est vraiment pas sorcier, sans dire que pour Arduino il doit y avoir tout prêt à l'emploi.

Donc des câbles entre chaque cylindre et un Arduino ou similaire qui lui sera relié en sans fil à un autre module branché sur le PC dans l'autre pièce. On pourrait partir sur des nRF24L01+ pour la liaison sans fil, contrairement au BT il n'y a pas de connection/déconnection à faire, les latences peuvent être très faibles. Perso je partirais sur un truc comme ça, car je pense toujours que mettre un ESP par cylindre c'est chercher les ennuis (et puis y'a les histoires de latence dont tu parles).

EDIT: Y'a des multiplexeurs de bus I2C aussi, PCF-quelque chose je crois :o , si ça peut servir...

[HS]
Le projet c'est d'étudier le fractionnement isotopique du dioxygène atmosphérique. En gros on regarde comment la respiration des plantes (projet où le RS485 m'a fait chier)
ou des algues (ce projet ; les cylindres sont remplis d'eau avec des algues dedans, et il sont plongés dans une cuve avec de l'eau maintenue à la température désirée, l'idée étant d'avoir un environnement contrôlé avec tous les paramètres connus, pour pouvoir savoir qu'est qui a une influence sur quoi).
Le but final étant de mieux comprendre les phénomènes en jeu et de pouvoir relier ce qu'on mesure aujourd'hui avec ce qui est mesuré dans les carottes de glace antarctiques.
En (très) gros, si en labo on a [conditions A] -> [mesures X] et [conditions B] -> [mesures Y] et que dans les carottes qui ont x milliers/millions d'années on a [mesures X], ben on peut supposer que la biosphère à l'époque était dans un mode de fonctionnement proche de [conditions A].
[/HS]
 
L'I2C commun je le sens mal franchement, déjà que j'ai eu des soucis avec le RS485 alors que normalement j'étais dans le bon cas d'usage, là jouer avec les limites ça va me péter à la gueule  :sweat:  
 
Pour la gestion de la collision, je pensais gérer ça comme ça :
- Les modules cylindres sont en "serveur", le module sur le PC est en client.
- Le module PC se connecte au cylindre1, envoie un message [donne-moi tes données], le cylindre1 reçoit le message et renvoie le contenu de son buffer, module PC se déconnecte de cylindre1
- Le module PC se connecte au cylindre2, envoie un message [donne-moi tes données], le cylindre2 reçoit le message et renvoie le contenu de son buffer, module PC se déconnecte de cylindre2
- Etc.
Le problème c'est qu'un cycle prend quelques centaines de ms, donc pour faire le tour de quelque cylindres on est sur un rafraichissement toutes les de 1 à 2s.
En vrai ça va pour cette application là parce que le module PC ne donne pas d'ordre "physique" aux modules cylindres (genre activer un relai) qui doivent être exécutés en temps réel. Faut pas qu'il y ait trop de communications quoi.
 
C'est pour ça que sur des application futures, je ferai plutôt du Wifi avec un petit routeur, comme ça pas besoin d'ouvrir la communication à chaque message (en tous cas ce sera plus rapide que de rechercher le device bluetooth à chaque fois).
 
Pour MQTT, c'est bien sur le principe mais pour la partie traitement des messages de données reçus, j'ai déjà des moulinettes que j'utilise pour d'autres projets et qui sont aussi adaptées à des communications RS232/RS485/USB voire pin IO de Raspberry Pi.
 

Curieuse demande par ailleurs, c'est quoi comme recherche si c'est pas indiscrèt? :o

I2C à toute petite vitesse (quelque kHz) ça marche sur pas mal de distance, perso j'ai environ 20m de câbles (non blindés, non torsadés en plus) avec je crois 5kHz (projet perso!!). Mais en effet ça peut merder et si le bus est bloqué il faut tout réinitialiser... Par contre est-ce que les capteurs sont tous identiques / ont la même adresse ou pas?

Perso je dirais, avec les éléments que tu donnes et ma faible expérience perso, I2C depuis les capteurs jusqu'à un seul ESP32/Arduino/RaPI ou similaire ou une combinaison de tout ça et puis un truc similaire dans l'autre pièce branché au PC. Par contre tes capteurs il faudra les interroger systématiquement, à moins que ce soit des capteurs qui font maître I2C mais je ne pense pas que ça existe?? Après la partie I2C se fera au niveau du bidule (ESP ou autre) dans la pièce humide qui lui pourra envoyer les données quand bon lui semble / quand nécessaire.

Partir sur un truc avec un ESP32 par capteur, soit un "mesh" sans fil c'est chercher les ennuis je pense car il faut voir l'arbitrage, les collisions "on air" etc. EDIT: En fait non, pas pour le Wifi en tout cas, c'est géré par la norme/le protocole. :o

Sinon il y a aussi les fameux nRF24L01+, mais c'est pas si évident que ça à utiliser et surtout les modules sur Ali etc c'est pas toujours gagné, au contraire (déviations au niveau de la fréquence donc pas de liaison ou liaison instable).

eg:
https://w2.influxdata.com/wp-conten [...] iagram.png

Tout à fait. La méthode du debounce en software est la bonne je pense.