Parlons de Gladys V4

Salut @pierre-gilles, au niveau de l’erreur ça a l’air d’être lié aux packages du zwave, j’ai ces erreurs ci :

2019-07-11T14:03:28+0200 <info> install_service_dependencies.js:17 (directories.forEach) Installing dependencies in folder C:\Users\user\Desktop\Gladys-master\server\services\zwave
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:197:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:254:12)
gyp ERR! System Windows_NT 10.0.17763
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd C:\Users\user\Desktop\Gladys-master\server\services\zwave\node_modules\openzwave-shared
gyp ERR! node -v v11.9.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
npm WARN [email protected] No description
npm WARN [email protected] No repository field.
npm WARN [email protected] No license field.
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

Ah yes ça peut être intéressant !

Vous avez essayé bash for windows ? ca installe un noyau linux en natif dans windows.
Je l’utilise depuis 2 ou 3 ans, et je n’ai jamais eu aucun problème d’install d’app avec.

Je n’ai pas installé le docker, mais la version de dev comme ca, et tout a bien marché du premier coup.

Source : https://docs.microsoft.com/en-us/windows/wsl/install-win10

1 Like

Euh pas exactement mais presque ! Ils vont bientôt sortir un vrai noyau natif linux 100% compatible windows (on pourra voir les périphériques par exemple).

Mais oui j’utilise ça moi au boulot c’est largement mieux que d’utiliser windows pour dev :slight_smile:

Perso j’utilise WSL pour dev le front de Gladys v4, pour la back, il manque encore les périphériques

Yes, ça devrait résoudre le problème d’@albenss

Bonjour à tous,
quelques nouvelles sur l’avancement du service Bluetooth pour Gladys v4 :

  • UI modifiée, ressemblant à la page ZWave
  • Scan manuel des périphériques Bluetooth
  • Ajout comme “nouveau device Gladys”
  • Prise en compte du Tracker Nut => récupération du niveau de batterie (poll toutes les 60 secondes)

@pierre-gilles j’essaie maintenant de m’attaquer à la gestion des ampoules, mais je ne trouve pas le moyen d’appeler la méthode “turnOn” de mon service.
Je me suis inspiré du service “example”, mais je reste bloqué.
As-tu quelques informations au sujet des actions ? Je vois dans le fichier scene.actions.js que la turnOn est appelée directement depuis le device… il manque peut-être une étape ??
Bref, je suis bloqué.

Edit:
il manque l’appel de init du LightManager, et lors de cet appel, les params du device ne sont pas remonté.
Je te ferai une PR ASAP.

Merci

Voici quelques screenshots :





8 Likes

Magnifique! Du super boulot! :slight_smile:

Alors pour l’histoire du turnOn, je t’avoue qu’on va peut être repasser à juste une seule fonction genre “setValue” côté service.

Cette partie n’a été fait nulle part sur d’autres services donc c’est tout nouveau, il faut tout concevoir!

1 Like

Merci :slight_smile:
Je vais regarder alors pour passer par “setValue”, mais je pense tout de même sortir ce dev dans une autre PR afin que tu puisses y voir plus clair.

En revanche, je commence à être limiter avec les icons de https://feathericons.com, par exemple pour color / contraste…
Il existe beaucoup de demande de création sur le repo git, mais je trouve que l’activité y est faible. Peut-être penser à changer de librairie ?

J’aimais bien feather icons pour sa légèreté justement!

Après quand on parle de lumière, est ce que l’icône n’est pas l’icône du lampe quel que soit l’action que l’on fait?

Pour les lampes, une pastille color picker pour la couleur et l’icone « sun » avec un slider pour l’intensité feront sûrement l’affaire.
Mais de manière générale, il n’y a pas d’icones spécial « home automation ». Je n’ai pas d’idée en tête, mais peut être que pour certains périphériques, ce sera limitant ? Chauffage, capteur de présence, prises …

@pierre-gilles je reviens ici pour que ça soit ouvert à plus de monde.

Tu compares à zwave:

Le problème que j’ai avec la façon de faire de zwave c’est que tu peux pas spécifier le nom de chaque variable (température, humidité, …). Du coup est-ce que l’on modifie juste le nom du capteur de manière général et ensuite on met par exemple Capteur 1 Température, Capteur 1 Humidité. (Où le nom du capteur est donc Capteur 1).

Qu’en penses tu / pensez vous ?

C’est pour que tous les modules soit sur la même longueur d’onde. Car effectivement si on laisse moins de possibilité à l’utilisateur de personnalisation du nom de chaque feature, alors on peut faire un truc plus sexy :slight_smile:

C’est vrai que c’est un vrai débat sur la philosophie du produit !

Prenons un exemple, Apple Homekit, qui décide des noms “Front door”, “Dining room light”, etc… ?

Je trouve que forcer l’utilisateur à nommer chaque deviceFeature un par un, c’est hyper lourd… Et est-ce que c’est utile? Je pense que non.

C’est à nous de designer une UI où il est facile de discerner quel capteur est quoi/et où.

