Lassen Sie uns über Gladys V4 sprechen

Ich speichere am Ende nicht die Stadt :slight_smile:

Nur das Land + die Region. Das ist übrigens sehr, sehr ungenau, da es nur auf der IP basiert. Ehrlich gesagt, in Bali liegt es etwa 1200 km daneben…

Und um das noch mehr zu verfälschen, runde ich die gegebene Breiten-/Längengradzahl auf die nächste ganze Zahl (die ohnehin schon falsch ist), sodass ich am Ende eine Genauigkeit von plus/minus 100 km auf dem bereits ungenauen Punkt habe.

Also… das Ergebnis ist wirklich ungenau und niemand kann etwas damit anfangen :face_with_tongue: Wenn ihr wollt, können wir uns ansehen, was das System mit euren IPs findet, und überprüfen, ob das System wirklich so ungenau ist, wie gewünscht!

Ja, das ist keine schlechte Idee! Vor allem, wenn wir wollen, dass alle vernetzten Geräte sich mit unserem Service verbinden, ist es notwendig, entweder einen DHCP auf dem Raspberry Pi einzurichten, der die Box ersetzt, oder den DHCP der Box so zu konfigurieren, dass er auf den pi-hole weiterleitet.

Kannst du mit Gladys einfach einen Docker starten?

Ja, @pierre-gilles hat ein Node.js-Paket gefunden, mit dem man den Daemon steuern kann.

Super! Warum nicht? Ich würde gerne diesen Teil anschauen, wenn Sie möchten! Es interessiert mich, nicht von den Chinesen ausspioniert zu werden :smiley:

Übrigens habe ich gesehen, dass Pi-Hole den DHCP verwaltet, also könnte man es potenziell alles erledigen lassen.

Pi-hole nutze ich zu Hause, ich sehe nicht, was es da zu „smartifizieren“ gibt, einmal installiert und konfiguriert, vergisst du es einfach.

Was möchtest du im Vergleich zu Gladys?

Ich habe Angst, dass wir am Ende Pi-hole-Support machen.

Achtung, in diesem Fall, wenn der Raspberry abstürzt oder nicht mehr antwortet, hat kein Gerät mehr Zugriff auf das Netzwerk.
Der RPI wird zu einem SPOF (Single Point of Failure): Wenn er abstürzt, hat das große Konsequenzen.

Die Idee ist, die Anfragen von vernetzten Geräten nach außen einfach zu begrenzen.

In diesem Fall muss man ohnehin Änderungen an der Box-Konfiguration vornehmen, die logischerweise von einem Benutzer durchgeführt werden sollten, der sich damit auskennt. Das ist ein Anwendungsfall, der nicht zwangsläufig umgesetzt werden muss.

Das ist klar und könnte ein Diskussionsthema oder sogar ein Tutorial sein, denn so wie es aussieht, wird das den Gladys-Thread nicht gerade bereichern…

Keine Ahnung, ob das für jemanden relevant ist, aber ich habe seit dem Wechsel zu CircleCI für Branch-Builds ein paar Probleme mit CodeCov…

Auf master funktioniert die Abdeckung durch codecov problemlos, aber nicht auf den Branches/PRs, wo ich eine Fehlermeldung bekomme:

Dabei scheint alles in Ordnung zu sein, der Upload der Coverage-Datei im .lcov-Format scheint auf dem CI okay zu sein.

Es sind schon mehrere Tage vergangen, und ich komme nicht weiter. Falls jemand einen Tipp hat… !

(vielleicht brauche ich einfach nur ein Wochenende :joy: )

Am Samstag habe ich an der Systemverwaltungsoberfläche gearbeitet.

Bisher ist es noch etwas simpel, keine RAM-Nutzungskurven oder CPU-Temperaturanzeigen, aber das kommt als nächstes :slight_smile: Behalten wir die Grundlagen für diese Alpha-Version bei.

Der Reiter „Container“ rechts ist optional und wird nur angezeigt, wenn der Benutzer Gladys in Docker ausführt.

