Lassen Sie uns über Gladys V4 sprechen

[pierre-gilles]

Wieder einmal bin ich sehr beeindruckt von der Leistung von Sequelize!

Stellen wir uns vor, ich möchte alle « Standorte » mit ihrem zugehörigen Benutzer abrufen.

Ich mache:

erhalte:

Aber das Interessante ist nicht das! Es ist die Art und Weise, wie Sequelize das unter der Haube macht.

Manche ORMs führen in dieser Situation X Abfragen aus:

• Ein SELECT * um alle Zeilen abzurufen
• Dann ein SELECT pro Fremdschlüssel, um das verschachtelte Attribut abzurufen

Hier führt Sequelize eine einzige Abfrage aus

SELECT `t_location`.`id`, `t_location`.`user_id`, `t_location`.`latitude`, `t_location`.`longitude`, `t_location`.`altitude`, `t_location`.`accuracy`, `t_location`.`created_at`, `t_location`.`updated_at`, 
`user`.`id` AS `user.id`, `user`.`firstname` AS `user.firstname`, `user`.`lastname` AS `user.lastname`, `user`.`email` AS `user.email`, `user`.`birthdate` AS `user.birthdate`, `user`.`language` AS `user.language`, `user`.`password_hash` AS `user.password_hash`, `user`.`role` AS `user.role`, `user`.`created_at` AS `user.created_at`, `user`.`updated_at` AS `user.updated_at`
FROM `t_location` AS `t_location`
LEFT OUTER JOIN `t_user` AS `user` ON `t_location`.`user_id` = `user`.`id`;

Dann setzt es das verschachtelte Objekt mit seinem « table.attribut »-Format in den « AS » zusammen

Das ist super leistungsfähig!

[pierre-gilles]

@piznel

Ich habe sie nicht im Modell gesehen. Werden sie später definiert? Oder ist die Analyse veraltet?

Wie ich oben schon sagte, war es noch in Arbeit, ich habe gerade die Indizes hochgeschoben

@piznel

Aus meiner Sicht, mit einer „non-dev“-Logik, wird ein Feature mit einer Kategorie (z. B. „light“) definiert, dann einer Unterkategorie (z. B. „dimmable“).
In diesem Fall hätten wir ein Paar „light/dimmable“, das die Anzeige und das erwartete Verhalten definiert, und der „Typ“ würde in dieser Tabelle verschwinden.

Okay, ich verstehe die Idee!

Es geht eher um die Benennung + eine Feinheit in der Granularität der Typen.

Ich mag die Idee von recht feinen Typen.

Was ich bei dir nicht verstehe, nimm dein Beispiel zum Beispiel:

category: "light"
sub-category": "dimmable"

Was bedeutet das für dich? Was wird in der UI angezeigt?

Dann mag ich die Idee von Typen, die feiner sind als nur « binary », « multilevel » und « color ».

Wenn wir die Idee nehmen, eine recht allgemeine Kategorie + eine Unterkategorie (der Name ist noch zu klären, ich finde, dass es « Typ » zu nennen, ist konsistenter), was hältst du von diesem Schema? (Ich habe es gerade gezeichnet)

(Entschuldigung, wenn es schwer zu lesen ist, von links nach rechts « light », « sensor », « switch », « fan », « door lock »)

Was wir dann tun müssen, ist, dass für jedes Paar (Kategorie/Typ) eine Funktion zurückgibt, welche Art von Button angezeigt werden soll, aber das ist nicht sehr kompliziert.

[pierre-gilles]

Du hast nicht gesagt, was du von meinem Schema hältst!

Ich gebe zu, dass ich nicht mehr alles verstehe, aber hier ^^

Sind Parameters nicht redundant mit Subcategory?

Um zu unserer Modellierung zurückzukehren, damit wir auf einer guten Grundlage starten.

Sind wir uns einig, dass:

• Ein Gerät ist ein physisches Gerät, ein Objekt.
• Eine Funktion (die wir « DeviceFeature » nennen, damit sie in der Datenbank leichter verständlich ist, aber im Grunde ist es eine Funktion), ist eine Funktion eines Geräts.

?

Beispiel:

Mein Gerät « Ampoule 1 Philips Hue » hat 3 Funktionen:

• Ein/Aus
• Helligkeit anpassen
• Farbe anpassen

Dieses Gerät könnte also wie folgt dargestellt werden:

{
  "name": "Ampoule 1",
  "service_id": "1ec7966f-e3ef-47d7-9aef-083a59956a68",
  "features": [{
      "category": "light",
      "type/sub_category": "binary"
    },
    {
      "category": "light",
      "type/sub_category": "brightness"
    },
    {
      "category": "light",
      "type/sub_category": "color"
    }
  ]
}

Deine Excel-Tabelle hat Potenzial, aber könntest du mir ein paar Beispiele geben, wie du es siehst? (so wie ich es hier gemacht habe).

Ich verstehe die Hierarchie und die Logik hinter jeder Entität/Attribut nicht, die du mir zeigst.

Ich mag die Idee der Parameter, die für Z-Wave sehr nützlich sind, aber wie speichern wir das?

Ich erinnere mich, dass wir schon mit @MathieuA darüber gesprochen haben, es könnte ein Boolean-Attribut « parameters » in einem DeviceFeature sein, das angeben würde, ob ein DeviceFeature ein Parameter oder eine echte Funktion ist.

[pierre-gilles]

Hallo zusammen!

Ich setze meine Überlegungen fort, diesmal zum Code-Stil, den der Skript-/Sicht- und Kern- sowie die Module haben werden.

1/ Erster Ansatz, sehr objektorientiert:

Eine Vorrichtung steuern:

const kitchenLight = await gladys.device.findOneBySelector('kitchen-main-light');
await kitchenLight.turnOn();
await kitchenLight.setBrightness(10);
await gladys.helpers.wait(100);
await kitchenLight.setBrightness(20);

Eine Gruppe von Vorrichtungen steuern:

const kitchenLightGroup = await gladys.device.find('kitchen.light'); // ROOM_SELECTOR.CATEGORY
await kitchenLightGroup.turnOn();
await kitchenLightGroup.addBrightness(10);

2/ Zweiter Ansatz, mehr funktional, wie wir es derzeit haben:

await gladys.device.turnOn('kitchen-main-light');
await gladys.device.setBrightness('kitchen-main-light', 10);
await gladys.helpers.wait(100);
await gladys.device.setBrightness('kitchen-main-light', 20);

await gladys.device.turnOn('kitchen.light');
await gladys.device.addBrightness('kitchen.light', 10);

Kleine Analyse

Die beiden Ansätze sind sehr unterschiedlich und haben sehr unterschiedliche Auswirkungen.

1/ Im ersten Fall müssen nach dem Empfang der Daten aus der Datenbank diese Objekte in Abhängigkeit von jeder Kategorie von Vorrichtungen erstellt werden, und diese gesamte Objektschicht hinzugefügt werden. Das ist ziemlich ähnlich dem Ansatz, den du in diesem Channel @piznel mit dem abstract-things-Repo gemacht hast.

Ich mag das visuelle Ergebnis, es sieht sauber aus und ist ziemlich sexy, um Entwickler anzulocken. Also aus Sicht der Syntax und Kommunikation ist das für mich ein Pluspunkt.

Meine Sorge ist, dass wir diese Logik an vielen Stellen erweitern wollen, und das kann eine Belastung sein, wo wir lieber eine leichte und einfach zu bedienende Software hätten. Ich bin nicht überzeugt, dass ein objektorientierter Ansatz in einem Backend Sinn macht. Für mich ist ein Backend vor allem ein Bridge, der CRUD zwischen der DB und dem Frontend durchführt, es ist nicht unbedingt notwendig, Objekte zu erstellen, die schwer im Speicher sein können und eine Entwicklungskomplexität mit sich bringen.

2/ Mir gefällt das visuelle Ergebnis weniger, es ist weniger sexy, das ist sicher.

Aber wir wissen genau, was passiert, und in Bezug auf das Speichermanagement ist die Arbeit dem Kern überlassen: wir rufen die Funktion auf, die Funktion erledigt ihre Arbeit, und das war’s.

Fazit

Ich weiß nicht, ob es eine Wahl zwischen dem einen oder dem anderen ist, wir können einen hybriden Ansatz haben.

Ich würde gerne eure Meinung hören, das ist eindeutig eine nette kleine Diskussion

[pierre-gilles]

Mmm, aber damit bin ich nicht einverstanden, wir würden zu spezialisierte und redundante Informationen speichern.

1/

light_dimmable: Ich verstehe den Sinn dahinter nicht. Du speicherst zwei Informationen in einem Feld: dass es sich um ein Gerät handelt, das Licht steuert + dass dieses Gerät dimmbar ist. Dazu verweise ich dich auf die funktionalen Abhängigkeiten in einer Datenbank

Wenn ich Gladys frage „Schalte das Licht im Wohnzimmer ein“, muss Gladys eine Möglichkeit haben, alle Geräte zu identifizieren, die Licht steuern (ob dimmbar oder nicht, ist hier nebensächlich, das ist eine sekundäre Information).

2/ Andererseits ist die Frage, die Kategorie auf das Gerät zu übertragen, eine echte Frage. Derzeit ist sie in DeviceFeature, weil einige Geräte (ich denke dabei besonders an Z-Wave) so ziemlich alles können, und wir haben die Kategorie im deviceType platziert, um diese „hybriden“ Geräte zu verwalten.

Dann stellt sich die Frage. Wenn du eine Überwachungskamera hast, die auch einen Temperatursensor und einen Bewegungssensor hat? Wenn du eine Tür hast, die auch Temperatur- und Feuchtigkeitsdaten übermittelt? Wie klassifizieren wir sie?

Wenn ihr Beispiele für seltsame Geräte habt, bin ich interessiert!

Persönlich bin ich dafür, die Kategorie auf das Gerät zu übertragen, das ist klarer.

[pierre-gilles]

Ich denke, das Beste, um das alles zu definieren, ist es, echte Fälle zu betrachten!

@piznel

Die Xiaomi-Gateway, die auch als Lichtsonde, Bewegungsmelder, HP und Licht fungiert!

Ausgezeichneter Fall!

Also, welche Kategorie hätte dieses Gerät, wenn wir davon ausgehen, dass wir die Kategorie im Gerät nach oben übertragen?

1/ Ich bin nicht begeistert davon, ein Gerät in drei Geräte aufzuteilen, das ist nicht logisch nach unserer Definition « ein Gerät ist ein physisches Gerät ».

2/ Wenn wir ihm zum Beispiel die Kategorie « bridge » zuweisen.

Ein DeviceFeature vom Typ « binary » hat keinen Sinn mehr: Geht es darum, das Gateway ein- und auszuschalten (ein/aus?) oder das Licht des Gateways?

Also kommen wir wieder zum Punkt, dass wir auf der Seite von DeviceFeature eine zusätzliche Kategorie hinzufügen müssen, um zu sagen « dieses Feature ist die Lichtsteuerung ».

PS: Als ich sagte, dass der Modellierungsteil 80% der Arbeit ausmacht, habe ich das nicht scherzhaft gemeint Der Code ist nichts!

[Albenss]

Zu den „seltsamen“ Peripheriegeräten gehört auch der Fibaro FGMS-001 (in Z-Wave), der als Bewegungsmelder, Temperatursensor, Helligkeitssensor und Vibrationssensor fungiert, glaube ich

[pierre-gilles]

Mmm ok

Schade, ich mochte die Idee, die Kategorie auf dem Gerät zu platzieren, aber das schränkt uns zu sehr ein..

Also sind wir uns einig, dass wir die Kategorie + den Typ auf dem DeviceFeature behalten?

Ich gebe zu, dass ich beim Benennen „Typ“ besser finde als „Unterkategorie“.

Ich bin einverstanden, dass es cool ist, feinere Typen zu haben!

Also statt:

• binary
• multilevel
• color

hätten wir reichhaltigere Typen:

• binary
• brightness
• temperature
• color

wie in meinem obigen Schema! Kleine Erinnerung:

[pierre-gilles]

Ein weiterer Punkt, über den wir nicht gesprochen haben, sind die berühmten Parameter der Geräte/Gerätefunktionen!

Z-Wave hat Parameter pro Gerät, und derzeit sind diese mit den Gerätefunktionen vermischt (nicht ideal).

Man könnte ein Attribut in der Gerätefunktion hinzufügen, um anzugeben, dass die Funktion ein Parameter ist.

Problem: Wenn der Parameter ein String ist, was macht man dann?

Beispiel: Wenn man die URL einer Kamera in Device/DeviceFeature speichern möchte, zum Beispiel.

Das könnte eine andere Tabelle sein…

Andere Idee, die nichts damit zu tun hat: Ein Boolean in DeviceFeature einfügen, um die Historisierung der Werte zu aktivieren oder nicht (sehr praktisch für bestimmte Sensoren, die Werte senden und deren Werte nicht unbedingt historisiert werden sollen).

