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)

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

Oui, en ouvrant juste deux ports tu peux tout gérer. Il y a une documentation intégrée à DSM, si tu as des questions, il y a un topic sur HAProxy.

@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

Il n'y a pas d'association http, que https.

Pour information (je fais un peu de pub) HAProxy permet de faire tout ça sans toucher à la conf du Syno et avec une interface agréable. Installer le SPK Rediriger le port vers 5080 Rediriger le port 443 vers 5443 Voilà, https://dsm.tondomaine.tld et tu as DSM. Cf tous les autres backends via l'interface pour connaitres les autres points d'entrée par défaut (sabnzbd, nzbget, sickbeard, couchpotatoserver, etc.) Quand PhotoStation pourra tourner sur un port alternatif, il suffira de rajouter ça via l'interface et hop, fini.

Comme j'ai pu l'expliquer dans ce fil, écrire des zeros c'est bien mais ce n'est pas toujours suffisant. Tu peux regarder les valeurs SMART pour voir si tu as des secteurs défectueux qui se sont révélés.

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.

Je pense que l'on peut résumer tout ces posts sur le reverse proxy et PhotoStation simplement par le fait que PhotoStation c'est la merde pour ça. Il n'y a qu'a voir comment est géré la création du fichier de conf apache par le SPK PhotoStation pour s'en rendre compte... Si seulement on avait la possibilité de faire tourner PhotoStation sur son port dédié directement depuis le SPK ce serait beaucoup plus simple.

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

https://github.com/SynoCommunity/spksrc/blob/develop/cross/python/Makefile#L21 Il y a le support de l'ipv6 dans Python de SynoCommunity.

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

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.

Je lance la compilation ce soir. Envoi moi ton email par MP que je t'envoie le SPK.

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

Quelqu'un a essayé Domogik ? J'essayerai bien de bidouiller un peu mais je n'au aucun module de domotique chez moi

C'est quoi ton architecture ? Je vais te donner une version de test.

C'est le groupe UNIX par défaut des utilisateurs ce qui est nécessaire de part la nature de l'OS (UNIX). C'est aussi la solution la plus simple de gérer les permissions par défaut au niveau groupe en UNIX et permet l'utilisation du NFS sans trop de problèmes.

J'ai eu l'occasion de réinstaller DSM sur mon DS412+ flambant neuf et je vais éclaircir quelques points : Le groupe users n'est plus supprimable, c'était un bug d'une ancienne version de DSM Le groupe users n'a par défaut auncun droit sur les dossiers partagés, il n'y a donc aucune action à mener sur ce groupe L'utilisateur guest est désactivé par défaut, il n'y a donc aucune action à faire non plus Les paramètres par défaut sont donc sécurisés. Si l'on change la configuration par défaut, c'est que l'on sait ce que l'on fait. En l'occurence, ce qu'a fait par erreur viba74 est de donner No access au groupe users sur ses dossiers partagés. Comme indiqué dans la fenêtre DSM de gestion des privilègres : Privileges Priority : NA > RO > RW Si un utilisateur a des privilèges RW sur un dossier partagé mais qu'il est dans un groupe qui lui a NA sur ce même dossier, le droit résultant sera NA. Tous les utilisateurs étant dans le groupe users, donner NA au groupe users revient à priver tout utilisateur d'accès à tous les dossiers partagés. @didierrp, la consigne que tu préconises est la configuration par défaut. La configuration par l'utilisateur est de sa responsabilité, la documentation officielle de DSM est amplement suffisante pour apréhender au mieux les fonctionnalités de son NAS. Il est vrai qu'il faut souvent le rappeler car de nos jours, personne ne lit plus les documentations. En un acronyme, RTFM.

Rendre le fichier exécutable ? Le renommer en .cgi ?

OK Installable OK Je te conseille de te faire un virtualenv python dans un répertoire de ton choix : /usr/local/python/bin/virtualenv --system-site-packages /volume1/scripts/python A partir de là tu as un environnement python isolé dans lequel tu pourras installer les modules que tu veux et que tu pourras supprimer sans impact sur le SPK Python de SynoCommunity. Pour installer requests dans cet environnement : /volume1/scripts/python/bin/pip install requests Puis pour lancer ton script : /volume1/scripts/python/bin/python mega.py Voilà.

Je ne sais pas ce que dit la législation. Je ne vends pas le logiciel mais le packaging. Des idées ? Les donations fonctionnent le problème est que ça ne touche pas tous les utilisateurs alors qu'un SPK payant oui.

La question du payement est peut être résolue mais le problème de la tarification reste entier. Faire payer appli par appli ? Ceci obligerait à ne plus rendre les sources accessibles Faire un abonnement SynoCommunity donnant accès aux packages ? Des petits malins pourraient s'amuser à tout recompiler depuis spksrc et les proposer gratuitement Le modèle open source + payant est délicat...

Ca sert à quoi de changer un Syno qui marche ? Moi aussi je croyais que ça venait de mon Syno, si tout ceux qui ont des problèmes avec les WD Red faisaient des échanges, Synology serait en faillite.

Non, c'est uniquement depuis que tu es en beta. libsynoha.so est une lib rajoutée par Syno depuis DSM 4.2 beta en vu du portage de leur package de haute disponibilité sur d'autres architectures que les modèles pro RS. https://github.com/SynoCommunity/spksrc/issues/373