Super!
Von meiner Seite aus beginnt der Bluetooth-Dienst langsam funktionell zu werden, aber mir fehlen noch ein paar Infos:

  • bereits existierende Geräte hochladen
  • wird ein Gerät wie zuvor einem Benutzer zugeordnet?
  • was ist der Ersatz für checkUserPresence?

Ich versuche, eine einfache Gerätekonfigurationsseite für den Benutzer zu erstellen.

Aber die Zeit wird knapp :frowning:

Toll! Gute Arbeit :slight_smile:

Bisher habe ich noch nicht über diesen Aspekt nachgedacht :thinking:

Wenn ich jetzt darüber nachdenke, wollen wir eigentlich Folgendes haben:

  • Wenn ein Gerät in einer Wohnung gesehen wird, dann den Benutzer als „gesehen“ in der Wohnung markieren.
  • Ein Benutzer kann mehrere Geräte haben.
  • Ein Gerät gehört nur einem Benutzer (sonst ergibt das keinen Sinn).

Die Modellierung, die wir bisher in Gladys 3 hatten, ist also eher logisch. (ein Attribut in der Device-Tabelle).

Allerdings denke ich, dass wir diesem Attribut einen besseren Namen geben sollten und es vor allem in der UI ganz anders darstellen sollten, in Gladys 3 war es wirklich nicht klar. Für mich muss es in der UI eine eigene kleine UI geben, die sich speziell mit der Anwesenheitserkennung befasst.

Das Attribut in der Device-Tabelle könnte presence_detection_user_id sein (ist nicht verrückt, wenn jemand eine bessere Idee hat..)

Wir könnten zum Beispiel einen Dienst „Anwesenheitserkennung“ erstellen, der klar erklärt:

"Einige Geräte haben die Möglichkeit, erkannt zu werden, wenn sie bei Ihnen zu Hause sind: über einen Bluetooth-Scan, einen Wi-Fi-Netzwerk-Scan oder über ihre Geolokalisierung. Gladys kann diese Informationen verwenden, um abzuleiten, ob Sie zu Hause sind oder im Gegenteil abwesend.

Wenn Sie möchten, dass Gladys die Erkennung bestimmter Geräte verwendet, um Sie als zu Hause anwesend zu markieren, müssen Sie Gladys die Geräte angeben, die sie verwenden kann, um Sie zu erkennen.

Beispiel: Wenn Sie einen Bluetooth-Schlüsselanhänger an Ihren Schlüsseln hängen haben, können Sie diesen Schlüsselanhänger mit Ihrem Benutzer verknüpfen, und wenn er per Bluetooth zu Hause gesehen wird, werden Sie als „anwesend“ markiert. Nach einer bestimmten Zeit, wenn das Gerät von Gladys nicht mehr erkannt wird, werden Sie als „abwesend“ markiert.

Wählen Sie die Geräte aus, die Gladys verwenden kann, um Sie zu erkennen:

[Liste mit Kontrollkästchen der Geräte mit einem DeviceFeature der Anwesenheit, die Informationen zurückgemeldet hat + Angabe der letzten zurückgemeldeten Information + Sortierung der Liste nach der neuesten zurückgemeldeten Information].

Beispiel:

  • :ballot_box_with_check: Fitbit Charge 2 (vor 2 Minuten gesehen)
  • :ballot_box_with_check: Nut Mini (vor 12 Minuten gesehen)

Gladys kann Sie automatisch als abwesend markieren, wenn diese Geräte nach einer bestimmten Zeit nicht erkannt werden.

Automatische Abwesenheitserkennung aktivieren :ballot_box_with_check: (standardmäßig deaktiviert)
Verzögerung vor Abwesenheit: 15 Minuten (Select-Box mit 4-5 Optionen, z. B. 5, 10, 15, 30, 45)

"
Auf Entwicklungsebene

