Un Raspberry Pi tournait déjà sur l’étagère. Un capteur BME280 coûte environ 10€. Ça aurait dû être un projet de week-end.

C’était globalement le cas, à l’exception de la partie où j’ai supposé que lire un capteur de température signifiait lire un registre.

Quatre fils et une puce

Le Bosch BME280 mesure la température, l’humidité et la pression atmosphérique par I²C. Quatre fils vers les pins GPIO du Raspberry Pi, activer l’I²C dans raspi-config, et le capteur apparaît à l’adresse 0x77 sur le bus :

i2cdetect -y 1

C’est la partie facile. Le piège, c’est ce qui se passe ensuite.

On ne lit pas juste la température

Le BME280 ne vous donne pas 21,5°C. Il vous donne des valeurs ADC brutes : des entiers 20 bits qui ne signifient absolument rien par eux-mêmes. Pour obtenir une vraie température, il faut :

1. Lire les coefficients de calibration que Bosch a gravés dans l’EEPROM de la puce à l’usine (registres 0x88, 0xA1, 0xE1)
2. Appliquer les formules de compensation Bosch : de l’arithmétique en virgule flottante double précision qui utilise ces coefficients pour transformer les valeurs brutes en vraies mesures
3. Attendre que la mesure soit terminée en scrutant le registre de statut

La compensation de température seule prend la valeur brute, applique une correction quadratique avec trois constantes de calibration, et crache une valeur en centièmes de degrés Celsius. La pression dépend de la température corrigée. L’humidité dépend des deux.

Tout est directement tiré de la datasheet Bosch, rien d’inventé. Mais ça signifie que le driver n’est pas un programme de cinq lignes. C’est implémenter une spec, pas importer une bibliothèque.

Le rendre accessible par le réseau

Une fois le driver fonctionnel, la question suivante était de savoir comment amener ces valeurs dans Home Assistant. Le chemin le plus simple : une API Flask avec deux endpoints.

GET /bme280 retourne la lecture courante en JSON. GET /bme280/publish lit le capteur et pousse les trois valeurs vers un broker MQTT. Un cron job sur le Pi appelle l’endpoint publish toutes les quelques minutes, et Home Assistant récupère les valeurs en temps réel.

Le mécanisme de découverte MQTT a rendu la partie Home Assistant presque sans friction. Une commande mosquitto_pub par type de capteur — publier un payload JSON de config vers le bon topic — et les entités apparaissent automatiquement dans l’UI. Pas d’édition de configuration.yaml, pas de redémarrage requis.

BME280  ──I²C──►  bme280.py  ──►  Flask API  ──MQTT──►  Home Assistant

Le guide d’installation complet est dans le repo.

Ce à quoi je ne m’attendais pas

La calibration Bosch n’est pas négociable. J’ai commencé par lire le registre de température brute directement et le scaler naïvement. Le résultat était des nombres qui avaient l’air presque plausibles et qui étaient complètement faux. L’algorithme de compensation n’est pas une décoration optionnelle, c’est ce qui rend la sortie significative.

Le polling bat les événements ici. Le capteur ne pousse pas de données, on lui demande une lecture. Un cron job toutes les minutes est tout ce dont on a besoin pour surveiller une pièce. Le streaming en temps réel serait excessif et userait probablement le capteur plus vite.

La découverte MQTT est sous-estimée. Déclarer manuellement les capteurs dans configuration.yaml fonctionne, mais l’auto-découverte semble simplement juste. Publier un payload de config une fois, et Home Assistant s’en occupe. Ajouter un nouveau type de capteur plus tard prend environ trente secondes.

La pièce est maintenant à 21,4°C et 47% d’humidité. Je le sais sans rien ouvrir.

Une note sur le SensorAPI officiel Bosch

En écrivant le driver, j’ai jeté un œil au SensorAPI officiel Bosch pour référence. Deux choses ont retenu mon attention.

L’exemple userspace Linux ne fonctionne pas vraiment sur Raspberry Pi sans modifications : ioctl est appelé avant que dev_addr soit assigné, donc l’adresse du périphérique I²C n’est jamais correctement définie. Le correctif est évident une fois qu’on le voit, et plusieurs contributeurs ont buté sur le même bug indépendamment, mais ils attendaient en PR depuis des années. Certains attendent encore.

Il y a aussi la PR #94 (toujours ouverte début 2025), signalant un comportement indéfini dans bme280_get_sensor_mode() : l’opérande gauche d’un & bit à bit est une variable non initialisée, détecté par analyse statique.

La puce elle-même est excellente. Mais le code de référence du fabricant est un point de départ, pas un évangile. Implémenter l’algorithme de compensation directement depuis la datasheet signifiait que je comprenais chaque ligne. Quand une lecture paraît bizarre, il n’y a pas de mystérieuse bibliothèque C à blâmer.

guillaumedelre/bme280

Driver Python pour le capteur BME280 — température, humidité et pression par I²C, avec publication MQTT et intégration Home Assistant.

