Hallo zusammen,
Tolle Arbeit @pierre-gilles.
Kleine Frage, wenn ich das richtig verstanden habe, haben wir jetzt keinen Store mehr für Module/Dienste. Werden also alle Dienste im Core von Gladys sein und beim Start geladen?
Ich werde die Migration des CalDAV-Dienstes zu Gladys v4 so schnell wie möglich beginnen.
Das ist einer der Vorteile der Zeitzone, wenn ihr schlaft, arbeite ich 
Top! Dafür brauchst du aber nicht die REST-API, du kannst das intern machen.
Vollkommen 
Ich denke, dieses Thema ist sehr gut, wenn du an einem Thema arbeiten willst, kannst du hier darüber sprechen! Sobald du dann anfängst, daran zu arbeiten, ist es am besten, wenn du so früh wie möglich einen PR erstellst (du kannst auf GitHub angeben, dass dieser PR in Arbeit ist)
Tatsächlich ist dieser Dienst entscheidend. Es ist übrigens ein gutes Beispiel für mich von einem Dienst, der in 2 Versionen vorhanden sein wird:
Die Priorität liegt auf dem internen Dienst, im Moment ist die MQTT-API für die entfernten Dienste noch nicht 100% fertig.
Genau! Das ist das Ziel dieser v4, eine konsistente Erfahrung und ein vollständiges Produkt zu bieten, das wir von Anfang bis Ende beherrschen.
Der CalDAV-Dienst ist interessant, bisher habe ich noch keinen Kalenderdienst in Gladys 4 gemacht, also wird es vor der Entwicklung einen kleinen Teil der Überlegung geben.
Ich denke, es lohnt sich, wenn wir gemeinsam darüber nachdenken Zögere nicht, wenn du Fragen hast, oder sogar anrufen, ich bin verfügbar!
Hallo, ich bin immer noch etwas skeptisch bezüglich des Modul-Store-Verschwindens.
Werden alle alten Module zu neuen Diensten im v4-Repo?? Oder nur die Dienste, die ein neues Protokoll ermöglichen?
Ich möchte nicht gezwungen sein, 1000 Dienste zu laden, wenn mich nur einer interessiert.
Ich muss wohl etwas verpasst haben…
Ja Ich möchte, dass Gladys ein konsistentes, schlüsselfertiges Produkt ist, das von Anfang an funktioniert, ohne dass man wie heute herumfummeln muss.
(Achtung, es wird keine redundanten Dienste geben, es wird nur einen Bluetooth-Dienst, einen Philips Hue-Dienst usw. geben.)
Mit den derzeit getrennten Modulen entstehen massenhaft Probleme. Wenn du ein Gladys 3-Modul installierst, führt Gladys ein git clone + NPM install + Neustart von Gladys aus. Und wir reden noch nicht einmal davon, das Modul in die UI zu integrieren, das hat in Gladys 3 nie richtig funktioniert, und wir mussten furchtbare Hacks machen, damit es mehr oder weniger funktioniert… Wenn ich sehe, wie viele Forumsnachrichten es gibt, in denen die UI einiger Leute aufgrund der Installation eines Moduls abgestürzt ist, ist das nicht normal!
Alles, was derzeit bei der Installation eines Moduls auf Benutzerseite geschieht, sollte nur auf Entwicklerseite geschehen.
Danach denke ich, dass du die Größe eines Dienstes überschätzt… Ein Dienst besteht in der Regel aus einigen JS-Dateien, wir sprechen von einigen Kilobyte Code… Ich sehe nicht, wie das Gladys aufbläht
Tatsächlich denke ich, dass man Gladys 4 anders sehen sollte als Gladys 3, es ist nicht dasselbe Produkt.
In Gladys 3 habe ich naiv gedacht, dass meine Rolle bei der Erstellung von Gladys darin bestand, die Plattform zu schaffen, aber die „Modulerfahrung“ vom Kern zu trennen.
Aber was ich unterschätzt habe, ist, dass das, was ein Benutzer über Gladys in Erinnerung behält, die Gesamterfahrung ist, die er gemacht hat. Wenn er Gladys installiert, das Modul speak installiert und Gladys abstürzt (und wir können nichts dagegen tun, „npm install“ schlägt oft aus externen Gründen wie RAM-Mangel, NPM-Downtime fehl), wird sein Feedback sein: Gladys funktioniert nicht und ist instabil.
Mein Paradigma für Gladys 4 ist, dass die Dienste ein integraler Bestandteil des Produkts sind, es sind keine Details: es ist das Herz der Gladys-Erfahrung.
Ich möchte, dass der Benutzer Bluetooth einfach durch das Ankreuzen der Option „Bluetooth“ in der Oberfläche nutzen kann, nichts weiter.
Und dafür müssen die Dienste im Kern des Produkts liegen, mit derselben Entwicklungsstrenge wie der Gladys-Kern:
Das ist der einzige Weg, um eine globale Erfahrung zu haben, die wir von Anfang bis Ende beherrschen können
Zögere nicht, wenn du Fragen oder Einwände dazu hast, das ist ein Teil, über den ich lange nachgedacht habe, und ich habe dir hier nur die großen Linien gezeigt. Wir können auch am Sonntag beim Community-Anruf darüber sprechen!
Im schlimmsten Fall erstellen wir einen Dienst zum Laden von „Plugins“ 
Aber ich verstehe die Idee, entweder haben wir eine offene Lösung, vielleicht sogar zu offen (v3), oder eine stabile und kontrollierte Lösung, die der ständigen Validierung des Hauptteams (du) unterliegt, die v4.
Das Einzige, was mir Sorgen macht, ist, dass, wenn eine Anforderung für eine Neuerung gestellt wird, sie zu lange dauert, um integriert zu werden.
Aha, das wäre zurück zu den Problemen der v3
Genau! Aber ich denke, du machst dir Sorgen wegen meinem GitHub-Merge-Rhythmus. Darüber habe ich nachgedacht und ich denke, es wird ziemlich anders sein als die v3.
Zur v3:
Zur v4:
Es wird viel Zeit damit gespart.Tatsache ist, dass alles in einem Monorepo vieles verändert.
Hallo @pierre-gilles,
super Arbeit, es sieht so aus, als ob es gut voran geht 
!
Ich habe ein paar Fragen:
Es gibt jetzt einige Module und ich denke, das wird eine Menge Arbeit machen..
Dann gebe ich zu, dass ich die Bedenken von @AlexTrovato bezüglich der internen Dienste teile.
Wenn zum Beispiel jemand einen Philips-TV-Service möchte (rein zufällig [https://community.gladysassistant.com/t/recherche-module-philips-tv/4667/5]), muss er dann warten, bis das erledigt und bereitgestellt ist?
Heißt das, dass ich einen Service nicht entwickeln kann, für den ich keine Hardware habe, und ihn von einem Mitglied testen lassen kann, so wie ich es mit @Jean34 und der Viera-TV gemacht habe, bevor ich ihn in die Produktion bringe?
Ich dachte, ich hätte vorher verstanden, dass bestimmte Module zu Diensten werden, aber nicht alle, es sei denn, ich irre mich 
Kleine Vorschläge:
Sollte es nicht eher einen großen TV-Service geben, der nach und nach Modelle integriert?
Aber ich stimme dir zu, es wird ein bisschen schwieriger sein, etwas an Tester zu verteilen…
Ich kann mir den Aufwand vorstellen, den das mit @piznel und seinem Xiaomi-Modul gegeben hätte, wenn man ständig am « Kern » hätte herumfummeln müssen…
Noch nicht! Im Moment liegt mein Fokus darauf, Gladys Core + Services so weit wie möglich voranzubringen, um eine Alpha-Version so schnell wie möglich herauszubringen
Ich würde sagen, ich verlasse mich auf jeden Modulentwickler von V3, um bei der Migration ihres Moduls auf Gladys 4 zu helfen, natürlich mit meiner Unterstützung. Aber zunächst ist das Wichtigste, die « essentiellen » Services (Z-wave, Philips hue, Milight, Bluetooth, Xiaomi, etc…) zu haben, die anderen Services werden nach und nach je nach Verfügbarkeit hinzukommen!
Übrigens habe ich gerade nachgeschaut und im Modul-Store von V3 gibt es 54 veröffentlichte Module. Nichts Schlimmes, was man migrieren müsste!
Nichts hindert dich daran, eine Beta-Version von Gladys an einen anderen Benutzer zu senden. Zur Erinnerung: Die Installation von Gladys 4 ist radikal anders, es ist nur ein Pull eines Docker-Images, also nichts hindert daran, in der Update-UI eine erweiterte Option zu haben, um Gladys über ein « Vorschau »-Image zu aktualisieren.
In Gladys 4 muss man Gladys als ein vollständiges Produkt sehen. Wenn du einfach ein Modul zum Testen an einen Benutzer schicktest, hatte er nicht unbedingt die gleiche Gladys-Version wie du, wenn du auf eine PR gewartet hast, die im Core ausstand, warst du blockiert. Jetzt ist Gladys ein Ganzes, also sollte es, wenn du ihm ein fertiges Image schickst, bei dir genauso funktionieren.
Ja!
Das ist bereits der Fall!
Jede Konfigurationsseite einer Gerätemarke hat ein reichhaltiges Tutorial, das erklärt, wie man das Gerät konfiguriert. Ich ermutige jeden Gladys-Beiträger, reichhaltige und vollständige UIs für die Integrationen zu erstellen
Beispiel:
Ich denke, wir werden Lösungen für die Entwicklung finden Ich bin im Gegensatz dazu der Meinung, dass sich die Erinnerungen an die Entwicklungsprozesse der Gladys 3 Module eher als schrecklich erwiesen haben ^^
Wenn du dich im Thema « Zwave », « Snips » oder « Rpi Infos » umschaust, findest du eine Menge von UI-Problemen, die springen, oder dumme Bugs, die nie zum Endbenutzer gelangen sollten, und die nur auf Entwicklungsprozessprobleme zurückzuführen sind.
Ich bin damit einverstanden, dass wir etwas an Agilität verlieren werden, aber wir werden enorm an Produktzuverlässigkeit und Sicherheit gewinnen. Das ist es, was Gladys derzeit fehlt, um Benutzer zu überzeugen, die eine ernsthafte Smart-Home-Lösung suchen.
Und in Bezug darauf, könnte man nicht einen Bereich wie die v3 beibehalten, um ein Modul aus einem externen Repository zu laden? Dadurch könnte das Testen eines Moduls erleichtert werden, bevor es in den Kern integriert wird?
Nicht wirklich, das Produktionsimage von Gladys wird ein sehr unterschiedlich gebautes Image im Vergleich zu deiner Entwicklungsinstallation sein. Um so minimal wie möglich zu sein, wird es ohne Build-Tools ausgeliefert.
Und selbst das hätte keinen Sinn, ich wiederhole es: Es gibt keine Modulkonzept mehr, die Dienste sind im Kern! Es ist ein einziges und dasselbe Programm.
Ein Service, meine erste Meinung:
Hallo, ich habe mein Wochenende damit verbracht, einen Service für die Bluetooth-Unterstützung zu entwickeln (ich sage nicht migrieren).
Die Vision ist nun völlig anders, denn es ist offensichtlich notwendig, zwei Teile zu entwickeln: Frontend und Backend.
Das Frontend: Preact ist magisch, die Entwicklertools, die damit geliefert werden, auch. Du änderst eine Seite, speicherst sie und dein Browser aktualisiert sich und du siehst direkt das Ergebnis… es ist ein echtes Vergnügen. Und Preact ist so angenehm zu programmieren. Aber es ist ziemlich komplex, sich in das Bestehende zu integrieren, und die Risiken von Git-Konflikten zwischen den verschiedenen Modulen werden beträchtlich sein.
Das Backend: Wir bleiben ziemlich nah am alten modularen System, ein Service, der auf Code-Ebene ziemlich unabhängig bleibt.
Große Vorteile, wenn man Frontend und Backend getrennt hat, man kann wirklich das eine ohne das andere entwickeln, mit gemockten URLs, aber die Integrationsphase ist auch nicht neutral.
Aber wir sind definitiv in einer Version, die derzeit in Entwicklung ist, noch nicht finalisiert, daher denke ich, es ist wichtig, dass jeder die noch nicht abgedeckten Punkte notieren kann, um nichts zu vergessen.
Und ich gebe zu, dass das Endergebnis nach Abschluss der Integration wirklich schön ist.
Ich denke bereits an ein System von Untermodulen für Services, Gerätemodule. Aber es wird sehr schwierig sein, nicht im v4-Repo zu entwickeln.
Kleine Anmerkung, ich finde es trotzdem etwas ärgerlich, die Bibliotheken zwave, philips-hue und andere zu laden, obwohl ich diese Dienste nicht nutzen werde.
Bis bald für die Fortsetzung.
Hallo @pierre-gilles, ich habe mir gerade den Aufruf angesehen, den du für diesen Monat auf YouTube gemacht hast.
Mir ist etwas für den Reiter „Integrationen“ eingefallen.
Wenn der Benutzer auf „Integrationen“ klickt, findet er alle Module, die er installiert hat.
Das fügt zwar eine Seite hinzu, aber es wird für den Benutzer übersichtlicher sein.
Darunter dann die Listen der Geräte, Kommunikation, Kalender und andere, die ich als eine Liste von Möglichkeiten sehe.
Man könnte es „Store“ nennen, irgendwann wird es vielleicht auch kostenpflichtige Module geben.
Es gibt mehr Module in der V4
Wenn Gladys zu einem Jeedom wird, wird das nicht funktionieren. Ich glaube nicht, dass das die Philosophie des Projekts ist.
Hallo zusammen!
Ich hatte heute eine interessante Frage im Community-Call: Wann wird Gladys 4 veröffentlicht?
Bisher habe ich kein Datum festgelegt, weil es schwierig war, die Entwicklungen zu quantifizieren, die sich noch in der „Forschungs“- und Erkundungsphase befinden, und ich das Produkt nicht ruinieren wollte, indem ich ein viel zu ambitioniertes Datum festlege (oder umgekehrt zu viel Zeit habe, indem ich ein zu weit entferntes Datum festlege). Und vor allem weiß ich aus Erfahrung, dass ich, wenn ich ein Datum ankündige, enttäuschen könnte, wenn das Datum nicht erreicht wird. Aber heute, jetzt, da der erste Backend-Meilenstein erreicht wurde, sind die verbleibenden Schritte ziemlich klar und es ist möglich, ein Release-Ziel zu setzen! Das gibt uns ein gemeinsames Ziel und verhindert, dass die Entwicklung schleppend wird.
Hier ist die Roadmap, die ich euch vorschlage:
Ich habe einen Monat für die Migration der Dienste von Gladys 3 zu Gladys 4 eingeplant.
Ich spreche nicht über alle Dienste, mindestens die wesentlichen:
Devices
Gesamt: 12
Kommunikation
Gesamt: 3
Kalender
Wetter
Gesamt: 1
Navigation
Gesamt: 1
Diese Roadmap führt uns zu einem Feature Freeze am Sonntag, 23. Juni, für eine erste Alpha-Version am Mittwoch, 26. Juni.
Was denkt ihr dazu?
Ich werde alle Aufgaben und Meilensteine in GitHub erstellen, damit wir einen Überblick über den Fortschritt haben und die Aufgaben aufteilen und sehen können, wo jeder steht.
Die GitHub Issues/PRs werden die Hauptplattform für die Kommunikation dieser Entwicklung sein.
Genau!
Schön, dass dir auch der Entwicklungscomfort gefällt, den preact bietet! Was die Git-Konflikte angeht, für mich ist Gladys einfach ein einziges Produkt, also ist es im Grunde genommen nur allgemeine Git-Entwicklung, wenn man das ordentlich macht, gibt es keine Probleme
100%! Es ist noch nicht fertig, wie ich sagte, wir sind nur beim Meilenstein Backend v0.1
Das wird in der finalen Version nicht mehr der Fall sein, ich muss diese Libs nur beim Start des Dienstes laden und nur, wenn der Benutzer sie konfiguriert hat. Guter Hinweis.
Weder das eine noch das andere. Gladys 4 ist ein einziges Produkt, es gibt keine Trennung mehr.
Hallo,
das hängt von der Verfügbarkeit und der Anzahl der Entwickler ab.
Ich werde ab Ende Mai bis Anfang Juli deutlich weniger Zeit haben.
PS (unrelated): Für das Bluetooth-Modul plane ich ein System zur „Distanz der Knoten“ einzurichten, wie du es für ZWave vorschlägst. Es wäre interessant, diesen Teil zu modularisieren, um die Anzeige unabhängig zu halten.
Dafür werde ich alle GitHub-Issues erstellen (eine pro zu migrierendem Modul, eine pro verbleibender Core-Funktion) und jeder kann angeben, ob er bei bestimmten Issues helfen möchte. Bei den Modul-Migrationen, bei denen sich niemand meldet, werde ich das übernehmen.
Persönlich verbringe ich meine Tage damit, also denke ich, dass ich in 2 Monaten genug Zeit habe, um mich um viele der verbleibenden Themen zu kümmern!
Mm okay, ich werde das Bluetooth-Modul-Issue erstellen, darüber können wir dann reden!
