Souvent délaissés, les tableaux de bord (ou dashboard en version british) sont l’élément visible de toute la domotique. Non seulement ils vous permettent de garder un œil sur ce qu’il se passe dans la maison, mais ce sont aussi une bonne méthode de promotion de ce que vous avez fait et améliore grandement le WAF.

La solution la plus rependue est d’exposer les informations de domotique à travers une « simple » page web … enfin, simple n’est qu’une expression, car les données étant par essence changeantes (sinon, pourquoi les surveiller ?) il faut maitriser le web Dynamique, PHP voir Ajax, tout ça …
L’avantage est que si votre site web est exposé sur la toile, vous pourrez voir ce qui se passe chez vous depuis votre taf … ou n’importe où d’ailleurs par votre smartphone. Je vous laisse vous pencher sur les problèmes de sécurité que cela pose et les mesures indispensables à mettre en place.

C’est la solution que j’avais déployé avec mon architecture V1 : Domestik collecte régulièrement toutes les informations, les agrège en base de données et les affiche à travers son interface Web avec moult graphiques.

Vous rentrez chez vous tard le soir … la porte du garage est-elle fermée ? Fallait-il passer par la boite aux lettres ? Les plantes ont-elles besoin d’être arrosées ?
Voilà, le besoin se fait sentir d’avoir toutes ces informations accessibles à n’importe quel moment : le besoin d’avoir un tableau de bord dans le salon.

La solution de facilité, et donc la plus courante est de recycler un vieux PC (vous rendez-vous compte de l’electricité que vous allez gaspiller ?) ou mieux de mettre un SBC tel qu’un BananaPI ou un Raspberry, avec un navigateur ouvert plein écran qui affichera la page décrite ci-dessus, en mode rafraîchissement automatique toutes les 30 secondes.
Le gros avantage est que le travail à accomplir est minime, n’importe quelle distribution Linux graphique fait l’affaire. Ensuite, tout n’est qu’une question de configuration :

• mettre le SBC en autologin,
• lancer le navigateur au démarrage de X,
• avec notre tableau de bord en page d’accueil …

rien que tu classique, et ça se trouve facilement sur le web.

Cette solution ne m’a pas paru très élégante :

• Même en utilisant un SBC d’entrée de gamme tel que le rPI-A ou le rPI-0, sa puissance est largement surdimensionnée pour le besoin … alors que parallèlement, ces machines sont parfois limite limite niveau ressource pour faire tourner X surtout si on choisi des distributions obèses telles qu’Ubuntu (je l'ai fait avec Gentoo/Lxde sur de vieux PC, ça passe).
• C’est quand même lourd d’installer une couche X complète et un navigateur (et ses dépendances) juste pour afficher une page web …
• Puis, nous sommes dépendant de la fréquence de rafraîchissement de la page. Par exemple, le compteur EDF envoie de trame téléinfo toutes les secondes … on ne va évidemment pas rafraîchir notre page aussi souvent : ça va charger notre serveur et sans doute être très disgracieux à l’affichage. Résultat, nous n’avons pas ces infos en temps réel.
• Enfin, autant de dashboard, autant de requêtes sur le serveur … et ça peut devenir vite lourd pour ce dernier. C’est la raison pour laquelle je suis passé en MQTT.

La suite de cette page décrit les solutions que j’emploie sur ma propre domotique, à l’exclusion de la page web de Domotik abordée plus haut et qui ne nécessite pas plus de commentaire.

Une tablette Android propulsée par un processeur Allwinner (je ne sais pas pour les autres fondeurs), boote en priorité sur sa carte SD puis, si elle n'y trouve pas de système, bascule sur sa NAND : la solution était donc d'installer linux sur une SD d'au moins 1Go (et oui, X n'est pas nécessaire pour mon dashboard, du coup, les besoins de stockage sont réduits) et de la rendre bootable. Comme bonus, je ne touche pas à la NAND, et peut-être qu'un jour, j'essaierai d'y réactiver Android … peut-être .

