Und schwupps, das Filtering auf der Integrationsseite funktioniert! Das ist der Hammer!
Ich denke schon, damit jeder nicht alles neu entwickeln muss 
Für sehr spezielle Fälle muss der Entwickler allerdings selbst seine Transformationsfunktion in die eine oder andere Richtung codieren.
Was würdest du dir als Farbformat vorstellen? Ich denke, es sollte ein Ganzzahlformat sein, damit wir es speichern und der Farbauswahl funktioniert, was meinst du?
Ich bin ganz deiner Meinung!
Ich habe das hier gefunden => https://www.npmjs.com/package/color-convert
Wir werden es auf jeden Fall verwenden, aber es sind schon mal super Beispiele.
Meine 2 Cent, ein Prozentsatz ist für den Endnutzer einfacher. Was dahinter passiert, ist eine andere Geschichte 
Das ist ein umgangssprachlich übersetzter Ausdruck „my 2 cents“ 
, nur um meine ganz kleine Beitrag zur Diskussion zu zeigen
Hallo,
Es wäre vielleicht gut, Gladys v4 von Anfang an mit einem Frontend und einem Backend zu planen
sowie die Möglichkeit, Themen auf der Frontend-Seite zu verwenden
so dass je nach Ort, Terminal auf das Frontend mit dem gewünschten Thema zugegriffen werden kann (mit einem Parameter, der auf der Backend-Seite definiert ist [Benutzer → Terminal → Vorlage])
Frontend
|------- Thema1
|------- Thema2
|------- …
Backend
Das ist tatsächlich bei Gladys 4 der Fall, das Frontend ist eine PWA mit Preact und das Backend ein Express-Server
Was das Thema angeht, Gladys 4 wird die Möglichkeit bieten, benutzerdefinierte Dashboards zu erstellen (und nicht nur ein einziges Dashboard, sondern mehrere!), also sollte das den Anforderungen entsprechen.
Um verschiedene Benutzeroberflächen zu haben, konzentrieren wir uns zunächst darauf, eine einzige Benutzeroberfläche zu erstellen, das ist schon komplex genug
Top, danke
Die Milight-LEDs steuern 2700k bis 6500k und die Hue-LEDs 2000k bis 6500k.
Hallo,
Ich teile mit euch eine Überlegung, die ich beim „Light device State“ hatte. Sollte man nicht die Temperatur der Farbe darstellen? Klar, nicht alle Lampen unterstützen das, aber genauso wie HSB. Sollte das Schema also nicht nur die Zustände EIN/AUS darstellen?
Dieses Schema war nur ein nicht abschließendes Beispiel Bei den Lampen müssen wir uns tatsächlich für das Format entscheiden, das wir unterstützen wollen. Bisher sind wir eher von der Philips Hue-Herangehensweise ausgegangen. Ich denke aber, dass wir während der Implementierung mit den verschiedenen Herstellern sehen werden, ob sich das gut integrieren lässt oder nicht, und wie wir die verschiedenen Inkompatibilitäten lösen.
Das liebe ich, es ist sehr clean. Super Arbeit @pierre-gilles
Hallo zusammen!
Heute habe ich am gesamten Szenario-Engine gearbeitet, mit zwei Zielen:
Heute Abend habe ich eine erste minimale Version des Engines fertiggestellt, und… es rockt!!
1/ Ich habe die verschiedenen Ereignisse, Zustände, und Bedingungen in einer Konstantendatei definiert. Es ist keine abschließende Liste, aber diese erste Liste hat mir den Einstieg ermöglicht Ich werde sie im Laufe der Entwicklung erweitern (dazu muss man die UML-Zustandsdiagramme schreiben, das mache ich ordentlich).
2/ Alle Zustände werden in einem Speicher-Store für maximale Leseleistung gespeichert. Die Zustände werden auf der Festplatte persistiert, aber diese Persistenz ist nur für die Visualisierung (Kurven) nützlich, nicht für die Echtzeitabfrage in einem Szenario.
Ich habe also eine kleine Leistungsanalyse mit meinem ersten Engine durchgeführt.
Ich habe einen typischen, vielleicht sogar extremen Anwendungsfall erstellt:
Das Video spricht für sich selbst =>
Wir haben 1,35 Millionen Ereignisse pro Sekunde, haha 
Danke!
Aber natürlich! Das stand doch im Manifest, glaube ich
@piznel:
Ich habe delay zu den Aktionen hinzugefügt, das war eine einfache Aktion 
Du kannst in den Aktionen Folgendes tun:
[{
"type": "delay",
"seconds": 10,
"then": [{
type: "light.turn-on",
deviceFeature: "piznel-lamp"
}]
}]
Diese Aktionssequenz wartet 10 Sekunden, dann schaltet sie die Lampe ein, die den Selector « piznel-lamp » hat!
Hinweis: Du kannst « Millisekunden », « Sekunden », « Minuten » oder « Stunden » verwenden!
Wäre es möglich, mehrere Zustände zu verwalten, da die Sonne keine Lampe (AN/AUS) ist?
Ähnlich wie in der Bibliothek suncalc gibt es mehrere Zustände:
| Eigenschaft | Beschreibung |
|---|---|
sunrise |
Sonnenaufgang (die Oberkante der Sonne erscheint am Horizont) |
sunriseEnd |
Sonnenaufgang endet (die Unterkante der Sonne berührt den Horizont) |
goldenHourEnd |
Morgenliche „goldene Stunde“ (weiches Licht, beste Zeit für Fotografie) endet |
solarNoon |
Mittag (die Sonne befindet sich in der höchsten Position) |
goldenHour |
Abendliche „goldene Stunde“ beginnt |
sunsetStart |
Sonnenuntergang beginnt (die Unterkante der Sonne berührt den Horizont) |
sunset |
Sonnenuntergang (die Sonne verschwindet unter dem Horizont, die Abenddämmerung beginnt) |
dusk |
Dämmerung (die nautische Abenddämmerung beginnt) |
nauticalDusk |
Nautische Dämmerung (die astronomische Abenddämmerung beginnt) |
night |
Nacht beginnt (dunkel genug für astronomische Beobachtungen) |
nadir |
Nadir (dunkelster Moment der Nacht, die Sonne befindet sich in der tiefsten Position) |
nightEnd |
Nacht endet (die morgendliche astronomische Dämmerung beginnt) |
nauticalDawn |
Nautischer Morgen (die morgendliche nautische Dämmerung beginnt) |
dawn |
Morgenröte (die morgendliche nautische Dämmerung endet, die morgendliche bürgerliche Dämmerung beginnt) |
ich bin mir nicht sicher, ob das nützlich ist, um den Sonnenaufgang zu erfassen, ist der Zustandswechsel (Nacht => Tag) und umgekehrt für den Sonnenuntergang.
Danach sehe ich persönlich nicht, wofür all die anderen Eigenschaften gut sein sollen, wobei man das mit der Uhrzeit neben dem Zustand ableiten kann
Klar und aufgeräumt! Sehr gut!
Was die Szenarien angeht, habe ich einen kleinen Vorschlag. Wäre es möglich, eine Einstellung zu haben, mit der man sie aktivieren und deaktivieren kann?
Ein Beispiel, um den Nutzen zu veranschaulichen:
Ich habe einen Bewegungssensor. Wenn er eine Bewegung erkennt, startet er ein Szenario, das das Außenlicht für 15 Sekunden einschaltet und dann wieder ausschaltet.
Ich kann das Licht auch manuell ein- und ausschalten, wenn ich möchte, mit einem Schalter.
Wenn ich das Licht manuell einschalte, weil ich weiß, dass ich eine Weile brauche (z. B. wenn ich hin und her gehe, um die Einkäufe aus dem Auto auszuladen), wird das Szenario ausgelöst, wenn mich der Sensor sieht, und schaltet das Licht 15 Sekunden später wieder aus, obwohl das nicht unbedingt das ist, was ich will.
Daher wäre es sinnvoll, wenn das Szenario auf „deaktiviert“ schaltet, wenn ich das Licht manuell einschalte.
Dieses Beispiel ist vielleicht nicht das logischste und könnte auf viele andere Arten gelöst werden, das weiß ich. Aber ich denke, es gibt andere Fälle, in denen das nützlich sein könnte 
Warum nicht, aber meiner Meinung nach wäre das ein zusätzlicher Zustand, da in den meisten Anwendungsfällen die eigentliche Frage in den Szenarien lautet: „Ist es Nacht oder Tag“, also sollte man diese Information auch nicht verlieren!
Ich verstehe die Idee!
Ich denke, in deinem Fall wäre die Lösung, eine Bedingung im Szenario hinzuzufügen: „UND das Licht ist nicht bereits eingeschaltet“, es ist nicht logisch, ein Szenario deswegen zu stornieren!
Ich werde über die Möglichkeit nachdenken, ein Szenario in den Aktionen zu stornieren, ich bin mir nicht sicher, ob das das ist, was wir wollen, ich habe Angst, dass es Verhaltensweisen einführen könnte, die nur durch einfache Bedingungen lösbar sind (denn schließlich ein Szenario jedes Mal stornieren/wiederherstellen, wenn du dein Licht an- oder ausschaltest, ist extrem umständlich!).
Wie startest du also eine Stunde vor Sonnenuntergang ein Szenario?
Wartest du auf ein zukünftiges Ereignis -1 Stunde?
Und ich mag es, wenn ich abends nach Hause komme und es beginnt dunkel zu werden (aber noch nicht Nacht), dass das Licht angeht
