Domotique Open Source. Des Volontaires Pour Un Vrai Projet ?

[declencher]

Bonjour tout le monde !

Je suis SynoZWave depuis le début du projet, et je trouvais l'idée vraiment intéressante (d'ailleurs je vais prochainement essayé). Le projet avance toujours, et un article récent sur le site touteladomotique m'a fait réagir. En gros pour l'instant le projet est fermé, et il pourrait un jour devenir payant. Une prochaine version du DSM aidera surement avec l'arrivée d'un market à la Play store ou App store.

Perso je n'ai rien contre donner quelques euros pour un soft ou un package qui a demandé du travail à son auteur. Mais on peut toujours se poser la question de la stabilité et du suivi des packages dans le temps...

Ce qui m'a étonné, c'est le nombre de personnes qui avaient envie de regarder/participer à la programmation du projet (j'en fait parti). L'auteur du soft s'est clairement exprimé là dessus, cette décision lui appartient et c'est son droit. Perso je n'ai rien contre cette position (j'ai la même sur un logiciel que je distribue pourtant gratuitement depuis des années).

J'aurai aimé travailler sur un projet similaire, mais perso je n'ai plus le temps, entre famille, boulot, projets informatiques déjà lancés et loisirs...

C'est là que je me suis dit : Et pourquoi pas créer un nouveau projet open source, un vrai projet, avec un cahier des charges, une feuille de route, des développeurs passionnés, des beta testeurs... et un code ouvert auquel chacun pourrait participer !

L'idée n'est pas de recréer le soft d'une vera, d'une zipabox, d'une zibase ou autre, mais plutôt de commencer à batir un système évolutif, exploitant le zwave et le rfxcom, sur lequel on pourrait greffer des plugins progressivement...

Nous sommes déjà nombreux à avoir fait des tests, dont certaines stars de ce forum qui aident tout le monde (rfxcom, sonde Oregon, téléinformation, zwave...).

Qu'en pensez vous ? Si un tel projet se lançait, seriez vous partant ?

[Sp@r0]

Moi je conseillerais plutôt de contribué au développement et au portage (un peu lourd mais faisable) d'un projet déjà bien avancée comme domogik en plus c'est français :)

Perso j'avais commencé à regarder mais j'ai pas eu le courage de continué, mais si des gens ce lance je veux bien participé sur des tâches précises

Modifié le 20 février 2013 par Sp@r0

[guenneguez_t]

Salut

Perso, je suis tout à fait pour. Je suis déjà sur le coup.

Je suis l'un des développeur de l'application https://sourceforge.net/p/multicardipx800.

Je suis en train de regarder le projet https://code.google.com/p/openzwave-control-panel/

Il est pas mal bien qu'il n'y ai aucune documentation. J'ai un Z-Stick S2, un thermostat Danfoss et un module Fibaro.

Mon objetif serait de faire un tourner le openzwave-control-panel sur synology et que l'application multicardipx800 s'y connecte et face l'interface homme machine. Si quelqu'un arrive à m'expliquer comment cross compiler openzwave-control-panel sans toucher au source, je serait très intéressé.

A+
Thomas

[Diaoul]

Je vais regarder pour la cross-compilation, ça ne devrait pas être bien méchant.

[declencher]

OK avec toi sparo et c'est pour ça que synozwave était une bonne base. Coordonner un groupe sur un projet open source from scratch est vraiment compliqué.

Guenneguez_t je ne connnaissais pas ces projets. Je vais jeter un œil à tout ça.

Super Diaoul si tu peux faire ça car si j'ai bien compris ce premier projet est une sorte de moteur zwave proposant une api ?

Je pense que nos syno méritent une vrai solution domotique open source.

Perso j'imaginais une solution à base d'Openremote pour l'ihm et d'openzwave pour le moteur.

J'ai un rfxcom, des sondes Oregon, un dongle zwave et bientôt un récepteur voler roulant pour les tests.

Pour le rfxcom j'ai codé un prog en c qui enregistre les données. Et là je bosse sur l'IHM.

La difficulté en domotique est souvent de mettre les briques applicatives bout à bout...

[Sp@r0]

C justement l'intérêt de domogik c'est un framework qui gère l'ihm et qui utilise xpl comme standard de com ce qui permet avec un minimum de développement de l'interfacer avec n'importe quels système de décodage (XPLperl, OpenZwave, ...)

