Le matériel tient dans la main. Il s'agit d'un dongle WiCAN, un boîtier basé sur la puce ESP32-S3, fabriqué par la petite société australienne MeatPi. Cette ESP32, c'est une puce Wi-Fi minuscule et bon marché qu'on retrouve dans une foule d'objets connectés faits maison.

Vous le branchez sur le port OBD-II, cette prise normalisée présente sur toutes les voitures vendues depuis le début des années 2000, celle que le garagiste utilise pour lire les codes défaut. Le boîtier s'allume tout seul dès que la voiture est sous tension.

Ensuite, il se configure en Wi-Fi exactement comme n'importe quel objet connecté, et rejoint votre réseau domestique. Rien de sorcier. À partir de là, Home Assistant le voit comme un appareil parmi les autres.

Pour dire ça plus simplement, vous pouvez suivre depuis votre téléphone le niveau du réservoir, l'intervalle avant la prochaine révision, la température du liquide de refroidissement ou encore la pression des pneus, et récupérer au passage les alertes moteur et batterie. De quoi savoir si l'auto a assez d'essence avant même de descendre dans le garage.

Le firmware WiCAN est open source et disponible sur GitHub, et The Stock Pot a partagé sa propre configuration au format YAML, le fichier texte qui décrit à Home Assistant quoi afficher et comment.

Sauf que voilà, ce n'est pas vraiment du plug-and-play. Chaque constructeur range les données à sa façon dans le calculateur de la voiture, ce qui passe par le CAN bus, le réseau interne par lequel tous les ordinateurs de bord se parlent. Du coup, il faut un réglage spécifique à chaque modèle, comme le précise d'ailleurs la documentation officielle de MeatPi.

Le dongle ne se limite pas à Home Assistant. Il fait aussi le pont vers MQTT, un protocole de messagerie léger très utilisé en domotique, et sait alimenter des applis comme RealDash pour fabriquer des tableaux de bord sur mesure. Il passe même en veille sous le milliampère quand la tension chute, histoire de ne pas vider la batterie pendant que la voiture dort. Pas mal comme idée non ?

Source : Hackaday

Mais le plus dingue, ce n'est pas d'avoir réussi à caser tous les composants car malgré ce qu'on pourrait croire, trouver des pièces assez fines, c'était la partie facile. Le vrai cauchemar, c'est la mécanique car à cette épaisseur, tout devient fragile. Le moindre pli, la moindre pression localisée, et paf, les soudures lâchent.

Krauseler a donc conçu des "îlots" rigides autour des puces et des zones de souplesse calculées ailleurs, pour que la carte plie sans jamais forcer sur les points sensibles.

Et la partie qui va parler aux bidouilleurs, c'est le circuit imprimé. Plutôt que d'attendre 3 semaines une commande de flexPCB chez un fabricant à l'autre bout du monde et de prier pour que ça marche, il a tout simplement gravé le sien à la maison.

Du ruban Kapton avec une feuille de cuivre laminée, une couche de photorésine, et une imprimante 3D détournée en machine de photolithographie pour insoler les pistes.... Ajoutez à cela le pochoir pour la pâte à souder, qu'il a fabriqué en empilant du film photorésine à usage unique, et voilà.

Si vous avez déjà tenté de fabriquer un circuit au marqueur , c'est le même principe, mais poussé à un niveau de dingue.

Le moment le plus douloureux, de ce que j'ai compris, ça a été le branchement de l'écran. Les connecteurs étaient trop épais, alors il a soudé chaque fil à la main en retenant sa respiration tellement c'est petit.

Maintenant, le point faible c'est la batterie. Un accu LiPo aussi fin, ça n'aime ni la chaleur, ni les chocs, ni qu'on s'assoie dessus avec le portefeuille dans la poche arrière. Une mini perforation et hop ça part en fumée, au sens propre.

