Mehrbenutzer

Mit den jüngsten riesigen Fortschritten von @pierre-gilles und allen Entwicklern seit der Rückkehr aus dem Urlaub ist Gladys V4 fast bereit für die Release Candidate. Das einzige echte Manko für mich für eine vollständige Nutzung zu Hause (ich spreche also für die Nutzer im Haushalt) ist die Mehrfachkonten-Funktion und damit die personalisierte Konfiguration des Dashboards für jeden.

Da die V4 fast voll funktionsfähig ist (außer für die Barriere) führt dieses Manko zu Spannungen (glücklicherweise nur geringfügigen ^^) zu Hause, um zu entscheiden:

  • welche Kamera zuerst anzeigen,
  • welches Gerät und in welcher Reihenfolge,
  • usw.

Was übrigens sehr gut ist, denn es bedeutet, dass sich Madame voll und ganz dafür interessiert.

Allerdings ist es auf der professionellen Seite für unsere Gesundheitsdienstleister unbrauchbar, solange diese Funktion nicht vorhanden ist. Daher halte ich einen Fuß in der V3, um auch die Modi zu verwalten.

@Terdious Sehr interessant, deine Rückmeldung, denn das, was du als Bedarf ausdrückst, ist nicht, dass dir der Multi-User-Modus fehlt, sondern dass dir der Multi-Dashboard-Modus fehlt!

Für mich sind das zwei verschiedene Dinge, die wir zwar umsetzen werden, aber wir müssen priorisieren.

Könntest du eine andere Karte für den Multi-Dashboard-Modus erstellen und dort über deinen Anwendungsfall sprechen? :slight_smile:

Ah … dann habe ich wohl die Sache falsch verstanden, denn für mich sind das auch zwei verschiedene Dinge, aber ich spreche tatsächlich über Multi-User.

  • Multi-Dashboard, zumindest wie ich es verstanden und erwartet habe, bedeutet, dass jeder Benutzer mehrere konfigurierbare Dashboards hat.
  • Multi-User bedeutet, wie in Gladys V3, dass jeder sich mit seiner E-Mail-Adresse oder seinem Benutzernamen anmelden kann und seine eigenen Dashboards, Szenen, Kalender und Owntracks hat. Aktuell ist das sein Haupt-Dashboard.
Aktuell sieht es in der v3 so aus:

Und jeder Profi meldet sich bei seinem Konto an, für das ich das Dashboard mit den notwendigen Elementen vorkonfiguriert habe. Am Ende dachte ich, dass man dafür kein Multi-Dashboard braucht;

Ich dachte, in der DB

image

[details=" In der Spalte selector kannst du den Benutzernamen und « _main » (hier « thomas_main ») eintragen"]
image|690x175
[/details]
Damit bleibt noch Platz, um Multi-Dashboard zu definieren.

Natürlich, ich wollte das auch tun, hatte aber heute Morgen keine Zeit dafür ^^ denn das interessiert mich persönlich auch ^^

Mmm okay. Dein Anwendungsfall ist wirklich sehr, sehr besonders, wie ich nochmal erwähne :smiley: Aber wir müssen ihn berücksichtigen, ohne die Sache für die Mehrheit, die in einer einfachen Situation ist, zu sehr zu verkomplizieren.

Meine Vision für die v4 war es, zu vereinfachen, zu vereinfachen, zu vereinfachen. Bei der v3 war alles „pro Benutzer“, und ehrlich gesagt war das zu komplex. Gladys ist ein Produkt, das die große Mehrheit „in einem Vertrauenskreis“ installiert, ich wollte also die Falle der Over-Engineering von Berechtigungsregeln vermeiden.

Für die Dashboards wurde die Dashboard-Funktion bisher im Modus „öffentlich“ konzipiert. Es kann mehrere Dashboards geben, die für alle sichtbar sind.