[guenneguez_t]

Bonjour,

Pour https://sourceforge....ulticardipx800., c'est écrit en php, avec de l'objet donc si une API existe, il devrait être asses simple d'implémenté n'importe quoi.

Pour https://code.google....-control-panel/, c'est un serveur web qui permet d'interragir avec les objets ZWave. Par contre il n'y a aucune doc. La seul doc c'est le code source. Donc je regarde. D'autre part, toutes les requêtes se font en POST. pas pratique. Mais au moins c'est open. Je l'ai compilé sur une VM Linux et j'arrive à piloter mon relai Fibaro.

A+
Thomas

[Diaoul]

OpenZwave c'est la merde à cross compiler, il faut hidraw.h et libudev.h qui ne sont pas présents sur les toolchains de Syno.

En plus la lib n'a pas de release, pas de version, juste une version de dev avec peu de documentation. Je ne pense pas que ce soit un bon point de départ.

[guenneguez_t]

Salut

J'avais un peu le même avis que toi, mais c'est le seul système open-source que j'ai trouvé sur le sujet. Si quelqu'un a une idée de solution alternative, je suis preneur.

A+
Thomas

PS : L'article dont parle @declencher est dispo là : http://www.touteladomotique.com/index.php?option=com_content&view=article&id=788

[Diaoul]

Il y a Z-Way en python mais ça date de 2008.

Je pense qu'il faut se rapprocher de Domogik pour savoir ou en est le travail la dessus. Le point d'entrée c'est la clé USB Aeon Labs ZStick V2 et la communication avec cette clé.

J'ai essayé de cross compiler openzwave, ça dépend de libudev donc j'ai cross compilé systemd sauf qu'il me demande une dépendance vers "POSIX caps library" j'ai essayé libpcap mais ça ne va pas à priori, peut être libcap mais je n'ai pas trouvé les sources. libcap2 dispo sur linuxfromscratch dépend de attr.

Ca semble être la voie à suivre d'après open-embedded.

Autre point, il faut hidraw.h, qui est dispo pour 88f6281 mais je ne l'ai pas vu dans certaines toolchains donc il est probable qu'il faille passer par la cross-compilation de kernel modules. Ca tombe bien, spksrc sait faire ça très bien.

A suivre

[guenneguez_t]

Salut

Perso j'ai acheté une clef Aeon Labs ZStick V2. J'ai aussi un module Fibaro et un thermostat Danfoss.

Ce WE, je démarrerai ma VM sur linux sur leque j'ai compilé openzwave-control-panel. Je le démarrerai et t'enverrai via MP l'URL d'accès pour que tu regardes ce que ça donne. Sinon j'ai un RS 812 pour tester.

A+
Thomas

[Diaoul]

Quel est l'intérêt de zwave par rapport à xPL ? Si j'ai bien compris la différence est le principe en noeuds permettant de faire de chacun des éléments un relai.

Le code de ozwave, un plugin Domogik basé sur open-zwave : http://tracker.domogik.org/projects/domogik/repository/revisions/5754/entry/src/domogik_packages/xpl/lib/ozwave.py

Je trouve que le plugin zwave est bien plus portable que ozwave car il communique directement avec la clé USB, sans passer par une lib (open-zwave) : http://tracker.domogik.org/projects/domogik/repository/revisions/5754/entry/src/domogik_packages/xpl/lib/zwave.py

Comme je le disais, il y a aussi ZWAY en python qui a plein de constantes de définies.

Ce qu'il manque a mon avis c'est :

• Soit une lib béton et des bons bindings Python à travailler avec openzwave
• Soit un module Python avec peu de dépendances comme le plugin Domogik zwave (dépend juste de serial en Python) ou ZWAY (il me semble) qui s'occuperait du très bas niveau (communication avec le stick USB) pour fournir une belle API

Sinon portabilité c'est chaud avec une lib bancale...

[Diaoul]

ZWAPI (ce qui fait tourner Z-WAY) est téléchargeable ici, j'ai eu du mal à trouver le lien.

C'est GPL

Ca ressemble plus à un PoC qu'a un vrai projet mais je pense que c'est un bonne base pour apprendre.

[declencher]

Salut,

Pas simple la cross compil visiblement :/

Perso je ne positionne pas zwave et xpl au même niveau. Zwave est un protocole de communication radio entre le serveur (le single fibaro par exemple) et des capteurs/actionneurs. Xpl est plutôt un protocole au niveau système...

Pourquoi favoriser le python ? Pour une appli robuste et légère y'a pas mieux qu'un langage compilé tel que le c... Enfin ce n'est que mon avis...

[Sp@r0]

Python et directement cross plateform rien a changer que le nas soit en arm/PowerPC/qoriq/x86 ou n'importe quoi d'autre ...

La gestion des dépendance et plus simple, et les performances sont proches d'un code compiler

[guenneguez_t]

Oui, mais tu es obligé d'avoir une bibliothèque pour zwave. Donc tu retombe sur openzwave...

Donc à ce moment là autant reprendre openzwave - control - panel et réussir à le compiler. Après il faudrait trouver un langage pour faire une belle interface...

Daoul merci pour le lien que j'ai pas réussi à trouver... Je regarde ce que ça donne ce week-end.

A+

Thomas

[declencher]

Le côté multiplateforme est pratique sur un matériel au multiple architecture comme nos syno.

Mais côté optimisation des performances et proximité avec le système y'a pas mieux.

Vous avez vu le site du mec qui a compilé synozwave sur un ds1010+ je crois ? Je vais essayé de retrouver le lien.

Je ne connaissais pas le dernier lien de diaoul. Je vais regarder aussi.

[guenneguez_t]

Salut

Voci le lien que tu cherchais :

http://www.livingroomfun.info/blog/20111020/openzwave-running-on-synology-ds1010/

Par contre ça necessite de modifier les sources donc notes bien ce que tu modifies.

A+
Thomas

[Diaoul]

@guenneguez_t : Il y a, en Python, la possibilité de construire un module bas niveau qui s'occupe de discuter avec la clé USB sans passer par open-zwave et juste en reposant sur le module serial de Python. Ce module est d'ores et déjà disponible sur nos Syno via le package Python de SynoCommunity.

C'est bas niveau donc il faut implémenter toutes les spécifications z-wave et refaire peu ou prou la même chose que open-zwave a fait.

Je vous invite vraiment à regarder ZWAPI, je serai partant pour bosser sur quelque chose dans ce goût là mais en plus "Pythonic".

Si j'ai bien compris, z-wave, le fonctionnement est event-driven avec pleins de callbacks pour plein de choses différentes. Il y a plusieurs frameworks en Python pour faire de la gestion événementielle dont l'incontournable Twisted (orienté réseau mais aussi port Serial, voir cet exemple avec la gestion des évènements de la souris).

Il suffit de faire l'équivalent du Protocol MouseMan : ZWaveMan

[guenneguez_t]

Salut

Ok, mais ça veut dire qu'il faut tout redévelopper en perl. Il y a du taf...

A+
Thomas

[declencher]

Redéfinir un protocole est un travail de fou surtout que pour chaque périphérique du marché il peut y avoir des spécificités.

C'est pour ça que les box domotique et openzwave on parfois du mal à suivre...

C'est pour ça qu'une des bases est de partir sur la cross compil de openzwave ou un équivalent comme c'est fait sur synozwave.

Qu'en pensez vous ?

[guenneguez_t]

Perso je suis d'accord, mais ça fait quelques temps que j'essaie de cross compiler openzwave et j'y arrive pas.

A+
Thomas

[Diaoul]

Je ne vois pas difficulté sachant que c'est déjà fait par open-zwave, il suffit de reprendre les fichiers de config.

[declencher]

Peux tu préciser diaoul ?

Je n'ai pas trouvé d'info sur les syno sur le wiki de openzwave.

[Diaoul]

Je parlais de la redéfinition du protocole. Il suffit de regarder le code source d'openzwave pour implémenter les spécificité de chaque device. D'ailleurs, c'est la première fois que je vois une librairie avec des fichiers de config. Pour moi une lib doit fournir une API, pas implémenter les spécificités de chaque device. Ca c'est le rôle de l'appli.

Pour la cross compilation j'a avancé, j'en suis à systemd qui merde parce qu'il lui manque un truc :

src/libudev/libudev-util.c:727: error: 'O_CLOEXEC' undeclared (first use in this function)