Zusammengefasst:

  • Ein Attribut in der Tabelle « t_device », z. B. presence_detection_user_id, nullbar und Fremdschlüssel auf t_user.id.
  • Eine neue Kategorie von device_feature, die angibt, dass es sich um ein device_feature der « Anwesenheit » eines Geräts handelt. Beispiel: { category: « detection », type: « push », min: 1, max: 1 }
  • Eine API-Route zum GET von Geräten, gefiltert nach Kategorie.
  • Eine API-Route zum PATCH von Geräten.
  • Zwei Variablen in der DB, z. B. « ABSENCE_DETECTION_ENABLED » und « ABSENCE_DETECTION_TIMEOUT ».
  • Eine Aufgabe im Scheduler (noch nicht entwickelt) von Gladys 4, um die mögliche Abwesenheit eines Benutzers zu überprüfen. Wenn wir alles im RAM machen (wie es oft in Gladys 4 der Fall ist), sollte ein Durchgang alle Minuten kein Problem darstellen.

Was denkst du? :smiley:

Ich bin nicht so begeistert von dem „user_id“ im Gerät, aber es scheint trotzdem ganz logisch.
Jetzt für den Rest, das betrifft nicht die Entwickler des „device“-Dienstes, also können wir uns Zeit nehmen, darüber nachzudenken.
Ich bin eher mit deinen Vorschlägen einverstanden, außer vielleicht bei den 2 Variablen in der DB, ich denke, wir brauchen sie als Standardwert, aber auch die Möglichkeit, den „timeout“ pro Gerät zu haben, und dann zu sagen, wenn der Nutzer nach einer Minute nicht sichtbar ist, oder wenn mein Telefon nach 5 Minuten nicht mehr über WLAN sichtbar ist, dann bin ich weg.

Ich stimme zu. Aber in Bezug auf die Modellierung sehe ich nicht wirklich andere Lösungen.

Ich stimme zu, aber ich denke, man sollte sie auch ändern können. Die Möglichkeit, die automatische Abwesenheit zu deaktivieren, ist entscheidend!

Ist das nicht viel ein Timeout pro Gerät? Man kann das in « t_device_param » speichern, sonst.

Hallo zusammen,
Etwas Verspätung bei der Migration von CalDAV… Entschuldigung… Ich habe einen Anfang eines Codes basierend auf dem der v3, aber ich stoße auf ein Problem und Hilfe wäre willkommen (noch mitten in der Entdeckung der Architektur der v4). Früher konnte man die Konfiguration jedes Benutzers identifizieren (im Modul google der v3 zum Beispiel) dank der Benutzervariablen, heute haben wir nur noch „klassische“ Variablen. Sie können mit einem Dienst verbunden sein, aber nicht mit einem Benutzer (was mir für diesen Art von Dienst, der mit einem Konto verbunden ist, jedoch obligatorisch erscheint). @pierre-gilles vielleicht hattest du eine Vorstellung davon, als du die neue Architektur implementiert hast?

Hallo!

Was ich mir bisher dachte, ist, dass alles, was eine Benutzervariable ist, einfach in die Tabelle t_user kommt. Schau dir zum Beispiel die Telegram-Chat-ID an, ich speichere sie in der Benutzertabelle.

Ich denke, dass es, angesichts der wenigen Benutzervariablen, übertrieben wäre, es wie in der v3 zu machen. Es ist ein « Zuviel an Sauberkeit », würde ich sagen, das außerdem im Gebrauch weniger performant ist ^^

Sag mir, was du davon hältst!

Danke, ich hatte nicht an Telegram gedacht. Wenn ich das also richtig verstehe, darf ich t_user ändern? Dann mache ich es so.
Genau da bin ich mir nicht sicher, ob ich dir folge. Es macht mir überhaupt nichts aus, es auf diese Weise zu tun, besonders wie du sagst, angesichts der Anzahl der Module, die die Benutzervariablen verwenden, aber wäre es auf lange Sicht nicht störend, ein t_user zu haben, das sich in Parametern verlängert? Und wäre es nicht einfacher für die Architektur, in der Tabelle t_variable eine user_id (die null sein kann) zu haben.

Meiner Meinung nach wirst du es nicht rechtzeitig schaffen, die Alpha am 26. Juni zu veröffentlichen, du wirst 24 Stunden zu spät dran sein.
Dann kommt sie am Tag meines Geburtstags raus!!! :crazy_face: :birthday: