Diskussion 3: "Things" als Strukturebene inkl. Management

[apollon77]

Dies ist ein Diskussions-Thread zu Thema 3 ""Physical Devices and Services"/"Things" als Strukturebene inkl. Management ausserhalb des Objekte-Tab anbieten". Der Haupt-Thread mit der übergreifenderen Idee ist unter https://forum.iobroker.net/topic/56308/iobroker-user-onboarding-flow-verbesserungen-2022 zu finden.

Da haben wir ja schon die Idee des "Hardware Tabs" in der Diskussion unter https://forum.iobroker.net/topic/47053/generische-geräte-verwaltung mit dem "Device Management"-Proptypen von @UncleSam gehabt.

Namenstechnisch waren wir da noch nicht ganz einig in den letzten Diskussionen. "Hardware-Tab", "Device Management" sind zwei Begriffe. Am Ende sind es "Physical Devices and Services" - oder bei OpenHab "Things" (der drückt es eigentlich perfekt aus ... sollten wir den Namen einfach auch nehmen?).

Die Idee ist, das in einem neuen Tab jede Instanz seine "Geräte" aka "Physical Devices and Services" zeigt und spezifisches Management dieser zulässt (wenn relevant). Durch die Erweiterung um "Services" wird das Konzept etwas erweitert um hier für die User, meiner Meinung nach, eine sinnvolle runde Sicht und eine Abtrennung zu den "Virtuellen Geräten" (Aliasses) zu haben. Daher die Idee etwas erweitert gedacht:

• Dieser Tab listet alle Instanzen auf die es gibt (per io-package gibt es ein opt-out für Logikadapter und so)
• Wenn man eine Instanz aufklappt wird geprüft ob der Adapter die DeviceManagement-API unterstützt (io-package Flag).
• Wenn ja, dann liefert der Adapter-Backend-Code die Liste der Devices und möglicher Aktionen und alles wie im DM-Prototyp gezeigt. Der Entwickler liefert die Daten und Konfiguration und der Tab regelt die Darstellung. Pairing-Prozesse können als Flows umgesetzt werden und so weiter. Jedes Device kann aufgeklappt noch weitere Infos und Aktionen (zusätzliche Button-Leiste unter den Detail-Daten) anbieten. Weiterhin brauchen wir noch pro Device sein device-Objekt als ID in den Daten (das ist neu - wofür diese gleich)
• Wenn nein, dann sucht der Tab nach "device" Objekten in der Instanz und stellt diese als Liste da, damit haben wir in jedem Fall den Namen und ggf. über die Status-States noch Error und Connected Flags. Ggf machen wir noch ein "Allow delete" o.ä. Flags ins Objekt, womit man steuern kann was hier an Default-Funktionen angezeigt werden soll. Dazu kommt ein Hinweis das man hier nicht viel tun kann und man mehr unter "Objekte findet" - aber man sieht "Things" (siehe gleich, da kommt noch was ...)
• Wenn keine Device-Objekte da sind (da sollten wir alle identifizieren und fixen, auch ein Wetter-Adapter stellt ein Device dar nämlich den Wetter-Service) dann kommt nur ein Hinweistext.
• In den angezeigten Device-Listen bauen wir eine Spalte ein, um den Raum des Gerätes einzustellen (bzw. anzuzeigen wenn einer gesetzt ist). Dafür haben wir dann je Device-Eintrag sein Hauptobjekt als ID und können dort den Raum setzen. Für eine Vielzahl an Geräten gilt, das Sie in EINEM Raum sind. Für Ausnahmefälle von Things, die auf Channel-Ebene in anderen Räumen sein können (Multi-Channel Aktoren in einer zentralen Verteilung oder so) haben wir immer noch die Option es unter "Objekte" einzustellen (oder eigentlich beim Alias - kommt noch), aber ich denke das wir damit einen Großteil der Realität abdecken (Und formal ist auch das Multi Channel gerät selbst ja in einem Raum :-).

Damit hat der User eine Sicht auf die "Things"/"Physical Devices und Services", die er einfach nutzen kann ohne bei "Objekte" rumklicken zu müssen. Und wir haben mal eben eine einfache und sinnvolle Möglichkeit Räume zuzuweisen.