Lassen Sie uns über Gladys V4 sprechen

Entwicklung
246

Übrigens, kleine Anmerkung, ich sehe, dass du dich von meinem Code aus der Integrationsansicht inspirieren ließt, der nicht unbedingt gut ist :joy:

Ich bin immer noch in der Erkundungsphase für einige Mechanismen, zum Beispiel sehe ich, dass du hier zwei Funktionen erstellt hast =>

const removeScene = (scene) => () => remove(scene);
const editScene = (scene) => () => edit(scene);

Ich weiß, dass ich es so in der Integration gemacht habe, aber das ist nicht die beste Praxis! Es werden bei jedem Render des Komponenten neue Funktionen erstellt und das macht die App schwerfälliger

247

Vollkommen einverstanden! Aber ich hatte mir eher ein kleines Popup vorgestellt, das sich daneben öffnet ^^
Ich habe Angst, dass es mit viel Information so anstrengend wird zu lesen..

Ja ja, ich weiß, und ich habe viele andere Dinge versucht, um das zu vermeiden, aber ich habe aufgegeben und mir gedacht, dass wir das später ändern könnten :slightly_smiling_face:

Gut, aber ich habe einen Branch erstellt und auf dem Repo committen, in dem Glauben, es sei mein Fork :stuck_out_tongue:
Entschuldigung… aber wenigstens hast du die Dateien :joy:

248

Ok! Ich habe mir das angesehen, es ist cool zu sehen, wie intuitiv du das entwickelt hast. Das erinnert mich daran, dass wir vor dem gemeinsamen Arbeiten unbedingt Guidelines aufstellen müssen, damit wir die gleichen Prozesse für die Entwicklung neuer Routen haben :slight_smile:

Ich spreche nicht vom Code-Stil, der bereits von ESLint durchgesetzt wird, sondern von den Entwicklungsmethoden.

Ein Beispiel:

Ich sehe, dass du für den Wechsel zur Bearbeitungsroute eine Funktion „Edit“ erstellt hast:

edit(state, scene) {
    const name = scene.name.replace(/[^A-Z0-9]/ig, '_').toLowerCase();
    store.setState({
      sceneEditing: scene
    });
    route(`/dashboard/scene/edit/${name}`);
  },

Das sollte vermieden werden, denn wenn man direkt auf die Route zugreift, indem man die URL eingibt, wird der Zustand nicht vorhanden sein! Hier reicht ein <Link>.

Übrigens wird die GET-Route /scene wahrscheinlich nur eine Liste von Szenen mit nur dem Namen, der ID und dem Selektor zurückgeben. Erst wenn die Bearbeitungsansicht geladen wird, wird die gesamte Szene abgerufen!

249

Ja, das ist mir klar geworden :stuck_out_tongue:
Aber da ich mich noch nicht gut mit Preact (und diesen Frameworks im Allgemeinen) auskenne, bin ich vorerst den einfachsten Weg gegangen.

Das wollte ich am Anfang auch machen, aber wieder bin ich den einfachsten Weg gegangen :sweat_smile:

250

Kein Problem :slight_smile: Wie ich schon sagte, ist die Architektur des aktuellen Preact-Projekts auch noch nicht ganz klar in meinem Kopf. Ich experimentiere noch mit einigen Themen! Wir sind noch sehr weit von der „industriellen Entwicklungsphase“ von Gladys 4 entfernt, es ist noch viel Erfahrung von meiner Seite.

Ich habe dein Design integriert, es ist cool, es sieht gut aus =>

37
372880×1374 172 KB

Übrigens habe ich einen „Trigger“-Tab hinzugefügt, um die Liste der Trigger zu verwalten. Meine Meinung dazu ist, dass es klar etwas getrennt von den Szenen ist, da es auch eine ganze Komplexität ist.

Wir müssen darüber nachdenken, wie wir den Trigger + die Bedingungen modellieren.

Für die Szenenansicht, im Moment bevorzuge ich die, die ich gemacht habe, aber ich bin einverstanden, dass wir daran arbeiten können, den Platz zu reduzieren, den jede Aktion einnimmt.

251

Zum Thema des Philips Hue-Dienstes habe ich eine erste, sehr grobe Version dieses Dienstes fertiggestellt (zumindest auf Serverseite, die Schnittstelle funktioniert noch nicht zu 100%)

Der gesamte Code des Dienstes ist hier.

Die Tests sind hier.

Eine interessante Funktion dieses Dienstes ist die Funktion light.turnOn.

Ich habe versucht, etwas so einfach wie möglich zu machen und dem Dienst so wenig wie möglich zuzumuten.

Ich habe absichtlich nicht den gesamten gladys-hue-Dienst gemacht, da ich noch experimentiere. Wenn wir Dinge finden, die geändert werden müssen, möchte ich lieber nur ein paar Funktionen ändern müssen, anstatt die gesamte API :stuck_out_tongue:

Ich werde weiter über andere „klassische“ Dienste nachdenken, um mich einzugewöhnen und zu sehen, ob diese Implementierung Sinn macht!

252

Oulala, wie schön, Jungs!!! Ich lese eure Nachrichten aufmerksam, um mich mit Wissen zu tränken… Vielleicht wird es mir eines Tages nützlich sein, wenn ich die Motivation habe, mich da reinzustürzen… :stuck_out_tongue:

253

Hallo zusammen!

Heute habe ich an zwei Themen gearbeitet, das erste ist MQTT.

Ich habe die MQTT-API-Spezifikation für Gladys 4 definiert:

https://gladys-4-docs.gladysassistant.com/en/development#mqtt

Zögert nicht, mir euer Feedback zu geben, bevor ich mit der Implementierung beginne :slight_smile:

Das andere Thema ist die Verwaltung des Pollings bestimmter Gerätetypen.

Ich erkläre es.

Bestimmte Geräte wie Philips Hue haben Methoden, um den Zustand der Lampen zu aktualisieren, falls der Zustand außerhalb von Gladys geändert wurde, z. B. über einen Schalter.

Bisher wurde das Polling vom Modul verwaltet.

Jetzt ist es in Gladys integriert.

Jedes Gerät hat zwei Attribute: « should_poll » und « poll_frequency », und Gladys fragt automatisch periodisch den Dienst über eine Methode « poll » an, um den Zustand eines bestimmten Geräts zu aktualisieren.

254

Interessante kleine Statistiken, die Suchanfragen der letzten Monate im Forum nach den häufigsten Suchbegriffen!

42
422254×1406 178 KB

Keine Überraschung, das bestätigt die Interessen der Leute an Smart Home im Jahr 2019.

  • Xiaomi, Bluetooth-Geräte, Sonoff, Z-Wave und Yeelight sind die Hardware, die am meisten gesucht werden. Das wundert mich nicht, angesichts des hervorragenden Preis-Leistungs-Verhältnisses der Xiaomi-Smart-Home-Angebote.
  • Bei den von Gladys spezifischen Problemen stehen HTTPS, Docker und MQTT ganz oben. Keine Überraschung, das bestätigt meinen Ehrgeiz, diese drei Punkte in Gladys 4 zu vereinfachen.
  • Bei der Software-Integration keine Überraschung mit Snips, Spotify, Alexa und Telegram.

Kurz gesagt, wir sind auf dem richtigen Weg! :smiley:

255

Xiaomi war einfach ein Muss!
Ich hoffe, dass das zum integrierten Standard-Equipment von Gladys 4 gehört :stuck_out_tongue:

256

Ich werde die Hilfe von @piznel benötigen, um sein hervorragendes Modul zu migrieren, aber ja, das ist das Ziel! :slight_smile:

Xiaomi ist in den obligatorischen Diensten für die v4, da gibt es keine Diskussion.

257

Das wird kompliziert werden… @piznel ist für eine ganze Weile offline!

258

Was ist mit Piznel los? Habe ich eine Folge verpasst?

259

Okay, ich habe gerade eine ziemlich umfassende Liste der verbleibenden Aufgaben erstellt, die noch erledigt werden müssen, bevor eine erste minimale funktionsfähige Version des Backends von Gladys 4 fertig ist.

28
282880×1800 509 KB

https://github.com/GladysAssistant/gladys-4-playground/milestone/1

Dieses Meilenstein enthält nicht:

  • Die Arbeit am Frontend
  • Die Arbeit an der API für die Pods
  • Die Arbeit an den Services

Ich habe dieses Meilenstein erstellt, um alle verbleibenden Aufgaben (sowohl Code als auch Dokumentation) zu listen, bevor wir mit den Services arbeiten können.

Das Frontend wird weiterhin parallel entwickelt, auch wenn mein persönlicher Fokus im Moment auf der API liegt.

Autsch, schade, reden wir von Tagen/Monaten/Jahren? Na, wir werden uns schon irgendwie durchschlagen :slight_smile:

260

Persönliche Gründe, aber es geht ihm gut, und nein, du hast keine Folge verpasst ^^

Keine Ahnung! Aber ich würde sagen ein paar Monate, basierend auf den letzten Nachrichten :thinking:

Ich habe deine Liste gesehen @pierre-gilles, deshalb habe ich heute Morgen die 40 und mehr Mails erhalten :joy:

Aber warum setzt du in jeder Route v1? Planst du, die APIs zu versionieren?

Wenn du möchtest, kann ich ein paar Dinge erledigen, um dir Zeit zu sparen! Sag mir einfach, was du von mir erledigt haben möchtest. Zum Beispiel habe ich gesehen, dass der Drawer auf mobilen Geräten nicht funktioniert, kann ich das beheben?

Oder ich kann kleine Dinge wie diese erledigen, während du die Richtlinien richtig definierst?

Außerdem habe ich den V1-Zweig von Tabler gebaut und festgestellt, dass das gesamte Template komplett neu erstellt wurde und sich vieles geändert hat! Also frage ich mich, ob es nicht besser wäre, von dieser Version auszugehen, auch wenn sie noch nicht vollständig ausgereift ist, anstatt in zwei oder drei Monaten drei Viertel der Arbeit neu machen zu müssen, wenn sie endlich die V1 veröffentlichen?

261

aha entschuldige für den Spam, ich habe mich durchgearbeitet :slight_smile:

Ja! Die API ist versioniert. Wenn wir anfangen, mobile Apps oder externe Dienste zu haben, die davon abhängen, können wir es uns nicht leisten, die API zu brechen. Wenn wir also das Antwortformat einer API ändern, behalten wir den v1-Pfad bei und erstellen einfach eine v2.

Mm, beim Drawer würde ich sagen, lass es sein, er funktioniert auf dem Gateway, ich muss nur den Code übernehmen, der das macht :slight_smile

Aber ich könnte Hilfe bei Frontend-Fragen gebrauchen, wie neulich bei der Szenenansicht, das hat mir sehr geholfen :slight_smile: Da ich denke, dass wir bei den Frontend-Richtlinien noch nicht bereit sind, mach dir nicht zu viele Gedanken über den Code, nur ein paar kleine Design-Tipps helfen mir enorm, das ist mein größter Schwachpunkt, der CSS ^^

Ein paar Ideen:

1/ Bei der Chat-Ansicht habe ich mich schwergetan, einen Chat neu zu erstellen, und ich bin nicht besonders zufrieden mit dem Ergebnis, da die Chat-Blasen nicht proportional zur Textgröße sind. Ich denke, wir sollten einfach das CSS von Gladys 3 übernehmen, das super war (vielleicht mit den Avataren hinzufügen, da in Gladys 4 ein Benutzer anscheinend ein Avatar hat + Gladys jetzt ein Logo hat!).

2/ Wenn du eine Möglichkeit siehst, die Größe der „Szene bearbeiten“-Ansicht zu reduzieren. Ich stimme zu, dass es im Moment zu groß ist. Allerdings möchte ich Klarheit und Einfachheit der Bedienung beibehalten, es sollte weiterhin luftig bleiben!

3/ Ich habe noch nicht an der „Trigger bearbeiten“-Ansicht gedacht

Oh Mist, das CSS ändert sich komplett?

Wir müssen ein wenig bewerten, wann sie planen, es zu veröffentlichen. Ich bin nicht unbedingt dafür, auf den v1-Zweig zu wechseln, wenn sie noch aktiv daran arbeiten, die aktuelle Version ist mehr als gut für das, was wir tun! Allerdings, wenn sie die v1 in 2 Wochen veröffentlichen, dann okay ^^

262

Für diejenigen, die mir auf GitHub folgen, ich bin gerade voll am Backend von Gladys 4 am Arbeiten, ich komme gut im Meilenstein 1 voran :rocket:

22
222068×742 63.5 KB

In den letzten Tagen habe ich an folgenden Dingen gearbeitet:

  • API zur Verwaltung der Häuser (Erstellung/Bearbeitung/Löschung) + Benutzerpräsenz
  • API zur Verwaltung der Räume (Erstellung/Bearbeitung/Löschung)
  • Geolokations-API
  • Verwaltung der Refresh-Token (Widerruf, Abruf eines neuen Access-Tokens)
  • Passwort-Wiederherstellungsprozedur
263

Hallo zusammen!

Kleine Neuigkeiten zum Fortschritt von Gladys 4 :slight_smile:

Fortschritt des ersten Backend-Meilensteins

Der Backend-Meilenstein v0.1 kommt gut voran, wir sind bei 54% der erledigten Aufgaben. Ich habe unterwegs ein paar To-dos hinzugefügt, aber ich denke, sobald alle Aufgaben erledigt sind, haben wir bereits ein minimales Backend, das funktioniert.

44
442042×738 74.7 KB

API-REST-Dokumentation online

Ich habe gerade die Dokumentation der API-REST von Gladys 4 online gestellt:

https://gladys-4-apidoc.gladysassistant.com/

Zögert nicht, sie anzusehen und einige Namenswahl oder Parameter, die an die API-Routen übergeben werden, zu kritisieren, da noch nichts veröffentlicht ist, kann man noch alles ändern. Es ist immer cool, externe Meinungen zu haben :slight_smile:

Die Skripte in Gladys 4

Ich habe eine kleine Frage an euch bezüglich der Skripte in Gladys 4.

In Bezug auf die Benutzeroberfläche fragte ich mich, ob es sich lohnt, einen separaten Skript-Tab von den Szenen zu haben.

Könnte ein Skript in Gladys 4 nicht einfach eine Aktion einer Szene sein, die sagt „führe diesen JS-Code aus“?

Die Vorteile

  • Das Design einer komplexen Szene ist einfacher, man kann in einer Szene Codefragmente codieren, die sich sequenziell/parallel von derselben UI aus abwechseln, ohne zwischen der Szenen-/Skript-UI hin und her springen zu müssen
  • Den Skripten in der UI weniger Bedeutung zu geben, in einem Produkt, das sich an ein nicht immer technisches Publikum richtet (natürlich die Power-User dabei zu behalten!). Ist es nützlich, einen ganzen Tab für die Skripte zu reservieren? Nicht sicher…
  • Eine bessere Integration mit den Szenen. Beispiel: Einen Wert von einem Trigger an eine Szene weitergeben und den Wert im Skript wiederfinden.

Die Nachteile

  • Bringt vielleicht eine Komplexität in die Szenen-UI, die einen Code-Editor einbeziehen muss (was schwer ist)
  • Große Skripte können an Lesbarkeit verlieren (übrigens habe ich noch nicht unbedingt eine Idee, wie man diese Skripte in der Szenenansicht codiert)

Sagt mir eure Meinung dazu, es ist eine Debatte, nichts ist noch festgelegt!

266

Einverstanden, außer wenn man es einfach nur alleine starten will, um schnell etwas Kleines zu testen. Es ist praktisch, es in einer separaten Liste zu haben.
Mal sehen, ob das Gleiche im Szenenteil möglich ist..

267

Genau! Der Sinn des Skripteditors in Gladys ist, dass er genau ausreicht, um darin sauber zu codieren.

Das ist der Sinn!

Gladys 4 ist eine vollständige Neuschreibung, es gibt keine gemeinsame Codezeile zwischen den beiden Codebases. Es ist ein komplett neues Produkt :slight_smile: Angesichts der Änderungen wird es auf jeden Fall eine Neuinstallation geben (wir ändern komplett die Technologie und den Bereitstellungsprozess). Andererseits werden wir wahrscheinlich ein Migrationswerkzeug bereitstellen, um einige Daten zu übernehmen :slight_smile:

Genau zu sehen, welche Daten man von der v3 zur v4 übertragen möchte. Nicht alles ist sinnvoll zu behalten, und es sollte keine mysteriösen Bugs aufgrund von falsch formatierten Daten der v3 geben.

Das Gleiche gilt für die Szenen! Das ist der Sinn der Szenen, du kannst auf « play » klicken und die Szene wird abgespielt.