Teddy Payet

Je suis passé à SPIP 4.0

Teddy Payet — 2021-09-14T06:00:00Z

Ça y est ! Je suis passé à SPIP 4.0 ! Je ne sais pas si vous avez suivi, mais SPIP 4.0 est sorti cet été pour ses 20 ans. Il y a pas mal de petites nouveautés, je vous laisse lire l'article sur le Blog de SPIP qui en parle très très bien.

Introduction

Je me suis décidé à passer à SPIP 4.0 en cette rentrée 2021. Pour être honnête, j'avais un peu peur de ce passage car j'avais quitté un peu l'actualité de SPIP (ses développements, son évolution, etc.). Je ne savais pas où j'allais mettre les pieds même si j'ai toujours aimé ce CMS. Je vais vous parler de mon chemin vers son adoption.

Par beau temps

Mon site était sous SPIP 3.2.9. Et j'utilise Zcore avec un template maison basé sur Bootstrap. Jusque là, rien de bien méchant. J'ai décidé de profiter de cette montée de version de SPIP pour revoir mon template et avoir également la dernière version de bootstrap : 5.1.1

J'ai dû retravailler les différentes classes que j'avais. Pas trop méchant. J'ai fait les choses étape par étape. Avant de migrer pour SPIP 4.0, j'ai fait la mise à jour de SPIP en 3.2.11 qui permet d'avoir la compatibilité PHP 7.4 (la version minimum pour SPIP 4.0 est PHP 7.3).

Mon hébergeur, OVH pour ne pas le citer, prend en charge cette version de PHP. Ouf.

Début septembre, j'ai mis en ligne mon template avec bootstrap 5.1.1 et SPIP 3.2.11. Cela me laissait le temps de tester en "live" la compatibilité avec PHP 7.4. Une lettre à la poste par beau temps !

Puis vint la pluie…

SPIP 3.2.11, PHP 7.4, Boostrap 5.1.1, c'était trop beau pour être vrai ! J'ai testé en local le passage à SPIP 4.0. Depuis le back-office, belle page avec la nouvelle interface de l'espace privé. Responsive, prenant toute la largeur de la fenêtre, c'est beau ! Certains diront que l'espace privé n'a pas changé depuis sa création, mais en fait tout a changé ! Il est plus light, plus agréable avec ces nouveaux jeux d'icônes SVG.

Puis, j'ai cliqué sur le bouton "voir le site public"… Et patatra ! La page met du temps à se charger… Je me dis que ce n'est que le cache qui se recalcule… Et ben non, j'ai une belle erreur php me disant soit que je n'ai suffisamment de mémoire allouée (mouais… 128Mo puis 256Mo…), soit qu'il ne trouvait pas une variable dans les scripts php…

Panique à bord !

Je cherche… désespérément… Je regarde mes scripts PHP maison en pensant trouver la bonne piste… Et non, rien y fait. J'y passe des heures sur le sujet, je change même d'environnement : d'un raspberry Pi avec LAMP, je passe sous MAMP sur mon mac et même en preprod sur mon espace d'hébergement. Rien y fait. Toujours ces erreurs aléatoires. Pourtant, tout fonctionne sous SPIP 3.2.11 en PHP 7.4.

Je sais que la gestion des documents et des logos a changé sous SPIP 4.0. Et j'utilise avec grand plaisir les filtres sur mes templates. Je décide alors d'aller vers cette piste.

Mes images sur mon site sont en moyenne à 2500px de largeur. Ça me permet d'avoir des images de bonnes dimensions et de pouvoir les redimensionner selon mon design. Je décide de venir à une version plus allégée de mes filtres. Suppression des filtres image_passe_partout, image_recadre, image_aplatir et j'en passe. Rien y fait !

Je peste sur mon idée de passer à SPIP 4.0 avec la méthode R.A.C.H.E. Même en sachant que SPIP 4.0 avait changé son approche pour les logos, je ne pensais pas que cela allait être aussi compliqué.

J'utilise un modèle nommé "logo.html". Ce modèle me permet de ne pas dupliquer mes filtres pour les visuels de mes articles, rubriques et cie. Je décide de l'ouvrir dans PHPStorm par raccourcis clavier "Search everywhere". Je tape donc modeles/logo.html. Et OH ! Surprise ! le plugin medias utilise un modèle logo en SPIP 4.0.

Ah tiens… En fait, j'étais tellement subjugué par la nouvelle interface que je n'avais pas remarqué qu'aucun de mes logos d'articles ne s'affichait. J'ai regardé en base de données dans la table spip_documents comment SPIP indique les logos d'articles. Je pige le truc rapidement. J'adopte la méthode R.A.C.H.E… La migration des données par SPIP n'a pas bien insérée les "anciens" logos dans la table de documents. Que cela ne tienne ! Je crée un petite fonction PHP qui va insérer dans la bdd mes logos d'article (de rubriques et de sites) en respectant les bons chemins (exemple : logo/arton-XX.png). Ça se fait rapidement.

Je reviens au fichier modeles/logo.html du plugin medias. Je consulte ce fichier et constate son extrême simplicité et efficacité :