Je serais intéressé de savoir plus d’exemples d’autres plateformes, pour comprendre quelles techniques d’UI ont été utilisées pour permettre à un utilisateur de comprendre son installation, même si celle-ci est très riche.

Je pense que c’est un problème à cause des utilisateurs de Gladys actuel … Des techniques … :smiley:

En tant que utilisateur standard je préfère pas m’embêter. Je peux partir sur le principe de faire comme zwave et permettre moins de modification. On peut se dire que l’utilisateur avancé ouvre la BDD et change la valeur directement à ses risques et périls.

Autre possibilité est tout simplement d’avoir un mode avancé (à mettre en place du côté des settings et ensuite de laisser apparaitre dans les modules d’autres options). C’est une possibilité qui peut être rajouté par la suite!

Je sais que cette idée est pas génial mais ça peut répondre à la problématique.

En tout cas pour Xioami je pars sur un truc plus simple et beau qui parle à tous. On verra plus tard ce sont des pistes de réfléxions.

Je ne pense pas! Je pense que les utilisateurs, technique ou non, veulent juste une UI claire qui fait le boulot.

Dans Gladys 3, la seule façon d’avoir une UI assez clair c’était de nommer chaque feature individuellement, c’était l’UI qui voulait ça.

Je veux revoir l’UI de Gladys 4 pour que ce ne soit pas nécessaire. Je pense d’ailleurs que le nom du deviceFeature peut être obsolète si on fait bien notre UI…

Ce que je voulais dire par là c’est qu’on aime bien contrôler les choses parfois de manière inutile mais au moins avoir cette possiblité.

Sinon je suis d’accord avec toi si on fait bien et qu’on dit c’est comme ça ils sont nommé automatiquement ça suffit.

De mon point de vue, device et device-feature ne doivent pas être traitées à égal:
Le nom du device, même si défini par défaut par le système doit être modifiable. Dans ton exemple, @pierre-gilles, garage door est sûrement défini par l’utilisateur. Dans un cas pratique où on aurait 2 portes de garage, le système pourrait les appeler garage-door-1 et garage-door-2 et l’utilisateur de les modifier en garage-front-door et garage-back-door parce que bon, c’est plus facile pour savoir kikoikece.
Pour les device-features je ne vois pas en quoi l’utilisateur devrait renommer quoi que ce soit. Ouvert/Fermé/Allumé/Éteint /%batterie/couleur… c’est intimement lié au type de device et aux fonctionnalités dont il dispose. Ces fonctionnalités sont hard codées et liées à des constantes dans le système.
Une feature = « une action » = une appellation / un état.

Si on prend l’exemple d’un capteur de température aka “temperature-sensor”.
Il peut implémenter différentes features (fonction de la marque du modèle…) ça n’en reste pas moins un capteur de température.
Maintenant en fonction de ces features, l’UI fera apparaître :

  • 24°C
  • 84% humidity (ou pas)
  • 1020 hPa (ou pas)

Hormis des réglages globaux d’environnement sur le système métrique (°C /F etc), je ne vois pas d’intérêt de personnaliser la sortie de ces features. C’est normalisé, y’a un nom, une icône, des boutons (et des actions liées).
Et pourtant, je suis un user qui aime personnaliser :smiley:

1 Like

Pour mieux comprendre:
image
Ici tu as écris Temperature qui est le nom de la feature lié au device.

Du coup toi tu voudrais qu’il y ait le nom du device et à chaque fois à droite les valeurs de chaque feature ?

Vu comme ça c’est chouette, effectivement. Mais du coup c’est une vue de features, pas de devices.
Tu pourrais avoir les deux mesures Temp et Humidité sur la même ligne aussi, non ? :thinking:
Si j’prends l’exemple d’une lampe, ça a moins de sens de faire 1 ligne pour on/off, une autre pour color, et une autre dimmer.
D’ou mon ressenti qu’une ligne par device c’est « mieux ».
Et d’un côté pur tech, tu passes ton device ds une func displayDevice qui est capable de générer la ligne en question en se basant sur les différentes features du dit device.

Oui je vois en gros avoir:

Capteur Chambre:
    Temperature 10°C
    Humidity 50%

Où humidity, temperature sont juste des variables qui ne sont pas en lien avec la base de données juste le fait que la feature affiche la temperature

Du coup refaire un petit peu la vue dashboard / device pour avoir une vrai vue en fonction des devices et non des features.

J’ai pensé à cette vue qui du coup peut alier les deux pas forcément faire sur une ligne (ca peut être dégueulasse) mais avoir la distinction des devices.

J’comprends pas exactement ce que tu veux dire… Si tu parles des « labels » effectivement, ce ne serait pas en base. Plutôt dans le fichier de trad à un index correspondant au device-feature.

En ce qui concerne 1 ou pls lignes, il faut en discuter, faire des essais. Peut-être que c’est mieux pour un device, et moins adapté pour un autre. Mais le regroupement par device me semble inévitable pour s’y retrouver.
Peut-être une règle du genre « 1 ligne par sensor, mais toutes les actions sur la même ligne ».
Bref… à challenger comme disent les consultants de mon ancienne boîte :stuck_out_tongue: