Nouveau projet libre de Supervision

[condo4]

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....

[pollux06]

Je vais suivre ça de très très près.

Juste deux petites questions :
- Si j'ai bien compris on obtient une application QT qui doit être compilée en fonction de l'OS ?
- De plus QT n'est pas dispo sur iOS ce qui exclu tous les iPhone ..... c'est bien ça ?

[condo4]

Je vais suivre ça de très très près.

Juste deux petites questions :
- Si j'ai bien compris on obtient une application QT qui doit être compilée en fonction de l'OS ?
- De plus QT n'est pas dispo sur iOS ce qui exclu tous les iPhone ..... c'est bien ça ?

Oui oui, c'est une application Qt QML.
Sauf que Qt peut etre compilé pour windows mac linux android ios sailfish... et encore d'autre platforme plus rare...
Donc si, on peut faire une apmlication ios, seul limitation, il faut posséder un Mac pour compiler pour iOS.
Et c'est justement parsque c'est une appli native qu'on a accès a des choses difficilement realisable en appli web.
Les gestures avancé cmeble pinch-zoom ou les flikables, les animation fluides, même la 3D si on s'en donne la peine.
Après sa demande quand même des connaissances en QML, donc c'est moins "universelle" qu'une solution web, mais les possibilités sont bien plus importante, et graphiquement c'est tout de suite bien plus puissant.

De plus avec le designer et les quick control 2, y'a pas mal de widget utilisable, sans compter les add ons comme kirigami de kde...

Bref, billet d'entrée plus lourd, mais possibilité bien plus poussé, plus loin meme que les supervisions payante que j'ai pu voir jusqu'a maintenant.

[R4v3n]

Je vais suivre ton projet de près, d'ailleurs je le suis déjà sur github
Petite question, avant de commencer ce projet, as-tu testé Domogik ?