[][(#ENV{lien}|?{})]

Je n'ai pas trouvé exactement où était appelé ce fichier. Mais j'ai pour principe de ne jamais utiliser les même noms que dans un framework. Cela évite les effets de bord indésirables. Donc, je renomme mon modèle maison en modeles/visuel.html. Cela colle bien à son utilisation première.

Une île paradisiaque au loin

Suite à ce renommage, je commence à avoir de nouveau un début de page sur mon espace public. Il y a encore quelques petits effets à régler. Des warnings plus compréhensibles. Je m'attèle à régler ça.

J'adopte de façon systématique (pas comme les antibiotiques) l'utilisation de modeles/visuel.html, je vide les répertoires local, tmp/cache et tmp/logs/ avant chaque grosse modification. Le site est à nouveau opérationnel et je retrouve le même template que j'utilisais en SPIP 3.2.21 en production en début de mois de septembre.

Je respire enfin. L'espoir en moi renait.

Un avenir radieux

Je teste toujours sur mon propre site la dernière version de SPIP avant de la proposer à mes clients. Ainsi, j'aurais déjà essuyé les plâtres. Il sera plus simple pour passer la peinture chez les clients.
L'erreur était toute bête, mon modèle logo gênait SPIP dans sa nouvelle monture. Ma surcharge changeait le comportement attendu. Je suis incapable de dire exactement pourquoi cela faisait planter PHP. Je n'ai pas cherché à le savoir non plus pour être franc.

Je constate surtout que SPIP est plus rapide. Merci PHP 7.4, merci à la core team d'avoir rendu SPIP plus léger et véloce. Je sais que si je passe à PHP 8.0, cela sera encore plus rapide. Mais j'ai plusieurs sites sur mon hébergement OVH qui ne sont pas compatibles PHP 8.0.

Vous pouvez consulter le résultat de cette migration en lisant cet article. En effet, en ce mardi 14 septembre, mon site est officiellement sous SPIP 4.0 sous vos yeux ébahis !

Et la suite ?

J'ai commencé à travailler sur mes plugins de la communauté pour une compatibilité avec SPIP 4.0 :

Info SPIP
Socicon
Lister les constantes PHP de SPIP
Lister les pages de configuration
Lister les pages ?exec=xxx
Lister les fonctions PHP de SPIP
Lister les objets principaux de SPIP
Lister les dossiers
Commits de projet
jQuery Vector Maps
Projets (je ne fais que la maintenance de ce plugin, je n'en suis pas le créateur, je tiens à le préciser)
Sites pour projets

Il m'en reste quelques uns à migrer dont le plus gros : InfoSites. Il est dans les bacs. Il est dépendant d'un plugin qui est en attente de mise en compatibilité avec SPIP 4.0. Plus qu'un pour pouvoir livrer la v2 de ce plugin qui me tient à cœur.

Fin de vie pour…

La liste précédente est plutôt longue. Mais il y aura des "laissés pour compte" dans la course à SPIP 4.0. En effet, selon ma vision, un plugin n'a plus lieu d'être :

Agrandir la largeur de page (SPIP_hop pour les intimes) : l'interface de l'espace privé a été revu pour prendre toute la largeur de la fenêtre et va même plus loin que ce qu'offrait spip_hop. Je ne vois pas l'utilité de le maintenir pour SPIP 4.0

Pour le moment, je n'ai plus le temps/besoin pour certains autres plugins. Donc leur mise à jour est repoussée à une date ultérieure :

Déréférencer les médias ;
Nettoyer la médiathèque.

Voilà le périple que j'ai connu avec SPIP 4.0. Je n'ai pas de regrets pour mon passage vers cette dernière version. Au contraire. :-)

La domotique et moi, 2ème partie

Teddy Payet — 2020-04-29T07:00:00Z

Alors, avez-vous pu lire la 1ère partie ? Si cela n'est pas fait, je vous invite à le lire avant d'entamer la lecture du présent article. C'est fait ? Parfait.

Je vais continuer de vous exposer simplement et concrètement ma vision de la domotique, ce qui m'y intéresse. Nous allons voir les points suivants :

L'accessibilité, l'interface homme/machine
Le contrôle et l'automatisation
L'open source

L'accessibilité, l'interface homme/machine

De part mon expérience professionnelle et au fil de mes rencontres, j'ai acquis la conviction que l'utilisateur doit pouvoir prendre la main sur la machine (Skynet ?). De ce fait, si je ne peux contrôler un produit manuellement sans passer par internet ou autre, alors c'est une mauvaise intégration du produit.

Il en va de même pour les solutions logicielles accompagnant ces produits qui doivent être simples de prise en main. En effet, par exemple, ma femme doit pouvoir configurer/désactiver une alarme sans devoir toucher à une seule ligne de codes. De même, mes enfants doivent pouvoir commander une lumière sans difficulté particulière.

Un second volet de l'accessibilité est le code source de ce que j'utilise pour contrôler mes appareils connectés. J'utilise des produits de différentes marques, mais ils doivent pouvoir communiquer entre eux. Si une solution open source existe, j'irai vers cette solution. Mais si une solution payante et abordable fait la même chose en moins compliquée et plus ergonomique, je testerai cette solution. Si elle s'avère fiable, je prendrais cette solution payante.

Encore une fois, quelque soit la solution, je dois pouvoir interagir avec elle depuis ma centrale, ma “box” domotique.

Le contrôle et l'automatisation

Le nerf de la guerre ! Pouvoir contrôler et automatiser est essentiel dans la domotique. Ici, ma philosophie de développeur prend les devants : si je fais une action plus de 2 fois, alors c'est que je peux l'automatiser ou la simplifier. Si je ne sais pas le faire, c'est que je n'ai pas la connaissance pour le moment de le faire.

Grâce à cet état d'esprit, en outre de pouvoir contrôler par la voix les lumières, je réfléchis systématiquement à comment simplifier notre vie au quotidien.

Tous les jours, à 00h25, le mode nuit s'active à la maison (extinction de toutes les lumières, volume des GHM et d'Alexa à 10%). A 6h30, le mode jour se met en place (volume des médias players à 60%). Ceux sont des actions très simples. Une autre automatisation est d'allumer la lumière de la pièce de vie si le soleil s'est couché et qu'il y a du monde à la maison.

Je pourrais automatiser encore des éléments dans l'appartement mais il me faut quelques capteurs de plus pour y arriver. Chaque chose en son temps.

Open source

Comme je l'ai déjà abordé précédemment, je préfère des solutions open source. Malheureusement, ce n'est pas toujours possible, surtout dans un pays francophone. En effet, si je désire avoir un contrôle par la voix des mes produits, il existe pléthore de solutions open source d'assistants personnels virtuels (Mycroft, Kalliope, Stephanie, Open Assistant, Jasper, Jarvis, etc.) Si ces solutions ont le mérite d'exister, les voix sont anglaises. Je ne suis pas contre, mais tout le monde n'est pas bilingue à la maison. Si des solutions avec des voix françaises existent, elles sont payantes, avec licence.

Ceci est un point important notamment pour mon choix de Google Home Mini. Google est très en avance sur le contrôle par la voix dans plusieurs langues. De plus, Google a mis à disposition des API qui permettent des interactions avec ses appareils.

Toutefois les Google Home Mini ne seront chez moi qu'une interface vers ma domotisation. J'ai fait des recherches sur internet de solution de “système domotique” :

OpenHab
Home Assistant
Jeedom (Cocorico ! Une solution française)
Domoticz

Ceux sont les noms que j'entendais le plus parler sur la toile. Mon choix pour ces 4 solutions est basé sur plusieurs critères :

Rapide à prendre en main ;
Compatible Raspberry Pi 3 ;
Flexible ;
Communauté importante et réactive ;
Bien documenté ;
Pas de licences à payer (ben oui, on est en open source là)
Un maximum de compatibilité avec des produits/API ;
L'esthétique de l'interface.

La décision finale s'est portée sur Home assistant. Il est compatible avec beaucoup d'outils que j'utilise déjà. Ce qui a fait pencher la balance est également un des Youtubers que je suis : DrZzs. Son discours dans les vidéos de sa chaîne m'a conquis. De plus, Home Assistant a le vent en poupe en France. Je ne m'éterniserai pas plus sur ce choix car cela n'est pas le but du présent article. Mais une série d'articles apparaîtra prochainement sur le sujet.

Quoiqu'il en soit, j'ai installé Home Assistant sur mon Raspberry Pi 3+ sur une carte MiniSD de 32Go grâce à Hass.io. Après quelques configurations, il n'y a que Home Assistant (Hass.io ou HA pour les intimes) qui sera connecté à des solutions propriétaires telles que Google (cf. Google Assistant). J'ai ajouté à HA une clé USB Conbee 2 qui me permet de contrôler des produits compatible avec le protocole Zigbee. Comme Google Assistant est connecté à mon compte Hass.io, il ne verra que du feu quelque soit le protocole que j'utiliserai sur HA. Magique. Un seul point d'entrée.

Conclusion

Voici ma vision de la domotique ou du moins ce qui m'intéresse dans la domotique. Je n'ai pas abordé tous les points de la domotique tels que la vidéo-surveillance (caméras) ou la sécurité (les serrures connectées), j'en parlerai peut-être plus tard. Tout le monde n'a pas la même vision de la domotique ni les même centres d'intérêts. Mon épouse n'aime pas être envahie par les “robots” (encore toi Skynet ?), elle veut pouvoir décider par elle-même de ce qu'elle désire faire (et elle a raison). Moi, j'aimerai aider mes enfants à être plus autonomes et également pouvoir avoir un oeil protecteur sur eux (ils ont 5, 10 et 13 ans). A cela, j'aimerai me faciliter la vie (flemmard un développeur ? “C'est pas faux”).

Au fil du temps et de mes installations, je voudrais rendre plus discret la domotique et indispensable.

La domotique et moi, 1ère partie

Teddy Payet — 2020-04-27T07:00:00Z

Je voulais aborder ce sujet depuis un moment déjà : ma vision de la domotique. Comme vous avez pu le lire sur mon blog, j'ai quelques articles qui tendent vers ce domaine ou plus exactement un assistant personnel. Le MagicMirror est un helper, une sorte de mini assistant personnel mais n'est pas de la “home automation”. Je vais essayer de partager avec vous ma vision. Je n'essaie pas de vous convaincre, j'essaie juste de poser sur le papier mon concept. Ce qui permettra de vous faire comprendre ma ligne éditoriale sur le sujet dans mes articles.

Mon profil avant tout

Avant de commencer de vous parler de la domotique pure et dure, je voudrais surtout me présenter pour que vous puissiez comprendre mes possibilités, mes compétences mais aussi mes limites.

Je suis de formation initiale graphiste ou “designer”. J'ai découvert le monde du web et notamment du développement de façon autodidacte. Je suis aujourd'hui Lead Developer PHP. J'installe des VM linux pour mes développements (merci vagrant). Donc, je n'ai pas vraiment peur de lire des lignes de code si besoin et d'en écrire (si je connais ou comprends le langage de programmation de la solution domotique). Je suis curieux des nouvelles technologies en général, de la SF (ne me demandez pas mon auteur favori, ça ne servira à rien, je n'en ai pas), de l'actualité en général, de l'interaction homme-machine (mais la plus basique qui soit : le comportement d'un utilisateur lambda devant une technologie). Je regarde énormément de Youtubers Makers, DIYers, etc.

Ça, ceux sont mes points “forts”. Maintenant, mes lacunes :

Quand on parle de domotique, souvent, on parle de DIY… Oui, mais je ne fais pas de soudure, pas d'électronique (mon dernier calcul de résistance date d'il y a 25 ans au collège), pas d'impression 3D (pas la place pour le moment). De ce fait, je préfère des solutions ou des produits finis. Je ne saurais pas brancher un ESP8266 avec un relay… Ni même flasher ce même ESP8266…

