Okay, dann blockiere ich meinen 21.!
Der 20. passt mir auch! 
Ich bin nicht einverstanden! Sails.js wird veraltet und wird quasi nicht mehr aktualisiert. Das blockiert uns, und vor allem haben wir derzeit wenig Freiheit bei der Ausführung von Modulen, was alle Module-Ausführungsprobleme verursacht, die du im Forum sehen kannst.
Es fügt zwar keine Funktionen hinzu, aber es fügt enorm viel Stabilität hinzu. Und Stabilität ist für mich eine Funktion!
Was Preact betrifft, gibt es große Vorteile beim Migrieren:
- Es ist eine PWA, also wird die Schnittstelle für den Kunden viel reaktionsfähiger sein
- Preact vs. AngularJS ist in Bezug auf die Client-Leistung nicht vergleichbar
- Aus Entwicklersicht ist es einfach angenehmer. Derzeit sind wir mit dem AngularJS-Tooling blockiert und möchten ES2018 auf der Client-Seite verwenden, aber das können wir nicht.
Ein weiterer wichtiger Aspekt ist der „Sexappeal“ für Entwickler, die dem Projekt beitreten wollen. Das ist ein wichtiger Erfolgsfaktor für ein Open-Source-Projekt 
Das aktuelle Tooling ist veraltet, und ich denke, es ist wichtig, auf dem neuesten Stand zu bleiben.
Ich sage nicht das Gegenteil! Ich stimme allen Funktionen zu, die du erwähnst!
Normalerweise wird diese Transcodierungstabelle bereits vom Z-Wave-Modul selbst erstellt! Es gibt bereits enorme Tabellen in Open-Zwave, die wir verwenden.
Da du Erfahrung mit anderen Smart-Home-Systemen hast, wie machen sie das auf ihrer Seite? Haben sie zusätzlich zu Open-Zwave eigene Transcodierungstabellen geschrieben?
Gladys ist unabhängig von jeder Technologie. Wenn Anpassungen erforderlich sind, dann auf Modulseite, nie auf Gladys-Seite! Für Gladys ist ein Gerät „abstrakt“, das Modul stellt die Verbindung zur realen Welt her
Das ist geplant!
Hallo !
Ich bin auch nicht einverstanden 
SailsJS geht noch, auch wenn ExpressJS in jeder Hinsicht doppelt so gut ist, aber Angular 1… das wird langsam alt. Auf der Client-Seite sind wir technologisch etwa vier Jahre im Rückstand…
Das ist ein anderes Thema ^^
Es ist unnötig, das Transcodieren selbst zu erledigen, da Open Zwave das bereits erledigt (und wir Open Zwave verwenden).
Allerdings gibt es in der Core tatsächlich keinen DT-Typ für diese Art von Funktionen. Daher könnten wir hier einen „select“-Typ hinzufügen, der die verschiedenen Listenelemente übernimmt und es dem Benutzer ermöglicht, auf einfache Weise auszuwählen.
Was denkst du dazu @pierre-gilles ?
Sehr gute Idee, ich bin dabei!
Auf der Implementierungsseite müssen wir am intelligentesten vorgehen, es darf nicht der Albtraum sein, es zu aktualisieren.
Beispiel: Man stellt fest, dass es einen Tippfehler in einer JSON-Option gibt, wie aktualisiert man dann in der DB bei den Benutzern, die das Modul bereits installiert haben und automatisch DeviceTypes erstellt haben. Man muss sehen, ob man es in der DB im DeviceType speichert, wie piznel gesagt hat, oder ob man einfach einen speziellen Typ macht und das Modul ein JSON exponiert… muss man überlegen
aha, nie solche Fragen stellen 
Wir haben noch nicht mal mit der Planung der v4 begonnen, die Planung beginnt am 21. Dezember!
Dann gibt es die Konzeption und schließlich die Implementierung. Kein geplantes Datum, solange wir den Umfang nicht haben.
Amazon gibt, glaube ich, etwas Geld, wenn du ein Produkt hast, das gut mit Alexa funktioniert, ich würde prüfen, ob wir berechtigt sind
persönlich würde ich mir nur ein Amazon-Gerät mit Alexa kaufen, wenn es mit Gladys kompatibel ist und Gladys bei der Spracherkennung hilft
Ich denke, eine Erwartung an die V4 wäre, dass die Module der V3 mit der V4 kompatibel sind. Es gibt mittlerweile viele Module (die unersetzlich werden!), ich denke, man sollte diese Module nicht neu entwickeln.
All das ist Aufgabe der Module, nicht des Gladys-Kerns ^^
Es ist also ein anderes Thema 
Ja, aber es liegt an den Modulen, die Boxen nach ihren Bedürfnissen zu erstellen ^^
Denn wir werden keine Box, die die Heizung verwaltet, in den Kern von Gladys setzen, wenn sie danach ein Modul benötigt, um korrekt zu funktionieren..
Alles, was sich im Kern befindet, muss abstrakt bleiben und darf nicht die Installation eines Moduls oder so etwas erfordern. Wenn also jemand ein RFPlayer-Modul erstellt, dann muss er auch die Box erstellen, die mit seinem Modul installiert wird
Andernfalls wird die Liste der verfügbaren Boxen in diesem Tempo riesig sein und nicht jeder benötigt so viele, da nicht jeder die gleiche Hardware besitzt!
Und übrigens sollte man vor dem Einsatz einer Box die API Device und DeviceType so weit wie möglich nutzen.
Aber all diese Protokolle müssen nicht von Gladys bekannt sein, das muss das Modul erledigen!
Du kannst die Helligkeit auf diese Weise im Moment nicht einstellen, aber du kannst ihm sehr gut sagen, dass es aus- und einschalten soll (ich habe auch Fibaro-Geräte und es funktioniert sehr gut bei mir)
Außerdem hat das nichts mit dem Z-Wave-Protokoll zu tun, es ist der Brain von Gladys, der diese Funktion nicht kennt
Nicht per Sprachsteuerung, aber kein Problem, Gladys über ein Skript einen bestimmten Prozentsatz zu fragen.
Also, ich weiß nicht warum, aber in dieser Nacht hat mein Gehirn nur an Gladys v4 gedacht, und ich habe kaum geschlafen (ich bin erledigt aha)
Deshalb habe ich mich heute Morgen mit einer ersten Vision des Datenmodells aufgeweckt, habe es aufgeschrieben und bin wirklich stolz auf mich! Gladys v4 wird großartig!
Ich muss alles aufschreiben, was mir an Änderungen vorschwebt, und das dann hier veröffentlichen. Die Idee ist, dass ich euch eine erste Vision präsentiere, ihr von eurer Seite aus eure Erwartungen einbringt, und wenn wir uns im Dezember sehen, haben wir schon etwas zu diskutieren und eine Grundlage für die Überlegungen.
Aber nur um das Thema hier etwas zu beruhigen, das Ziel ist es, über Gladys v4 zu sprechen, nicht über kleine Änderungen/Module! Bei Gladys v4 geht es vor allem um große Änderungen des Datenmodells, wir hinterfragen die verwendeten Technologien und Abhängigkeiten. Wir sprechen über Installation/Migration/Stabilität/Modulinstallation, so etwas vor allem
Ich warte auf den Stein..
Wahrscheinlich nächste Woche, ich möchte lieber ein bisschen in Ruhe darüber nachdenken am Wochenende, und nächste Woche einen langen Text schreiben!
Für mich ist es quasi Wochenende 
Bisher bin ich bei 6 Seiten auf Google Drive…
Bleibt dran 
Sollen wir uns am 20. oder 21. zum informellen Treffen sehen?
Ich kann beides! Also 20 auf jeden Fall!
Am 20. passt mir das noch besser!
Mir ist jeder Zeitpunkt recht… 
Was ist mit euch? Welcher Zeitpunkt passt euch?
Mir ist das auch egal ^^
Am 20. muss ich leider einen Tag früher nach Paris kommen, also wäre nachmittags eigentlich besser, dann kann ich morgens losfahren statt am Mittwochabend.