Installer Linux sur une SD, on sait faire : il suffit de suivre les indications du site SunXI ou de ma page dédiée au BananaPI. Elles indiquent aussi comment rendre la carte bootable en y installant uboot, qui est l'équivalent à la fois du boot sector et du BIOS des PC, en mieux.

La carte contiendra au moins 2 partitions :

• La première, formatée en FAT ou en ext2, pour
• le kernel sous la forme d'un fichier uImage,
• le fichier script.bin de configuration hardware : c'est grâce à lui qu'uboot sait où trouver sa console, les timings de la mémoire, la configuration des GPIO, etc … De mon côté, j'ai simplement récupéré celui présent dans la partition NANDa d'Android.
• Un fichier texte contenant les options à passer au kernel.
• Sur la seconde, nous allons installer le système, Gentoo pour moi, et il suivre la même procédure que pour le BananaPI

A noter que pour économiser 10% de place supplémentaire sur la SD, j'ai choisie une version du système utilisant uclibc … 1Go commence en effet à devenir serré surtout lorsqu'on y installe la chaîne complète de développement (GCC, …). Mais du coup, je n'ai pu installer syslog : rotatelog à besoin d'une API non disponible dans uclibc ... on fera avec.

Profitons-en pour parler un peu de l'endurance de la SD : comme toute mémoire NAND (ce qui inclut les disques SSD), elle s'use rapidement face aux écritures, créant des blocs défectueux. Pas de risques pour nos données : chaque SD contient un petit processeur qui élimine ces blocs et les remplace par des saints, mais la place disponible diminue peu à peu.
Pour pallier ce problème, j'ai mis en RAM tout ce qui nécessite des écritures : les homes, les logs, … Ce qui me donne le /etc/fstab suivant :

/dev/mmcblk0p1		/boot		vfat		noauto,noatime	1 2
/dev/mmcblk0p2		/		ext4		noatime		0 1
#/dev/SWAP		none		swap		sw		0 0
#/dev/cdrom		/mnt/cdrom	auto		noauto,ro	0 0
#/dev/fd0		/mnt/floppy	auto		noauto		0 0

none			/var/tmp	tmpfs		defaults	0 0
none			/tmp		tmpfs		defaults	0 0
none			/home/laurent	tmpfs		defaults	0 0

Évidemment, tout sera perdu lors d'un reboot … mais on s'en fout.

Toute tablette peut évidemment se connecter par WiFi … pour peu qu'on lui fournisse le driver qui va bien.
Et dans mon cas, ce n'était pas si simple : le dit driver n'existe qu'avec un kernel très récent, qui nécessite lui-même un uboot tout aussi récent, uboot pour lequel je n'avais pas de fichier de configuration. Bref, pas gagné.

Mais comme ma tablette se trouve juste à côté de ma Freebox, j'ai simplifié les choses en utilisant la possibilité d'établir un réseau par USB (« Simple USB Network Links » ou « CDC Ethernet subset ») : il suffit juste de compiler les modules kernel cdc_ether & usbnet.

On reboote, et voilà, la tablette accède à mon réseau et à ses précieux messages MQTT.

La partie matérielle étant maintenant couverte, passons au côté logiciel.

DirectFB (Direct Frame Buffer) est une librairie qui facilite la programmation aux couches graphiques de bas niveau de Linux et en particulier son fameux Frame Buffer (fbdev) et aux input devices s'y rapportant (clavier, souris). Il fournit même un système de fenêtrages simple mais qui va nous être bien utile.

Ses objectifs sont :

• Empreinte mémoire réduite
• Pas de modification kernel si ce n'est évidemment d'activer fbdev
• Hormis libc, aucune dépendance vers d'autres librairies
• Utilisation de l'accélération hard lorsque c'est possible. Dans notre cas ... ça ne le sera pas car le nombre de cartes graphiques connues de DirectFB est réduit et surtout focalisé sur des modèles anciens. Cependant, les CPU sont tellement véloces de nos jours et les graphiques que nous souhaitons faire somme toute relativement simple, ça n'aura pas d'incidence.