Dernier point, ma famille et moi-même vivons dans un appartement. Nous ne pouvons pas faire de grands travaux/bricolages pour mettre en place la domotique.

Inspecteur gadget

Comme dirait ma femme, “c'est gadget !”. Oui, ce n'est pas faux de prime abord. Vous vous en doutez, au fil de la lecture de mon blog, vous avez pu voir que je suis un geek, un technophile. Mais j'ai une fibre de “designer”, d'expérience utilisateur.

J'ai démarré l'installation de ma “domotique” avec le MagicMirror pour avoir un tableau de bord. C'est un projet “gentillet” pour démarrer, pour me frotter à cet univers. Le système me paraissait accessible. Je ne me suis pas trompé. Très très rapidement, la deuxième étape était l'installation d'interrupteurs connectés, de la marque Sonoff. Peu cher et facile à installer chez moi. Il y a un aspect financier qui m'intéresse dans la domotique : acheter du matériel abordable. Mais qui dit abordable, ne dit pas de mauvaises qualités.

Par la suite, j'ai pu acheter 2 Google Home Mini pour le prix d'un.

Mon écosystème a commencé à se mettre en place. Des interrupteurs connectés, des Google Home Mini et un Raspberry Pi (celui du Magic Mirror) pour les commander tous. Je ne saurais vous dire exactement combien j'ai dépensé pour faire tout ça, mais ce n'est pas excessif car étalé sur 1 an environ. Pour preuve, j'ai aujourd'hui cet équipement :

3 interrupteurs Sonoff Touch
2 contrôleurs Wifi monocouleur MagicHome
1 prise Zigbee
2 Raspberry Pi 3
Une clé Conbee2
5 Google Home Mini
1 Alexa Echo Dot

J'ai un Google Home Mini (GHM) par pièce principale, j'en ai payé 3 sur 5 à moitié prix lors de promo à chaque fois. Certains, et je peux comprendre, pourront dire que j'offre mes données à une grosse entreprise… Oui, certes. Mais on y reviendra plus tard sur ce sujet spécifique. Les Google Home Mini me permettent de commander mes lumières par la voix, entre autres.

J'ai d'autres utilisations marrantes des GHM. Ce qui ne déplaît pas à mes enfants.

Entre autres, je cherche des produits/solutions ouvertes, au mieux open source. Les Google Home Mini ne sont pas open source, elles sont d'un écosystème propriétaire mais Google permet d'interagir avec leurs produits grâce à des API/SDK gratuitement. Donc, cela me va très bien.

L'économie financière

Il n'y a pas à dire sur le sujet, un des buts de la domotique est l'économie financière ! Si on met en place une domotique sur le chauffage (commande de la température lorsque les personnes sont présentes ou pas à la maison, ouverture des fenêtres, etc.), on peut baisser sa consommation d'énergie. En effet, s'il n'y a personne à la maison, cela ne sert à rien de chauffer à 30° ! Et si on a oublié de baisser la température souhaitée de la chaufferie alors qu'on est déjà à 100 bornes, il nous suffit de se connecter à notre interface pour soit couper le chauffage, soit de baisser la température. Gain de temps, pas de dépenses énergétiques inutiles.

Autre exemple, on a oublié d'éteindre une lumière. Mon installation domotique remarque qu'une lumière est allumée mais qu'aucune personne n'est présente (merci les détecteurs de mouvements !). Alors, elle éteint la lumière pour ne pas éclairer une pièce pendant une semaine alors que vous avez les doigts de pieds en éventail à la plage à plusieurs centaines de bornes de chez vous !

Réussir à maîtriser sa consommation énergétique permet de réduire sa facture, de moins dépenser de pépètes, de pognon. Il y a bien d'autres scénarios possibles liés à la consommation énergétique. Si on se débrouille bien, on peut diviser par 2 certaines factures. A chacun son installation.

Conclusion

Cet aspect financier conclus la première partie de cet article. Il est assez long à lire, je ne voulais pas vous assommez alors que l'idée est simple : s'approprier la domotique. La deuxième partie sera en ligne dans 1 ou 2 jours. Elle abordera ma vision de l'accessibilité, le contrôle, l'automatisation et l'open source dans le domaine de la domotique. Comme d'habitude, je suis preneur de vos retours sur le sujet.

Photo by Yassine Khalfalli on Unsplash

MagicMirror², configuration scriptée, 2ème partie

Teddy Payet — 2020-04-14T22:55:42Z

Comme vous le savez tous, nous sommes en confinement depuis mi-mars. Pour m'occuper un peu en chômage partiel, en plus de ma vie de famille, je me suis inscris à une groupe d'entraide sur le MagicMirror sur Facebook. J'ai eu l'agréable surprise de voir qu'un article de mon blog était cité. Merci de la confiance de ces utilisateurs !
Après quelques échanges, j'ai proposé d'expliquer plus en détail mon installation scriptée et notamment ce à quoi correspond mes différents principaux scripts.

Tout a été déposé sur github (vous pourrez trouver le lien en bas de l'article). Je reprends ici plus ou moins le contenu du fichier Readme.

Cet article est un exemple d'automatisation de la maintenance de mon installation de MagicMirror. Le dépôt github a pour but de montrer la possibilité d'automatiser la maintenance d'une installation d'un MagicMirror.

Introduction

Le dépôt s'appelle mm_config_automate. Son existence n'est que pédagogique. Il n'est en aucun cas un module de MagicMirror.

De plus, je ne suis pas responsable d'une altération de vos données. Il vous faudra tester et adapter chaque script pour correspondre à VOS attentes.

Liste des scripts

L'ensemble des scripts sont en bash. Ils restent simples à comprendre et à prendre en main avec un peu de patience et de lecture. Voici la liste des scripts :

first_install.sh
mm_reset.sh
mm_update.sh
update_files_config.sh
disk_usage.sh

first_install.sh

Ce script permet d'installer l'ensemble des éléments de base pour qu'un MagicMirror puisse fonctionner. Il est à lancer sur une installation toute belle, toute neuve d'un Raspberry Pi 3. Je n'ai pas testé sur un Raspberry Pi 4 pour le moment. Il prend en compte un Raspbian basé sur un Debian Buster (10) mis à disposition des utilisateurs en février 2020.

Il fera dans l'ordre :

sudo apt update -y : Récupère la liste des mises à jour disponibles
sudo apt upgrade -y : Installe quelques mises à jour, ne supprime pas les packages
sudo apt autoremove -y : Supprime tous les anciens paquets qui ne sont plus nécessaires
sudo apt clean -y : Cette commande de terminal libère de l'espace disque en nettoyant les fichiers .deb téléchargés du référentiel local.

Puis :

On active le son par le HDMI ;
Forcer le HDMI ;
Forcer l'affichage vertical de l'écran ;
Enlever des programmes inutiles ;
Installation de quelques packages ;
Installation de Nodejs et NPM selon la méthode indiquée ici : https://github.com/audstanley/NodeJs-Raspberry-Pi
Ajouter les binaires de node dans le PATH ;
Installation de PM2 ;
Enregistrer les variables d'environnement (le home de MagicMirror, ainsi que de PM2) ;
Création du fichier mm.sh dans /home/pi/ ;
Exécution du script d'installation du MagicMirror ;
Sauvegarder les réglages de pm2 et lancement des scripts au démarrage ;

Et enfin, on enregistre le contenu du fichier crontab.txt dans le crontab de l'utilisateur en cours.

mm_reset.sh

Ce script installe MagicMirror à partir du dépôt github dudit projet. Il s'appelle "mm_reset" au lieu de "mm_install" car il supprime le répertoire /home/pi/MagicMirror/ s'il existe. Donc, il faut faire attention à ce point si vous désirez garder une précédente installation.

A son tour, ce script va lancer une série de commandes :

Arrêt de MM grâce à pm2 stop mm ;
Effacer le répertoire de MagicMirror si existant ;
Récupération du dépôt de MagicMirror ;
Passer sur la branche develop de MagicMirror ;
Création des liens symboliques dans MM (custom.css et config.js) ;
Installation des dépendances de MM grâce à npm ;
Lancement du script d'update des modules de MM (cf. update_files_config.sh) ;
Relancer MM sur pm2.

Liens symboliques

Dans le script mm_reset.sh, il est présumé que le fichier "config.js" et le fichier de personnalisation de css vitaux à MagicMirror soient présents dans votre répertoire /home/pi/mm_config_automate/. Un lien symbolique dans /home/pi/MagicMirror/css/ et /home/pi/MagicMirror/config/ sera fait pointant vers votre répertoire mm_config_automate.

MagicMirror n'y verra que du feu !

mm_update.sh

Ce script est plus rapide. Dans ce dépôt d'exemple, il n'est pas utilisé dans le crontab. Il est à utiliser manuellement lorsque MM doit être mis à jour.

Il arrête MM par pm2, puis va dans le répertoire de MagicMirror. A partir de là, le dépôt git est mis à jour avec les derniers fichiers. Une installation et une mise à jour des packages npm sont lancées.

Cela fait, on relance MM sur pm2.

update_files_config.sh

Ce script bash est le nerf de la guerre. Crontab appellera dans notre exemple le fichier update_files_config.sh tous les jours à 00h15.

Ce script contient 2 fonctions clés :

import_module ;
delete_modules.

Après l'utilisation de ces fonctions, une boucle est lancée pour vérifier l'existence du module MMM-AlarmClock. Ce dernier peut utiliser des fichiers mp3 comme sonnerie d'alarme.

Si vous désirez ajouter des fichiers mp3 à votre convenance, il vous suffira de les copier dans le répertoire sounds de votre dépôt "mm_config_automate". Automatiquement, tous les soirs (selon le crontab mis en place), chaque fichier mp3 présent sera copié dans /home/pi/MagicMirror/modules/MMM-AlarmClock/sounds/. Vous n'aurez plus à vous soucier d'autres choses que sa bonne utilisation dans votre fichier config.js

update_files_config.sh : fonction import_module

Cette fonction bash attend un paramètre : l'url vers le dépôt git du module que vous désirez installer sur votre MagicMirror.

Par exemple, si vous désirez utiliser le module de pages de MM, vous devez indiquer dans le fichier update_files_config.sh la commande suivante :

import_module https://github.com/edward-shen/MMM-pages.git

Elle ira dans le répertoire /home/pi/MagicMirror/modules/, vérifiera si le module existe déjà (en gros l'existence du répertoire "MMM-pages") ou pas. S'il n'existe pas, elle clonera le répertoire. Puis :

Accéder au répertoire du module ;
Si un fichier package.json existe, l'installation des packages npm est lancée.

Il faudra utiliser cette fonction autant de fois que de modules désirés. Vous trouverez des exemples dans ledit fichier.
Cerise sur le gateau, si le module existe déjà, il le mettra à jour avec les derniers fichiers provenant du dépôt que vous avez indiqué en paramètre.

update_files_config.sh : fonction delete_modules

Cette fonction se lance après l'ensemble des appels à import_module. Elle a pour but de supprimer les modules présents dans /home/pi/MagicMirror/modules/ devenus obsolètes.

Comme vous le savez, pour utiliser un module dans MagicMirror, nous devons l'avoir téléchargé d'une part dans /home/pi/MagicMirror/modules/ mais d'autre part l'avoir indiqué dans notre fichier config.js.

Si le répertoire /home/pi/MagicMirror/modules/nom_repertoire/ n'est pas indiqué dans ce fichier, le répertoire sera considéré comme obsolète. Donc, qu'il peut être supprimé. La présente fonction vérifiera chaque répertoire dans modules/ à l'exclusion de :

default/
node_modules/

Cela préservera l'espace disque de votre Raspberry Pi et évitera des erreurs dans votre MagicMirror.

disk_usage.sh

Ce script permet de savoir le pourcentage d'utilisation d'espace disque. Dans le présent exemple, si le taux d'utilisation arrive à 90% de sa capacité, un email est envoyé (je vous laisse le soin de configurer le serveur d'envoi d'emails).

Il faut savoir que pm2 écrit beaucoup d'information dans les logs (cela dépend surtout des applications lancées sous pm2 mais c'est un autre sujet). En prenant cela en compte, si le taux d'utilisation excède les 90%, le script lance en premier lieu la commande pm2 flush pour vider l'ensemble des fichiers logs de pm2. Puis vérifie à nouveau le taux de remplissage. Si la commande n'a pas changé la donne, l'email est envoyé.

crontab.txt

Ce petit bout de fichier vous permet d'indiquer l'heure à laquelle vos routines doivent être mises en place.

Dans le présent exemple, voici les routines :

A 0h00 : On vérifie d'abord l'espace disque
A 0h05 : On met à jour les fichiers de mm_config_automate
A 0h10 : On importe le contenu du fichier crontab.txt dans le crontab à 00h10
A 0h15 : On peut maintenant lancer les scripts de routine (update_files_config.sh)
A 0h20 : On relance MagicMirror pour prendre en compte la configuration à jour.
Tous les mois, on redémarre le Raspberry Pi

Si vous êtes parents et/ou assujetti à des périodes de vacances et un planning différents durant ces périodes, il est possible de mettre en place un fichier de config dédié à cette période.

Dans notre exemple, le contenu de config.js et config_vac.js sont identiques. Le but est d'illustrer l'existence des fichiers selon la période. En ayant en tête les dates de vacances qui vous intéressent, vous pouvez ajouter une ligne dédiée dans crontab pour que le lien symbolique de /home/pi/MagicMirror/config/config.js pointe vers le fichier /home/pi/mm_config_automate/config_vac.js au lieu de /home/pi/mm_config_automate/config.js. Le jour où vous devez revenir au travail (donc la fin de votre période de vacances) à 00h30, il suffira de remettre le lien symbolique vers /home/pi/mm_config_automate/config.js

Exemple pour les vacances de l'Ascension de la zone C :

############### # Vacances Ascension : 20 mai 30 0 20 5 0 cd /home/pi/MagicMirror/config/; rm -rf config.js; ln -s /home/pi/mm_config_automate/config_vac.js config.js; pm2 restart mm # Rentrée : 25 mai 30 0 25 5 * cd /home/pi/MagicMirror/config/; rm -rf config.js; ln -s /home/pi/mm_config_automate/config.js config.js; pm2 restart mm

Voilà. A vous de prendre en main ce projet en le copiant dans un dépôt personnel privé et de le faire vivre.

Le projet sur github

Comme indiqué en début de cet article, les différents fichiers ont été déposé sur github. Ils ont pour but de vous aider à mettre en place votre automatisation :
https://github.com/Ybbet/mm_config_automate

Attention de ne pas mettre le projet en public si vous l'utiliser sur VOTRE installation. Préservez votre vie... privée.

A lire aussi

MagicMirror², un miroir qui vous veut du bien.
MagicMirror², on recommence depuis le début
MagicMirror², un socle qui lui va comme un gant
MagicMirror², un Raspberry Pi, un écran et cie sont dans un bateau
MagicMirror², ma configuration personnalisée
MagicMirror², configuration scriptée
MagicMirror², configuration scriptée, 2ème partie

Des astuces et mémos pour SVN

Teddy Payet — 2018-06-15T09:00:00Z

Je travaille encore très souvent sur des projets sous SVN avec grand plaisir. J'utilise des lignes de commandes pour aller plus vite. Il arrive parfois que je me creuse les méninges pour certaines lignes de commandes. Alors, un petit article mémo ne fera pas de mal.

Lorsqu'on est sous SVN, il est parfois utile de voir la liste des éléments qui ne sont pas encore reconnus dans le dépôt.

svn st | grep ^?

Et si on ne veut pas avoir le " ?" et les espaces entre ce " ?" et le nom des éléments :

svn st | grep ^? | cut -c9-

Pour lister tous les éléments qui ont été modifié :

svn st | grep ^M

Pour lister tous les éléments qui ont été ajouté :

svn st | grep ^A

Pour lister tous les éléments qui sont introuvables :

svn st | grep ^!

Si vous désirez afficher tous les éléments autres que modifiés ou ajoutés :

svn st | grep -v ^[AM]

Afficher tous les fichiers ayant été modifié, ou ajouté ou qui ne sont pas reconnus par svn :

svn st | grep ^[AMD\!?]

Il arrive parfois qu'on ait besoin de déposer des fichiers (exemple : un dump d'une base de données) mais sans vouloir télécharger tout le répertoire cible sur son local. Voici la commande adéquate :

svn co http://example.org/url_depot/bdd_dump/ --depth empty

Cela permettra de faire un checkout sur son local sans télécharger tous les fichiers présents sur le dépôt.

Règle générique

De manière générale, SVN en lignes de commande ajoute 9 caractères avant le nom de l'élément affiché. De ce fait, à chaque fois que vous ne désirez pas voir ces 9 caractères (ou 9 colonnes), il faut mettre à la fin de votre commande | cut -c9-

En bash, si on désire exporter le résultat de notre commande dans un fichier, il faut rajouter à la fin de notre commande " > nom_fichier.txt"
Soit pour exemple, la liste des fichiers autres que modifiés et/ou ajoutés :

svn st | grep -v ^[AM] > files.txt

Ajouter de nouveaux fichiers/répertoires au dépôt

for new_element in $(svn st | grep "^?" | cut -c9-); do svn add ${new_element}; done;

Supprimer des fichiers/répertoires obsolètes au dépôt

for delete_element in $(svn st | grep "^\!" | cut -c9-); do svn delete ${delete_element}; done;

Visuel : Photo by Moja Msanii on Unsplash

MagicMirror², on recommence depuis le début

Teddy Payet — 2018-06-08T05:30:00Z

Récemment, j'ai écrit un article pour installer mon MagicMirror². Ce tutoriel est tout à fait fonctionnel. Malheureusement, pas dans mon cas car j'avais des versions de packages trop anciennes (cf. node.js). Je vais vous expliquer comment j'ai remédié à cela. :-)

J'ai acheté mon Raspberry Pi en juin 2016. J'en avais fait l'acquisition pour tester Gladys. A cette période, la version 2 de Gladys sortait des cartons et avaient peu de plugins pour agrémenter le tout.
Je l'ai donc laissé un peu de côté en attendant le bon moment pour réaliser mon deuxième projet pour ce petit bijoux.

Incompatibilité

J'avais installé toutes les librairies nécessaires pour Gladys et elle-même également. Or, ces versions sont conflictuelles avec ce que MagicMirror² désire. Je vais être honnête, ça me prendrait plus de temps de désinstaller chaque composant plutôt que de refaire la carte SD à partir de l'image de Raspbian fourni par raspberry.org.

Recommençons

Le premier point est de refaire la carte SD avec l'image 2018-04-18-raspbian-stretch issue du site officiel. Cela aura pour effet de repartir de zéro.

Cela fait, on remet la carte SD dans le Raspberry PI pour un redémarrage. Ce dernier point se passe quand même rapidement. Il n'y a pratiquement rien à faire. Les choses sont bien ficelées.

Installation de packages

Il est nécessaire d'installer quelques petits packages pour assurer leur disponibilité au moment voulu :

sudo apt-get install git zip unzip curl wget

Oui, ce n'est pas vraiment nécessaire avec une installation fraîche. Toutefois, cette action permettra de mettre tout le monde au même niveau.

Mise à jour des packages

Comme dans le précédent tutoriel, j'ai mis à jour les packages et le firmware :

sudo apt-get update; sudo apt-get upgrade; sudo apt-get autoremove; sudo rpi-update; sudo apt-get clean

A la fin de cette ligne, je vide le cache puis un redémarrage : sudo reboot

Installation de Node et MagicMirror²

Le redémarrage étant fait, on va maintenant lancer les scripts initiaux :
Node.js

wget -O - https://raw.githubusercontent.com/audstanley/NodeJs-Raspberry-Pi/master/Install-Node.sh | sudo bash node -v

MagicMirror²

bash -c "$(curl -sL https://raw.githubusercontent.com/MichMich/MagicMirror/master/installers/raspberry.sh)"

J'ai vu qu'une branche develop était présente et des commits sur cette branche réglaient quelques bugs. Alors, je passe à cette branche :

cd ~/MagicMirror/ git checkout -b develop git pull

Après cela, on peut lancer l'installation :

npm install

Tout s'est bien passé pour mon installation. Cool.

Installation des modules

Pour mes besoins actuels, j'utilise les modules suivants :

Le principe d'installation est le même pour tous les modules :

cd ~/MagicMirror/modules/ git clone https://github.com/user/mmm-nom-module

Soit :

cd ~/MagicMirror/modules/ git clone https://github.com/tataille/MMM-FreeBox-Monitor.git git clone https://github.com/spectroman/mmm-moon-phases.git git clone https://github.com/edward-shen/MMM-page-indicator.git git clone https://github.com/edward-shen/MMM-pages.git

Pour le reste, la configuration des modules se fait dans le fichier ~/MagicMirror/config/config.js

Configuration du fichier config.js

Comme le demande la documentation de MagicMirror², on doit copier ~/MagicMirror/config/config.js.sample vers ~/MagicMirror/config/config.js
Cela dit… Je ne vais pas faire ça. :-D

En effet, je vais faire en sorte d'avoir une version du fichier config.js qui soit versionnée sur un git.
Comme tout projet git, il n'est pas possible de cibler sur un fichier purement et simplement (comme le ferait svn par exemple). De ce fait, j'ai créé sur Gitlab.com un projet qui sera en mode privé.

On peut nommer ce projet "magicmirror_config" pour faire simple.
Depuis le terminal, je tape les lignes suivantes :

cd ~/ git clone https://gitlab.com/user/magicmirror_config.git

Maintenant, je crée un lien symbolique dans ~/MagicMirror/config/ pointant vers ~/magicmirror_config/config.js

cd ~/MagicMirror/config/ mv config.js config.js.old ln -s ~/magicmirror_config/config.js config.js

Par la même occasion, j'ai fait la même chose avec le fichier ~/MagicMirror/css/custom.css. Pratique pour personnaliser son affichage graphiquement.

cd ~/MagicMirror/css/ mv custom.css custom.css.old ln -s ~/magicmirror_config/custom.css custom.css

Démarrage automatique de MagicMirror²

Comme indiqué dans https://github.com/MichMich/MagicMirror/wiki/Auto-Starting-MagicMirror, il est possible de lancer automatiquement MagicMirror² au démarrage. Pour cela, il est nécessaire d'installer PM2 sur la machine.
Le script d'installation de MagicMirror² le fait. Mais j'ai eu un souci que je ne saurais identifier pour le moment. Je verrai cela plus tard.

Le script a bien installé pm2 mais n'a pas fait les liens symboliques pour ce stretch. Cela se trouve dans /opt/nodejs/bin/.
Sur stretch, on fait un lien vers /etc/alternatives/ puis de là, un lien dans /usr/bin/.
Voici le code à taper dans Terminal :

sudo ln -s /opt/nodejs/bin/pm2 /etc/alternatives/pm2 sudo ln -s /etc/alternatives/pm2 /usr/bin/pm2 sudo ln -s /opt/nodejs/bin/pm2-dev /etc/alternatives/pm2-dev sudo ln -s /etc/alternatives/pm2-dev /usr/bin/pm2-dev sudo ln -s /opt/nodejs/bin/pm2-docker /etc/alternatives/pm2-docker sudo ln -s /etc/alternatives/pm2-docker /usr/bin/pm2-docker sudo ln -s /opt/nodejs/bin/pm2-runtime /etc/alternatives/pm2-runtime sudo ln -s /etc/alternatives/pm2-runtime /usr/bin/pm2-runtime

Créer un fichier de démarrage de MagicMirror²
Pour nous simplifier la tâche, il est conseillé de créer un fichier bash :

cd ~ nano mm.sh

Puis d'ajouter les lignes suivantes :

cd ~/MagicMirror DISPLAY=:0 npm start

On enregistre le tout. Puis on le rend exécutable.

chmod +x mm.sh

