declencher

Salut, Merci pour ton aide. Voici la trace : crw-r--r-- 1 root root 188, 0 Mar 27 18:37 ttyUSB0 crw-r--r-- 1 root root 188, 0 Mar 27 19:17 ttyUSB1 J'avais fait une erreur dans mon script lancé au démarrage (je ne l'avais jamais testé)...

Salut, Je viens de passer en DSM 4.2 et après le reboot, j'ai vu que mes programmes perso ne tournaient pas comme prévu. J'ai un module de téléinformation USB et un rfxtrx en USB. J'ai donc créé 2 "node" ttyUSB. Pourtant, quoi que je fasse, j'ai toujours, les 2 nodes sont alimentés par le module de téléinformation. Comment dire au système que le premier périphérique doit causer avec le ttyUSB0, et le deuxième avec ttyUSB1 ? Plus étrange encore : je débranche et je rebranche le rfxtrx et voilà ce que j'ai quand je fais un dmesg : [ 1331.050000] ftdi_sio 1-1.3:1.0: device disconnected [ 1334.590000] usb 1-1.3: new full speed USB device using orion-ehci and address 6 [ 1334.700000] usb 1-1.3: configuration #1 chosen from 1 choice [ 1334.720000] ftdi_sio 1-1.3:1.0: FTDI USB Serial Device converter detected [ 1334.750000] usb 1-1.3: Detected FT232RL [ 1334.750000] usb 1-1.3: Number of endpoints 2 [ 1334.760000] usb 1-1.3: Endpoint 1 MaxPacketSize 64 [ 1334.760000] usb 1-1.3: Endpoint 2 MaxPacketSize 64 [ 1334.770000] usb 1-1.3: Setting MaxPacketSize 64 [ 1334.810000] usb 1-1.3: FTDI USB Serial Device converter now attached to ttyUSB1 J'en déduis que mon rfxtrx est bien associé au node ttyUSB1. Et pourtant si je fais un cat sur ttyUSB1, ce sont les données du module de téléinformation que je vois, c'est à dire comme sur ttyUSB0 Quelqu'un aurais une idée pour m'aider ?

Salut, Je pensais simplement utiliser un dock USB. Personne n'en parle. C'est une si mauvaise idée ? C'est pour sauvegarder une partie de mon ds212...

Salut, Je ne doutais pas que tout était bien fait pour synocommunity, c'est toujours le cas. C'est plutôt pour les diffuseurs de spk qui ne partage pas les sources de projets GPL aujourd'hui, et qui seront tentés de vendre les packages, toujours sans partager les sources. Eux seront en infraction d'après ce que tu expliques... J'ai hâte de voir comment tout ça va se mettre en place...

Bonjour, Je me pose une question peut être bête... Des rumeurs circulent sur la mise en place d'un market permettant de monétiser les packages. Jusque là je me dis "pourquoi pas c'est la mode". Ensuite j'ai pensé aux licences. Par exemple tout soft disponible sous licence GPL peut être vendu mais ses sources doivent être partagées. Toutes modifications de ces sources doit être rendues publiques, et mieux, tout logiciel exploitant tout ou partie de ce code GPL est obligatoirement soumis à la licence GPL. Et donc le code doit être publié... Si on revient aux packages d'appli sous licence GPL, il faudrait que les sources du package soient publiées pour rester dans la légalité non ? Et si c'est le cas c'est invendable non ? J'attends vos commentaires et corrections éventuelles car je m'interroge pas mal sur le sujet...

À ma connaissance aucun package pour ça malheureusement... On m'avait aussi conseillé une recherche sur lftp que je n'ai jamais faite... pour l'instant je lance encore cobian depuis le pc.

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