[pKNyX] Release dev

[fma38]

Hello,

Je viens de mettre en ligne une release de développement :

http://www.pknyx.org/wiki/Download

Bon, pour tout vous dire, chez moi, ça ne fonctionne pas bien. Les trames multicast ethernet envoyées sont consommées localement par l'appli, et n'arrivent jamais jusqu'à eibd. Et je ne comprend pas pourquoi ! Car si je lance un autre bout de code sur la même machine, on voit bien les trames. Mais elles ne semblent pas sortir de la machine.

Le pire, c'est que ça eu marché !!! Mais je ne sais pas ce que j'ai foutu, impossible de revenir à quelque chose de fonctionnel. Mais j'ai aussi des comportements différents suivant les noyaux linux, donc je me demande si je n'ai pas plusieurs choses qui se cumulent !

Donc si des courageux testeurs pouvaient me dire ce que ça donne chez eux...

Pour info, il faut un routeur KNX. Si vous n'avez pas (qui a ?), il suffit de lancer eibd pour qu'il fasse office de, en ajoutant simplement le flag -R.

Ensuite, vous pouvez tester en utilisant l'outil multicast.py pour lire sur le bus, genre :

$ multicast.py -l trace read 6/1/1

Merci d'avance !

PS : par contre, cette release est tout à fait fonctionnel pour ce qui est du coeur. Comme dans la page Idée en vrac, on peut créer des blocs fonctionels et les faire dialoguer entre eux. On peut déclencher des actions en fonction de modifications sur le bus, ou en fonction du temps. Cf dans le dossier d'exemples. Vous pouvez d'ailleurs utiliser l'exemple du timer pour tester sur votre installe et voir si les infos passent ou non (changez juste les GA).

[fma38]

Rhâââââ, je l'ai trouvé ce foutu bug !!!! Il était bien entre la chaise et le clavier !

Bon, sans rire, ça fonctionne. Les ceusses qui veulent faire des tests sont les bienvenus. On peut déjà s'amuser à faire des choses rigolottes, comme le timer en exemple (3_timer), qui éteint une lumière 10s (paramétrable via une GA) après qu'elle soit allumée.

Si vous avez des idées, et ne savez pas comment prendre le truc, n'hésitez pas à poster sur ce présent forum (ouvrez un nouveau fil), on pourra voir ensemble comment faire ça. Ça fera du concrêt.

Allez, va falloir que je fasse une annonce un peu officielle, quoi ;o)

[.vince]

Bravo Frédéric!
Dès que je peux, je jette un œil.

[Weevil]

Beau boulot,

J'aimerais avoir le temps de tester mais ça ne va pas être possible dans l'immédiat. Belle initiative en tout cas.

Bon courage pour la suite.

[fma38]

Pas de souci, les gars, y'a pas d'urgence ! Et pis c'est les vacances

Merci pour vos encouragements !

[fma38]

Je viens de mettre en ligne une nouvelle release de dev (0.9.2)

Le principal changement réside dans l'ajout d'un outil qui permet de créer un device à partir d'un template, et de gérer le lancement.

L'écriture d'un device s'en voit du coup simplifiée, le framework prenant en charge plus de trucs de manière transparente.

J'ai pondu un tutoriel qui correspond à cette version :

http://www.pknyx.org/wiki/Tutorial

[fma38]

Hello,

Je viens de mettre en ligne une nouvelle release de dev (0.9.3)

La principale amélioration est l'ajout du support du flag 'init' : dès que la pile KNX est démarrée, une requête de lecture est envoyée sur les Group possédant au moins un GroupObject avec le flag init mis.

[Stephane]

Salut,

je viens enfin de trouver le temps de tester pKNyX et vraiment c'est le top, je m'en sert pour controler ma tele avec un raspi et LibCEC.

Ca fonctionne parfaitement bien, par contre, il y a quelque chose que je n'ai pas du bien comprendre, le device ce lance correctement avec la commande "./admin.py rundevice" par contre je n'ai pas trouvé comment lancer automatiquement le device avec le rpi.

[fma38]

Cool que ça réponde à ton besoin

Le lancement automatique au démarrage... J'y pense, j'y pense, mais plus j'y pense, plus je désespère ! Le problème, ce sont ces foutus systèmes d'init, qui diffèrent d'une distro à l'autre. Debian est en train de basculer sur systemd...

Le plus simple, à mon avis, c'est d'utiliser la crontab, ainsi que le script global pknyx-admin.py (./admin.py est plutôt fait pour la phase de dev).

Un truc comme :

@reboot /usr/local/bin/pknyx-admin.py --path <chemin complet vers ton répertoire contenant ton device> rundevice

devrait marcher (note que l'option --detach n'est pas implémentée, mais n'est pas utile ici).

Dis-moi si ça fonctionne...

PS : faudrait que je fasse un stopdevice, mais je ne sais pas encore comment m'y prendre.

[Stephane]

J'ai essayé sans le cron sur un des exemples et ca ne marche pas:

pi@raspberrypi ~ $ pknyx-admin.py --path /home/pi/pKNyX/pknyx/examples/1_timer/ rundevice
usage: pknyx-admin.py [-h] {createdevice,checkdevice,rundevice} ...
pknyx-admin.py: error: invalid choice: '/home/pi/pKNyX/pknyx/examples/1_timer/' (choose from 'createdevice', 'checkdevice', 'rundevice')

au cas ou j'ai essayé aussi dans le repertoire du device et j'ai eu la même erreur.

[fma38]

Ah, essaye de mettre le rundevice avant le --path, cette dernière option étant spécifique à la commande rundevice.

Et c'est bien le dossier contenant le device qu'il faut pointer, par celui qui contient admin.py.

[Stephane]

Après pas mal de temps a testé/reboot j'abandonne, je me suis tourné vers une solution plus simple, lancer la devise manuellement en le lancant avec screen.

Ça me permet de faire tourner la device en tache de fond tout en gardant la possibilité de visualiser son exécution et éventuellement les erreurs.

Je n'ai pas réussi a le lancer avec cron je ne sait pas ce qui bloque mais pknyx ne ce lance pas...

[fma38]

Bon, je viens de tester (sous debian), et effectivement, ça ne veut pas partir... Je creuse pour trouver le problème.

---

J'ai réussi à le faire marcher (j'avais juste un souci dans le path). J'ai ceci dans ma crontab :

@reboot /usr/local/bin/pknyx-admin.py rundevice --path /home/fma/develop/git/pKNyX/pknyx/examples/1_timer/timer

Il faut bien éditer la crontab sous root avec :

$ sudo crontab -e

ça t'ouvre ton éditeur console sur le fichier temporaire de cron ; une fois modifié, tu le sauves (sous le même nom), tu quittes, et c'est bon. Tu peux vérifier avec :

$ sudo crontab -l

Tu dois pouvoir associer ça avec l'utilisation de screen, logiquement (ce qui est une bonne idée).

[Stephane]

Ok, merci pour ton aide je retesterai ca demain.

Pour ce qui est du cron, le @reboot nécessite de toute facon que ce soit sur le compte admin donc je l'avais bien pris en compte.

[fma38]

Quelle distro utilises-tu ? Le mieux est de configurer le compte admin (root, quoi) pour lui dire d'envoyer les notifications sur une adresse courriel ; comme ça, tu vois passer les erreurs de cron. En tout cas, c'est comme ça sous debian...

[Stephane]

J'utilise raspbian donc oui je doit pouvoir l'activer.