Démarrer MagicMirror² avec PM2

C'est vraiment tout simple :

pm2 start mm.sh

Activer le démarrage du script
On doit être sûr que le script soit lancé au démarrage. Pour cela, on sauvegarde les réglages actuels de PM2 :

pm2 save

Contrôler son MagicMirror² via PM2

Avec MagicMirror fonctionnant via PM2, on dispose d'outils pratiques :

Redémarrer MagicMirror

pm2 restart mm

Arrêter MagicMirror

pm2 stop mm

Afficher les logs MagicMirror

pm2 logs mm

Afficher les informations sur le processus MagicMirror

pm2 show mm

A lire aussi

MagicMirror², un miroir qui vous veut du bien.
MagicMirror², on recommence depuis le début
MagicMirror², un socle qui lui va comme un gant
MagicMirror², un Raspberry Pi, un écran et cie sont dans un bateau
MagicMirror², ma configuration personnalisée
MagicMirror², configuration scriptée
MagicMirror², configuration scriptée, 2ème partie

MagicMirror², un miroir qui vous veut du bien.

Teddy Payet — 2018-06-01T15:09:00Z

Le “MagicMirror²” est un projet open source qui a été mis à disposition par son créateur : Michael Teeuw
Présentation : “MagicMirror² est une plate-forme modulaires open source de miroirs intelligents. Avec une liste croissante de modules installables, le MagicMirror² vous permet de convertir votre couloir ou votre miroir de salle de bains en votre assistant personnel. MagicMirror² est construit par le créateur du MagicMirror original avec l'aide incroyable d'une communauté croissante de contributeurs.”

Le matériel

Le matériel nécessaire est le suivant :

Un Raspberry Pi 3 (ne pas oublier une source d'alimentation) ;
Une carte SD de 8Go (minimum) ;
Un clavier ;
Une souris ;
Un câble HDMI ;
Un écran HDMI.

Je vous propose de voir comment installer MagicMirror² (aka MM²) sur votre Raspberry Pi 3. Bien entendu, le moment venu, vous brancherez tous les éléments les uns aux autres lorsque vous devrez vous connecter au Raspberry PI.

Installation du Raspberry Pi
Préparer une carte SD.

Il est nécessaire d'installer Raspbian sur votre carte SD pour optimiser votre utilisation du Raspberry Pi et de MagicMirror². Cette opération doit être réalisée depuis un ordinateur (Windows, Mac, Linux)

Aller sur l'url https://www.raspberrypi.org/downloads/raspbian/

Télécharger la dernière version de Raspbian (en mai 2018, Raspbian Stretch with desktop). Une fois téléchargé sur votre ordinateur, veuillez décompresser le fichier.

Avec le répertoire extrait, vous pouvez préparer la carte SD. Insérez votre carte SD dans votre ordinateur. Ouvrez votre logiciel* de gestion de disques (SD Card Formatter, Win32 Disk Imager, Utilitaire de Disques, etc.). Sélectionnez votre carte SD et lui donner un nom (de préférence sans espace ou accents pour simplifier les lignes de commandes). Référez-vous à la documentation propre à votre logiciel pour toutes ces étapes.

Sélectionnez l'image de Raspbian fraîchement extrait pour l'importer sur la carte SD. Lancez l'écriture de cette image sur la carte.

Cela fait, éjectez la carte SD.

Démarrer et configurer le Raspberry Pi

Maintenant que la carte SD est prête avec Raspbian, il est nécessaire de l'insérer dans le Raspberry Pi.

Connecter le câble HDMI à l'écran puis au Raspberry. Allumez votre écran. Branchez le clavier, la souris au Raspberry. Ne pas oublier maintenant de brancher la source d'alimentation du Raspberry.

Au premier démarrage du Raspberry Pi, cela peut prendre un peu de temps. Vous serez invité à renseigner le mot de passe pour l'utilisateur pi (soit par défaut : raspberry).

Depuis le terminal, entrez sudo raspi-config et validez. Cela lancera la configuration du Raspberry. Choisissez “Expand Filesystem” en tapant sur la touche “Entrée”. On utilisera ainsi tout l'espace de la carte SD.
Cela fait, on sélectionne “Internationalisation Options” pour choisir la langue désirée. Le faire à votre convenance : la langue, le timezone, le format du clavier, le protocole Wifi.

Maintenant, on va choisir “Advanced options”, puis “Hostname”. Par défaut, on a raspberrypi. Mais au vu du projet, on peut appeler ça magicpi. A votre convenance ici :-)

Après cela, revenir sur “Advanced options” et choisir “SSH”. Il sera utile de pouvoir une connexion SSH pour accéder au Raspberry à distance.

On devrait être bon maintenant. Revenir à l'écran principal et utiliser la touche de tabulation pour mettre en surbrillance “Finish” en bas de l'écran et cliquer sur “Entrée”. A la demande de redémarrage, cliquer sur “Yes”.

Configurer le Wifi du Raspberry Pi

Une particularité du Raspberry Pi 3 est d'avoir le wifi nativement. Il va falloir le configurer pour avoir accès à votre réseau internet.

Après le redémarrage, vous aurez un bureau graphique Linux. Lancez le Terminal, vous y configurez le wifi en éditant le fichier wpa_supplicant.conf :

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

A la fin du fichier, renseignez vos informations de connexion :

network={ ssid="votre_nom_de_reseau" psk="votre_mot_de_passe_reseau" }

Pour enregistrer votre configuration, cliquer sur CTRL-X puis sur Y.

Il faut redémarrer votre raspberry : sudo reboot.

Nettoyer et mettre à jour le système

Bon, tout cela est sympa, mais il va falloir mettre tout ce petit monde à jour et faire maigrir tout ça.

Depuis votre Terminal, taper df -h pour avoir la capacité actuelle de votre Raspberry. Notez l'espace utilisé pour le comparer.

On va supprimer quelques packages inutiles pour le MM² :

sudo apt-get remove --purge idle3 java-common libreoffice* minecraft-pi scratch nuscratch penguinspuzzle python-minecraftpi python3-minecraftpi smartsim sonic-pi wolfram-engine

Puis :

sudo apt-get clean sudo apt-get autoremove

Cela va prendre un petit moment pour que ces opérations se terminent. Soyez patient et pas trop loin de votre écran pour valider certaines opérations. Faites à nouveau df -h dans votre terminal et remarquez le changement.

Continuons. Il est temps de mettre à jour vos packages :

sudo apt-get update ; sudo apt-get upgrade ; sudo rpi-update.

“update” met à jour la liste des packages disponibles et leur version ;
“upgrade” met à jour les packages installées ;
“rpi-update” va quant à lui mettre à jour le firmware du Raspberry Pi.

Respirez à nouveau et tapez sudo reboot

Installation de MagicMirror²

Le Raspberry est prêt. Alors, installons le temps attendu MagicMirror².

Il existe un script qui permettra d'installer MM² comme il se doit. Toutefois, il arrive que l'installation du package “node” pose un problème. Le script installe une version NodeJS 9.x. La version de node testée par MM² est la 5.1.0. Si vous avec une version inférieure, cela bloquera l'installation de composants node qui nécessitent eux un node 4.6.x minimum.
Il faudra faire attention à la version de NodeJS surtout si vous avez depuis un moment votre Raspberry Pi. Ce qui était mon cas. J'avais un node v4.4.2 qui forcément n'était pas au goût de MM².

Installation préalable de NodeJS

Pour y remédier, vous allez installer node en premier. Tapez ceci dans votre Terminal :

wget -O - https://raw.githubusercontent.com/audstanley/NodeJs-Raspberry-Pi/master/Install-Node.sh | sudo bash node -v

Ce script bash installera par défaut la version NodeJS 10.x. Il est possible de changer la version de NodeJS en tapant ceci :

sudo node-install -v 9; # then you will get prompted with which # specific version of 9 you wish to install

Mais on n'en est pas là.

Exécution du script pour MagicMirror²

NodeJS étant installé, vous allez lancer le script d'installation de MagicMirror² :

bash -c "$(curl -sL https://raw.githubusercontent.com/MichMich/MagicMirror/master/installers/raspberry.sh)"

Cela lancera le processus d'installation pour vous. Ne partez pas trop loin du Raspberry car des validations seront à faire au fil de l'eau.

