Generische Geräte Verwaltung

[OliverIO]

@jey-cee sagte in Generische Geräte Verwaltung:

@oliverio sagte in Generische Geräte Verwaltung:

Das ist auch für Anwender einfacher zu verstehen und verhindert ein Wechseln zwischen Adapter config und device config.

Ich glaube es ist Ansichtssache ob das einfacher für Anwender zu verstehen ist. Aus meiner Perspektive erwarte ich einen Ort an dem ich eine Operation für jeden Adapter Ausführen kann und der soll immer gleich Aufgebaut sein und Aussehen.

Kein Widerspruch. Zur Wahl steht eine einheitliche Liste, mit allen Geräten, die aber nur einen Funktionsumfang über den kleinsten gemeinsamen Nenner über alle Geräte anbietet. Sobal was nicht passt, gehen die Entwickler wieder ihren eigenen Weg.

Mal so ein kleines Beispiel:
Wenn ich ein Gerät aus ioBroker löschen möchte erwarte ich einen Button Gerät löschen und zwar immer an der gleichen Stelle.

Auch kein Widerspruch, aber ein Anwender sucht das halt zuerst bei der Adapter Konfiguration. Wie ich das beschrieben habe, wäre die Ansicht ja schon gleich und mit einem hohen Wiedererkennungseffekt. Durch Erweiterungsmöglichkeiten kann jeder Entwickler den Standard, der immer gleich benannt ist, erweitern.

Stand der Dinge ist das es Adapter gibt bei denen die Instanz gelöscht werden muss, bei anderen geht es nur wenn man die Objekte löscht und dann gibt es noch die Verwaltung in der Konfiguration oder als Tab oder als Tab wo das selbe nochmal in der Konfiguration zu finden ist.

Wie verhinderst du dann bei einer einheitlichen List, das das nicht wieder passiert. Wenn der Entwickler sich mit seinen Geräten nicht dort registriert, dann erscheint sein Adapter und seine Geräte auch nicht in dieser Liste.
Viele Entwickler sind meiner Meinung nicht so firm. Viele Informationen muss man sich mühsam zusammensuchen. Ich selbst hab einiges durch debugged und in den Code von Iobroker schauen herausgefunden, da es als Dokumentation nicht auffindbar, veraltet oder einfach nicht oder nur dünn beschrieben war.
Die Entwickler, die nicht so firm sind geben da wahrscheinlich schon früher auf, wie andere. Dann fallen optional Funktionalitäten einfach weg.

Das verwirrt mich als Benutzer nicht nur sonder Ärgert mich auch.

Aber mich würde deine Argumentation interessieren. Besonders was an einem Wechsel zwischen Adapterkonfiguration und Geräteverwaltung so schlimm wäre.
Du legst in einer Liste ein Gerät an und musst wo anders zünde konfigurieren? Nicht so erfahrene Benutzer erschließt sich der Zusammenhang nicht immer warum man das eine dort und wo anders konfigurieren muss/kann.
Dadurch löst du die Einheit Konfiguration auf ein oder mehrere Stellen auf.

Die Adapterkonfiguration fasst man ja nur bei der Einrichtung der Instanz an, danach sollte man dort nie wieder rein müssen.

Das gilt für alle jetzt bekannten anwendungsfälle ?
Ich glaub nicht.

@oliverio sagte in Generische Geräte Verwaltung:

Um Einheitlichkeit zu erhalten, wäre eine tab innerhalb der Adapter config denkbar,

Naja das haben wir ja jetzt schon mehr oder weniger, aber das ist eben nicht Praktikabel weswegen es schon Adapter gibt die einen Tab im Admin anlegen.

Auch das ist nicht gut.
Adapter haben mE in der Konfiguration von Iobroker nix zu suchen.

@oliverio sagte in Generische Geräte Verwaltung:

Darauf aufbauend kann dann jeder adapterentwickler seine Spezialitäten einbauen und erweitern (eigenes Master-detail-View damit Geräte spezifische Parameter verwaltet werden können, weitere Operationen wie bspw on off,Push,pull,etc.)

