@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
1 « J'aime »
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 
1 « J'aime »
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 !
1 « J'aime »
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 =>
1 « J'aime »
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…^^
1 « J'aime »
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 !
Quelques news de la sortie de Gladys 4 RC !
Hello, petit appel aux devs :
Je tente de bosser sur le sujet de la traduction côté serveur, notamment parce que ayant repris un peu les essais et le tri sur la PR Netatmo, il y aurait de nombreuses features dont le nom nécessite une traduction. Je pensais faire une PR à côté pour ça.
Bon ça fonctionne bien mais :
1er point :
J’ai cette erreur sur l’eslint. Pour la 1ère ligne, je ne comprends pas car, j’ai installé i18n directement sous
/server. Je pensais qu’il serais propagé … Auriez-vous une idée (c’est la 1ère vrai fois que j’installe une dépendance …) ?Pour les lignes suivantes, je comprends que c’est juste ESLINT qui interdit ces caractères, peut-on lui assigner de nouvelles règles manuellement ? A-t-on le droit de le faire ? Et si oui pourriez-vous m’indiquer la voie ?
2ème point : Pour la langue de traduction, par défaut « EN », ensuite j’utilise la langue du 1er user créé au démarrage de Gladys. Pour le moment (je me doute qu’on ne fera pas comme ça à terme), j’utilise le user.update et user.updateBySelector pour mettre à jour la langue (au cas où) d’i18n. Les nouveaux devices créés le sont ensuite dans la nouvelle langue.
Pour relancer le débat donc, que pensez-vous de la méthodologie ? De comment en structure ?
Pour le moment j’ai fait :
Dossier config :
Fichier /server/api/index.js :
Fichiers user.updatexx :
Exemple d’utilisation :
Doc i18n : i18n - npm
@Terdious a mon avis pas besoin de librairie pour ça, un fichier JSON clé/valeur par langue comme on fait dans le front fonctionnera largement !
Faut pas se compliquer la vie, le plus simple le mieux 
D’ailleurs, dans le cas d’une intégration, je pense qu’il faut le faire dans l’intégration directement, pas dans le code du core.
Si tu as des noms d’appareils à traduire, tu te créé un dossier avec un fichier en.json et fr.json et ça fera le job
Tu require tes fichiers où tu as besoin, et hop !
Merci d’avoir répondu @pierre-gilles,
On est d’accord que ce n’est pas le nom de l’appareil à proprement parler qu’on veut traduire, en général ceux-ci sont déjà nommés dans l’api dont on récupère les appareils. Pour le 1er cas d’usage que je voyais il s’agit plutôt des features qui sont nommés par leur catégorie / type. Toute les intégrations nomment en DB les features en « [nom] - On/Off », « [nom] - humidity », « [nom] - Color temperature »,« [nom] - Power », … etc. Donc pour beaucoup de ces traductions ce sont les mêmes ? Quel est l’intérêt de dupliquer les fichiers pour chaque intégration ?
Justement j’ai repris le fonctionnement et la logique du front avec i18n… J’ai mis 10 min à le mettre en place ça ne me semblait pas du tout compliqué et surtout :
Le jour ou on rajoute une langue il faut donc repasser par tous les fichiers qui appel une traduction ? Ca ne m’embête pas mais on retire la facilité de dev cette fois.
Aucun, effectivement si c’est les mêmes traductions, on peut utiliser les fichiers du front dans le backend, ou vice-versa. Je ne savais pas exactement ton cas d’usage!
ah non non, l’idée c’est juste d’avoir un objet de traduction que tu require au besoin, et ensuite si t’ajoute une langue t’as rien à toucher.
Je parlais juste du fait d’ajouter des libs, c’est pas forcément utile dans le cas du backend, un simple objet JS fait le job, c’est du clé/valeur.
Après j’ai pas lu ta PR donc je ne sais pas l’étendu de ton développement
Oki top !! Encore mieux si on peut reutiliser ceux du front !! Tu confirmeras plus tard via la PR quand tu as le temps.
Ok mais du coup pour tester ton idée, j’ai testé le require par fichier de langue, mais du coup ca doit pas etre ça car dans mon test avec ma comprehension de tes propos j’appelle les 2 fichiers en faisant
const tradFr = require('../../../config/translate/fr.json')
const tradEn = require('../../../config/translate/en.json')
dans chaque fichier qui a besoin. Du coup en cas d’ajout de langue on aurait été obligé de repasser sur chaque fichier !! Du coup tu les fais où ton require dans ton idee ? (Reponds moi sur github quand tu auras eu le temps de la relire ^^ on en reparlera a ce moment ^^)
Tu fais un fichier i18n.js (nom d’exemple, ça peut être n’importe quoi), qui contient:
const fr = require('./fr.json');
const en = require('./en.json');
module.exports = {
en,
fr
};
Dans tous tes fichiers, tu fais:
const i18n = require('../../config/i18n/i18n.js');
Et quand tu as besoin d’une trad:
const myTitleExample = i18n[lang][key];
Ce n’est qu’un exemple sur un bout de post sur le forum, si on veut un truc plus complet on peut exporter une fonction dans i18n pour gérer les erreurs, etc…
1 « J'aime »
Merci beaucoup,
Je m’y emploi !!^^