Une architecture centralisée comme ma V1 fonctionne très bien, mais n'est pas des plus optimisée lorsque qu'il s'agit d'avoir plusieurs clients : Domestik pour la supervision et l'archivage, affichage en temps réels sur les stations de travail, un tableau de bord dans le salon, des widget sur les PCs ...
Si la première version se basait sur les webservices, la colonne vertébrale de la V2 est un bus de message : Parmi les protocoles disponibles (voir l'encadré), j'ai choisi MQTT pour sa rapidité, sa légèreté et la facilité de programmation.
L'IoT commence enfin à se standardiser et plusieurs protocoles ouverts émergent :
- Les WebService REST : rien que du bien classique et qui fournit un mode 1<->1. Cette méthode est déjà prise en charge par Domestik (c'est même son mode de communication natif).
- Le CoAP : une ré-interprétation du REST, mais en nécessitant des ressources minimums. En résumé, tout ce qui peut être codé sous forme binaire l'est, les phases de négociation sont réduites au minimum, ... Les trames échangées sont très réduites tout comme les besoins mémoire. Il existe aussi un mode "non confirmable" où les données sont envoyées sans acquittement ce qui implique aucune sécurité quant à la bonne réception de la donnée.
- Le MQTT : on vise plus une architecture 1 <-> n en mode "publier et souscrire". Des sécurités d'acheminement et d'authentification peuvent être mises en place, ainsi que de la persistance. Il est même possible d'indiquer sa dernière volonté (valeur à publiée si une source disparait). C'est ce que je vais détailler dans ma V2.
Cette page sur le site de l'organisation eclipse offre plus d'informations et une comparaison entre ces différents protocoles.
Du coup, l'architecture s'est complexifiée ... enfin en apparence car du moment où tout est découpé de manière logique et qu'on évite toute adhérence, sa gestion reste simple (mon but : j'ai évidemment d'autres choses à faire 
)
Différents démons collectent les données de la maison qui seront consommées par autant de clients que nécessaire sans que cela n'influe sur les performances du serveur ou du réseau.
Le coeur du réseau est donc le broker MQTT et le choix est pléthorique :
.
Domestik reste un élément important :
Marcel est un démon écrit en C, donc très léger, qui prend en charge
L'utilisation du bus 1Wire avec le BananaPI est décrite sur cette page. J'ai commencé à le déployer à travers la maison (enfin, où s'est possible sans trop de travaux ... si vous construisez, pensez à câbler toutes les pièces ! Chez moi, c'est de l'ancien donc la question ne se posait pas, mais c'est parfois un peu galère 
).
La gestion de bas niveau est assurée par l'incontournable OWFS ; Marcel est là pour publier les informations vers le bus.
Il permet aussi le contrôle d'objet à distance comme la pompe de ma piscine.
Ce sont les 2 sondes qui m'ont fait migrer des WebServices vers le bus : leurs données sont consommées par plusieurs clients, Domestik bien sûr, Marcel, mais aussi mes différents tableaux de bord.
Sinon, pas grand chose à ajouter :
Mon FAI "offrant" une API pour envoyer des SMS, je m'en sers pour m'avertir d'évènements importants tel que :
(liste non exhaustive bien sûr et certaines reste à implémenter).
Ici aussi, il s'agit d'une sonde qui passe de Domestik à la messagerie MQTT : ainsi, il est possible d'afficher en temps réel ces informations sur plusieurs écrans.
Comme je le disais précédemment, le nombre et la nature des clients n'ont quasiment aucune influence sur les performances du réseau et/ou des serveurs : tous juste une petite augmentation des transfères. En tout cas, rien comparé à ce qu'on aurait eu avec des webservices.
Comme clients, j'ai actuellement
|
Visitez : Nos sorties Ski et rando |
Copyright Laurent Faillie
2001-2024
N'oubliez pas d'entrer le mot de passe pour voir aussi les photos perso. |
Contactez moi si vous souhaitez réutiliser ces photos et pour les obtenir avec une plus grande résolution. |
|
Visites durant les 7 derniers jours
|
Vous pouvez
laissez un commentaire
sur cette page.