Parlons de Gladys V4

Développement
181

Et hop le filtering qui fonctionne sur la page intégrations, ça en jette!

https://twitter.com/pierregillesl/status/1098166550345830406?s=20

Je pense oui, histoire que chacun n’ait pas à tout redévelopper :slight_smile: Après pour les cas très particulier le développeur devra coder lui même sa fonction de transformation dans un sens/dans l’autre.

Du coup tu verrais quoi comme format de couleur toi? Je pense il faudrait un format entier comme ça on peut le stocker et le colorpicker fonctionne, t’en pense quoi?

183

Je suis d’accord!

J’ai trouvé ça => https://www.npmjs.com/package/color-convert

On va forcément s’en servir mais bon c’est déjà des super exemples

184

Mes 2 centimes, un pourcentage est plus simple pour l’utilisateur final. Derrière comment ça se passe c’est une autre histoire :metal:

186

C’est une expression “my 2 cents” vulgairement traduite :grinning_face_with_smiling_eyes:, juste pour signifier ma toute petite contribution à la discussion

1 « J'aime »
188

Bonjour,

Cela serait peut être bien de prévoir nativement Gladys v4 avec un front-end et un back-end

  • le front-end donne accès au box ( boutons, infos,…)
  • le back-end accès aux paramétrages (ajout périphérique…)

avec aussi la possibilité de thème coté front-end
ainsi suivant l’endroit, le terminal on accède au front-end sur le thème désiré (avec un paramètre défini coté back-end [ user → terminal → template])

:notebook_with_decorative_cover: front-end
|------- :notebook_with_decorative_cover: theme1
|------- :notebook_with_decorative_cover: theme2
|------- …
:notebook_with_decorative_cover: back-end

189

C’est effectivement le cas dans Gladys 4, le front est une PWA avec preact et le back un serveur Express :slight_smile:

Pour le thème, Gladys 4 va offrir la possibilité de créer des dashboard personnalisé (et pas qu’un seul dashboard, plusieurs!), donc ça devrait répondre au besoin.

Pour avoir différentes UI, pour l’instant on va se concentrer sur créer une seule UI, c’est déjà assez complexe comme ça :slight_smile:

1 « J'aime »
190

:ok_hand::+1: Top merci

191

Les milight gèrent de 2700k à 6500k et les hue de 2000k à 6500k.

192

Salut,

Je partage avec vous une réflexion que j’ai eu en voyant le “Light device State”. Ne devrait-on pas représenter le changement de la température de la couleur ? Après c’est vrai que toutes les ampoules ne le gèrent pas, mais tout comme le HSB en fait. Du coup est-ce que le schéma ne devrait pas représenter que les états ON/OFF?

193

Ce schéma était un exemple non-exhaustif :slight_smile: Pour les ampoules, il faut qu’on choisisse effectivement le format qu’on va gérer, pour l’instant on est plus parti sur l’approche philips hue, après je pense qu’on va voir lors de l’implémentation avec les différents fabricants si ça se plug bien ou pas, et comment on résout les différentes incompatibilités.

194

j’adore, c’est très épuré. super boulot @pierre-gilles

195

Salut à tous!

Aujourd’hui j’ai travaillé sur tout le moteur de scénario, avec deux objectifs:

  • Concevoir un moteur riche avec toutes les fonctions dont on a besoin (Trigger + conditions multiples avec des ET/OU + actions)
  • Concevoir un moteur très performant et économe en ressource

Ce soir je viens de finir une première version minimale du moteur, et… ça dépote!!

1/ J’ai défini les différents évènements, états, et conditions dans un fichier de constantes. Ce n’est pas une liste exhaustive, mais cette première liste m’a permis de commencer :slight_smile: Je l’étofferais au fur et à mesure des développements (il faut pour cela écrire les schémas UML d’états, je fais ça proprement).

2/ Tous les états sont stocké dans un store en mémoire pour des performances en lectures maximales. Les états sont persistés sur disque mais cette persistence n’est utile que pour la visualisation (courbes), pas l’interrogation en temps réel dans un scénario.

J’ai donc fais une petite simulation de performance avec mon premier moteur.

J’ai créé un cas d’usage typique voir un peu extrême:

  • Un utilisateur avec 300 scénarios (généré aléatoirement, avec des triggers au hasard)
  • 5 conditions par trigger
  • 1000 états à surveiller
  • Pas de travail asynchrone. L’objectif du benchmark n’est pas de tester la performance d’une tierce-partie, mais juste du moteur en lui même, donc on évalue ici juste la performance de l’évaluation des conditions, en gros: combien le moteur peut manger par seconde!

La vidéo parle d’elle même =>

https://twitter.com/pierregillesl/status/1100344419742404608?s=20