Das beißt sich mit der jsonConfig und würde sie mehr oder weniger Überflüssig machen. Davon abgesehen das auch das wieder Wildwuchs gibt.
In meinen Augen kein Gangbarer weg.
Ich hab mir jsonconfig jetzt noch nicht angeschaut, aber das ist doch sicherlich ein vereinfachter Weg um react zu befüttern und dadurch einfache Dialoge zu erzeugen.
Das schließt sich ja nicht aus.

[Jey Cee]

@oliverio sagte in Generische Geräte Verwaltung:

Wie verhinderst du dann bei einer einheitlichen List, das das nicht wieder passiert. Wenn der Entwickler sich mit seinen Geräten nicht dort registriert, dann erscheint sein Adapter und seine Geräte auch nicht in dieser Liste.

Fliegt einfach beim review raus und kommt nicht in die Offizielle Liste. Außerdem lässt sich beim Automatischen check schon prüfen ob der Adapter entsprechende Funktionen implementiert hat, da sie ja Standardisiert sind. Dann kann man gleich darauf Hinweisen ohne das sich das jemand angesehen haben muss und der Entwickler bekommt die Info das es so etwas gibt Frei Haus geliefert (am Besten gleich mit Link zur entsprechenden Doku).

@oliverio sagte in Generische Geräte Verwaltung:

Die Entwickler, die nicht so firm sind geben da wahrscheinlich schon früher auf, wie andere. Dann fallen optional Funktionalitäten einfach weg.

Auch das haben wir schon jetzt, das ist ja einer der Gründe warum es die jsonConfig gibt. Viele Entwickler kommen mit Frontend nicht gut klar. Die jsonConfig nimmt wirklich alles was Frontend Gestaltung angeht weg und bietet fertige Elemente an.
Zugegeben man muss da erstmal rein kommen, aber das Ergebnis Überzeugt.
Dafür ist es halt nicht möglich eigene Funktionen zu realisieren. Das ist dann eben der Punkt wo sich dein Vorschlag mit jsonConfig Beißt, weil man dann wieder auf React selber schreiben angewiesen ist. Und glaub mir dafür haben 80% der Entwickler keinen nerv und die Zeit das auch noch Ordentlich zu lernen.

@oliverio sagte in Generische Geräte Verwaltung:

Sobal was nicht passt, gehen die Entwickler wieder ihren eigenen Weg.

Da gegen gibt es nur 2 Mittel: Alles verbieten was nicht gewünscht ist oder dafür sorgen das es keinen Grund gibt einen anderen Weg zu gehen.

Für den zweiten fehlt nur manchmal das Feedback der Entwickler weil sie nicht Fragen bevor sie etwas umsetzen. Das hab ich immer wieder gesehen.

[OliverIO]

@jey-cee

Na dann bin ich mal gespannt

[AlCalzone]

@jey-cee sagte in Generische Geräte Verwaltung:

weil man dann wieder auf React selber schreiben angewiesen ist

Ne, tut auch "einfaches" HTML/CSS/JS mit z.B. https://materializecss.com/. React ist und bleibt optional.

[Homoran]

Ich habe jetzt hier nur mal quergelesen.
Dabei ist mir folgendes durch den Kopf gegangen:

Wenn ein User etwas von Geräteverwaltung liest, wird er genau das erwarten.
So wie es z.B. FHEM macht.
Dort wird sogar keine CCU mehr benötigt. Entsprechende Diskussionen mit Umsteigern haben wir immer wieder.
Auch "einfache" HM-User erwarten immer wieder von ioBroker, dass sie darüber die Gerätekonfigurationen durchführen können.

Anscheinend wurde so etwas auch bei anderen Systemen, die ich nicht nutze, bereits (ansatzweise?) umgesetzt.

[apollon77]

@homoran sagte in Generische Geräte Verwaltung:

Anscheinend wurde so etwas auch bei anderen Systemen, die ich nicht nutze, bereits (ansatzweise?) umgesetzt.