(ich dump meine Ideen einfach so).

[pierre-gilles]

Kleine Modellierung, wie das aussehen könnte:

[pierre-gilles]

@piznel

JSON in einem Parameterfeld? Das könnte auch für andere nützlich sein.

Daran habe ich auch gedacht, aber das funktioniert nicht im Fall von z-wave! Es sendet die Parameter einzeln, als wären es Features, und man müsste einen aufwendigen Vorgang durchführen:

• Device auswählen
• JSON-Wert hinzufügen
• Device aktualisieren

Während es hier in einem Vorgang erledigt ist!

Und vor allem bevorzuge ich den relationalen Aspekt für alles, was Entwicklern ausgesetzt ist, es muss strikt in der DB sein, sonst ist es in 30 Sekunden ein Chaos ^^

Die wenigen Stellen, an denen wir JSON in der Gladys-DB verwenden, sind aus sehr spezifischen Gründen!

[VonOx]

Ich habe nicht so viele Meinungen, da ich nicht viel Erfahrung mit so etwas habe, aber eure Überlegungen sind sehr interessant, Leute.

[pierre-gilles]

Heute Morgen habe ich viel an dem Thema der „Module“, die in Gladys 4 zu „Diensten“ werden, gearbeitet.

Ich habe eine Dokumentation geschrieben und einen Dienst example von vorne bis hinten (inklusive Tests) codiert, um zu zeigen, wie ein Dienst in Gladys 4 aussieht.

Das ist nur ein erster Entwurf, ich werde sicherlich Änderungen vornehmen, basierend auf eurem Feedback

Das README und der Code sind hier verfügbar =>

https://github.com/GladysAssistant/gladys-4-playground/tree/master/server/services/example

@VonOx

Ich habe nicht viel zu sagen, da ich nicht viel Erfahrung in dem Bereich habe, aber eure Überlegungen sind sehr interessant, Jungs.

Danke @VonOx!

[pierre-gilles]

Also, ich bin in den Wireframe-Modus gewechselt und habe am Onboarding-Prozess gearbeitet.

Bisher habe ich 6 Schritte identifiziert:

1/ Willkommen: Gladys begrüßt den Nutzer. Eine kurze Erinnerung an die Philosophie des Projekts, die Werte und die Geschichte.

2/ Erstellung des lokalen Kontos: Name, E-Mail, Passwort & Passwortwiederholung

3/ Konfiguration des Wohnraums: Registrierung des Hausnamens und Hinzufügen der Räume

4/ Hinzufügen von Geräten: Der Nutzer fügt seine Geräte hinzu. Er hat eine Suchleiste und kann die Integrationen auswählen, die er konfigurieren möchte. (Optional)

5/ Konfiguration der Benachrichtigungen: Um mit Gladys in Kontakt zu bleiben, schlägt Gladys vor, die Kommunikationsdienste zu konfigurieren: Telegram, SMS free, etc.. (Optional)

6/ Verbindung zum Gladys Gateway-Konto: Vorstellung des Gateways und Verbindung. (Optional)

Wenn ihr noch andere Schritte einfallen, zögert nicht!

[pierre-gilles]

Hallo zusammen!

Ich hoffe, ihr hattet ein schönes Wochenende.

Gestern und heute Morgen habe ich an der Definition der Zustände / Zustandsübergänge gearbeitet. Das mag ein einfaches Thema erscheinen, aber es ist eine echte Überlegung.

Jede Entität in Gladys ist ein endlicher Automat mit mehreren Zuständen und Übergängen zwischen diesen Zuständen. Diese Zustände und Übergänge müssen definiert und benannt werden.

Der Schlaf eines Benutzers

4 Zustände:

• Wach
• Schlafend
• Soll aufstehen
• Soll schlafen gehen

Hier ist das Schema der Übergänge. Jeder Übergang entspricht einem Ereignis in Gladys, einem « Trigger », an dem jede Szene anknüpfen kann.

Der Hausalarm

In Gladys 4 führe ich den Begriff des Alarms für das Haus ein, damit Gladys endlich eine klare und saubere Alarmanlage sein kann.

Wie beim Schlaf, 4 Zustände:

• Aktiviert
• Deaktiviert
• Versuch der Aktivierung
• Versuch der Deaktivierung

Die Anwesenheit der Benutzer im Haus

Die Ausführung einer Szene

Der Zustand der Sonne

Die Anwesenheit bei der Arbeit

