Parlons de Gladys V4


#182

La définition du standard HLB est :

  • Hue : de 0 à 360 (angle sur le cercle chromatique) (pour qu’il soit entier, il faut coder de 0 à 3600)
  • saturation : 0 à 100%
  • Brightness : 0 à 100%

Mais j’aurais tendance à faire comme Philips Hue (comme je ne connais pas mieux sur le marché), à savoir :

  • Hue : uint16 ; de 0 à 65535,
  • brightness : uint8 ; de 0 à 255 (En fait, Philips se limite à 1 -> 254),
  • saturation : uint8 ; de 0 à 255 (En fait, Philips se limite à 0 -> 254),

il faudrait également la température de couleur, mais j’ai pas encore regardé.

Là où ça va se compliquer, c’est pour les devices à 256 couleurs, car le colorPicker ne sait pas les gérer, et de ce que j’en ai vu, passer de 65K à 256 couleurs n’est pas si simple, sans parler du fait que l’user verra une couleur qui ne correspondra pas à ce qu’il a choisi.


#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:


#185

Salut,

là, je ne comprends pas : “Mes 2 centimes”, j’ai beau cherché, je ne vois pas … Un coup du correcteur orthographique ?


#186

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


#187

:joy: Effectivement, j’aurais pu trouver quand même !


#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:


#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 =>

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

Merci! :slight_smile:


#196

Bien joué !
On pourra mettre une tempo dans les scénarii ? Très utile pour allumer pendant 1 min une lampe s’il fait nuit sur un changement d’état d’un capteur de mouvement.


#197

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


#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” !


#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:


#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)

#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