Bonjour a tous,
Pour ceux que ça intéresse, je viens de publier sur github un nouveau projet pour faire de la supervision KNX.
Pourquoi j'en suis arrivé la ? Je m'explique.
Je souhaite avoir sur mon téléphone portable, et sur mes PC chez moi un moyen de supervision assez complet.
J'ai donc commencé comme beaucoup a installer le trio knxd + linknx + knxweb2.
Seulement, je suis tombé sur plusieurs problèmes :
- Le principal, c'est la réactivité; en effet, sur mon plan principal, ou j'ai pas mal d'objet (lumière, volet roulant, température...), la page met toujours beaucoup de temps a s'ouvrir la première fois (parfois plus de 30s, et linknx renvois plein de Read sur le bus)...
Si je veux juste allumer la lumière ou faire une action, c'est très pénible...
- La compilation de linknx et le code rend le projet difficile (les autotools, j'ai toujours été allergique, la dépendance a libpth...)
- Il est difficile sous knxweb de créé des widget réutilisable.
- Le fait que la configuration du projet est faite en ligne, rend les usages de Git ou autre difficile.
- Le backgroud du plan principale étant fournis par la page web, cela prend toujours du temps a la première ouverture de la page...
- des types d'objet ne sont pas géré par linknx, et malheureusement il n'y a pas de déclassement générique; je ne sais plus lequel, mais c'est un problème que j'ai couramment quand je génère le linknx.xml depuis mon .knxproj; un type genre 9.015 s'il n'est pas géré, pourrait être utilisé comme un 9.xxx, mais au lieu de sa, linknx refuse simplement de se lancé.
Je me suis donc dis que l'utilisation des technologie Web n'était peut être pas le plus adapté...
Parallèlement a ça, dans mon travail, je me suis mis a Qt/QML, et plus je travail avec, plus je trouve cette techno bien adapté a ce genre de besoin... surtout que depuis Qt5, on peut facilement en faire une application Android.
Voici donc mon projet:
L'idée est de faire plusieurs daemons très simple, qui ne font qu'une seul chose chaqu'un (philosophie Unix).
1) La première couche est toujours knxd (https://github.com/knxd/knxd)
2) La seconde, a la place de linknx est KnxCached (https://github.com/condo4/knxcached)
Projet pure c++ sans autre dépendance que c++11 (et indirectement pthread, mais c'est du standard).
Compilé avec cmake.
Fichier de configuration généré par un script python a partir du projet.knxproj
3) Enfin, la derniere est une application Qt, j'ai mis dans un module la partie C++ et propre a ma communication avec KnxCached, ce qui fait que le développement de l'application finale, c'est uniquement du design QML qui peut même être fait intégralement dans le designer graphique.
Le module KnxQApp est disponible sur https://github.com/condo4/knxqapp et il dépend de la libssh2.
4) Pour l'utilisé, on peut utiliser les git submodule, et il faut juste écrire le main, pour donné un exemple, j'ai mis un bout de mon application pour servir d'exemple sur https://github.com/condo4/kaza
Le fonctionnement de KnxQApp permet sur Android le fonctionnement suivant:
Si je suis chez moi, dans mon reseau wifi a moi, KnxQApp se connect directement sur le port 6721 de KnxCached qui tourne sur ma wandboard (ma box domotique, une sorte de rasberry pi).
Sinon, une connection SSH (donc, niveau sécurité, c'est le top) est lancé par KnxQApp, pour établir un tunnel entre mon téléphone et KnxCached.
Cela me permet, en très peu de ligne de QML d'avoir une application très "tactile" sur mon téléphone, qui s'ouvre instantanément sur le réseau local (quand je suis chez moi), et s'ouvre en 5 seconde par le tunnel SSH malgré ma ligne ADSL pourri (j'ai pas 4Mo/s de débit download, donc, l'upload c'est quelques centaine de Ko/s).
En effet, toutes les ressources sont dans l'appli sur le téléphone, et seul quelques lignes de textes circule sur ma ligne (j'ai même prévu une option pour passer en communication binaire pour encore optimisé les temps de chargement).
Bien-sur, je ne suis qu'au commencement de ce projet; il n'est pas encore bien documenté, je n'ai pas encore fait les scripts d'init pour KnxCached, ni les fichiers pour packager sous debian, mais ça viendra....
Il reste donc encore pas mal de boulot; mais dans l'état actuel, j'ai déjà de quoi remplacer linknx/knxweb de façon plus souple pour mon besoin.
Pour le future, il me reste a faire:
1 daemon qui se connectera a KnxCached et permettra de logger les événements souhaité dans une base de donnée (ce que permet linknx).
1 autre qui permettra d'écrire des règles au format QML (l'équivalement du moteur de rules de linknx, mais en utilisant des fichiers QML non graphique, en effet, grace au "binding" qml, je pense que l'écriture de ces régle pourra être très souple et simple; en plus, le javascript permettra d'être illimité dans les possibilités offerte par ce moteur de règle.
Voici quelques image de mon application exemple:
A SUIVRE....
Pour ceux que ça intéresse, je viens de publier sur github un nouveau projet pour faire de la supervision KNX.
Pourquoi j'en suis arrivé la ? Je m'explique.
Je souhaite avoir sur mon téléphone portable, et sur mes PC chez moi un moyen de supervision assez complet.
J'ai donc commencé comme beaucoup a installer le trio knxd + linknx + knxweb2.
Seulement, je suis tombé sur plusieurs problèmes :
- Le principal, c'est la réactivité; en effet, sur mon plan principal, ou j'ai pas mal d'objet (lumière, volet roulant, température...), la page met toujours beaucoup de temps a s'ouvrir la première fois (parfois plus de 30s, et linknx renvois plein de Read sur le bus)...
Si je veux juste allumer la lumière ou faire une action, c'est très pénible...
- La compilation de linknx et le code rend le projet difficile (les autotools, j'ai toujours été allergique, la dépendance a libpth...)
- Il est difficile sous knxweb de créé des widget réutilisable.
- Le fait que la configuration du projet est faite en ligne, rend les usages de Git ou autre difficile.
- Le backgroud du plan principale étant fournis par la page web, cela prend toujours du temps a la première ouverture de la page...
- des types d'objet ne sont pas géré par linknx, et malheureusement il n'y a pas de déclassement générique; je ne sais plus lequel, mais c'est un problème que j'ai couramment quand je génère le linknx.xml depuis mon .knxproj; un type genre 9.015 s'il n'est pas géré, pourrait être utilisé comme un 9.xxx, mais au lieu de sa, linknx refuse simplement de se lancé.
Je me suis donc dis que l'utilisation des technologie Web n'était peut être pas le plus adapté...
Parallèlement a ça, dans mon travail, je me suis mis a Qt/QML, et plus je travail avec, plus je trouve cette techno bien adapté a ce genre de besoin... surtout que depuis Qt5, on peut facilement en faire une application Android.
Voici donc mon projet:
L'idée est de faire plusieurs daemons très simple, qui ne font qu'une seul chose chaqu'un (philosophie Unix).
1) La première couche est toujours knxd (https://github.com/knxd/knxd)
2) La seconde, a la place de linknx est KnxCached (https://github.com/condo4/knxcached)
Projet pure c++ sans autre dépendance que c++11 (et indirectement pthread, mais c'est du standard).
Compilé avec cmake.
Fichier de configuration généré par un script python a partir du projet.knxproj
3) Enfin, la derniere est une application Qt, j'ai mis dans un module la partie C++ et propre a ma communication avec KnxCached, ce qui fait que le développement de l'application finale, c'est uniquement du design QML qui peut même être fait intégralement dans le designer graphique.
Le module KnxQApp est disponible sur https://github.com/condo4/knxqapp et il dépend de la libssh2.
4) Pour l'utilisé, on peut utiliser les git submodule, et il faut juste écrire le main, pour donné un exemple, j'ai mis un bout de mon application pour servir d'exemple sur https://github.com/condo4/kaza
Le fonctionnement de KnxQApp permet sur Android le fonctionnement suivant:
Si je suis chez moi, dans mon reseau wifi a moi, KnxQApp se connect directement sur le port 6721 de KnxCached qui tourne sur ma wandboard (ma box domotique, une sorte de rasberry pi).
Sinon, une connection SSH (donc, niveau sécurité, c'est le top) est lancé par KnxQApp, pour établir un tunnel entre mon téléphone et KnxCached.
Cela me permet, en très peu de ligne de QML d'avoir une application très "tactile" sur mon téléphone, qui s'ouvre instantanément sur le réseau local (quand je suis chez moi), et s'ouvre en 5 seconde par le tunnel SSH malgré ma ligne ADSL pourri (j'ai pas 4Mo/s de débit download, donc, l'upload c'est quelques centaine de Ko/s).
En effet, toutes les ressources sont dans l'appli sur le téléphone, et seul quelques lignes de textes circule sur ma ligne (j'ai même prévu une option pour passer en communication binaire pour encore optimisé les temps de chargement).
Bien-sur, je ne suis qu'au commencement de ce projet; il n'est pas encore bien documenté, je n'ai pas encore fait les scripts d'init pour KnxCached, ni les fichiers pour packager sous debian, mais ça viendra....
Il reste donc encore pas mal de boulot; mais dans l'état actuel, j'ai déjà de quoi remplacer linknx/knxweb de façon plus souple pour mon besoin.
Pour le future, il me reste a faire:
1 daemon qui se connectera a KnxCached et permettra de logger les événements souhaité dans une base de donnée (ce que permet linknx).
1 autre qui permettra d'écrire des règles au format QML (l'équivalement du moteur de rules de linknx, mais en utilisant des fichiers QML non graphique, en effet, grace au "binding" qml, je pense que l'écriture de ces régle pourra être très souple et simple; en plus, le javascript permettra d'être illimité dans les possibilités offerte par ce moteur de règle.
Voici quelques image de mon application exemple:
A SUIVRE....