12/05/2013, 18:08:42
Merci pour vos retours. Voici quelques compléments d'explication ; je dois admettre que tout n'est pas encore clair dans ma tête, même si j'ai des idées pour l'essentiel.
En fait, je ne cherche pas à ré-inventer la roue. On a des projets existants très aboutis, mais très différents par leur approche. Il y a bien sûr linknx, qui est en fait le déclencheur de mon projet. On a aussi Calimero, très chouette d'un point de vue architecture logicielle, mais qui ne fait rien de clé en main ; et d'autres projets, comme Domogik, qui est beaucoup plus généraliste.
linknx ne répond pas à 100% de mes besoins, pour 2 raisons principales : il est écrit en C++, qui nécessite une compilation, toujours pénible et laborieuse sur les systèmes embarqués ; il est trop monolithique, et ne permet pas d'étendre ses possibilités facilement. Il est conçu comme une appli finale, avec juste du paramétrage (fichiers xml).
Domogik, lui, permet de mixer plein de technos, chose dont je n'ai pas forcément besoin. C'est un atout pour la domotique DIY, où l'on essaye d'utiliser des composants pas trop chers (1-wire, CPL...), mais du coup, je pense qu'on ne peut pas exploiter les possibilités d'un bus plus industriel comme le KNX.
Il y a plein d'autres superviseurs, mais qui tiennent plus du gadget, pour frimer avec son iPhone/bidule Android (je n'ai ni l'un ni l'autre !!!). Ce n'est pas du tout ce que je cherche.
Je pense qu'il y a réellement la place pour un nouveau truc tel que je le conçois : à mi-chemin entre Calimero (purement une librairie), et une appli finale comme linknx. Ça s'adressera clairement à des gens qui ont envie de faire un peu de développement : rien ne se fera directement depuis une interface web clickodrome pour la mise en oeuvre/configuration (le web permettra, en fait, d'éditer directement les scripts ; c'est hyper simple à faire, et ne souffrira d'aucune limitation). Il faudra coder (en python, langage vraiment très abordable pour des non spécialistes ; il est maintenant au programme découverte info en 2nde !). Mais pas coder from scratch : on aura à sa disposition des briques de très haut niveau, très proche du fonctionnement du bus KNX, et qui permettront de construire principalement une sorte d'automate intelligent pour étendre les fonctionnalités d'une installation KNX.
La première brique sera les rules, comme je l'ai grossièrement présenté . L'idée c'est de pouvoir faire une sorte de petit programme autonome, simple et robuste, pour déclencher des évènements (en fonction du temps, de l'activité sur le bus, d'un signal sur bus série ou IR). Ce sera donc à l'utilisateur décrire un script python qui s'exécutera en tâche de fond pour répondre à un problème précis (genre gestion du chauffage, avec modification des consignes en fonction des heures et jours de la semaine). À priori, les rules seront state-less (pas de mémorisation d'état d'un appel sur l'autre).
Un autre aspect sera de pouvoir créer des participant virtuels, genre station météo utilisant des infos web. linknx permet de dialoguer avec le monde extérieur, mais c'est trop limité. Là, on pourra écrire un bout de programme qui ira chercher des infos sur le web, et qui les présentera sur le bus KNX. Ce nouveau participant aura des objets de communication, qui devront être liés à des GA, comme on le fait sous ETS. Mais là, ça se fera en codant (toujours très simplement, genre juste un appel à un gestionnaire avec 2 ou 3 paramètres). Le tout restant très lisible : la lisibilité du code résultant sera pour moi une priorité ; même sans tout piger, il sera facile pour un non initié de modifier un script pour aller changer quelques paramètres, comme il le ferait via un clickodrome (changer les température, par exemple).
Je pense que les gens qui ont choisi le bus KNX sont des gens qui ont un peu plus de moyens, et qui ne cherchent généralement pas à faire du 1-wire ou du CPL. Le KNX sera dont l'épine dorsale du projet, pour l'échange d'infomations. La majorité des pariticipants seront réels, et le framwork permettra juste d'étendre les possibilités de l'installation ; il n'aura pas vocation à créer une installation de toute pièce, avec uniquement des trucs virtuels. Je pense que ça n'aurait pas de sens d'utiliser KNX, dans ce cas (mieux vaut se tourner vers xPL, comme le fait Domogik).
Voili. J'espère être plus clair. Encore une fois, simplicité, robustesse et maintenance seront mes priorités. Python est très bien pour ça. Pour info, j'ai développé pendant quelques années un logiciel de pilotage pour gros instrument (diffraction neutronique) : on a une partie sur des cartes embarquées, et une partie sur un PC sous linux. Ça tourne 24/24, pendant de longues périodes. Et on n'a vraiment aucun souci de stabilité (vu le coût des neutrons, faut que ça marche !).
Je n'ai pas beaucoup avancé sur le dev, ces derniers temps, mais je suis en train de m'y remettre. J'ai pour le moment besoin de bien comprendre comme s'articule Calimero par rapport aux divers fonctionalités du bus KNX, pour faire du tri et ne conserver que ce qui est pertinent. Calimero permet par exemple d'aller taper directement sur les participants réels, pour voir les propriétés de ceux-ci. Ou de programmer un participant. Ce n'est pas du tout mon but !
En fait, je ne cherche pas à ré-inventer la roue. On a des projets existants très aboutis, mais très différents par leur approche. Il y a bien sûr linknx, qui est en fait le déclencheur de mon projet. On a aussi Calimero, très chouette d'un point de vue architecture logicielle, mais qui ne fait rien de clé en main ; et d'autres projets, comme Domogik, qui est beaucoup plus généraliste.
linknx ne répond pas à 100% de mes besoins, pour 2 raisons principales : il est écrit en C++, qui nécessite une compilation, toujours pénible et laborieuse sur les systèmes embarqués ; il est trop monolithique, et ne permet pas d'étendre ses possibilités facilement. Il est conçu comme une appli finale, avec juste du paramétrage (fichiers xml).
Domogik, lui, permet de mixer plein de technos, chose dont je n'ai pas forcément besoin. C'est un atout pour la domotique DIY, où l'on essaye d'utiliser des composants pas trop chers (1-wire, CPL...), mais du coup, je pense qu'on ne peut pas exploiter les possibilités d'un bus plus industriel comme le KNX.
Il y a plein d'autres superviseurs, mais qui tiennent plus du gadget, pour frimer avec son iPhone/bidule Android (je n'ai ni l'un ni l'autre !!!). Ce n'est pas du tout ce que je cherche.
Je pense qu'il y a réellement la place pour un nouveau truc tel que je le conçois : à mi-chemin entre Calimero (purement une librairie), et une appli finale comme linknx. Ça s'adressera clairement à des gens qui ont envie de faire un peu de développement : rien ne se fera directement depuis une interface web clickodrome pour la mise en oeuvre/configuration (le web permettra, en fait, d'éditer directement les scripts ; c'est hyper simple à faire, et ne souffrira d'aucune limitation). Il faudra coder (en python, langage vraiment très abordable pour des non spécialistes ; il est maintenant au programme découverte info en 2nde !). Mais pas coder from scratch : on aura à sa disposition des briques de très haut niveau, très proche du fonctionnement du bus KNX, et qui permettront de construire principalement une sorte d'automate intelligent pour étendre les fonctionnalités d'une installation KNX.
La première brique sera les rules, comme je l'ai grossièrement présenté . L'idée c'est de pouvoir faire une sorte de petit programme autonome, simple et robuste, pour déclencher des évènements (en fonction du temps, de l'activité sur le bus, d'un signal sur bus série ou IR). Ce sera donc à l'utilisateur décrire un script python qui s'exécutera en tâche de fond pour répondre à un problème précis (genre gestion du chauffage, avec modification des consignes en fonction des heures et jours de la semaine). À priori, les rules seront state-less (pas de mémorisation d'état d'un appel sur l'autre).
Un autre aspect sera de pouvoir créer des participant virtuels, genre station météo utilisant des infos web. linknx permet de dialoguer avec le monde extérieur, mais c'est trop limité. Là, on pourra écrire un bout de programme qui ira chercher des infos sur le web, et qui les présentera sur le bus KNX. Ce nouveau participant aura des objets de communication, qui devront être liés à des GA, comme on le fait sous ETS. Mais là, ça se fera en codant (toujours très simplement, genre juste un appel à un gestionnaire avec 2 ou 3 paramètres). Le tout restant très lisible : la lisibilité du code résultant sera pour moi une priorité ; même sans tout piger, il sera facile pour un non initié de modifier un script pour aller changer quelques paramètres, comme il le ferait via un clickodrome (changer les température, par exemple).
Je pense que les gens qui ont choisi le bus KNX sont des gens qui ont un peu plus de moyens, et qui ne cherchent généralement pas à faire du 1-wire ou du CPL. Le KNX sera dont l'épine dorsale du projet, pour l'échange d'infomations. La majorité des pariticipants seront réels, et le framwork permettra juste d'étendre les possibilités de l'installation ; il n'aura pas vocation à créer une installation de toute pièce, avec uniquement des trucs virtuels. Je pense que ça n'aurait pas de sens d'utiliser KNX, dans ce cas (mieux vaut se tourner vers xPL, comme le fait Domogik).
Voili. J'espère être plus clair. Encore une fois, simplicité, robustesse et maintenance seront mes priorités. Python est très bien pour ça. Pour info, j'ai développé pendant quelques années un logiciel de pilotage pour gros instrument (diffraction neutronique) : on a une partie sur des cartes embarquées, et une partie sur un PC sous linux. Ça tourne 24/24, pendant de longues périodes. Et on n'a vraiment aucun souci de stabilité (vu le coût des neutrons, faut que ça marche !).
Je n'ai pas beaucoup avancé sur le dev, ces derniers temps, mais je suis en train de m'y remettre. J'ai pour le moment besoin de bien comprendre comme s'articule Calimero par rapport aux divers fonctionalités du bus KNX, pour faire du tri et ne conserver que ce qui est pertinent. Calimero permet par exemple d'aller taper directement sur les participants réels, pour voir les propriétés de ceux-ci. Ou de programmer un participant. Ce n'est pas du tout mon but !