Expert Zwave carrement, j’ai juste beaucoup de module 
Je te rejoins pour les points que tu as mentionné. Côté fonctionnalité, il faut aussi pouvoir récupérer les “command class central” et les exploiter dans les scènes.
Pour la partie “amélioration de l’onglet Network”, tu penses à l’affichage d’une matrice plus lisible et du nombre de message en attente de traitement par la clef ?
c’est quoi ça? ^^
Yes !
Une association directe se limite à faire travailler deux équipements zwave ensemble, par exemple : L’oeil fibaro détecte un mouvement et indique à ma prise connecté de s’allumer.
La command class central scene est bien plus puissante car elle notifie le stick zwave d’un événement avec un couple sceneId/Value !
Tu peux donc le récupérer et déclencher des scènes Gladys pour controler n’importe quel type d’équipement.
Par exemple,
Tu vois la logique et l’intérêt de cette fonction ?
Salut, je m’intéresse un peu plus au Gateway pour les futurs développements que j’envisage et j’ai dû rater un truc donc je viens vous demander un peu d’aide.
Au niveau de l’API disponible depuis la Gateway, est ce une réplique de l’API Gladys local mais disponible partout (avec quelques routes supplémentaires liées au gateway) ? Je m’explique, si on développe un service contenant un controller, est il possible d’accéder à la route aussi bien depuis l’intérieur que de l’extérieur du réseau (au travers du Gateway) ? Imaginons un service qui peut recevoir des informations de Tasker ou d’une autre application d’un appareil de l’utilisateur. Il y a ceux qui auront juste besoins de communiquer avec Gladys quand ils sont chez eux et ceux qui auront besoins de communiquer avec Gladys peu importe où ils sont (avec le Gateway). Faudra il développer le service Gladys de base et un “service” côté Gateway ? ou le service de base suffira ?
Pour moi c’était oui, j’avais en tête que c’était une simple passerelle qui permettait d’accéder à tout Gladys à l’extérieur comme si nous étions sur le réseau du raspberry. Je pose cette question parceque le code d’Owntrack est côté Gateway. Merci pour votre aide.
Merci pour l’explication ! Je vois l’intérêt 
Il y a deux parties dans le Gladys Gateway:
L’API Websockets
L’API websocket, chiffrée de bout en bout, est un passe-plat entre ton client web (plus.gladysassistant.com), et ton instance locale.
Toute route disponible dans Gladys, est disponible dans l’API websocket, car le Gateway ne fait que transmettre les requêtes de l’un à l’autre, et le Gateway n’a aucune conscience des routes appelés ou ce qui transite, les messages sont entièrement chiffré de ton browser à ton client.
L’Open API REST pour Owntracks
Afin qu’on puisse utiliser Owntracks très simplement, j’ai développé une route Owntracks qui transfère le body JSON envoyé à l’instance Gladys de l’utilisateur.
Comme nous ne maitrisons pas le code des applications clientes d’Owntracks, cette route n’est pas chiffrée de bout en bout, elle est chiffrée en transite bien entendu via HTTPS, mais uniquement entre le mobile et le gateway, puis chiffrée entre le Gateway et l’instance Gladys. C’est dommage, mais on ne maitrise pas le code d’Owntracks.
J’ai eu des demandes comme toi pour avoir la possibilité d’avoir plus, voir toutes les routes de Gladys disponible en Open API sur le Gateway: c’est une vrai réflexion et un vrai débat.
Développer des routes qui seraient aussi facile à appeler qu’une API classique, sans chiffrement de bout en bout, je trouve ça dommage… Cela voudrait dire qu’en tant que mainteneur du Gladys Gateway, j’aurais un full access aux instances de mes utilisateurs… est-ce que c’est ce qu’on veut? Je ne pense pas !
Mon avis perso
Il faudrait trouver un moyen de faire fonctionner le chiffrement de bout en bout via Tasker! J’ai vu que Tasker permet d’exécuter du code JS, ainsi on pourrait très bien invoquer le même code de chiffrement que dans le client JS Gladys Plus, c’est pas très compliqué !
Désolé pour le pavé, mais il fallait une explication à ce fonctionnement hybride, et je voulais être précis dans ma réponse
Qu’en pense-tu?
Merci pour ces détails c’est exactement ça que je cherchais à comprendre.
C’est exactement ce que j’allais dire, tout ce qui viens vers cette Open API n’est pas chiffré.
C’est sûr dès que c’est possible il faut chiffrer, mais ça ne sera pas possible dans tous les cas. Tu as surement raison pour Tasker c’est à étudier, mais je ne le prenais que comme exemple. Il y aura d’autres applications/services dans lesquels ce ne sera pas possible, Totof citait PhoneTrack ici: Utiliser Owntracks avec Gladys 4! - #24 par Totof, les données sont transmises dans une requête HTTP, on ne pourra pas chiffrer depuis l’application. Dans ta présentation du Gateway tu parlais de connexion avec des services exterieurs (Google Assistant, Alexa, IFTTT…) je ne sais pas exactement comment ils fonctionnent mais s’ils ont besoins d’un webhook vers Gladys ça sera le Gateway et une nouvelle fois on ne pourra malheureusement rien y faire. Je comprends tout à fait l’objectif de chiffrer de bout en bout, personnellement je suis totalement pour, et Gladys a entre autre comme points essentiels la sécurité et le respect de la vie privée. Malheureusement dans certains cas il va peut être falloir de la confiance (comme pour OwnTrack), quitte à bien avertir l’utilisateur dans la documentation. On fait notre maximum pour le chiffrement et on est transparent pour le reste.
Pour ce qui est de la liste des routes de l’Open API, je ne sais pas si cela vaut le coup de mettre toutes les routes de Gladys. Je n’ai pas encore beaucoup de scénarios en tête, mais limiter l’Open API à quelques routes qui en ont réellement besoins nous pousserait à vraiment limiter cette exposition des données à la Gateway et nous forcerai à toujours chercher la solution la plus sécurisée.
Comme tu dis la réflexion reste complètement ouverte je vais continuer d’étudier cela ces prochains jours.
Effectivement, il y a des cas où le chiffrement de bout en bout n’est pas possible et n’a pas de sens (Google Assistant, Alexa, IFTTT, etc…) et dans ce cas là je suis 100% d’accord que ça vaut de coup d’ouvrir une route d’Open API du Gateway pour permettre une connexion facile de l’extérieur
Tu avais un besoin précis pour demander ça? Je pense il faut réfléchir au cas par cas!
Comme je le disais dans le premier message, c’était pour le moment à titre informatif. Je cherchais à comprendre le fonctionnement de la Gateway pour bien concevoir les futurs services que je vais développer.
À terme je souhaite créer un service PhoneTrack car j’utilise déjà l’application depuis quelques mois avec une instance Nextcloud et elle me convient. Pour commencer il va surement falloir réfléchir à comment gérer les clés API côté Gladys. J’ai l’impression qu’elles existent sur la Gateway mais pas sur l’instance Gladys. Personnellement je l’utiliserai au travers de la Gateway mais je souhaite que le service soit disponible sur Gladys directement pour plusieurs raisons (ceux qui hébergent publiquement leur instance Gladys, ceux qui souhaitent juste sauvegarder leurs positions de la journée le soir en rentrant…).
Ok, je comprends !
Effectivement, j’avais codé les clés d’API dans le Gateway dès la v3, en revanche l’Open API avec des token longue durée n’a pas encore été codée dans Gladys 4. C’est un développement qui est listé sur Github, personne ne s’est encore lancé dessus !
Tout à fait, je pense autant faire un truc générique qui tourne avec les deux
Parfait je n’avais pas fait attention, je vais surement le prendre alors.
@bertrandda Top ! Avant de commencer le développement, peux-tu écrire les specs techniques sur l’issue GitHub afin qu’on soit d’accord de l’implémentation avant ? 
Je détaillerai tout ça oui
La détection de présence et le multiutilisateur ne sont pas encore implémentés.
S’il y’ a une solution ça m’intéresse aussi 
Effectivement c’est une bonne remarque, il faudrait faire une fonctionnalité qui permette d’envoyer un message « max 1 fois par heure » par exemple, ou « max 1 fois par jour », ça permettrait de faire un système d’alerte qui ne spamme pas trop.
A réfléchir, merci du retour en tout cas !
Hello,
J’avais exactement le même besoin, je voulais me mettre une alerte dès que la température d’une pièce dépasse un seuil, mais je me retrouve avec des messages dès que la température change et est au dessus du seuil, pas terrible
Sinon, je me demandais, est-ce que ce serait possible de récupérer une variable d’une action pour la transmettre dans l’action suivante par message ?
Enfin j’ai remarqué un truc côté dashboard, si on active l’édition et que l’on change de page, lors du retour sur le dashboard, l’édition est toujours active. Je ne sais pas si c’est un comportement voulu, je trouvais ça bizarre !
J’ai créé une issue =>
Mmm effectivement, il faut changer ça, bien vu !
J’ai créé l’issue =>
C’est prévu
C’est prévu de pouvoir créer autant de dashboard que l’utilisateur veut =>
Avez vous vue cet article??
Salut à tous,
En allant faire un tour sur le Github de Gladys, j’ai vu qu’il y a pas mal d’issues et features en attente…alors j’ai envie de me lancer.
Je poste ici car ce topic est pas mal suivi, mais je peux le déplacer si jamais.
Je suis au rudiments de Javascript. Je fais du HTML/PHP/SQL, mais je ne suis pas dév de métier…(je rédige de la doc aéronautique, de base ^^)
Alors voici de quoi j’aurais besoin :
Si vous avez de bons cours JS bien structurés, je suis preneur !
J’en ai déjà, mais ça fait pas de mal
Des ressources sur PreactJS, que je ne connais pas
Les bases de GitHub : comment qu’on fait une PR ? C’est quoi codecov et les tests à faire que je vois un peu partout ?
Une fois que j’aurai bûché tout ça, si une bonne âme est assez motivée pour me guider via Skype ou autre pour faire un setup bien propre de l’environnement de dev, ça serait purement génial.
(Il me semble qu’il y avait un lien ici vers un tuto, mais je ne remets pas la main dessus…)
Voilà, merci à tous ceux qui voudront bien donner un peu de leur temps au newbie motivé que je suis !
Il faut bien commencer quelque part…^^
Salut @Biscotte ! C’est cool de vouloir donner un coup de main
Je n’ai pas de cours spécifique à te donner, d’expérience, la meilleure façon d’apprendre c’est de pratiquer Pour Preact, tu peux faire un tutoriel sur React (c’est quasiment la même chose). Je te conseille après de te lancer sur un petit projet pour tester tout ça (peut-être quelque chose de plus simple que Gladys)
Github a pas mal de tutoriels sur leur site pour cette partie.
Codecov sert à mesurer la couverture de code de nos tests automatisés. L’objectif est de vérifier que tout le code que nous écrivons est correctement testé, cela évite les régressions et rend le logiciel plus stable sur le long terme
Salut @pierre-gilles,
Bon retour ! J’espère que les vacances ont été bonnes !
Je suis dedans…il va me falloir quelques mois pour être opé, mais je lâche pas l’affaire !