Das hängt immer davon ab was das System anbietet. Bei digitalstrom und homee als Beispiel lässt der Adapter die Finger davon und syncs es nur - sogar bei jedem Start. Also Geräte löschen nur in ioBroker hätte keinen Sinn weil die beim nächsten Start wieder da wären. Nur umbenennen der Objekte erlaubt der Adapter aber damit ist es „out of Sync“ mit dem Hauptsystem.

Das fhem keine ccu braucht liegt daran das die bidcos mit allem ccu kompatibel gebaut haben. Ist so ne Sache.

[Homoran]

@apollon77 sagte in Generische Geräte Verwaltung:

Das fhem keine ccu braucht liegt daran das die bidcos mit allem ccu kompatibel gebaut haben

Das weiß ich, mir ging es aber um die Erwartungshaltung der User, die nicht unbedingt dem machbaren entspricht

[OpenSourceNomad]

@homoran said in Generische Geräte Verwaltung:

Anscheinend wurde so etwas auch bei anderen Systemen, die ich nicht nutze, bereits (ansatzweise?) umgesetzt.

Der große Bruder hat auch eine zentrale/generische Geräteverwaltung. Die Gerätschaften selber werden immer automatisch hinzugefügt sofern eine Integration diese "mitbringt".

Ein klick auf ein Gerät zeigt dann alle nur erdenklichen Informationen (u.a auch in welchen Skripten, Automations etc. das Gerät verwendet wird). Ebenfalls können hier Entities unbenannt, angepasst oder auch deaktiviert werden:

[Homoran]

@opensourcenomad sagte in Generische Geräte Verwaltung:

@homoran said in Generische Geräte Verwaltung:

Anscheinend wurde so etwas auch bei anderen Systemen, die ich nicht nutze, bereits (ansatzweise?) umgesetzt.

Der große Bruder

ich meinte schon bei der Integration anderer Systeme in ioBroker.

dabei vermutete ich so etwas bei zigbee oder/ und weiteren

[OliverIO]

@homoran
Mal noch eine etwas abstraktere Frage.
Wie definiert sich den ein Gerät?

sind da nur die typischen physische Geräte gemeint, die über irgendeinen Funkstandard oder Netzwerk angebunden sind?
oder sind das auch virtuelle Geräte, wie bspw bei squeezebox
oder Informationsanbieter/softwaregestützte Geräte wie bspw
ein Wetterdienst oder ein RSS-Feed

[apollon77]

Ich würde es hier mal eher auf Hardware Geräte beziehen Bzw was auch immer ein Adapter als „Gerät“ definiert. Virtuelle Geräte wie ein parser Ergebnis oder ein RSS feed Eintrag oder das Wetter von einem Wetterdienst würde ich hier erstmal nicht drin sehen. Das ist aber dann bei den virtuellen Geräten im devices adapter wieder dabei.

Daher war ja mein Vorschlag es eher „Hardware Geräte“ oder so zu nennen.

[apollon77]

@opensourcenomad ist hier wirklich ein device einer Hardware Entität zugeordnet? Ich erinnere mich das da auch ggf aus einem Hardware Geräte mehrere „devices“ werden können und es daher bei Hass (großer Bruder ist seeeehr relativ ;-)) ) ne Mischung ist. Oder bin ich da falsch?

[Jey Cee]

@oliverio für mich sind das erstmal nur Geräte die ein Adapter definiert. Ein Dienst wie Wetterdaten ist per se erstmal kein Gerät, zumindest wüsste ich nicht das einer der Adapter das so definiert.
Jetzt geht es erstmal darum diese Geräte Zusammen zu bekommen.
Die Verwaltung Virtueller Geräte die innerhalb von ioBroker angelegt werden ist erst mal nicht vorgesehen. Wenn dann liefe das auf eine Verschmelzung vom Aktuellen Devices und dem neuen Hinaus. Da der Devices momentan aber auch noch in der Findungsphase steckt, sehe ich das noch nicht. Das muss man dann später Entscheiden.

[apollon77]

@jey-cee sagte in Generische Geräte Verwaltung:

Da der Devices momentan aber auch noch in der Findungsphase steckt, sehe ich das noch nicht.

Das sehe ich nicht so ... DIe rundlage ist da ... jetzt ist maximal die Frage wie/wann/auf welcher Basis weitere Gerätetypen ergänzt werden. Die (virtuellen) Devices/Geräte sind denke so wie Sie sind erstmal sinnvoll und eine Basis für Verbesserungen.

[OpenSourceNomad]

@apollon77 said in Generische Geräte Verwaltung:

ist hier wirklich ein device einer Hardware Entität zugeordnet?

Also einer "Integration" kann ein oder mehrere "Devices" haben, muss aber nicht. "Devices" können wiederum x "Entites" haben.

Eine Integration ohne Device:

[Garfonso]

@apollon77 Im Normalfall passt ein entity schon ganz gut zu einem type-detector device (also womit Devices arbeitet). Das ist von der Ebene her sehr vergleichbar.

Zum eigentlichen Thema meine Überlegung:
Ich würde die Geräteverwaltung gerne aus den Instanzeinstellungen heraus kriegen.

Ich sehe in Einstellungen, die ein Gerät betreffen (neues Gerät anlernen / hinzufügen, löschen, umbenennen, ändern, deaktivieren, ...) schon eine andere Klasse von Konfiguration als welche die eben die Instanz betreffen (z.B. com-port oder IP Adresse auf dem der Adapter die Hardware suchen soll).

Das man aktuell die Geräteverwaltung in den Instanzeinstellungen sucht, liegt meiner Meinung nach daran, dass die aktuellen User es so gelernt haben und es (vor dem Devices-Adapter) auch keine andere Stelle gab, wo man das direkt vermutet.
Das mit der Gewöhnung ist aber ein schwaches Argument. Wenn man sich in einen neuen User hineinversetzt, ist der "Geräte"-Tab, den es nun gibt, schon das, wo man am ehesten gucken würde, oder? Schon allein deswegen wäre ein zusätzlicher "Hardware" Tab (wäre gleichzeitig mein Namensvorschlag, wenn auch nicht 100% passend) hilfreich, auch wenn er erstmal nicht alle Anforderungen direkt erfüllen kann (das, was nicht geht, könnte mit Links auf die Instanzeinstellungen / Tabs der Adapter gelöst werden).

[apollon77]

@garfonso sagte in Generische Geräte Verwaltung:

@apollon77 Im Normalfall passt ein entity schon ganz gut zu einem type-detector device (also womit Devices arbeitet). Das ist von der Ebene her sehr vergleichbar.

Das hatte ich ja auch gesagt. Ein Entitiy ist bei uns ein" virtual Device" und nicht das Hardware-Device um die es hier geht

[Asgothian]

@garfonso sagte in Generische Geräte Verwaltung:

Zum eigentlichen Thema meine Überlegung:
Ich würde die Geräteverwaltung gerne aus den Instanzeinstellungen heraus kriegen

Ich denke das war ein Grund warum der zigbee adapter einen eigenen Tab bereit stellt.

Ich she’s aber durchaus einige Hürden dabei das so allgemeingültig zu definieren das eine adapterseitige Möglichkeit zur Geräteverwaltung entfallen kann.

A.

[apollon77]

Hi All,

nach den grundsätzlichen Diskussionen zu einem Hardware-Tab (ich nenn es jetzt mal so) und der Möglichkeit (generisch) Geräte zu verwalten hier mal eine Idee wie man es vllt generisch genug machen könnte.

Seht es mal als Idee - man kann alles darin noch diskutieren. Vor allem Namen und "technische Bezeichner" sind erstmal "zum verstehen des Contents/Scopes" benannt ... kann später alles anders heissen - geht hier um Verständnis der Idee.

Generelle Technische Idee

Die ganze Idee basiert auf vordefinierten oder dynamisch vom Backend generierten JSonConfig "Formulare" und eine Reihe von vordefinierten Messages die der Adapter unterstützen muss.

hardwareConfig.json

Json File mit der Konfig für den Hardware Tab. Enthält:

