Et hop the filtering that works on the integrations page, it’s awesome!
https://twitter.com/pierregillesl/status/1098166550345830406?s=20
I think so, so that everyone doesn’t have to redevelop everything 
However, for very specific cases, the developer will have to code their own transformation function in one direction or the other.
So what color format would you see? I think we should have an integer format so we can store it and the color picker works, what do you think?
I agree!
I found this => https://www.npmjs.com/package/color-convert
We will definitely use it but well it’s already great examples
2 cents, a percentage is simpler for the end user. Behind the scenes, it’s a different story 
It’s a roughly translated expression « my 2 cents » 
, just to signify my very small contribution to the discussion
Hello,
It might be a good idea to plan Gladys v4 natively with a front-end and a back-end
with the possibility of themes on the front-end
so depending on the location, the terminal, you access the front-end with the desired theme (with a parameter defined on the back-end [user → terminal → template])
front-end
|------- theme1
|------- theme2
|------- …
back-end
This is indeed the case in Gladys 4, the front is a PWA with Preact and the back is an Express server
For the theme, Gladys 4 will offer the possibility to create custom dashboards (and not just one dashboard, several!), so this should meet the need.
To have different UIs, for now we will focus on creating a single UI, that’s already complex enough
Top thanks
The milight devices handle 2700K to 6500K, and the hue devices handle 2000K to 6500K.
Hello,
I am sharing with you a thought I had when seeing the « Light device State ». Shouldn’t we represent the change in color temperature? It’s true that not all bulbs support this, just like HSB does. So should the schema not represent only the ON/OFF states?
This diagram was a non-exhaustive example For the bulbs, we need to choose the format we are going to manage. For now, we are more focused on the Philips Hue approach. Later, I think we will see during the implementation with the different manufacturers if it works well or not, and how we resolve the different incompatibilities.
I love it, it’s very minimalist. Great job @pierre-gilles
Hello everyone!
Today I worked on the entire scenario engine, with two goals:
Tonight I just finished a minimal first version of the engine, and… it’s awesome!!
1/ I defined the different events, states, and conditions in a constants file. This is not an exhaustive list, but this first list allowed me to get started I will expand it as development progresses (for this, I need to write the UML state diagrams, I do this properly).
2/ All states are stored in an in-memory store for maximum read performance. States are persisted on disk but this persistence is only useful for visualization (curves), not for real-time querying in a scenario.
I therefore did a small performance simulation with my first engine.
I created a typical or even extreme use case:
The video speaks for itself =>
https://twitter.com/pierregillesl/status/1100344419742404608?s=20
We’re at 1.35 million events per second hehe 
Thanks!
Of course! I think it was in the manifesto
@piznel:
I added the delay to actions, it was an easy action 
You can do in actions:
[
{
"type": "delay",
"seconds": 10,
"then": [
{
type: "light.turn-on",
deviceFeature: "piznel-lamp"
}
]
}
]
This action sequence will wait 10 seconds, then turn on the lamp with the selector « piznel-lamp »!
Note: You can use « milliseconds », « seconds », « minutes », or « hours »!
Would it be possible to manage multiple states, as the sun is not a lamp (ON/OFF)?
Similar to what is done in the suncalc library, there are several states:
| 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) |
I’m not sure that’s useful, to capture sunrise it’s the state change (night → day) and vice versa for sunset. After that personally I don’t see what all the other properties can be used for, knowing that you can deduce it with the time in addition to the state
Clear and minimal! Very well!
Regarding scenarios, I have a small suggestion. Would it be possible to have a setting that allows them to be activated and deactivated?
A case to illustrate the interest:
I have a motion detector. When it detects movement, it triggers a scenario that turns on the outdoor light for a duration of 15 seconds and then turns it off.
I can also turn the light on and off manually if I wish, with a switch.
If I manually turn on the light, because I know I’ll be there for a while (for example, I’m making trips to unload groceries from my car). When my detector sees me, the scenario will trigger and therefore turn off the light 15 seconds later, which is not necessarily what I want.
Therefore, it would be useful for the scenario to go to « deactivated » when I manually turn on the light.
This example may not be the most logical and may be solved in many other ways, I know. But I think there are other cases where this can be useful 
Why not, but in my opinion, it would be an additional state, since for most use cases the real question in scenarios is « Is it night or day, » so we shouldn’t lose that information either!
I see the idea!
I think in your case, the solution is to put a condition in the scenario « AND the light is not already on, » it’s not logical to cancel a scenario for that!
I will think about the possibility of canceling a scenario in the actions, I’m not sure that’s what we want, I’m afraid it will introduce illogical behaviors that are just solvable by simple conditions (because turning on/off a scenario every time you turn on/off your light is very heavy!)
So, how do you go about launching a scenario 1 hour before sunset?
Do you wait for a future event -1h?
And then I like it when I come home in the evening, and it starts to get dark (and not night) that the light turns on