Darüber müssen wir diskutieren (vielleicht in einem Gemeinschaftsanruf mit mehreren?), ich frage mich, ob wir entweder:

  • Die Dashboards persönlich machen
  • Oder die Dashboards öffentlich lassen und jeder kann sein Standard-Dashboard auswählen.

Bonjour @pierre-gilles,

Tatsächlich denke ich, dass es interessant sein könnte, einen Gemeinschaftsanruf abzuhalten, bei dem dieser spezifische Punkt integriert wird. Vielleicht könntest du aber einen Thread erstellen, um diesen vorzubereiten, mit dem Ziel, mehrere Themen zusammenzufassen. Ich bin auf meiner Seite sehr an diesen Anrufen interessiert ^^ Hättest du die Zeit, diese wieder regelmäßig zu planen?

Tatsächlich ist dieser sehr spezifische Fall (ich meine Gesundheitsfachleute) sehr besonders. Aber das war nur ein Beispiel für einen speziellen Fall, um zu zeigen, dass jeder solche haben kann, und dass, wenn Gladys es schaffen kann, diese Flexibilität zu verwalten, während sie eine einfache Möglichkeit bietet, dies zu konfigurieren, das für viele interessant sein könnte.

Ich bin voll und ganz damit einverstanden, und das schon von Anfang an, mit der Vision und dem Aufbau, den du für Gladys hast. Aber vor allem mit der zu verfolgenden Linie und insbesondere der Dokumentation, die nach und nach zu einem der wichtigsten Punkte wird. Aber meiner Meinung nach sollte das nicht verhindern, dass man etwas präzisere Dinge verwaltet. Denn in diesem Fall schließt man einen großen Teil der Bevölkerung aus. Und immer meiner Meinung nach, selbst in einem « Vertrauenskreis », sollte man dem Benutzer nicht « verbieten », weiter zu gehen.

Ich bleibe beim Fall des Multi-User und erlaube mir zwei Beispiele:

  1. Ich bin ein normaler Benutzer, ich nutze Gladys allein oder als Paar
    Voraussetzung: Auf der DEV-Seite einen « Szene-Typ » eingerichtet haben, der « Haupt » oder « Benutzerkonto » im DB + in der Tabelle « t_scene » eine Spalte « Szene-Typ » hinzugefügt haben oder die Spalte Selector automatisiert haben, um den Szene-Typ zu integrieren.

    Ich kann:

  • entweder mein Konto (Admin von Grund auf) erstellen, meinem/ meiner Partner(in) den Zugriff gewähren und wir teilen alles. Nichts weiter zu konfigurieren im Vergleich zu heute. Wenn ich eine Szene erstelle, wird sie auf jeden Fall als « Haupt » erstellt
  • oder 2 Konten erstellen (Admin von Grund auf - nichts zusätzlich zu ändern im Vergleich zu jetzt, bei der Kontoerstellung wird der Admin-Typ standardmäßig vorgeschlagen), jeder hat sein eigenes Konto und:
    • konfiguriert sein Dashboard aus allen erstellten Geräten,
    • jeder konfiguriert seinen Kalender (verbunden mit seinem E-Mail-/Kalenderkonto),
    • jeder kann Szenen des Typs « Haupt » (Ablaufmenü beim Öffnen der Szenen, das die Typen « Haupt / Benutzerkonto [d. h. Berücksichtigung des Erstellers der Szene] » anbietet) erstellen und sehen/ändern, die auf der Entwicklerseite in einer neuen Spalte der DB definiert werden können oder « _main » oder « _benutzername » zum Selector hinzufügen, wenn man die DB nicht anpassen möchte.
    • jeder konfiguriert seine Szenen im Kalender (Nachrichten, die z. B. an das konfigurierte Telegram-Konto gesendet werden) vom Typ « Benutzerkonto ».
  1. Ich bin ein Benutzer, der sein Zuhause vollständig mit Smart Home ausstatten und die Sicherheit und die Einfachheit der Automatisierung nutzen möchte, die die Smart Home-Technologie bieten kann:
    Voraussetzung: Gleich wie 1. + Eine Tabelle « Benutzerkontotypen » erstellt haben + Eine Seite entwickelt haben, um diese « Benutzerkontotypen » zu definieren (auf einfache Weise, dies kann oben auf der Seite ein Feld sein, in das man den Namen des Kontotyps eingibt, mit einem « Neu »-Button und darunter die Liste der Kontotypen mit einem « Konfigurieren »-Button daneben) um zu definieren, was sie sehen/ändern können (z. B. alle Ansichten außer dem Dashboard verstecken; Haupt-Szenen verstecken, aber dem Benutzer ermöglichen, seine eigenen Szenen zu erstellen; usw.) alles auf einfache Weise (z. B. Kontrollkästchen) + Eine Spalte im t_device- oder t_device_feature-Tabellen der DB vom Typ multiple hinzufügen, um die Kontotypen definieren zu können, die darauf zugreifen können.

Also kann ich:

  • Mein Admin-Konto erstellen,

  • Ein Admin-Konto für meine Partnerin erstellen, identisch mit Punkt 1.

  • Einen Kontotyp « Jugendliche » erstellen, meine Tochter/mein Sohn ist 16 Jahre alt und kennt sich mit Smart Home aus, ich gebe ihr/ihm Zugriff auf die Ansichten Dashboard / Chat / Integrationen / Kalender / Maps / Szenen und lasse den Zugriff auf Integrationen nur vom Typ Kalender / Kommunikation zu. Für ihr/sein Dashboard lasse ich die Möglichkeit zu, das Wetter / die Anwesenheit des Benutzers im Haus / die Geräte der Gemeinschaftsräume und ihres/seines Zimmers, aber nicht unseres Zimmers oder der automatisierten Geräte / die Hauptkameras, aber nicht alle / ihre eigenen Szenen, aber nicht die als « Haupt » definierten Szenen anzuzeigen,

  • Einen Kontotyp « Kinder » erstellen, meine Tochter/mein Sohn ist 10 Jahre alt und beginnt mit Smart Home, ich gebe ihr/ihm Zugriff auf die Ansichten Dashboard / Chat / Maps. Für ihr/sein Dashboard lasse ich die Möglichkeit zu, das Wetter / die Anwesenheit des Benutzers im Haus / die Geräte der Gemeinschaftsräume, aber nicht den Fernseher und ihr/sein Zimmer, aber nicht unser Zimmer oder die automatisierten Geräte / die Kamera des Hühnergeheges z. B. aber nicht die anderen / ihre eigenen Szenen, aber nicht die als « Haupt » definierten Szenen anzuzeigen,

  • Einen Kontotyp « Vertrauenswürdige Gäste » erstellen, meine Freunde/meine Familie, die von Zeit zu Zeit vorbeikommen, möchten die Musik, den Fernseher oder eine Atmosphäre steuern, manchmal kommen sie ins Haus, um sich ein Werkzeug auszuleihen, aber ich bin nicht oft da, ich gebe ihnen Zugriff auf die Ansichten Dashboard / Szenen. Für ihr Dashboard lasse ich die Möglichkeit zu, das Wetter / keine Benutzerpräsenz / die Geräte des Wohnzimmers, des Außenbereichs und der Garage, insbesondere das Schloss der Tür dieses letzten Raums sowie die Barriere, aber nicht den Rest / keine Kameras / Szenen vom Typ « Haupt », aber ich verbiete ihnen, ihre eigenen Szenen zu definieren,

  • Einen Kontotyp « Haushaltshilfe » erstellen, ich habe eine Putzfrau, die einmal pro Woche am Dienstag zwischen 13 und 16 Uhr kommt, ich gebe ihr Zugriff nur auf die Ansicht Dashboard, die ich mit den Geräten der Barriere, dem elektronischen Schloss der Haustür, den Beleuchtungen des Hauses, der Musik und dem Wasserhahn der Küche, aber nichts anderem, definieren werde. Ich würde ihr Konto (z. B. über eine Szene?) am Dienstag ab 12 Uhr aktivieren und dieses Konto am selben Tag ab 19 Uhr (für den Fall, dass sie an einem Tag später fertig wird) deaktivieren,

  • Einen Kontotyp « Gartenpflege » erstellen, ich habe einen Gärtner, der dreimal pro Woche montags, mittwochs und freitags zwischen 17 und 18:30 Uhr kommt, ich gebe ihm Zugriff auf die Ansichten Dashboard / Szenen mit den Geräten: die Barriere, das elektronische Schloss der Garagentür und das der Gewächshaus (ja, da sind Werkzeuge drin ^^), die Beleuchtung der Garage, der Außenbereiche (für den Winter) und des Gewächshauses, die Außenmusik (das habe ich wirklich ^^), die Steckdose der Brunnenpumpe und die Wasserzufuhrventile für die Pferde, das Gewächshaus und die Außenpflanzen. Ich würde sein Konto an den entsprechenden Tagen ab 16:30 Uhr aktivieren und dieses Konto an denselben Tagen um 18:35 Uhr deaktivieren (ich möchte nicht, dass er an einem Tag länger arbeitet).Professionelle Beispiele
    Für @Shermi (auf Slack):

  • Erstellen Sie einen Kontotyp « Kunden », ich habe ein kleines Hotel mit 10 Zimmern und habe an jeder Tür ein Smart Lock installiert. Ich erstelle ein Benutzerkonto pro Zimmer und kann das Passwort jedes Kontos von meinem Admin-Konto aus ändern. Dank einer vorkonfigurierten Einstellung kann ich Szenen pro Zimmer erstellen, um Stimmungen zu steuern, auf die er über die Dashboard-Ansicht zugreifen kann, und ein Telegram-Konto referenzieren und die Ansicht der Integrationen deaktivieren. Ein Kunde bucht für die Woche, ich aktiviere das Konto für dieselbe Dauer und gebe das Benutzername/Passwort-Paar bei seiner Ankunft weiter, er hat über die vom Administrator konfigurierte Adresse https direkt Zugang zu seiner Zimmertür, zur Fernbedienung des Fernsehers und zu allem, was in seinem Zimmer smart gesteuert werden kann, sowie zum Starten der mit dem Konto (also dem Zimmer) verknüpften Szenen. Warum nicht auch über den Chat direkte Anfragen für die Bestellung seines Frühstücks, wobei er seine Zimmernummer angeben kann. Wenn sein Aufenthalt beendet ist, deaktiviere ich das Konto.

Für mich:

  • Erstellen Sie einen Kontotyp « Büro Nr. 1 », ich habe eine Arztpraxis, die von zwei Fachkräften geteilt wird, die unseren Eingangsportal teilen. Ich erstelle ein Benutzerkonto pro Fachkraft. Ich gebe ihnen Zugang zu den Ansichten Dashboard / Chat / Integrationen / Kalender / Karten / Szenen und lasse ihnen den Zugang zu den Integrationen nur vom Typ Kalender / Kommunikation. Für ihr Dashboard lasse ich ihnen die Möglichkeit, das Wetter / die Geräte des Portals, die Außenbeleuchtung, ihres Büros, des Wartezimmers und der Toiletten / die Kamera des Portals (Ankunft des Patienten an der Klingel = Sicherheit) / ihre eigenen Szenen, aber nicht die als « Haupt » definierten Szenen anzuzeigen. Ich kann somit auf jedem ihrer Konten in Verbindung mit ihrem Konto die Automatisierung der Beleuchtung und des Portals in Bezug auf ihre Arbeitszeiten über den Kalender konfigurieren,

  • Erstellen Sie einen Kontotyp « Campingplatz-Standort », in derselben Idee wie das Hotelbeispiel oben, um die Standorte unabhängig zu verwalten.

(All dies sind nur Beispiele für das, was in Betracht gezogen werden könnte, ich habe noch keine Kinder, aber angesichts dessen, was man im Forum in all diesen Jahren lesen konnte, kann ich mir die Anwendungsfälle für einige vorstellen)

Das war’s, entschuldige viele Beispiele, aber ich wollte lieber alles, was ich zu diesem Thema im Kopf hatte, besprechen. Und was die Benutzererfahrung betrifft, so ändert sich für Punkt 1. nichts im Vergleich zu heute. Alles würde automatisch in « Admin » erstellt werden, alle Optionen standardmäßig aktiviert, alle Geräte für alle Benutzer zugänglich und alle erstellten Szenen als « Haupt ». Die Konfiguration würde nur in Richtung down erfolgen. Es würde dann ausreichen, in der Benutzererstellungsansicht einen Link zur Dokumentation einzufügen (z. B. « Um mehr zu erfahren ») und dort zu erklären, wie man all das konfiguriert, und zwar nur, wenn man spezifische Konten konfigurieren möchte.

PS: Es ist klar, dass dies auf der Entwicklerseite Zeit in Anspruch nimmt, aber meiner Meinung nach wären die Möglichkeiten der vollständigen Smart-Home-Steuerung, aber auch die Mundpropaganda und die Demonstration enorm.

Hallo zusammen!

Ich habe gerade die Entwicklung der injizierten Variablen in den Szenen abgeschlossen und mache mich nun an eine der am häufigsten nachgefragten Funktionen :slight_smile:

Ich habe funktionale Spezifikationen erstellt und einige Screens entworfen und wollte eure Meinung dazu hören.

Funktionale Spezifikation

Als erster Benutzer einer Gladys-Instanz bin ich standardmäßig „Administrator“.

Dieser Benutzer hat die Möglichkeit, andere Benutzer, andere „Administratoren“ oder andere „Benutzer“ zu erstellen.

  • Administrator: Die Standardrolle des ersten Gladys-Benutzers, er hat alle Rechte.
  • Benutzer: Ein Benutzer hat eine eingeschränkte Rolle mit weniger Rechten. Ihm werden folgende Integrationen der Kategorie „Devices“ und „Weather“ verborgen und gesperrt: Alle Integrationen der Kategorie „Devices“ und „Weather“. Er kann die Integrationen „Telegram“ und „Caldav“ konfigurieren. Das „Settings“-Tab ist für ihn ausgeblendet.

Neuen Benutzer erstellen

Der Administrator geht zu „Settings“ => „Users“

Er kann einen Benutzer erstellen und ihm ein Passwort zuweisen. Da wir uns in einem Vertrauenskreis (der Familie) befinden und aus Gründen der Einfachheit der Konfiguration, ist es kein Problem, dass der Administrator das erste Passwort des Benutzers festlegt (der Benutzer kann dieses Passwort später ändern).


Benutzer bearbeiten

Bestehenden Benutzer bearbeiten

Jeder Administrator kann Benutzer bearbeiten, einschließlich anderer Administratoren. Er kann sowohl sein Profil als auch seine Einstellungen bearbeiten.

Benutzer löschen

Jeder Administrator kann einen Benutzer löschen. Ein Administrator kann sich selbst nicht löschen.

Sichtbarkeit der verschiedenen Daten

Die Dashboards

2 Arten von Dashboards:

  • Privat (nur für den Benutzer zugänglich, der es erstellt hat)
  • Gemeinsam genutzt (für alle Mitglieder der Gladys-Instanz zugänglich)

Jeder Benutzer hat ein privates „Standard“-Dashboard. Die Frage ist, ob die gemeinsam genutzten Dashboards in einem ersten Schritt überhaupt nötig sind…

Die Szenen

Zu besprechen: Die Szenen werden von der ganzen Familie geteilt. Jeder kann Szenen erstellen und die Szenen der anderen sehen.

Andere Möglichkeit: Die Szenen sind vollständig privat. Jede Person sieht nur ihre eigenen Szenen.

Chat

Das Gespräch mit Gladys ist zwischen dem Benutzer und Gladys. Es ist vollständig privat.

Sehr praktische Funktion!

Ich finde den Teil mit den Rechten eher unklar. Du blockierst die Integrationen (Konfiguration der Dienste), das ist okay, aber du kannst auch verhindern, dass eine Person auf bestimmte Informationen zugreift. Zum Beispiel Zugriff auf die Öffnung des Tors, Zugriff auf bestimmte Kameras, Zugriff auf einen verbundenen Safe usw.

Wie soll man diesen Teil also verwalten?

Ansonsten finde ich es gut.

Wollen wir das wirklich?

Das ist extrem aufwendig, es macht das Produkt in jeder Hinsicht komplizierter.

Nur zur Information: Selbst Apple macht das meines Wissens nicht in Homekit:

Ich schon :smiley:

Ich bin deiner Meinung, das ist sehr schwer. Aber wenn diese Funktion später gefordert wird, wird es ein Albtraum sein, sie zu integrieren …

Aber ich verstehe den Standpunkt :slight_smile:

Verstehe ich das richtig, wäre eine Liste von „blackgelisteten“ Geräten pro Benutzer ausreichend?

Beispiel:

Benutzer A darf das Gerät X nicht verwenden. Er sieht das Gerät nirgends und kann es nicht steuern.

Die Probleme, die ich sehe, sind:

  • Geteilte Dashboards: Was passiert, wenn du ein Dashboard mit jemandem teilst, dessen im Dashboard verwendetes Gerät blackgelistet ist?
  • Was ist mit Sprachbefehlen? Wenn ein Gerät für einen Benutzer blackgelistet ist, bedeutet das, dass es auch in den „öffentlichen, nicht authentifizierten“ Sprachsensoren des Hauses blackgelistet ist, da wir nicht wissen, wer spricht?
  • Szenen: Man muss sicherstellen, dass ein Benutzer keine Umgehungsmethode hat, um ein blackgelistetes Gerät zu steuern.
  • Alle zukünftigen Entwicklungen müssen diese Berechtigungen immer berücksichtigen.

Grundsätzlich bin ich nicht dagegen, aber ich habe das Gefühl, dass die Rechteverwaltung vor allem eine Utopie ist, die sich jeder so vorstellt wie „ich will alles kontrollieren“, und in der Realität ist es vor allem ein Wirrwarr, der die Produktnutzung und die Entwicklung doppelt so komplex macht.

Selbst Apple macht das nicht, ehrlich gesagt macht mir das Angst :sweat_smile: Sie haben Hunderte von Ingenieuren, die seit 2014 daran arbeiten, und selbst nach so vielen Jahren machen sie es nicht :stuck_out_tongue:

Ja, vollkommen! Für mich muss man die Möglichkeit haben, bestimmte Geräte nicht zu kontrollieren. Zum Beispiel hast du bei dir ein Smart Lock. Du hast Gäste, gibst ihnen Zugang zu Gladys. Du willst vielleicht nicht, dass diese Gäste deine Haustür entsperren. Ich sehe das so.

Blacklisten ist eine gute Idee und die Integration ist eher „einfach“.

Vielleicht haben sie nicht daran gedacht / es nicht für wichtig gehalten :slight_smile:

Hallo !!

Also da !! Damit habe ich nicht so schnell gerechnet !! Was für eine gute Nachricht.

Meine Meinung ist meiner Meinung nach nicht so wichtig, denn wir wissen jetzt alle, wofür ich Gladys verwenden möchte, und ich sollte nicht zu persönlich meine Interessen einbringen.

