VinCiv

Les difficultés sur lesquelles est susceptible de buter un citoyen lambda sont nombreuses (voir le sprint PyCon sur les capteurs : compte-rendu)

Le choix d'une connexion WiFi imposerait le paramétrage du boitier à la box Internet du citoyen (qui devrait donc en avoir une), ce qui est une gestion lourde.

Le choix d'une technologie radio longue portée (LoRa, SigFox, XBee) permettrait à tous les boîtiers d'émettre directement vers le serveur ⇒ un seul paramétrage “usine”

Le choix radio suppose alors une géo-localisation par le boîtier lui-même ⇒ composant GPS embarqué (mais du coup, plus besoin de se soucier de localiser le boîtier). Mais cela éviterait de demander (et surtout stocker) les informations personnelles du citoyen (on peut alors se contenter d'un simple fichier pour gérer les volontaires et leur caution).

L'un des problèmes est l'alimentation en énergie de l'équipement intégré au boîtier.

Je préconise une alimentation via un port micro-USB (comme celui des smartphones) :

• il suffit de fournir un cable et un adaptateur 220-USB bons marché avec le boîtier
• si le citoyen perd ou abime le cable, il peut le remplacer à faible coût
• le citoyen peut envisager de nombreuses autres options :
  • une batterie portable de rechargement de téléphone (bien connues des ados)
  • un capteur solaire (avec ou sans accus)
  • une éolienne maison …
• le citoyen peut utiliser le boîtier en itinérant (en bandoulière, à vélo)

Il me semble qu'une personne ayant un boîtier dont elle ne peut voir les données ne s'y intéressera pas très longtemps ⇒ il faut lui donner un accès aux infos.

je préconise donc d'ajouter au boîtier précédemment envisagé un composant BlueTooth auquel elle pourrait se connecter via son smartphone (en utilisant une version simplifiée, et francisée, de l'application Android d'AirCasting) ou son PC portable (petite application à développer).

L'une des difficultés est de choisir la bonne fréquence de collecte et d'émission des données.

Du point de vue serveur, une fréquence faible ⇒ moins de données à traiter et stocker. Mais ce qui va commander est l'ensemble des utilisations envisageables de ces donnés :

• simple affichage des polluants sur la carte ⇒ une moyenne mensuelle par capteur suffit
• étude/affichage en fonction de l'heure de la journée ⇒ fréquence de 5 mn
• traitements “big data”, comme le font les étudiands de l'ENSAI à Bruz ⇒ données plus détaillées, et recoupées avec des données globales comme le vent, la pluviométrie, le gel, le trafic routier,…
• application proposant l'historique d'une rue ⇒ requête sur les coordonnées GPS
• et toutes les applications qui pourront se greffer sur la partie Open Data auront des besoins encore pas imaginés
• cas particulier d'une collecte itinérante ⇒ fréquence plus élevée (~30 sec), à gérer programmatiquement (test des coordonnées GPS ⇒ si elles changent, on collecte à haute fréquence

Du point de vue utilisateur, le problème est celui de la restitution (voir ci-dessus). L'utilisateur ne va pas attendre 5 mn avant d'avoir les données de son boîtier (mais il faudra qu'il attende que les sondes chauffent s'il vient de l'allumer). Il faut donc une fréquence élevée (10 à 30 sec), mais nécessaire uniquement quand il l'interroge. Peut-on envisager une attente sur l'entrée BlueTooth et émettre en réponse ?? On ne va guère économiser sur l'alimentation, le BlueTooth devant rester en ligne. D'un point de vue technique, le BlueTooth et l'émetteur radio seront sur deux ports distincts, donc on peut leur parler différemment.

Plusieurs visiteurs du Village des Sciences ont suggéré des mesures à effectuer, en plus de celles déjà prévues (NO², CO,…), telles que le vent (orientation et vitesse),..

Il serait intéressant de prévoir des champs supplémentaires, non renseignés au départ, qui pourraient être utilisés ultérieurement sans devoir changer le code embarqué des boîtiers déjà distribués (ce qui sera le cas si le nombre de champs de données est trop court au départ). Exemple : id;long;lat;alt;NO²;CO;CO²;SO²;temp;hum;;;;;;;;;;;;;;;;;;;;;;;;;;;

D'autres visiteurs se demandaient ce qui arriverait si quelqu'un piratait le réseau et envoyait des données erronées. Je leur ai signalé que le problème était similaire à des sondes défectueuses, ce qui m'a amené à répondre qu'un système pourrait détecter ces erreurs, et les mesures effectuées par le boîtier défaillant (ou piraté) seraient effacées du serveur. Cela suppose donc un identifiant, en plus des données elles-mêmes (id dans l'exemple ci-dessus).

La construction d'un boîtier “grand public” suppose sans doute une réglementation, des garanties et sécurités appropriées :

• protection électrique ?
• pas vendu donc pas d'aspect “consommateur” ?
• normes radio ?
• assurance adhoc du “constructeur”, du service délivrant les boîtiers ??