• Liste mit vordefinierten JSonConfig Formularen die eine eindeutige ID bekommen und später genutzt werden können
• Konfig für die Instanz-Funktionen um zu bestimmen welche Buttons und Elemente angezeigt werden

Wenn das File da ist zeigt der Adapter mit common.adminConfig.hardware="json" in der io-package das er Hardware Funktionen unterstützt.

Messages

Zur Kommunikation nutzen wir vor allem messages (sendTo/onMessage).
Der Hardware-Tab definiert/nutzt zwei Typen von Messages: Datenabfrage-Messages und Aktions-Messages, die am Ende eine gewisse einheitliche Struktur der Daten der Message definieren.

Datenabfrage-Messages

Werden genutzt um Details zu lesen die für die Anzeige der Seite benötigt werden

Aktions-Messages

Der Ursprung ist ein Button der in der UI geklickt wird.

Das UI generiert für den Button-Press eine "unique Session-ID" und sendet die mit. Diese ID ist später dazu da das das Backend einen "Message Flow" verarbeiten kann.

Als Response der Message definieren wir das eine "Aktion" zurückgegeben wird und ggf weitere Daten. Aktion kann sein:

• Query - Backend erfordert das (erneute) Anzeigen eines Formulars, sendet die jsonconfig ID oder direkt ein dynamisches JSonConfig als Antwort und Daten und definiert die Message für die nächste Antwort. Session-ID bleibt gleich und geht wieder mit zurück.
• ProcessInfo - Backend antwortet mit ner Statusinfo die Als Message oder Log-Style angezeigt werden kann um einen Prozessinfo zB von einem Pairing-Verlauf anzuzeigen. UI sendet direkt message wieder ans Backend (Log polling approach). Alternativ könnte der adapter eine state ID zurückgeben die die UI subscribed um von dort status meldungen zu bekommen zur Anzeige
• Pending - nach zb 20s sollte das Backend auf jeden Fall antworten und UI macht neuen Long.Polling message call
• Done - Aktion abgeschlossen, UI zeigt ein "Ok bzw eine "zurückgegebene Meldung" (Lokalisierung todo), Device-List wird aktualisiert
• Error -Fehler passiert, Anzeige Fehlermeldung

Die ganze Backend Logik könnte man in eine Conenient Klasse packen um ggf für Devs zu erleichtern, aber im ersten Schritt geht das auch mit Plain "onMessage".

Oberfläche/UI

Die Oberfläche besteht aus drei "Teilen".

Hardware-Overview

Wenn man den Hardware-Tab öffnet landet man in der "Hardware-Übersicht". Dort sind alle Instanzen gelistet die die Hardware-Funktionen unterstützen. Jede Instanz bekommt einen "Hardware-getOverviewDetails"-Message call der zB

• Anzahl erkannte/discovered Gerät
• Anzahl verbundene Geräte
  zurückgibt

Hardware-Instance Overview

Nach Auswahl einer Instanz werden einerseits eine Liste von Buttons für generelle Aktionen angezeigt und eine Liste von Geräten mit einem Status.

Buttons:

• Discover (wenn konfiguriert im hardwareConfig)
• Add Device (wenn konfiguriert, zB um per IP oder so direkt Geräte hinzuzufügen)

Die Buttons lösen direkt eine Message aus die im Json konfiguriert ist, oder erlauben die Anzeige eines JsonConfig forumlars (auch konfiguriert im json) und sendet die angegebenen Daten als "Aktions-Message".

Geräteliste:

• ID, Name
• Status (connected, disconnected, discovered/no-paired)
• Erlaubte Aktionen (Buttons) wie: Configure, Delete/Unpair (mit dynamischer konfig ob/welche Message gesendet wird und ob/welches Formular angezeigt wird)

Um die Daten für die Geräteliste zu bekommen bekommt der Adapter einen Message call "Hardware-getDeviceList" bzw vor Configure ein "Hardware-getDeviceConfig" um die Daten zu bekommen.

"Button Actions"

Die Buttons lösen direkt eine Message aus die im Json konfiguriert ist, oder erlauben die Anzeige eines JsonConfig forumlars (auch konfiguriert im json) und sendet die angegebenen Daten als "Aktions-Message".

Wir haben als quasi 3 "Datenabfrage-Messages" (Hardware-getOverviewDetails, Hardware-getDeviceList, Hardware-getDeviceConfig) und "frei konfigurierbare" Aktions-Messages.

Als Oberfläche muss man "einmal" die "Aktions-Message-UI-Logik" bauen die den gesamten Flow als Komponente abbildet in der UI und dann "einfach" von allen Buttons generisch verwendet wird. Der Rest der Ui ist denke ich eher überschaubar (ok ich als nicht FE Dev muss das sagen) :-))

Ich denke über so einen Ansatz können wir sehr viel abbilden:

• einen pairing prozess der nach Kommunikation mit dem Gerät Rückfragen stellen kann
• einen Prozess ala zigbee der sekündlich status infos gibt während der controller für "including" freigeschaltet ist
• Einfache Aktionen die nur aus klick, ergebnis bestehen

Weitere Features des tabs (pro Devcie) könnte es noch sein Funktion und Room festzulegen ... das sind dann zentrale Enum Einträge o.ä, und mus ggf gar nicht zum Adapter direkt gehen sondern kann der Tab machen wenn er das "Device Object" kennt. Gleiches für den namen ... Aber da muss man mal überlegen was noch Sinn macht

Was denkt Ihr?

Ingo

[Jey Cee]

@apollon77 Klingt nach mehr Overhead als nötig. Wenn der der Adapter richtig gemacht ist verwendet er Objekte vom typ device* und das kann mit den Vorhandenen Mitteln schon gelesen werden. Ganz klares Ziel: Es muss für den Adapter Entwickler einfacher werden und nicht mit mehr Arbeit verbunden sein.
Deswegen muss der Geräte Manager so viel Arbeit wie möglich übernehmen.

*Wenn nicht dann wird auch der Zusätzliche Overhead nicht oder nicht richtig gemacht.

Da es ein leichtes ist mit den vorhandenen Mitteln Objekte zu lesen sehe ich nicht wofür es neuer Funktionen bedarf die das selbe machen. Vor allem nicht wenn es dafür nötig ist auf beiden Seiten, Adapter und Geräte Manager, etwas zu Bauen.

Messages
Wenn ich deinen Vorschlag richtig verstehe soll es ein neues Kommunikationsprotokoll geben um damit zu Arbeiten. Das bedeutet dann doch wieder mehr Arbeit für den Adapter Entwickler?!
Mit sendTo/onMessage haben wir doch bereits ein Mittel um den Datenaustausch zu ermöglichen.

Die Session ID finde ich eine gute Idee und würde sogar Vorschlagen diese SID in die Funktion sendTo/onMessage zu integrieren.
Also wenn man sendTo aufruft wird eine SID generiert die an die Message angehängt wird und als Wert zurück gegeben wird. Damit steht dieses Feature ioBroker weit zur Verfügung, es ist kein Breaking change und dürfte nicht all zu Aufwendig zu implementieren sein.
In die SID sollte auch der Zeitstempel mit eingebracht werden um das Handling zu vereinfachen, dann muss man sich nicht merken wann die Message Gesendet/Empfangen wurde.

Funktionen/Buttons
Es wäre wirklich besser wenn der Geräte Manager selbst überprüft ob die entsprechenden Funktionen vom Adapter zur Verfügung gestellt werden.
Der Ablauf sieht dann so aus:

1. Geräte Manger sucht Adapter
2. Es werden die vorgegebenen Funktionen für jeden Adapter aufgerufen
3. Bei positiver Antwort des Funktionsaufrufs merkt der Geräte Manager sich das
4. Die Gesammelten Informationen werden in einem Profil für den Adapter (Instanz) gespeichert

Funktion im Adapter könnte so aussehen:

deleteDevice(deviceID){
   //Do not remove this 
   if(deviceID === 'device manager check'){
      return true;
   }
   //Do your stuff here
}