Trotzdem, auch wenn man den professionellen Aspekt etc. beiseite lässt, bin ich derselben Meinung wie @damalgos.

  1. Es gibt zwar die Gäste, aber nicht nur. Man kann schon mit den Kindern anfangen. Die Zugänglichkeit von Gladys und ihre Einfachheit (die ihr größter Vorteil ist und an dem du sehr hängst @pierre-gilles - und jetzt auch wir) können sehr schnell dazu führen, dass man zum Beispiel die Barriere integrieren kann, oder wie @damalgos sagt, das Dashboard für ein Kind. Aber auch die Steuerung der Heizung der Wohnung / des Hauses usw. usw. !! und so weiter.
  1. Aus Sicht des Administrators/Nutzers überhaupt nicht. Wir wollen etwas Einfaches, okay, und gut, es reicht, wenn es nur eine Möglichkeit und keine Verpflichtung ist. Mit deiner Idee, Geräte zu blacklisten, gibt es kein Problem. Der Nutzer, der diese Berechtigungsverwaltung nicht benötigt, berührt absolut nichts. Am Ende werden nur Entwickler wie wir etwas mehr Arbeit haben.
  1. Und nicht nur Apple, genauso bei Alexa (ich nutze sie, habe nichts Derartiges gefunden), trotzdem werfen viele Menschen das als Kritik auf. Aber sie machen auch nicht dasselbe Produkt wie Gladys, das wird meiner Meinung nach ein starkes Argument sein, das du gerade hervorheben kannst.

  2. Ja, man muss natürlich sehen, wohin das für die Verwaltung von Szenen usw. führt. Zunächst, wenn dieser Punkt der Rechte umgesetzt wird, wird es sich tatsächlich nur um Privates für die Dashboards und Szenen handeln. Dann bleibt nur noch, die Sperren entsprechend zu setzen. Auch für den Chat.

In jedem Fall finde ich, was du da vorstellst, ist schon sehr appetitlich ^^ Ich liebe es ^^

Meine Idee zu den Rechten (vielleicht eine schlechte Idee)

Eine Seite für den Benutzer mit den Rechten, die der Administrator erteilt oder nicht:

Szene:

  • Erlaubnis zum Erstellen einer Szene: ja/nein
  • Erlaubnis zum Löschen einer Szene: ja/nein
  • Erlaubnis zum Starten einer Szene: ja/nein
  • Erlaubnis zum Anzeigen der Szenen: ja/nein

Dashboard:

  • Erlaubnis zum Ändern des Dashboards: ja/nein
  • …

Integrationen:

  • Erlaubnis zum Hinzufügen einer Integration: ja/nein
  • Erlaubnis zum Löschen einer Integration: ja/nein
  • Erlaubnis zum Ändern einer Integration: ja/nein

Beim Erstellen einer Szene:

  • Erlaubnis zum Verwenden der Szene erteilt an: Benutzer
    Ein Beispiel in Bildform:

Ich mag die Idee sehr. Nur eine Sache: Wie kann ein Admin das Dashboard eines Nutzers konfigurieren, der dazu nicht berechtigt ist? Aber es ist die einfachste Lösung, die zudem die Entwicklung nicht beeinträchtigt.

Für mich kommt es darauf an, wer es nutzt:

  • meine Partnerin (Wetter, Heizung, Hausbeleuchtung, Innen- und Außenkameras)
  • mein Sohn (Musik, Licht in seinem Zimmer, Temperatur in seinem Zimmer, ohne die Heizung zu verändern)

Ich habe mich auf dieses Recht bezogen. Wenn dein Sohn keine Berechtigung hat, das Dashboard zu ändern (Kein Bearbeitungsbutton), müssen wir festlegen, wie wir dieses Dashboard ändern können.

Das ist ein Argument dagegen :stuck_out_tongue: Es ist keine Überraschung, dass Apple/Amazon Millionen von Nutzern für ihr Produkt haben: Es ist einfach und kommt auf den Punkt.

Wenn sie es nicht für wichtig halten, dann war es am Ende vielleicht nicht so wichtig, und es gab sicherlich wichtigere Funktionen, denen sie ihre Ressourcen gewidmet haben (und die haben sie, Ressourcen! :p)

Man sollte nicht vergessen, dass für jede Funktion, die wir entwickeln, eine Funktion ist, die wir nicht entwickeln.

Es ist einfach: Die Community hat abgestimmt, es ist eine der am meisten geforderten Funktionen, also mache ich diese Funktion :slight_smile: Wir kommen schrittweise voran in der Liste, das macht Spaß!

Trotzdem haben sie Millionen von Nutzern, also hat sich die Einfachheit ihrer Lösung ausgezahlt!

Oh je, eine Rechte-Matrix ist wirklich das, was ich vermeiden will. Aus Erfahrung in der Softwareentwicklung ist das einfach die Hölle (sowohl für die Nutzererfahrung als auch für den Entwickler)!

Okay, ich habe nachgedacht, und für mich sind das wirklich zwei verschiedene Themen: Multi-User und feines Rechtemanagement auf den Geräten.

Das ist immer etwas, das man später hinzufügen kann (es wird nicht komplizierter sein, es später hinzuzufügen).

Also meine Meinung:

  • Wir behalten die Funktion « Multi-User » allein, ohne Komplexität. Kein Rechtemanagement auf den Geräten, keine Blacklist. So vermeiden wir einen 3-Monats-Tunnel und können Multi-User + Multi-Dashboard schnell herausbringen.
  • Sobald wir Multi-User haben, erstellen wir eine Karte in « Feature Request » für die Geschichte der Geräte-Blacklist, und das wird von der Community gegen alles andere priorisiert!

Ich bevorzuge es, Funktionen in kleine Entwicklungen aufzuteilen, um alle paar Wochen / zwei Wochen veröffentlichen zu können, wie wir es von Anfang an getan haben, zumindest sind wir in der Lage, in kurzen Zyklen zu iterieren und vermeiden endlose Entwicklungen, die nicht vorankommen :slight_smile:

Ja und nein. Apple / Amazon / … zielen auf die breite Masse mit maximaler Grundfunktionalität, Kompatibilität und einem sehr guten Gesamtfunktionsumfang ab. Gladys hingegen richtet sich an Nutzer, die potenziell etwas weiter in der Konfiguration gehen wollen. Szenen, Verwaltung aller Geräte untereinander mit einer gewissen Kohärenz. (nicht nur andere Punkte in Bezug auf Datenkontrolle, DIY, …)

Diese Unternehmen denken in Bezug auf Kosten. Aber der Bedarf ist trotzdem vorhanden.

Das Problem in diesem Beispiel ist, dass der Bedarf unterschiedlich ist. Jemand, der eine Alexa-Lautsprecher kauft, will vor allem eine Station, um Alltagsaktionen durchzuführen, ohne fast nie Smart-Home zu konfigurieren (Timer, Radio, Musik). Mit der zusätzlichen Kraft der Bekanntheit / Werbung usw. dieser Unternehmen, dominieren sie natürlich! Und trotzdem decken sie nicht alle Bedürfnisse ab. Deshalb gibt es in der Smart-Home-Branche auch noch andere Anbieter, die manchmal relevanter sind.

Aber ich bin mit dir einverstanden, in zwei Schritten könnte es perfekt sein :slight_smile:

Ich weiß nicht, wie es für den Entwickler ist, aber für den Benutzer, sobald es konfiguriert ist, wird es nicht mehr angefasst.
Wenn der Benutzer Zugang zu einer anderen Integration haben möchte, kann die Verwaltung dies aktivieren oder nicht.

In zwei Schritten ist es gut, das gibt dir Zeit, es zu verfeinern.