Krauseler le reconnaît sans détour, et c'est sa plus grosse contrainte. Mais rassurez-vous, il bosse déjà sur des feuilles d'acier inox pour blinder l'accu contre la pression. Pas simple quand on sait que chaque solution crée un nouveau problème...

Bon, et qu'est-ce qu'on en fait au juste de cette Muxcard ?

Hé bien pour l'instant le proto affiche surtout des trucs sur son écran e-paper et joue les cartes de visite qui claquent. Mais pour moi, son potentiel qui fait rêver, ce serait d'imaginer qu'avec le NFC en lecture-écriture et l'ESP32, vous avez là de quoi bricoler un générateur de codes 2FA, un gestionnaire de mots de passe hors ligne, un portefeuille de QR codes pour vos billets de transport et autres, un portefeuille crypto, voire un petit outil de pentesting dans l'esprit du Flipper Zero .

Le tout dans un objet qui se glisse dans votre portefeuille sans que personne ne remarque la différence. En fait, le seul vrai frein, c'est qu'il faut savoir coder son propre firmware Arduino pour en tirer quoi que ce soit.

Maintenant, est-ce qu'on peut le refaire chez soi ?

Bien sûr, Krauseler a mis les schémas, le layout et un firmware d'exemple sur son GitHub mais attention quand même, c'est sous licence CC-BY-NC-SA, donc vous avez le droit de vous amuser à le reproduire mais pas de le vendre.

Maintenant, je pense que vous l'avez compris, reproduire ce truc relève de l'exploit. Il faut l'équipement de photolithographie, une soudure de précision de chirurgien, et surtout une batterie de moins d'un millimètre d'épaisseur que lui-même galère à sourcer. Et sur le coût total de tout ça, on n'a pas l'info ! Dommage, j'aurais bien aimé savoir combien ça coûte.

Bref, c'est moins un produit qu'une démonstration de force. Et c'est surtout une preuve de plus qu'un passionné seul peut encore repousser des limites que l'industrie jugerait pas assez rentable pour s'y coller...

Source

L'affichage passe par un écran e-paper, le même type d'écran que sur une liseuse, qui ne consomme du courant que pour changer d'image. Pour détecter quand vous secouez l'objet, gokux a ajouté un accéléromètre MPU-6050, le capteur de mouvement qu'on trouve dans les manettes et les téléphones.

Et une petite batterie Li-Po alimente l'ensemble. Rien d'introuvable, tout se commande en ligne pour une poignée d'euros.

Le bon point, c'est que tout est embarqué. Le gadget stocke plus de 3 000 prédictions et fonctionne entièrement hors ligne, donc pas besoin de connexion, pas de serveur, pas d'appli.

Votre oracle de poche marche même au fond d'une cave. L'écran e-paper apporte un vrai plus ici : une fois la prédiction affichée, elle reste lisible même batterie vide, comme une vraie page de papier. Et gokux n'a pas oublié de glisser deux modes bonus, accessibles via les boutons sur le côté : un lanceur de dés et un tirage à pile ou face. De quoi régler vos petits dilemmes du quotidien sans même sortir le téléphone.

Le projet est entièrement documenté sur Instructables , vous y trouvez la liste des pièces, le câblage, les fichiers à imprimer en 3D, le code et même les instructions pour ajouter vos propres prédictions. Comptez quelques dizaines d'euros de composants et une soirée de montage, pas plus. C'est le projet idéal à offrir, ou à bricoler avec un ado curieux d'électronique.

Et comme le code est ouvert, rien ne vous empêche de remplacer les 3 000 messages d'origine par vos propres blagues, citations ou vannes pour vos collègues. C'est exactement le genre de projet parfait pour débuter, assez simple pour ne pas décourager, assez complet pour apprendre à manipuler un ESP32 et un écran e-paper en même temps.

Bref, ça ne sert objectivement à rien, et c'est précisément pour ça qu'on a envie d'en monter un.

Source : Hackaday

Et pour comprendre pourquoi c'est une vraie bonne nouvelle, il faut se rappeler d'où on vient. Chrome propose quand même Web Serial depuis 2021 mais Mozilla a toujours considéré qu'un accès série accordait trop de contrôle sur un appareil, sans la moindre authentification. Et ils n'ont pas tord... D'ailleurs Apple, de son côté, campe toujours sur cette position et qualifie carrément la spec de dangereuse, notamment à cause des risques de fingerprinting .

Mais ce qui a fait bouger Mozilla, c'est un revirement progressif en interne. En 2022, Bobby Holley, le CTO de Firefox, a rouvert le dossier, puis en 2024, il a posé ses conditions, à savoir un mécanisme de contrôle par add-on et un consentement clairement formulé. Et le résultat, on peut le voir dans l'implémentation finale, puisque l'autorisation marche par site et par port. C'est bien puisqu'un site ne voit absolument rien tant que vous ne lui donnez pas la main, et ne récupère aucune liste des appareils branchés, ni aucune info de fingerprinting exploitable au-delà du port que vous sélectionnez vous-même.

J'étais le premier à pester contre Mozilla pour cette absence de support. Parfois je les trouve trop prudent, au delà du raisonnable, ce qui les mets en décalage avec ce que proposent les autres et ce qui fait leur fait perdre bêtement des parts de marché.

Mais c'est vrai aussi que la prudence sur ce genre d'API qui touche directement au hardware, c'est ce qu'on attend tous d'un navigateur qui mise tout sur le respect de la vie privée de ses utilisateurs. D'ailleurs, pour les parano ou les admins système (oui c'est pareil ^^), sachez qu'en environnement Firefox Enterprise, Web Serial est désactivé par défaut.

Au-delà du flashage de cartes, les usages réels sont déjà très nombreux. Un ingénieur de Mozilla, Florian Quèze, s'en sert par exemple pour lire la consommation d'un compteur USB d'énergie standard (du genre AVHzY C3 ou Joy-IT TC66C) et balancer les données directement dans le Firefox Profiler. Les imprimantes 3D, les briques LEGO programmables, les Raspberry Pi Pico, tout ce petit monde cause série et devient ainsi pilotable depuis une page web.

D'ailleurs je vous parlais récemment de CANviz, qui analyse le bus CAN de votre bagnole directement dans le navigateur, hé bien c'est typiquement le genre de truc que Web Serial rend possible sans app native.

Après la spec Web Serial traîne toujours au Web Incubator Community Group, donc rien n'est gravé dans le marbre mais cela dit, Mozilla pousse pour une vraie standardisation via le WHATWG, ce qui n'était pas gagné vu d'où on est parti.

Voilà, allez, je vous laisse, j'ai un dafalgan qui m'attend ^^

Source

Avec cette seule règle, ça fonctionne. Mettez deux groupes de badges désynchronisés dans la même pièce, et en quelques instants tout le monde s'aligne sur l'horloge la plus avancée, puisetdéroule les mêmes animations lumineuses en même temps. D'habitude, synchroniser une flotte d'appareils, ça demande un serveur, une désignation de maître et une négociation en bonne et due forme entre tout ce petit monde. Là, rien de tout ça. Cette absence de mémoire partagée est même ce qui rend le système très solide : un badge qui arrive, qui repart, qui tombe en panne de batterie, rien de tout ça ne flingue la synchro.

Niveau matériel, c'est très accessible : un microcontrôleur ESP32, un anneau de 16 LED RGB adressables (le genre de LED qu'on pilote une par une), une batterie et un support imprimé en 3D. Rien d'exotique, rien de cher. Le code est publié en open source sur GitHub, donc n'importe qui peut reproduire le projet et s'en inspirer. Le tout revient à quelques euros de composants pour chaque badge, de quoi en fabriquer toute une fournée pour un atelier ou un festival.

CrowdClock a été monté avec des jeunes au sein d'une association qui s'appelle Inclusive Bytes, pour un festival. L'idée derrière tout dépasse donc le simple gadget : la foule ne regarde plus le spectacle lumineux, elle le compose. Pour beaucoup de ces jeunes, c'était probablement le premier contact avec les systèmes distribués, et c'est difficile de trouver meilleure démo.

Source : Hackaday

Ensuite vous la fixez sur un axe motorisé piloté par un ESP32 (un petit microcontrôleur Wi-Fi du même style qu'un Raspberry Pi en plus modeste) qui fait tourner doucement la pièce via un moteur pas-à-pas. La pièce trempe à moitié dans la cuve d'électrolyte, et la rotation se charge du reste. Au bout d'une nuit complète, le cuivre s'est déposé uniformément sur toute la surface.

La cuve elle-même est fabriquée maison en acrylique, dimensionnée juste pour la zone immergée. Une carte électronique custom gère le moteur, un boîtier imprimé en 3D protège l'ensemble.

Une fois le cuivrage terminé, Hendrik polit la couche obtenue puis enchaîne avec d'autres bains pour ajouter d'autres métaux par-dessus si besoin, comme du nickel ou de l'or. Le résultat ressemble à une pièce métallique pleine, alors qu'en dessous c'est juste du plastique imprimé.

C'est exactement le genre de bricolage qui ne paie pas de mine mais qui débloque un truc bien utile. Une cuve d'électrolyse pour un casque ou une grosse pièce cosplay, c'est plusieurs centaines d'euros de produits chimiques, sans compter la place que ça prend dans un atelier.

Là, l'investissement matériel se réduit à un moteur pas-à-pas à 15 euros, un ESP32 à 5 euros, un bout d'acrylique et la peinture conductrice. Le tout est réutilisable indéfiniment, donc l'amortissement se fait rapidement.

Petit bémol quand même : si vous ne plaquez qu'une seule pièce dans votre vie, c'est sans doute plus simple de payer un pro pour vous le faire et il faut accepter de laisser tourner un montage chimique pendant douze heures dans son garage.

Mais pour quelqu'un qui produit des accessoires en série, des prototypes de bijoux ou des pièces cosplay régulièrement, c'est une vraie alternative.

Source : Hackaday

Concrètement, ce capteur fonctionne comme une grille de 64 capteurs (8 sur 8) qui sort une carte des distances comprises entre 2 cm et 3,5 m. Au lieu de savoir juste "il y a un obstacle à un mètre", le robot récupère une vraie image en relief de ce qu'il a devant lui.

La différence est énorme : un capteur classique vous dit qu'il y a quelque chose, un capteur matriciel vous dit quoi, où, et à quelle hauteur. C'est tout de suite plus exploitable pour un engin qui doit se débrouiller seul, parce qu'il peut distinguer un mur d'une marche, ou un obstacle au sol d'un truc suspendu.

Mellow Labs a greffé ce capteur sur Zippy, son petit robot à chenilles imprimé en 3D et piloté par un ESP32, la puce bon marché qu'on retrouve dans la moitié des projets de bricolage électronique de la planète. L'objectif : faire passer Zippy du mode télécommandé à un vrai mode autonome. Avec sa grille de points, le robot peut enfin voir le sol devant lui et décider tout seul où aller. Enfin, en théorie.

Sauf que voilà, ça ne s'est pas fait en claquant des doigts. Premier souci, la moitié des données du capteur ne servait à rien, parce que la grille captait aussi le sol juste sous le robot. Du coup il a fallu trier, ne garder que la partie utile, et réduire encore le volume de données à traiter.

Mellow Labs a fait plusieurs allers-retours, avec, comme souvent désormais, un coup de main d'un modèle d'IA pour générer le code, avant que l'ensemble tourne enfin correctement !

Source : Hackaday