Attention, le script d'installation de MM² s'occupe déjà d'installer un NodeJS (v9.x en mai 2018). Donc, vous pourriez vous passer de l'étape précédente en réalité. Mais si vous désirez tester sur d'autres versions de NodeJS, une installation manuelle, citée précédemment, vous facilitera grandement la tâche.
Si le script de MM² détecte un node existant, il sautera cette étape et vous indiquera qu'il faudra mettre à jour node si votre version est inférieure à la version testée.

Configuration complémentaire

Le script s'est bien déroulé. Vous devez configurer quelques points complémentaires spécifiques à MM². Il faut par exemple indiquer que l'écran est à la verticale. Tapez :

sudo nano /boot/config.txt

Et ajoutez à la fin du fichier les lignes suivantes :

# Rotate display vertically display_rotate=1

Appuyez sur CTRL-X quand vous avez fini puis Y pour sauvegarder vos modifications.
Raspbian lance un écran de veille au bout d'un certain temps. De ce fait, nous allons désactiver ceci en modifiant un fichier :

sudo nano /etc/xdg/lxsession/LXDE-pi/autostart

Ajoutez à la fin du fichier ces lignes :

@xset s noblank @xset s off @xset -dpms

Modifiez le fichier lightdm.conf :

sudo nano /etc/lightdm/lightdm.conf

Recherchez la ligne xserver-command en descendant plus bas. Y renseigner ces valeurs :

xserver-command=X -s 0 -dpms

Enlevez le « # » en début de ligne si besoin. Enregistrez vos modifications CTRL-X puis Y et entrée.

Pour des soucis d'économie d'énergie Raspberry désactive certains composants dont le wifi. En modifiant un paramètre dans /etc/network/interfaces, cette fonctionnalité sera ineffective :

sudo nano /etc/network/interfaces

Cherchez wlan0 et ajoutez, en-dessous, la ligne suivante :

wireless-power off

Sauvegardez vos modifications et redémarrez votre Raspberry Pi :

sudo reboot

A ce stade, vous avez configuré entièrement votre MM². Il vous faudra le personnaliser en éditant le fichier config.js et/ou en ajoutant des modules supplémentaires.

cd ~/MagicMirror/config cp config.js.sample config.js

Et maintenant, vous pouvez l'essayer :

cd ~$HOME/MagicMirror npm start

Enjoy !

Sources :

A lire aussi

MagicMirror², un miroir qui vous veut du bien.
MagicMirror², on recommence depuis le début
MagicMirror², un socle qui lui va comme un gant
MagicMirror², un Raspberry Pi, un écran et cie sont dans un bateau
MagicMirror², ma configuration personnalisée
MagicMirror², configuration scriptée
MagicMirror², configuration scriptée, 2ème partie

Installer Homebrew sur Mac OSX

Teddy Payet — 2016-03-02T08:00:00Z

Il arrive souvent quand on développe qu'il nous soit nécessaire d'installer certains outils pour mieux travailler. Il existe plusieurs solutions pour y arriver :

faire le tout à la main en compilant les sources de l'outil (pas simple pour tout le monde, même pour moi) ;
utiliser MacPorts pour installer les outils (je vous partagerai bientôt un pas à pas pour son installation) ;
utiliser Homebrew pour installer les outils.

Présentation de Homebrew

Homebrew nous permet d'installer des outils qu'Apple n'a pas installé sur MacOS. Généralement ceux sont des utilitaires accessibles par lignes de commande. Donc si vous y êtes allergiques, passez votre chemin.
La communauté autour d'Homebrew est grande et réactive. Ce qui a l'avantage de nous donner accès à un panel très large d'outils. Ces outils sont souvent issus de la communauté Linux (Ubuntu, Debian et cie).
Pour simplifier l'idée, c'est un gestionnaire de packages (cf. nos outils).

Installation

Comme le dit la page d'accueil du site d'Homebrew le moyen le plus simple est de taper cette ligne dans votre Terminal :

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Le script va nous expliquer les actions qu'il va réaliser avant de les lancer. Il nous suffira de valider son message pour que l'installation puisse se lancer. Cela fait, nous pouvons lancer la ligne de commande brew doctor pour savoir si tout est opérationnel pour Homebrew sur notre système d'exploitation. Suivre les indications de cet utilitaire le cas échéant.

Homebrew installe ses packages dans son répertoire (cf. "Cellar") et créera des alias dans le répertoire /usr/local/. C'est un avantage pour reconnaitre ce qui a été installé par Homebrew sans altérer notre OS.

Exemple d'utilisation : GruntJS

Lorsqu'on réalise des sites (ce n'est qu'un exemple), nous réalisons des actions répétitives. Mais voilà… le faire manuellement est chronophage. Pour éviter cela, il existe GruntJS (je vous invite à lire la documentation officielle). Pour installer GruntJS, on a besoin de Node.js et de npm. Et c'est là qu'intervient Homebrew.

Voici le code à exécuter pour installer Node.js et npm :

brew install node npm

Puis

npm install -g grunt-cli

Et voilà, le tour est joué.

Exemple d'installation : wget

Sous MacOS, on a accès à curl en lignes de commande mais pas à wget. Les 2 sont similaires ou du moins peuvent servir aux même tâches. Toutefois pour aspirer un site sur son ordinateur, il est plus aisé d'utiliser la commande wget. Il est très simple d'installer cette commande par l'intermédiaire de Homebrew :

brew install wget

Mettre à jour sa version d'Homebrew et ses packages

Comme indiqué dans la documentation officielle d'Homebrew, si on désire mettre à jour ce dernier, il suffit de saisir la ligne de commande suivante :

brew update

Oui, mais est-ce que nous avons des packages qui ont besoin d'une mise à jour ? Pour le vérifier, taper cette ligne de commande dans votre Terminal :

brew outdated

Homebrew nous indiquera donc la liste des mises à jour disponibles pour nos packages. S'il nous dit que tout est à jour, eh bien, tant mieux ! Sinon, il nous faut saisir cette ligne de commande :

brew update

Et tous nos packages se mettront à jour.

Conclusion

Ce gestionnaire de package n'est pas encore dans une version "1" à l'heure actuelle mais il est déjà suffisamment robuste pour nous permettre de travailler sereinement.
De plus, si nous avons besoin de connaitre la liste des packages disponibles sous Homebrew, il existe un site dédié : ~~http://brewformulas.org/~~ https://formulae.brew.sh
Un formulaire de recherche y est disponible, donc vous n'aurez pas d'excuses pour ne pas trouver le package qui vous va bien.

© Photo par Maciej Korsan
Le visuel de la bière a été choisi en rapport avec l'histoire d'Homebrew. En effet, en anglais, "brew" veut dire "breuvage". Et le créateur de ce projet avait choisi ce nom car il aimait beaucoup tout ce qui touchait à la bière, sans avoir considéré que son projet allait avoir tant d'influence. Quand il l'a réalisé, c'était déjà trop tard.
Référence

Récupérer des fichiers d'un serveur à un autre par SFTP

Teddy Payet — 2015-09-30T08:29:25Z

Lorsqu'on développe des sites, nous avons une version de chaque site selon son statut : production, pré-production, développement, etc. [1]. Il est nécessaire d'avoir les dernières images et médias du site de production sur les autres versions du site pour avoir quelque chose au plus proche de la réalité.
Bien entendu, on prend le contexte ici d'améliorations d'un site, et pas une ré-écriture totale du site.

Préambule

Nous avons prendre en compte 2 types de site : la production et la recette. Nous pouvons accéder à minima le site de production par sftp et le site de recettes par ssh. Ce n'est pas une généralité certes, mais c'est personnellement mon quotidien.
L'arborescence que nous allons décrire est celle d'un site sous SPIP. Mais cela n'empêchera pas l'utilisation de cette mécanique sur des sites gérés par un autre CMS ou un Framework.

Se connecter au serveur de recettes

Pour cela, nous allons ouvrir le Terminal pour entrer les quelques lignes de commandes adéquates. En premier lieu, nous nous connectons au serveur :

> ssh teddy.payet@recettes.example.tld

Nous renseignons le mot de passe à l'invitation du Terminal. Puis nous regardons où nous nous trouvons sur le serveur en tapant :

> pwd
/home/teddy.payet/