On est sur du 1.35 millions d’évènements par secondes héhé :rocket:

Merci! :slight_smile:

3 « J'aime »
197

Biensûr! C’était dans le manifeste je crois :slight_smile:

1 « J'aime »
198

@piznel:

J’ai ajouté le delay au actions, c’était une action facile :wink:

Tu peux faire dans des actions:

[{
  "type": "delay",
  "seconds": 10,
  "then": [{
    type: "light.turn-on",
    deviceFeature: "piznel-lamp"
  }]
}]

Cette séquence d’action va attendre 10 secondes, puis allumer la lampe qui a pour selector “piznel-lamp”! :slight_smile:

Note: Tu peux utiliser “milliseconds”, “seconds”, “minutes”, ou “hours” !

3 « J'aime »
199

D’ailleurs pour les scènes je pensais à ça en terme de design, vous en pensez quoi ? :slight_smile:

C’est un premier jet, que du design rien n’est câblé! :stuck_out_tongue:

30
302024×1094 98 KB

3 « J'aime »
200

Serait-il possible de gérer plusieurs états, car le soleil n’est pas une lampe (ON/OFF)?

A l’image de ce qui se fait dans la librairie suncalc, il y a plusieurs états :

Property Description
sunrise sunrise (top edge of the sun appears on the horizon)
sunriseEnd sunrise ends (bottom edge of the sun touches the horizon)
goldenHourEnd morning golden hour (soft light, best time for photography) ends
solarNoon solar noon (sun is in the highest position)
goldenHour evening golden hour starts
sunsetStart sunset starts (bottom edge of the sun touches the horizon)
sunset sunset (sun disappears below the horizon, evening civil twilight starts)
dusk dusk (evening nautical twilight starts)
nauticalDusk nautical dusk (evening astronomical twilight starts)
night night starts (dark enough for astronomical observations)
nadir nadir (darkest moment of the night, sun is in the lowest position)
nightEnd night ends (morning astronomical twilight starts)
nauticalDawn nautical dawn (morning nautical twilight starts)
dawn dawn (morning nautical twilight ends, morning civil twilight starts)
1 « J'aime »
201

je suis pas sur que ça soir utile, pour capter le lever du soleil c’est le changement d’état (night => day) et inversement pour le coucher.
Après personnellement je ne vois pas à quoi peuvent servir toutes les autres propriétés, en sachant que tu peux le déduire avec l’heure en plus de l’état

202

Clair et épuré ! très bien !

Au niveau des scénarios, j’ai une petit suggestion. Est-ce qu’il serait possible d’avoir un paramétrage qui permet de les activer et désactiver ?

Un cas pour illustré l’intérêt :
J’ai un détecteur de présence. Quand il détecte un mouvement il lance un scénario qui allume la lumière extérieure pour une durée de 15 seconde puis il l’éteins.
Je peux aussi allumer et éteindre la lumière manuellement si je le souhaite, avec un interrupteur.

Si j’allume manuellement la lumière, car je sais que j’en ai pour un moment. (Par exemple je fais des aller/retour pour décharger les courses de ma voiture). Quand mon détecteur va me voir, le scénario va se déclencher et donc éteindre la lumière 15 secondes plus tard alors que ce n’est pas forcement ce que je veux.
Du coup il y aurait un intérêt à ce que le scénario passe en “désactivé” quand j’allume manuellement la lumière.

Cet exemple n’est peut-être pas le plus logique et peut-être solutionné de bien d’autre manière, je le sais. Mais je pense qu’il y a d’autre cas où ça peut servir :smiley:

203

Pourquoi pas, mais ce sera à mon avis un état supplémentaire, vu que pour la plupart des cas d’usage la vrai question dans les scénarios c’est « est-ce que c’est la nuit ou le jour » donc il ne faudrait pas perdre cette information non plus! :slight_smile:

Je vois l’idée!

Je pense que dans ton cas, la solution c’est de mettre une condition au scénario « ET que la lumière n’est pas déjà allumée », c’est pas logique d’annuler un scénario pour ça!

Je vais réfléchir pour la possibilité d’annuler un scénario dans les actions, je ne suis pas sur que ce soit ce qu’on veuille, j’ai peur que ça introduise des comportements illogiques qui sont juste solvable par des simple conditions :slight_smile: ( parce que bon annuler/rétablir un scénario à chaque fois que tu allume/éteins ta lumière, c’est hyper lourd!)

204

Du coup, comment fais-tu pour lancer un scénario 1h avant le coucher du soleil ?
Tu attends un événement futur -1h?

Et puis j’aime bien quand je rentre le soir, et qu’il commence à faire sombre (et pas nuit) que la lumière s’allume :wink: