Le dilemme du maker : d’abord on choisit les composants
ven, 21/08/2020 - 09:51
Cet été, je voulais améliorer la gestion de ma bibliothèque. Celle-ci comprend une cinquantaine d’étagères et plus de 2 000 ouvrages. Mais parfois, je perds un temps fou à trouver tel livre. Et très souvent, je me dis : je l’ai quelque part... Bref, quelles solutions seraient utilisables pour améliorer mes recherches ?
Mes premières idées :
1 - mieux organiser les étagères et les livres eux-mêmes : bonne idée en théorie, en pratique je sais très bien que je change de place les livres quand je les remets en place...
2 - faire une base de données avec numérotation des étagères et des livres : en théorie re-bonne idée, mais très long et nécessite beaucoup d’étiquettes ! Et honnêtement, cela manque de fun !
3 - et si j’optais pour le RFID / NFC ? Ah, là, ça devient un peu plus fun.
Bon, l’idée 3 me plaît bien. Et justement, cela faisait pas mal de temps que je voulais faire un petit POC RFID / NFC (après ma mailbox geek). Rapidement, l’idée que l’on imagine se heurte à petit truc : la réalité ! Eh oui, que l’on soit développeur ou maker, on est parfois un peu naïf.
Donc. Initialement, je me dis : un tag sur chaque livre. Rapidement, je me rends à l’évidence :
1 cela me prendrait un temps fou pour écrire chaque tag avec les bonnes informations
2 au niveau usage ce n’est pas top, car : oui chaque livre possède son tag, mais comment le repérer ?
3 pour résoudre le point 2 : je me dis qu’il faut rajouter un numéro d'’étagère et faire une base de données. Mais cela exige un double travail de saisie...
4 et quand tu regardes le coût pour 2 000 tags, ça te calme un peu :-)
Donc, étage 2. Tu reprends le projet. Et tu vas aller au plus simple : un tag par étagère avec la liste des livres dedans.
Avantages de cette approche :
– on simplifie le POC et on réduit les coûts
– moins de saisie et donc moins d’écrire sur le tag (qui est très limité en stockage)
Inconvénients de cette approche :
– respecter l’étagère du livre quand on le remet en place
– la liste des livres doit être simplifiée pour ne pas déborder de la mémoire disponible
– dans l’idéale, avoir une liste des étagères avec les livres dans un simple fichier plat
En soi, ce POC n’a rien d’excitant au niveau technique. Il nous faut des tags, une app NFC pour lire et écrire ledit tag (typiquement sur son smartphone), des étiquettes pour numéroter les étagères et un peu de patience.
Level +1 : rajouter une board de prototype
Pour faire un peu plus excitant, il nous faut un lecteur de tag qui ne soit pas notre smartphone. Donc pour se faire, rapidement, on opte pour une Arduino, une shield RFID / NFC. Dans le premier choix, on prend une simple Arduino Uno et une shield PN532. Pour les tags, nous optons pour les classiques NTag215 et 216 (origine : NXP). Ces tags sont faciles à trouver, petits et peu chers.
Le lecteur est donc un des classiques : un PN532. Il se pilote en SPI ou I2C. Et il fonctionne avec nos tags. Certains tags nécessitent un lecteur précis... Nos besoins sont en réalité très simple : détecter le tag, lire le tag, récupérer les informations stockées. Les données écrites sont dans la partie NDEF du tag. Et là, les problèmes vont commencer...
Finalement, un problème arrive très vite : quelle librairie choisir ? Nous en avons essayé plusieurs. La moins pire, ou la plus efficace, selon son humeur du moment, c’est la librairie Adradruit PN532. Généralement, Adafruit produit des libs plutôt stables et efficaces. Le brochage en SPI ne pose aucun problème. On modifie juste la numérotation des broches dans le début du code. Finalement, les samples reconnaissent pas trop mal les tags et nous voyons les données NDEF même si cette partie est pauvrement supportée. Prochaine étape : rajouter un écran de type e-ink et peaufiner la récupérer des messages NDEF qui nous pose encore un problème. La récupération actuelle se fait en hexa ce qui n’est pas top, car en soi, les messages NDEF sont en plain text et il faut récupérer les bonnes pages de données pour les concaténer.
vNext : un peu de brainstorming ne fera pas de mal
Donc si je résume : j’ai un POC un peu bancal. J’ai commencé à numéroter les étagères. Les Tags sont installés et je commence à les écrire. Côté lecteur, je vais sans doute revoir le concept. Soit je trouve le moyen de mieux récupérer et afficher les messages NDEF (= pas avec un formatage brut) avec la lib actuelle ou une autre (mais là c’est la galère, car finalement, il y a plein de libs mais à la stabilité douteuse et avec une documentation parfois inexistante). Soit je monte un POC sur une autre board, telle qu’une board micropython de type PyBStick... Je me dis que la lib python est peut être meilleure...
Commentaires
Je reste dubitatif, je pense que les ranger par ordre alphabétique (par rapport à la 1er lettre) passe il suffit de se prendre les 26 lettres de l'alphabet via séparateur (voir les imprimer en 3D) et de mettre son livre au bon emplacement 1/26 bon on peut reporcher que le groupe de livre ne se pas égaux par lettre et que les L ou autres peuvent être importants mais après avec un peu de pratique on peut faire sur la 1er lettre du mot important pour mieux répartir les livres. Enfin bref plusieurs méthodes à chacun de voir ^^
Dans un autre domaine, j'ai géré ma cave à vin (plusieurs centaines de bouteilles) avec un site et des étiquettes papier avec un QR code. A chaque fois que je scanne, ça décrémente la base en backend. Je pourrais certainement relire le QR code papier dans 20 ans, pour le NFC, c'est moins sûr!
Oui, cela prend du teps de faire l'inventaire mais ensuite, c'est super rapide et simple!
Pour NFC, il y a pas mal de lecteurs supportés à traver .NET Core Iot: https://github.com/dotnet/iot/tree/master/src/devices. NDEF n'est pas supporté en tant que tel mais écrire et lire and une carte Type A l'est. NDEF n'est qu'un sur ensemble assez simple et basic.
Autre approche : Acquérir un lecteur de code à barre (à partir de 15€) et utiliser l'ISBN ... Du coup plus de hardware, plus de composants ... Là on peut envisager l'option 1 et/ou 2.