**Schließlich ein Beispiel für ein Gerät der Kategorie « light »

[VonOx]

Ja, du sprichst von Szenarien, die Graphen sind der Flow zwischen den Zuständen.

Und es gibt tatsächlich den Zustand „bewaffnet“ für den Alarm.

[pierre-gilles]

@Jap93

Wie verwaltest du den Zustand „Alarm aktiviert“ nach einer Erkennung? Braucht man nicht auch einen Zustand „Alarm aktiviert“?
Aktiviert/deaktiviert der Zustand „Eintritt/Austritt“ des Hauses automatisch die Alarmanlage oder muss man ein Szenario verwenden?
Bisher sehe ich nur das, weil du an viele Fälle gedacht hast

Tatsächlich habe ich in diesem Diagramm angenommen, dass der Teil „Aktivierung“ der Alarmanlage eher auf der Szenario-Seite liegt. Aber ich denke, du hast recht, es wäre sinnvoll, es dort zu platzieren, zumindest um die Namen der verschiedenen Übergänge zu definieren

Danke für das Feedback!

[pierre-gilles]

Hallo zusammen!

Heute richtig viel Arbeit am Frontend, ich bin mitten im Thema

Hier ein kleiner Vorschau, ihr habt Feedback/Ideen zur Organisation der Navigationsleiste? Ich bin offen für Vorschläge!

Für den Login zögere ich zwischen zwei Versionen…

Sagt mir, was ihr davon haltet!

[Hamtaro]

Mit Logo für den Login für mich.
Übrigens, benennst du Gladys Assistant auch im Dashboard um?

[pierre-gilles]

@Hamtaro

Mit Logo für den Login für mich.

Ich denke, ich werde mich dafür entscheiden, auf Twitter ist sich jeder einig

@Hamtaro

Übrigens, benennst du Gladys Assistant auch im Dashboard um?

Gut beobachtet!

Neue Seite, die Integrationen:

@piznel

Ich arbeite gerade an einem Homekit-Modul.

Hallo @piznel! Super alles!

@piznel

Ich sehe nicht genau, was die Parameter pro Funktion von Zwave sind. Hast du ein Beispiel?

Jedes Z-Wave-Gerät hat Parameter (z. B. Aktualisierungsfrequenz, Helligkeitssensorempfindlichkeit, Erkennungsgrenze eines Eindringlings usw.), die du einstellen kannst. Ich habe einen DeviceParam vorgeschlagen, um diese Parameter zu speichern, die für mich keine echten Funktionen sind, sondern Parameter.

Dieser DeviceParam könnte auch verwendet werden, um andere Dinge zu speichern, z. B. die Anmeldeinformationen einer IP-Kamera oder Ähnliches.

Verstehst du die Idee?

@piznel

Ich habe eine Excel-Tabelle erstellt, die alle Homekit-Dienste und Merkmale enthält.

Jetzt ist Philippe die Maschine wieder da

@piznel

Das scheint mir eine gute Grundlage zu sein. Was denkst du?

Das kommt dem, was wir besprochen haben, doch recht nahe, oder? Eine Kategorie plus ein Typ?

Abgesehen von einigen Unterschieden in der Benennung ist die Idee dieselbe!

@piznel

Ich denke, es wäre gut, jede Eigenschaft der Kategorien zu definieren; das würde auch die Anzeige standardisieren; im obigen Beispiel kann der Farbauswahl nicht mit dem Milight-Modul funktionieren.

Ich bin zu 100 % dafür, zu harmonisieren!

Wir müssen eine Wahl treffen, die möglichst viele Informationen abdeckt, um keine Informationen über Geräte zu verlieren, die feine Werte ermöglichen, und wir müssen die Farbe konvertieren, bevor wir sie in Gladys speichern.

@piznel

0 bis 65535 für das Hue-Modul,

Das Hue-Modul ist kompliziert, du hast 3 Gerätetypen: Hue und Sättigung und Helligkeit, das ist HSL, wenn ich mich nicht irre.

Milight habe ich den Eindruck, dass sie RGBV machen, aber es gibt Umwandlungsfunktionen HSL in diesem Modul zum Beispiel => https://www.npmjs.com/package/node-milight-promise (schnelle Suche)

Es liegt an uns zu entscheiden, welches Format wir in Gladys bevorzugen, und die verschiedenen Getter/Setter in Gladys 4 zu codieren, damit das Modul einfach seine Daten senden kann