declencher

J'ai un ds212. Je pourrai peut être tester.

J'en déduis que tu as stoppé tes recherches sur openzwave ? En tout cas il ne faut pas mélanger openzwave et domoticz. Et je ne pense pas qu'on puisse dire qu'il y en a un plus standard que l'autre. Ce sont juste 2 projets totalement différents. Le premier propose une API open-source assurant la compatibilité avec le protocole zwave et ses nombreuses implémentations au niveau se différent capteurs et actionneurs. Le second est un projet complet proposant IHM et gestion du rfxcom pour l'instant. Peu importe l'API et l'IHM : je pense que l'idéal dans un système domotique est de coupler rfxcom pour les capteurs non critiques et zwave pour le reste...

Je pourrai tester aussi, en espérant que ce soit compatible avec ma solution perso. Je préfèrerai une cross compil de openzwave, j'aurai bientôt le matosse pour tester

Peu de retour. Certains arrivent ࠬ'installer et d'autres non... En tout cas pour lire le signal de sondes m鴩o j'ai 飲it un programme moi mꭥ. Il me reste les courbes ࠦaire au sein d'une page web.

Peux tu préciser diaoul ? Je n'ai pas trouvé d'info sur les syno sur le wiki de openzwave.

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 ?

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.

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

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

Salut, A tout ceux qui passerait sur ce poste, j'ai lancé comme ça une petite idée de projet open source :

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 ?

Salut, Je confirme que uptobox n'a pas de cpatcha quand j'utilise le soft mipony. Seulement un temps d'attente avant le début du téléchargement.

Je voulais dire que j'allais garder la solution exploitant screen comme le disait sp@ro

Mon script lancé au démarrage est déjà à cet emplacement. Je vais retenir la solution screen pour l'instant car c'est déjà comme ça que je lance mon prog. Je vais faire quelques recherches côté service pour voir comment ça se code. Est ce que les appli du syno sont déclarées ainsi comme le serveur multimédia par exemple ?

Bonjour, C'est surement une question de noob mais savez vous quelle est la solution la plus propre pour lancer un programme au démarrage du NAS ? Je viens de finir un programme en C qui tourne H24, et pour l'instant le programme est très "verbeux" et je l'ai lancé avec screen. Mais par la suite, si je fais un programme "propre" qui n'écrit dans sa log qu'en cas d'erreur applicative, quel est la meilleur façon de le lancer au boot du syno ? J'ai déjà un shell qui s'exécute au démarrage pour la téléinformation, mais là ça ne doit pas être pareil car mon, programme ne s'interrompant jamais, il ne doit pas empêcher la fin de l'exécution du shell... Merci d'avance aux pro d'unix

Salut, Peut être que ta liste d'hébergeur n'est pas à jour. Sinon pour free regarde là :

Mon programme en C fonctionne. Tout n'est pas enclore clair mais voilà ce que j'ai constaté si ça peut en aider d'autres : - Après installation du module pyserial en root et exécution du script de PatrickH, j'ai pu observer une trame - Ensuite j'ai voulu lancer le script avec le user admin : échec. J'ai donc fait un chmod 777 sur mon ttyUSB1, et ensuite le script a fonctionné. - J'ai ensuite lancé mon programme en C, sans l'avoir modifié, et il fonctionne. Ce qui me reste à éclaircir, c'est si mon programme aurait fonctionner sans avoir lancer le script de PatrickH auparavant, car ce script configure le taux de transfert du device. Il faudrait que je reboot le NAS et que je lance mon programme pour vérifier ça. En tout cas ça fonctionne maintenant. Prochaine étape, compléter le programme pour que les données reçues soient enregistrées dans la BDD. Merci PatrickH d'avoir donner un peu de ton temps !

Après install du module "serial", ton programme de test se lance et j'ai une trame : ['0D', '01', '00', '01', '02', '53', '37', '00', '0E', '6F', '01', '01', '00', '00'] Et quand je fais stty -a < /dev/ttyUSB1 j'obtiens quelque chose qui se rapproche de ta log : speed 38400 baud; rows 24; columns ; intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 0; time = 0; -parenb -parodd cs8 hupcl -cstopb cread clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany -imaxbel -opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 -isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt -echoctl -echoke Et maintenant j'ai bien le bon taux de transfert. Par contre je n'ai pas de résultat en faisant un cat sur /dev/ttyUSB1. C'est peut être normal ?? Maintenant il faut que je trouve pourquoi mon programme en C ne fonctionne pas...

Salut, Penses tu que je puisse utiliser ta méthode tout en utilisant le pakage de synocommunity ? Je ne voudrai pas tout casser... J'ai commencé à chercher comment ajouter ce module à Python 2.7 et pour l'instant je ne trouve rien. Edit : pour ceux qui chercherait, voilà ce que je viens de trouver et que je dois tester pour intaller ce module : http://pyserial.sourceforge.net/pyserial.html#installation

Patrick, J'ai tenté d'utiliser ton programme de test, mais je dois encore travailler sur ma config car j'obtiens un message d'erreur lié à python Traceback (most recent call last): File "./test.py", line 6, in <module> import serial ImportError: No module named serial Quand tu constates le taux de transfert que tu indiques dans ton message, c'est avant ou après avoir lancé un de tes scripts python ? Parce que j'ai vu que dans tes scripts tu commencé justement par configurer ce taux de transfert, ce que ne fait pas mon programme en C. Edit : j'utilise python 2.7 de synocommunity. Il ne contient peut être pas ce module ?

Je ne peux pas installer pl2303.ko car je ne l'ai pas sous la main. Quelqu'un a ça pour le DS212 ? Au pire ce week-end je réinstallerai VMWare et je restaurerai ma vielle VM qui m'avait servi pour la compil du driver ftdi. Sous Windows RAS, le rfxtrx fonctionne bien et je vois mes trames.

Ça c'est juste pour accéder au Nas de façon sécurisé. Mais ça ne permet pas de surfer sur le net ?

J'en d餵is que le temps d'attente n'est pas g鲡ble via le host ? Pour le captcha je vais v鲩fier. Je dois confondre avec un autre.

Non mais tu fais bien de m'y faire penser. Je testerai ça.

Ça devrait aussi se faire au niveau système également non ? Car le système devrait voir les trames passer même sans programme ? La commande stty ne sert pas à ça ? Je vais tenter une mise à jour du rfxcom sur un PC avec windows, et un test. Déjà je serais sûr qu'il fonctionne. Pour l'instant mon programme dit qu'il n'arrive pas à utiliser le port série...