Séléné ayant déjà sa page dédiée, je ne vais pas rentrer plus dans les détails.

En résumé, il prend en charge tout ce qui est bas niveau que ce soit pour les messages MQTT, graphique et fonction support (timer, ...).

Toile est un autre framework qui s'appuie sur Séléné et qui fournit des "widgets" pour les différents objets graphiques que l'on doit afficher : champs texte, graphismes, icônes ...
Programmer en méthode Objet, il permet une grande abstraction (et donc une facilité de programmation).

local srf_trndconso = GfxArea( srf, 0, 15, 100, 75, COL_RED, COL_GFXBG, { align=ALIGN_RIGHT } )

Dans cet exemple, on crée une surface graphique à la position 0,15 et de taille 100x75

local srf_conso = Field( srf, 0, 105, fsdigit, COL_DIGIT, {
	align = ALIGN_RIGHT,
	sample_text = "12345"
} )

On crée une surface de texte (Field) à la position 0,0 et dont la taille sera déterminée automatique pour la police donnée et pour laisser la place pour 5 digits (de part le texte d'exemple 12345)

local consommation = MQTTStoreGfx( 'consommation', 'TeleInfo/Consommation/values/PAPP', srf_consommation, srf_trndconso,
	{
		gradient = Gradient(
			{
				[500] = COL_DIGIT,
				[1500] = COL_ORANGE,
				[4500] = COL_RED
			}
		),
		forced_min = 0,
	}
)

Enfin, on crée une collection d'objet nommé "consommation", liée aux 2 surfaces précédemment créées et dont la couleur variera en fonction de la valeur.

Le tableau de bord en lui-même est une succession de pages qui défilent automatiquement et qui regroupent les informations par lieux géographiques (étage de la maison) ou par fonctions (gestion de l'énergie, ...).

Il est possible de les construire

• soit par incrustation des informations sur des images de fond
• soit entièrement par programme (tracer une ligne de telle position à telle autre, affiché l'icône goûte à cette position, ...).

C'est la seconde solution que j'ai utilisé : la piètre qualité de la dalle de ma tablette à bas coup ne permet pas beaucoup de débordements graphiques et cette méthode est plus adaptée à quelque chose qui est en constante évolution.

Ce tableau de bord permet aussi de configurer certains paramètres de la domotique par des menus accessibles par les boutons Vol+ / Vol- / Selection de la tablette ou par une télécommande lorsque c'est possible. Vraiment très très pratique.

Un jour peut-être, l'écran tactile de la tablette sera utilisable ... Un jour ...

Il faut savoir que la tablette à un écran assez "bas de gamme" qui fait que les couleurs sont mal rendues si on n'est pas vraiment en face : c'est pourquoi les graphismes sont relativement simples et les couleurs passablement criardes (ça fait un peu trop "flat design" à mon gout).

Utilisation classique : les chambres du premier étage avant les températures, le mode de fonctionnement des volets de chacune des chambres, ... Les bandeaux à gauche et en bas contiennent les informations "critiques" qui sont toujours affichées.

La météo est récupérée d'OpenWeatherMap et je me suis rendu compte qu'elle est franchement pessimiste. Il est possible que je bascule vers met.no qui est la source du plugin météo sur Xfce qui m'a l'air beaucoup plus fiable.

En plus des valeurs instantanées visibles sur le bandeau gauche, cette page fournit des courbes intéressantes sur les production et consommation électriques. Pour le moment, je n'ai pas encore mis en place un suivi spécifique des appareils les plus consommateurs. Mais il est facile de déterminer l'impact des cumulus / machine à laver / ... par les augmentations qu'ils provoquent sur les courbes.
A noter aussi que mon compteur n'a une granularité que d'une 10e de Watts et d'1 Ampères ce qui ne facilite pas le suivi des appareils à basse consommation comme les lampes LED.

Un exemple plus spécifique : mon poulailler.