Un Dream Cheeky Thunder a atterri sur un bureau peu après. Quatre missiles en mousse, un câble USB, et un consensus d’équipe très clair : le brancher au cluster, le câbler au pipeline de build, et laisser le CI décider qui mérite une volée.

Le lanceur devait répondre à des appels HTTP depuis n’importe où sur le réseau. Sans driver, sans GUI, sans visée manuelle. Juste un endpoint qui le fait tirer dans la direction du bureau du coupable.

Voilà l’histoire de dream-cheeky-thunder.

Pas de SDK, pas de docs, pas de problème

Dream Cheeky n’a jamais publié de spec de protocole. Le lanceur parle USB HID brut, et le seul point de départ était un script Python vendorisé de 2012 qui traînait dans des fils de forum. Vendor ID 0x2123, product ID 0x1010, et une poignée d’octets de contrôle que quelqu’un avait rétro-ingénié des années auparavant.

C’était suffisant. Le protocole est simple : envoyer une séquence d’octets pour bouger les moteurs, en envoyer une autre pour tirer. La partie délicate : le lanceur n’a aucun retour de position. Pas d’encodeurs, pas de fins de course en dehors des butées physiques aux extrémités. On le pilote à l’aveugle.

Du USB au HTTP

Le pipeline CI devait déclencher le lanceur par le réseau. Un script local ne suffisait pas — le lanceur devait être accessible depuis n’importe quelle machine du cluster, y compris le serveur de build. Donc : une API REST.

FastAPI était le choix évident. Le flux de ciblage côté CI se résume à trois appels HTTP :

curl -X POST http://localhost:8000/park      # reset vers une position connue
curl -X POST http://localhost:8000/yaw/20    # rotation vers le bureau du coupable
curl -X POST "http://localhost:8000/fire?shots=2"

L’appel /park est plus important qu’il n’y paraît. Puisque le lanceur n’a pas de retour de position, le serveur estime l’angle courant en suivant le temps de rotation des moteurs. Cette estimation dérive. Un choc sur le hardware, une commande interrompue, ou simplement l’imprécision du tracking temporel — tout s’accumule. Le parking pousse les deux moteurs contre les butées physiques en balayage complet, ce qui garantit l’alignement quelle que soit la représentation interne du serveur. Sans ça, la visée est une approximation.

La référence complète de l’API est dans le repo. Il y a aussi une UI web si vous préférez cliquer plutôt que curl.

Docker ne connaît pas l’USB

Faire tourner ça dans un conteneur Docker sur le cluster, c’est là que les choses ont commencé à devenir intéressantes : les conteneurs ne voient pas les périphériques USB par défaut.

Le mount devices dans compose.yaml expose le bus USB au conteneur :

devices:
  - /dev/bus/usb:/dev/bus/usb

Pas suffisant. Première exécution : USBError: [Errno 13] Access denied. Le nœud de device est bien là dans le conteneur, mais il hérite des permissions du host, et sur le host seul root peut l’ouvrir par défaut.

La solution : une règle udev. Déposer un fichier dans /etc/udev/rules.d/, et le kernel applique le bon groupe et les bonnes permissions quand le device se branche. Après ça, l’utilisateur du conteneur peut l’ouvrir sans privilèges élevés. La règle est fournie avec le projet, les instructions d’installation sont dans la doc.

WSL2 a rendu ça intéressant

La moitié de l’équipe tourne sous Windows avec Docker Desktop sur WSL2. C’est là que ça devient créatif.

WSL2 n’a pas accès aux périphériques USB par défaut : le kernel Windows les détient, et le mount devices seul ne fait rien parce que WSL2 ne voit simplement pas le hardware. La solution est usbipd-win, qui transfère le périphérique USB de Windows vers le kernel WSL2 par IP. Une fois ça fait, le chemin Linux fonctionne à l’identique : règle udev, mount devices, terminé.

L’attachement ne survit pas aux redémarrages, cependant. usbipd v4+ a ajouté un mécanisme de policy qui automatise la reconnexion, ce qui a mis fin au mystère du “ça marchait hier” qui nous agaçait depuis des jours.

Ce qui nous a vraiment surpris

Le positionnement temporel fonctionne suffisamment bien. Sans encodeurs, on s’attendait à ce que le tracking d’angle soit quasi-inutilisable. En pratique, le parking avant chaque séquence le maintenait assez précis pour viser un bureau spécifique de manière fiable. Pas au millimètre, mais la précision missile en mousse, ça convient.

Le mount devices est nécessaire mais pas suffisant. L’erreur de permission était déroutante précisément parce que le device était clairement visible dans le conteneur. La règle udev est la partie que la plupart des tutoriels passent discrètement sous silence.

La règle café n’a plus jamais été la même après ça. Une fois le lanceur câblé au pipeline, les builds cassés sont devenus beaucoup plus motivants à corriger.

guillaumedelre/dream-cheeky-thunder

FastAPI + Docker + PyUSB — contrôle HTTP pour le lance-missiles USB Dream Cheeky Thunder. Pull requests bienvenus, surtout si vous avez une meilleure approche de calibration d'angle.