Nous allons nous placer dans le répertoire recueillant les médias de notre site internet :

> cd /var/www/IMG/

Bien, cela fait, nous vérifions que nous avons bien sftp accessible en ligne de commande. Pour cela nous saisissons ceci :

> which sftp
/usr/bin/sftp

Parfait si nous avons cela. Sinon, il faut installer « sftp» sur notre serveur.

Récupérer les médias sur le serveur de production

Après les actions précédentes, nous pouvons maintenant se connecter au serveur de production depuis le serveur de recettes. Il nous faut saisir la ligne suivante :

> sftp teddy.payet@example.tld

Nous tapons le mot de passe maintenant. Vérifions où nous nous trouvons sur le serveur de production :

> pwd
/

Et par sécurité, vérifions que le serveur de production et notamment sftp, reconnaît bien notre emplacement sur le serveur de recettes :

> lpwd
/var/www/IMG/

Bien. Nous sommes presque prêts à récupérer les médias. Pour cela, on doit aussi se placer dans le répertoire des médias du site de production :

> cd /var/www/IMG/
> pwd
/var/www/IMG/

Maintenant, récupérons tous les médias de ce répertoire et de ces sous-répertoires :

> get -Pr .

N'oublions pas de mettre le point à la fin de la commande. Le « P » dit à sftp de récupérer tous les fichiers en gardant les propriétés des fichiers. Le « r » indique à sftp de récupérer les fichiers du répertoires courant et de ses sous-répertoires.
Nous verrons alors le terminal afficher chaque action et fichier récupérés, avec le temps de chargement estimé et le poids du fichier.

Et voilà. Rien de plus simple. Il suffit de patienter le temps que le serveur rapatrie tous les médias du site de production vers le site de recettes.

[1] D'ailleurs à ce sujet, je vous invite à lire la documentation du plugin « Info SPIP »

Créer un trunk sur la zone SPIP

Teddy Payet — 2015-07-30T07:00:00Z

Il arrive parfois que lorsqu'on a créé un plugin sur SPIP-Zone (ou qu'on veuille reprendre le développement d'un plugin sur SPIP-Zone) que ce plugin n'est pas sur la structure trunk/branches/tags. Pour reprendre ce plugin, il est conseillé de mettre le répertoire sous cette structure avant de commencer.

Un script pour les commander tous !

Au lieu de faire cela ligne par ligne, commande par commande, vous pouvez lancer un script à personnaliser selon le besoin. Les lignes de commande à taper ne sont pas forcément très nombreuses mais elles sont répétitives. Je vais de ce fait vous montrer un script bash qui simplifiera cette migration. Mais qui dit "bash", dit être donc sous un environnement UNIX : Linux, Mac OS.

Le script

#!/bin/bash
url_svn=svn://zone.spip.org/spip-zone/_plugins_/
plugin_nom=votreplugin
plugin_numero=0.9.0
svn mv ${url_svn}${plugin_nom} ${url_svn}${plugin_nom}_trunk -m "On commence la migration du plugin ${plugin_nom} en trunk/branches/tags"
svn mkdir ${url_svn}${plugin_nom} ${url_svn}${plugin_nom}/branches/ ${url_svn}${plugin_nom}/tags/ -m "On recrée le nom du répertoire ${plugin_nom} avec le répertoire branches/ et tags/"
svn cp ${url_svn}${plugin_nom}_trunk ${url_svn}${plugin_nom}/branches/v${plugin_numero:0:1} -m "On copie les fichiers du plugin ${plugin_nom} dans sa branche v${plugin_numero:0:1}"
svn cp ${url_svn}${plugin_nom}/branches/v${plugin_numero:0:1} ${url_svn}${plugin_nom}/tags/${plugin_numero} -m "On pose le tag correspondant à la version ${plugin_numero} du plugin ${plugin_nom}"
svn mv ${url_svn}${plugin_nom}_trunk ${url_svn}${plugin_nom}/trunk -m "On déplace enfin le répertoire initial vers le trunk pour le plugin ${plugin_nom} v${plugin_numero}"

Personnalisation

Il faut copier-coller ces lignes de commande dans un fichier qui aura pour extension .sh. Pour votre plugin, vous devez changer 2 valeurs :

plugin_nom : le nom du répertoire de votre plugin
plugin_numero : le numéro du plugin (sous la forme x.y.z) que vous trouverez dans le fichier plugin.xml ou paquet.xml

Vous n'avez pas besoin de changer l'URL du serveur svn de la zone sauf si le plugin que vous désirez reprendre le développement n'est pas dans le répertoire _plugins_.
Ce script va faire 5 commits au final avec les commentaires qui vont bien avec. Pour cela, ouvrez votre terminal et lancer le script que vous avez créé.

J'ai déjà éprouvé ce script à mon travail sur mes différents projets. Il est simple et efficace.

Explications

Même si le script est simple, on peut expliquer ce qui se passe et notamment l'écriture particulière de la syntaxe de bash.

Tout fichier bash commence par la ligne #!/bin/bash. Cela indique (en plus de l'extension .sh) que c'est bien un fichier… bash.
url_svn= : lorsque vous voyez un texte suivi d'un simple signe égal "=", c'est que vous créez une variable avec une valeur ;
Pour rappeler au besoin la variable, vous devez taper $ puis le nom de la variable désirée.
Pour pouvoir mettre du texte collé à votre variable, il faut mettre le nom de la variable entre accolades. Exemple : ${plugin_nom}_trunk donnera votreplugin_trunk
Si vous désirez avoir les premiers caractères de votre variable, dans le rappel de votre variable, vous pouvez utiliser la forme ${nom_variable:debut:longueur} où :
- nom_variable : le nom de votre variable ;
- debut : emplacement où commencer (0 étant le numéro du premier caractère) ;
- longueur : le nombre de caractères que vous désirez récupérer.

Plus de lecture

Le sujet du rangement sur la zone a été abordé à plusieurs reprises :

Teddy Payet

Je suis passé à SPIP 4.0

Introduction

Par beau temps

Puis vint la pluie…

Panique à bord !

Une île paradisiaque au loin

Un avenir radieux

Et la suite ?

Fin de vie pour…

La domotique et moi, 2ème partie

L'accessibilité, l'interface homme/machine

Le contrôle et l'automatisation

Open source

Conclusion

La domotique et moi, 1ère partie

Mon profil avant tout

Inspecteur gadget

L'économie financière

Conclusion

MagicMirror², configuration scriptée, 2ème partie

Introduction

Liste des scripts

first_install.sh

mm_reset.sh

mm_update.sh

update_files_config.sh

update_files_config.sh : fonction import_module

update_files_config.sh : fonction delete_modules

disk_usage.sh

crontab.txt

Le projet sur github

A lire aussi

Des astuces et mémos pour SVN

Règle générique

Ajouter de nouveaux fichiers/répertoires au dépôt

Supprimer des fichiers/répertoires obsolètes au dépôt

MagicMirror², on recommence depuis le début

Incompatibilité

Recommençons

Installation de packages

Mise à jour des packages

Installation de Node et MagicMirror²

Installation des modules

Configuration du fichier config.js

Démarrage automatique de MagicMirror²

Démarrer MagicMirror² avec PM2

Contrôler son MagicMirror² via PM2

A lire aussi

MagicMirror², un miroir qui vous veut du bien.

Le matériel

Installation du Raspberry Pi Préparer une carte SD.

Démarrer et configurer le Raspberry Pi

Configurer le Wifi du Raspberry Pi

Nettoyer et mettre à jour le système

Installation de MagicMirror²

Installation préalable de NodeJS

Exécution du script pour MagicMirror²

Configuration complémentaire

Sources :

A lire aussi

Installer Homebrew sur Mac OSX

Présentation de Homebrew

Installation

Exemple d'utilisation : GruntJS

Exemple d'installation : wget

Mettre à jour sa version d'Homebrew et ses packages

Conclusion

Récupérer des fichiers d'un serveur à un autre par SFTP

Préambule

Se connecter au serveur de recettes

Récupérer les médias sur le serveur de production

Créer un trunk sur la zone SPIP

Un script pour les commander tous !

Le script

Personnalisation

Explications

Plus de lecture

Installation du Raspberry Pi
Préparer une carte SD.