@apollon77
Hallo, ich habe Anfang Dezember 2020 mit ioBroker begonnen und seit dem einiges getestet. Den Ansatz mit den Alias finde ich sehr gut, ähnlich einer Variablentabelle, allerdings habe ich noch einige Lücken im Verständnis der Philisophie des Adapters.
Soweit ich es bisher Verstanden habe erstellt man unter "Geräte" ein Alias Gerät (Geräte denen ich vorher schon Raum und Funktion zugeordnet hatte erscheinen automatisch in der Liste - allerdings nicht als Alias - was hat es damit auf sich wie sieht der Use case aus ?) hierbei kann man sich einen vorgefertigen Typ aussuchen.
Wenn man das neue Alias Gerät editiert sieht man, dass es eine vorgefertigte Struktur hat - welche sicherlich von dem zuvor gewaehlten Typ kommt.
Leider kann man in diesem Fenster nur die Quellen zu den einzelnen Tags/Members editieren, die Struktur selbst lässt sich hier nicht ändern genauso wie andere Parameter wie z.B. eine Konvertierung des Wertes.
Anpassungen der Struktur (Member hinzufügen) konnte ich nur unter Objekte durchführen und dort auch nur mit manuellen Anpassungen z.B. um diesen Fehler beim Anlagen eines neuen Datenpunkt unter dem Gerät zu lösen
erst wenn man den alias Parameter einfügt wird der Datenpunkt erkannt.
Legt man nun auf diese Weise mehrere Datenpunkte an funktionieren Sie in Objekte unter alias.0 auch wunderbar. Wenn man aber jetzt ein Geräte das entsprechende Gerät editiert sind die neuen Member zwar in dargestellt aber alle sind "scheinbar" mit der gleichen Quelle verbunden --> Darstellungsproblem ?
wie gesagt die Datenpunkte funktionieren.
Ok jetzt zu meinem Problem bzw. Verbesserungsvorschlag.
Die Vorgegebenen Typen finde ich gut jedoch sehe ich hier den generischen Ansatz als problematisch. Z.B. passt der Typ Jalousie von der Struktur her nicht zu meinen HomePilot20 RademacherGeräten. So wie ich das bis jetzt verstanden habe werden diese Typen Entwicklerseitig zur Verfügung gestellt ? Was im Grunde sehr gut ist da so eine gewisse Standardisierung rein kommt.
-
Vorschlag:
Der Adapterhersteller z.B. hier Homepilot20 liefert den GeräteTyp mit - er weiss am besten wie dieser auszusehen hat.
-
Vorschlag:
Der User sollte seine eigenen Typen erstellen können evtl. in einem Editor. In dem Editor können auch die Systemseitig gelieferten Typen dargestellt und verwaltet werden. Ich denke da an ein Typ --> Instanz Konzept. Das Gerät arbeitet nur mit der Instanz somit haben ich die Möglichkeit zentral den Typ zu editieren (single point of change)
Die Verknüpfung der Quellen mit den einzelnen Member des Gerätes muss mit jedem neuen Gerät (für jeden Member) auch neu durchgeführt werden. Man kann es etwas schneller gestalten indem man das Gerät unter Objekte als JSON exportiert und nach Anpassung wieder importiert, ist aber alles nicht sehr effektiv.
Beispiel: Ich habe 10 Rollos vom gleichen Hersteller somit haben alle die selbe Struktur
und ein möglicher Typ "Rademacher_Rollo" hat die Parameter des Gerät ("Position"; "Action"; etc ) schon vorverbunden da diese ja bekannt sind, Somit muss ich nach anlegen eines neuen Gerätes nur noch den richtigen Pfad auswählen.
- Vorschlag: Zweistufige Projektierung
Stufe Eins:
Zuordnen eines GeräteTyp (oder User Defined Datatyp UDT) zu dem neu erstellten Alias Gerät.
Stufe Zwei:
Verschalten des Alias Gerät mit dem Pfad des realen Geräts.
Vorteil ist ich muss nur noch eine Verbindung herstellen und nicht jeden einzelnen Member einzeln verbinden. Diese spart sehr viel Zeit und ist weniger Fehleranfällig.
Ich hoffe ich habe es einigermaßen nachvollziehbar ausgedrückt sonst bitte einfach nachfragen. Gerne kann ich das auch in Github eintragen, möchte aber erst mal ein gemeinsames Verständnis und Wording finden.
Gruß Bungee