Si tu as besoin d'un coup de main rapide pour tes scripts d'init et/ou pour packager tes debs (si tu ne l'as jamais fait), je peux te filer un coup de main

[condo4]

Je vais suivre ton projet de près, d'ailleurs je le suis déjà sur github
Petite question, avant de commencer ce projet, as-tu testé Domogik ?

Si tu as besoin d'un coup de main rapide pour tes scripts d'init et/ou pour packager tes debs (si tu ne l'as jamais fait), je peux te filer un coup de main

Salut,

Domogik, je n'ai pas testé, mais est-t-elle vraiment efficace sur KNX ?
J'ai surtout testé linknx/knwweb, et jeedom.
Jeedom n'est pas vraiment super reactif car il n'est pas fait a la base pour KNX, et utilise un plugin pour communiqué sur le bus; résultat, un clique sur une action met plus d'une seconde pour réagir sur l'actionneur...

Le but avec KnxCached, c'est l'inverse; en gros, traduire touts les composant non KNX en objets KNX; et que tout le design se base sur la techno KNX elle même.
Par exemple, ma VMC, mon poel, mon chauffe eau... je vais écrire des script/programme/deamon qui traduiront les commandes/status/informations en objets KNX avec une GA.
La supervision les verra vraiment comme de véritable objets KNX (répondant au READ; réagissant au WRITE...)
Ils pourront aussi directement être utilisé par les vrais objets KNX.

Parallèlement a ça, je développe un petit composant universelle a base de Nucleo-STM32L432 + TPUART alimenté directement par le bus KNX, qui me permettra de créer des interfaces avec par exemple des sondes de température one-wire, des ADC / DAC / GPIO...
J'ai un début fonctionnant avec FREERTOS je gère parfaitement la lecture, mais j'ai un gros bug lorsque je cherche a envoyer une trame sur le bus; dès qu'il sera finalisé, je le placerais aussi sur GitHub.

[filou59]

Interessant comme projet.
Bon courage.

Sinon une solution pour éviter ce genre de problème de lenteur, c'est de passer par un Tier pour recevoir ou envoyer les info sur le bus KNX.
Moi je passe par un automate WAGO, du coup si je met une supervision pas besoin de soft KNX pour recevoir et interpréter les trame, c'est l'automate qui le fait, ensuite on communique avec l'automate en TCP avec des protocole rapide et plus standard (Modbus TCP par exemple).

Certaines société vendent des solutions a base de Raspberry et de Codesys il me semble.

Enfin voilà c'est une autre approche.

[R4v3n]

Je vais suivre ton projet de près, d'ailleurs je le suis déjà sur github
Petite question, avant de commencer ce projet, as-tu testé Domogik ?

Si tu as besoin d'un coup de main rapide pour tes scripts d'init et/ou pour packager tes debs (si tu ne l'as jamais fait), je peux te filer un coup de main

Salut,

Domogik, je n'ai pas testé, mais est-t-elle vraiment efficace sur KNX ?
J'ai surtout testé linknx/knwweb, et jeedom.

Justement, je n'ai (malheureusement) pas encore d'installation KNX chez moi.
Par contre je sais que Basilic (de domogik) supervise déjà son KNX avec : https://github.com/Basilic/domogik-plugin-knx

Donc si tu veux tester la pertinence et l'efficacité, pour le comparer à ce que tu as déjà pu tester, c'est cool

[vf62]

J'ai surtout testé linknx/knwweb, et jeedom.
Jeedom n'est pas vraiment super reactif car il n'est pas fait a la base pour KNX, et utilise un plugin pour communiqué sur le bus; résultat, un clique sur une action met plus d'une seconde pour réagir sur l'actionneur...

Etrange, de mon côté, je suis passer de linknx à jeedom et je ne constate pas cette latence

bon courage !

[ferllings]

Justement, je n'ai (malheureusement) pas encore d'installation KNX chez moi.
Par contre je sais que Basilic (de domogik) supervise déjà son KNX avec : https://github.com/Basilic/domogik-plugin-knx

Donc si tu veux tester la pertinence et l'efficacité, pour le comparer à ce que tu as déjà pu tester, c'est cool

Pour avoir participé à Domogik, je peux dire que c'est un super projet.
Par contre le plugin de Basilic n'est pas supporté par la dernière version.

[R4v3n]

Justement, je n'ai (malheureusement) pas encore d'installation KNX chez moi.
Par contre je sais que Basilic (de domogik) supervise déjà son KNX avec : https://github.com/Basilic/domogik-plugin-knx

Donc si tu veux tester la pertinence et l'efficacité, pour le comparer à ce que tu as déjà pu tester, c'est cool

Pour avoir participé à Domogik, je peux dire que c'est un super projet.
Par contre le plugin de Basilic n'est pas supporté par la dernière version.

Suffit de lui demander d'upgrader

[ferllings]

Justement, je n'ai (malheureusement) pas encore d'installation KNX chez moi.
Par contre je sais que Basilic (de domogik) supervise déjà son KNX avec : https://github.com/Basilic/domogik-plugin-knx

Donc si tu veux tester la pertinence et l'efficacité, pour le comparer à ce que tu as déjà pu tester, c'est cool

Pour avoir participé à Domogik, je peux dire que c'est un super projet.
Par contre le plugin de Basilic n'est pas supporté par la dernière version.

Suffit de lui demander d'upgrader

Il le sait. Mais je ne sais pas si il a le temps

[R4v3n]

Justement, je n'ai (malheureusement) pas encore d'installation KNX chez moi.
Par contre je sais que Basilic (de domogik) supervise déjà son KNX avec : https://github.com/Basilic/domogik-plugin-knx

Donc si tu veux tester la pertinence et l'efficacité, pour le comparer à ce que tu as déjà pu tester, c'est cool

Pour avoir participé à Domogik, je peux dire que c'est un super projet.
Par contre le plugin de Basilic n'est pas supporté par la dernière version.

Suffit de lui demander d'upgrader

Il le sait. Mais je ne sais pas si il a le temps

Basilic me dit qu'il a refait le plugin complètement il y a 1 an environ et qu'il fonctionne sur le dernier domogik. Il n'a juste pas implémenté tous les différents services au niveau de la config.

Si des gens veulent contribuer, ils sont les bienvenus !

[Baslic]

Bon visiblement il y a un couack dans l'enregristrement de mon pseudo (Basilic devenu Baslic) ce qui m'a occassionner quelque problème pour me connecté.

Merci a R4v3n pour la réponse.

Je confirme donc avoir re développé le plugin KNX pour la dernière version de Domogik (plugin en MQ) le plugin intégre l'ensemble des DPT dans sont fonctionnement interne.

Ce qui n'est pas "terminé" c'est la création de tous les différents type de composant pouvais être ajouter a Domogik car je n'ai que des lumières ou variateur piloté en KNX.

Il suffit en "gros" de rajouté ceux qui manque dans le fichier json du plugin pour pouvoir ajouter les autres nécessaire a Domogik, ce que je serai ravis de faire si j'avais tous le matériel pour testé tous.

[pollux06]

Salut Basilic,

Est-ce que ton plugin + Domogik sont capable de d'extraire des données de certains DPT "exotiques" comme le DPT 235.001 ?

Ce DPT est sur 6 octets et contient l'énergie consommée sur les 4 premiers octets, le tarif sur le cinquième octet et un sixième octet réservé pour de futures extensions.
Linknx ne gère pas ce genre de DPT et pour faire une extraction via du LUA, il faut un proc + OS en full 64 bits ce qui exclu tous les Raspi et consorts.

[Baslic]

Salut Basilic,

Est-ce que ton plugin + Domogik sont capable de d'extraire des données de certains DPT "exotiques" comme le DPT 235.001 ?

Ce DPT est sur 6 octets et contient l'énergie consommée sur les 4 premiers octets, le tarif sur le cinquième octet et un sixième octet réservé pour de futures extensions.
Linknx ne gère pas ce genre de DPT et pour faire une extraction via du LUA, il faut un proc + OS en full 64 bits ce qui exclu tous les Raspi et consorts.

J'aurais du dire, le plugin gère les DPT courant (de 1 à 20 je crois)

Mais si tu as la documentation on peut l'intégrer, je ne vois pas de problème particulier à l'ajouter.

Par contre je ne vois pas le 235 dans ce document

[pollux06]

Les DPT 229 et 235 ont été introduite dans la version 2.1 du protocole KNX (Janvier 2014).

Pour le DPT 235.001 il 'agit en fait d'un regroupement sur 6 octets de l'énergie active + l'index tarifaire  + 1 byte de validité des données
Donc dans le détail  :

•    les 4 premier bytes sont un entier signé 32 bits active energie (DPT 13.010) mesurée en Wh en fonction du tarif indiqué dans le champ Tariff.
  
•    le cinquième byte est un entier non signé 8 bits Tarif (DPT 5.006) associé à l'énergie active du champs ActiveElectricalEnergy
  
•    le sixième byte est un simple binaire 8 bits b0 =0 si Tarif valide et b1=0 si Active energy valide. Le reste est réservé.
  

La description du DPT 229.001 est dispo en page 75 de ce pdf. Pour le 235.001, je n'arrive plus à remettre la main dessus.

[fma38]

Le but avec KnxCached, c'est l'inverse; en gros, traduire touts les composant non KNX en objets KNX; et que tout le design se base sur la techno KNX elle même.

C'est exactement le paradigme que j'ai adopté avec pKNyX (framework python pour KNX).

Intéressant, ton projet ; je vais y jeter un oeil.

[silverrcx]

1) La première couche est toujours knxd (https://github.com/knxd/knxd)

[..]

Fichier de configuration généré par un script python a partir du projet.knxproj

Je vais être critique mais franchement, en 2018, un nouveau projet de supervision se doit de:
(a) importer correctement toute la config ETS5. Elle est en XML pour ça. Toute la maison (ou presque) peut-être documentée dans ETS: étages, pièces, fonctions. 
C'est dommage de limiter l'import du fichier ETS à l'obtention d'une liste plate des GA alors que tout pourrait être importé d'un coup...
(b) être KNX/IP natif. KNX est documenté sur multicast IP (ou TCP si vraiment on veut du tunnel), on peut avoir un appareil KNX complètement IP. 
A quoi sert la brique KNXD ?
Ceux qui ont refait leur BCU avec un FPGA pour interfacer le bus peuvent utiliser KNXD pour prétendre avoir une interface IP. Les autres ont un routeur IP et n'ont pas franchement besoin d'un process en plus qui fait vaguement passe plat.

[condo4]

Je vais être critique mais franchement, en 2018, un nouveau projet de supervision se doit de:
(a) importer correctement toute la config ETS5. Elle est en XML pour ça. Toute la maison (ou presque) peut-être documentée dans ETS: étages, pièces, fonctions. 
C'est dommage de limiter l'import du fichier ETS à l'obtention d'une liste plate des GA alors que tout pourrait être importé d'un coup...
(b) être KNX/IP natif. KNX est documenté sur multicast IP (ou TCP si vraiment on veut du tunnel), on peut avoir un appareil KNX complètement IP. 
A quoi sert la brique KNXD ?
Ceux qui ont refait leur BCU avec un FPGA pour interfacer le bus peuvent utiliser KNXD pour prétendre avoir une interface IP. Les autres ont un routeur IP et n'ont pas franchement besoin d'un process en plus qui fait vaguement passe plat.

Je ne suis pas totalement d'accord avec toi.
Déjà pour A, je ne vois pas ce que je pourrais importer de plus que les GA pour le moment.
Au niveau de KnxCached, j'ai uniquement besoin de connaitre les GA et leur types; je ne vois pas pourquoi j'aurais besoin des pièces ou d'une autre info d'ETS sur cette couche...
Pour B, être KNX/IP natif, j'y ai pensé; mais ça ne marche que pour ceux qui ont un routeur KNX/IP... perso, je n'ai qu'une passerelle... et la possibilité de  mettre directement une raspberry sur KNX avec un TPUART est aussi une solution qui peut être intéressant. Pourquoi refaire ce que knxd fait déjà , bref, je suis un amoureux du principe d'unix, ou a un programme couteau suisse (usine a gaz difficile a maintenir et a faire évoluer), je préfère plusieurs démon qui ne servent qu'a une chose chaqu'uns, mais que mis ensemble, ils offres des possibilités infinis.
Pour la couche de connexion a KNX, knxd fait très bien son travail, ne consomme pas beaucoup de ressource, et offre de nombreuses possibilité, depuis qu'ils ont supprimé la dépendance a la lib pthsem, je ne voit plus de problème pour l'utiliser.
Mon but n'est justement pas de refaire un N-ième Jeedom ou autre supervision existante; je cherche plutôt un ensemble de projets simple, qui pourront être potentiellement interchangeable, qui resteront le plus simple possible pour que n'importe qui puisse s'approprier le code; qui ne dépendront que d'un minimum de librairies, qui seront compiler (j'ai horreur de Java, node.js et autre techno de ce genre, surtout pour des démons). Seul les couches "hautes" du système dépendront de Qt5, mais ce sera tout, et encore c'est du C++, compilé et performant.
Pour le moment, je n'en suit qu'au début, c'est encore assez brouillon et pas trop débuguer (en paralelle, je suis sur un projet de composant KNX STM32+TPUART, donc mon temps libre est pas mal occupé), mais ma première application sur mon téléphone marche déjà de façon bien plus fluide que les 2 dernières supervisions  que j'avais testé (Jeedom et KnxWeb2), et les possibilité de design (avec QML) sont beaucoup plus ouverte.
Alors certe, il faut connaitre QML, Qt, un peut de C++; 
Ce n'ai pas une supervision ne demandant que de la configuration au travers d'un site Web, c'est plus un framework basé sur Qt/QML, permettant assez rapidement pour un développeur Qt de faire une application professionnel, personnalisé et performante a son gout.

[silverrcx]

Au niveau de KnxCached, j'ai uniquement besoin de connaitre les GA et leur types; je ne vois pas pourquoi j'aurais besoin des pièces ou d'une autre info d'ETS sur cette couche...

Un dimmer, ca a un GA de switch, un de dim, un pour lire l'état, un pour écrire un % de dim, un pour lire le même %. Tu importes ca en liste plate sans lien entre les GA alors que ton appli QT devra savoir que ces GAs vont ensemble pour contrôler le dimmer.

ETS propose un système qui permet de documenter ce groupe et l'exporte (pareil pour les pièces, etc). En tant qu'utilisateur du logiciel de supervision, ca me serait utile que l'ensemble des composants qui réalisent la supervision ne jette pas cette information pour des raisons de simplicité ou d'architecture logicielle.

Les magazines sont pleins d'articles qui s'alarment de la montée de l'intelligence artificielle, mais pour que cela devienne une réalité, il va falloir que les développeurs embrassent un peu de complexité plutôt que de l'externaliser

Je ne vois pas pourquoi KnxCached ne pourrait pas exposer les infos de building et de fonctions apprises de l'import ETS. Que je sache, l'appli QT ne les sucera pas de son pouce, ces infos...

Pour B, être KNX/IP natif, j'y ai pensé; mais ça ne marche que pour ceux qui ont un routeur KNX/IP... perso, je n'ai qu'une passerelle... et la possibilité de mettre directement une raspberry sur KNX avec un TPUART est aussi une solution qui peut être intéressant.

Ben alors utilise knxd pour faire le lien. KNXD peut réaliser la fonction de routage. Donc dans le cas le plus simple, il y a un routeur et KnxCached. Si il n'y a pas de routeur, alors knxd fait le boulot de remettre ça en IP multicast depuis un BCU ou quoi.

Et je ne me limitais pas au routage. KnxCached pourrait supporter le tunneling directement sur ta passerelle (ce que, pareil, knxd peut émuler si jamais il n'y a pas de passerelle).

Je ne dis pas que knxd est inutile. Je dis qu'on peut en réserver l'usage au cas particuliers et considérer que l'utilisateur moyen d'une supervision aura au moins une passerelle, sinon un routeur.

[condo4]

Un dimmer, ca a un GA de switch, un de dim, un pour lire l'état, un pour écrire un % de dim, un pour lire le même %. Tu importes ca en liste plate sans lien entre les GA alors que ton appli QT devra savoir que ces GAs vont ensemble pour contrôler le dimmer.

ETS propose un système qui permet de documenter ce groupe et l'exporte (pareil pour les pièces, etc). En tant qu'utilisateur du logiciel de supervision, ca me serait utile que l'ensemble des composants qui réalisent la supervision ne jette pas cette information pour des raisons de simplicité ou d'architecture logicielle.

Le problème, c'est qu'il me semble qu'il me manque des infos dans ETS pour que je puisse m'en servir (ou alors, j'ai pas trouvé..)
Si je reprend l'exemple du Dimmer, chez moi j'ai jusqu’à 7 objets pour cette fonction (avec la passerelle DALI):
Lock (1.003)
Switch (1.001) et son retour Status (1.011)
Dimming (3.007)
SetValue (5.001) et son retour GetValue (5.001)
Errors (1.011)
Slope (225.001) (Que je n'utilise pas encore)
Donc, dans ma première idée, depuis l'XML d'ETS, je récupérais cette information depuis les fonctions défit dans "Batiment"; malheureusement, je n'ai pas trouvé comment savoir qui est Switch, qui est Errors...
Je pensais me basé sur leur type, mais comment différencier SetValue de GetValue...
Du coup, j'ai structuré mes groupes pour que l'information soit contenu dans le group median
Light/Switch/Chambre1
Light/Errors/Chambre1
....
Ce qui fait que ma liste "a plat" contient finalement l'information, et dans mon QML, j'ai créé un Widget Dimmer, le seul paramètre que je lui donne, c'est Chambre1, a partir de la, il retrouve les 7 GAs dont il a besoin...
Ce qui fait que en quelques minutes, j'ai instancier les 12 Dimmer que j'avais besoin sur mon plan...
J'aurais préféré me basé sur les "fonctions" défini dans ETS, mais il me manque une information... du coup, je m'en suis passé...
Si tu as une meilleur idée, je ne suis pas contre, mais dans mon projet, la vue Bâtiment ne me sert pas a grand chose, et soit j'ai pas compris un truc dans ETS, soit les "fonctions" ne sont pas vraiment utiles car il manque une information...

[condo4]

Bonjour a tous,
Quelques nouvelle de ce projet;
Je ne l'ai pas abandonné, mais comme j'avais un peu moins de temps ces derniers moi, j'ai pas énormément avancé.
J'ai quand même avancé sur mon architecture.
1er gros point, je suis en train de remplacer mes communications avec knxcached, elles étaient auparavant basé sur des ordre SCPI (format text sur socket TCP), je suis en train de le remplacer par 2 sockets NNG (ex nanomsg, lui même dérivé de ZeroMQ), une socket REQ/REP pour interroger le service, et une PUB/SUB pour être notifier des changements (suite a des W sur le bus KNX par exemple).
ça va me permettre d'être beaucoup plus performant. En effet, NNG permet a la fois de communiqué par socket TCP pour les applications qui tournent sur un host différent (donc ma supervision), mais aussi par IPC/pipe/unix socket/websocket.... pour les daemon qui tourneront sur le même host, et ce, de façon totalement transparente, et je ne suis plus obligé de passer par la conversion text. Sur PubSub, j'ai des topic sous forme text, et sous forme binaire. Chaque objet émettant les 2, libre a l'application d'utiliser celle qu'elle souhaite...
De plus, avec les possibilités donnée par les websocket, rien n’empêche plus tard de développer aussi une interface web.
Je suis donc en train de revoir mon connecteur KnxQApp pour utiliser ces nouvelles sockets.
De plus, je vais faire en sorte de pouvoir mettre sur GitHub mon applications complète pour servir d'exemple a ceux qui voudraient essayer.

[lolilol]

Bonjour,

je viens de tomber sur ceci : QT Knx

Cela semble pas mal du tout. Il y a pas mal d'exemple qui m'ont l'air simple.
Quelques instructions pour réaliser la connexion à la passerelle IP. Ensuite, il suffit de construire la trame de bus que l'on veut envoyer et faire sendFrame

Code :

QKnxNetIpTunnel connection;
connection.connectToHost(QHostAddress(...), port);

QKnxLinkLayerFrame frame = QKnxLinkLayerFrame::builder()
   .setDestinationAddress({ QKnxAddress::Type::Group, QLatin1String("2/6/4") })
   .setTpdu({
       QKnxTpdu::TransportControlField::DataGroup,
       QKnxTpdu::ApplicationControlField::GroupValueWrite,
       QKnxSwitch(QKnxSwitch::State::On).bytes()
   }).create();

connection.sendFrame(frame);

Dispo également quelques infos ici : https://github.com/qt/qtknx

J'ai pas regardé plus en détail, mais il doit y avoir un handler au niveau des classes pour lire également les messages du bus.

Si on le combine avec ceci :
https://www.ics.com/blog/configuring-qt-...spberry-pi

Cela permettrait facilement de faire tourner sur un raspberry une solution KNX très simple, fiable et rapide.

J'avais envisagé cela avec falcon au début. Ce qui m’ennuie, c'est le fait de pas être exportable facilement sur un raspberry ou autre. Alors qu'avec QT, il ne devrait plus y avoir de problème de compatibilité.

Tu en penses quoi ?