Generische Geräte Verwaltung
-
@jey-cee sagte in Generische Geräte Verwaltung:
Ansich bin ich für mehr Einheitlichkeit, aber ich kann mir gerade nicht viel drunter vorstellen. Was verstehst du denn beispielsweise unter Verwaltung, wenn anlernen/ablernen nicht enthalten ist?Extended Goal
Das Anlernen / Verbinden der Geräte wird mit einem Assistenten in der Geräteverwaltung durchgeführt. Dieser Assistent führt Schritt für Schritt durch den Prozess.Sehr löbliches Ziel, jedoch kann ich mir kaum vorstellen, das komplett zentral regeln zu können. Hier müsste die Kontrolle zwangsläufig an Adapter abgegeben werden, die durch die Einbindung führen. Kann man ja durchaus innerhalb dieses Tabs erledigen, aber die UI wird am Ende vom Adapter kommen müssen, für die wir dann Vorgaben und einen Rahmen schaffen müssen..
Weil ichs gerade für meine Z-Wave Lib niedergeschrieben habe, hier ist je nach gewählter Verschlüsselung eine unterschiedliche Nutzer-Interaktion während dem Einbinden nötig:
https://zwave-js.github.io/node-zwave-js/#/getting-started/security-s2?id=inclusion-strategy -
@alcalzone sagte in Generische Geräte Verwaltung:
aber die UI wird am Ende vom Adapter kommen müssen, für die wir dann Vorgaben und einen Rahmen schaffen müssen..
Eine Möglichkeit wäre ja ein JSON UI. Das wäre einfach zu schreiben und wäre immer gut eingebunden - wie wir das für Custom nun auch haben.
-
@unclesam sagte in Generische Geräte Verwaltung:
Eventuell könnte man dort auch gleich die Alias Verwaltung machen (anstelle eines separaten Devices Adapter) oder deine gewünschten Features gleich im Devices Adapter einbauen.
Ja die Alias Verwaltung zu integrieren könnte Sinn machen. Da ich Persönlich vom Devices Adapter (so wie er jetzt ist) nicht überzeugt bin, kommt das für mich nicht in frage.
@alcalzone sagte in Generische Geräte Verwaltung:
Was verstehst du denn beispielsweise unter Verwaltung, wenn anlernen/ablernen nicht enthalten ist?
Löschen, Umbennen, Einstellungen (IP, Port, ...) ändern, Gerät Tauschen Funktion das die Alias Objekte entsprechend anpasst(?)
Wie Ich bei Nachteilen geschrieben habe ist das Anlernen ein eher Komplexes Thema wenn man es über alle Adapter vereinheitlichen will.
Bei EnOcean selbst gibt es schon zig verschiedene Methoden um Geräte Anlernen zu können. Am Ende habe ich einen geführten Anlernvorgang in die Config eingebaut, weil die User ständig verwirrt waren.
Dafür hab ich im Backend mehrere Funktionen die die jeweiligen Methoden dann Umsetzen. Wenn das in eine Globale Verwaltung integrierten werden soll braucht es schon eine sehr durchdachte Funktion. Einerseits muss sie flexibel sein und andererseits darf sie nicht zu Kompliziert werden damit sie von jedem Entwickler auch genutzt wird.
Also kein Gefummel um es irgendwie ans laufen zu bekommen!Für den Entwickler muss dann klar sein es gibt eine Funktion "addDevice" mit einem bestimmten Set an Attributen die sein Adapter bereit stellen muss.
Dabei ist dann die JSON UI definition.
Momentan fehlt mir noch die Idee wie man es Handhabt wenn der Anlernprozess mehr als nur einen Anstoß durch den Benutzer braucht. Also wenn Rückfragen vom Adapter kommen und der Benutzer während des Anlernens weitere Informationen eingeben muss.@unclesam sagte in Generische Geräte Verwaltung:
@alcalzone sagte in Generische Geräte Verwaltung:
aber die UI wird am Ende vom Adapter kommen müssen, für die wir dann Vorgaben und einen Rahmen schaffen müssen..
Eine Möglichkeit wäre ja ein JSON UI. Das wäre einfach zu schreiben und wäre immer gut eingebunden - wie wir das für Custom nun auch haben.
Exakt so und am besten gleich mit den selben Componenten, den genau das soll ja die stärke von React sein, wiederverwendbarkeit.
@alcalzone sagte in Generische Geräte Verwaltung:
Weil ichs gerade für meine Z-Wave Lib niedergeschrieben habe, hier ist je nach gewählter Verschlüsselung eine unterschiedliche Nutzer-Interaktion während dem Einbinden nötig:
https://zwave-js.github.io/node-zwave-js/#/getting-started/security-s2?id=inclusion-strategyWie hast du das im Z-Wave Adapter integriert?
-
Hey,
also generell mag ich die Idee, wie man es umsetzt wird denke die interessante Fragestellung.
Daher mal (aus meiner Sicht) ein kurzer Realitäts-Exkurs damit man ggf besser diskutieren kann.
Ich denke 90% der Adapter die "Geräte" anbieten legen diese an weil Sie von einem anderen "führenden System" stammen (z.B. Homematic, Homee, Digitalstrom, ...). Hie muss man genau überlegen was die Aktionen bedeuten und der User erwartet bzw ihm klar machen. Ein Gerät zu Löschen oder umzubenennen kann eine Auswirkung auf ioBroker haben, aber ob man es im Führenden System darüber auch pflegt wird eher unterschiedlich sein - und denke in den meisten Fällen nicht gehen. Auch Einstellungen oder so wird man hier ggf nicht so einfach machen können. Klar anzeigen geht, ein State Mapping auf Battery/Reachable/Seriennnummer/rssi o.ä. geht natürlich auch.
Dann haben wir die Adapter die Geräte "nativ" in ioBroker implementieren und somit auch den Anlern/Pairing Prozess brauchen. Beispiele "Zwave", "Zigbee", "EnOcean", aber auch zB mbus. Hier ist Benamung und Löschen sinnvoller als Funktion und ja das Muss aktuell jeder Dev selbst implementieren.
Passt das oder sehr Ihr noch weitere Szenarien oder Mischformen?
Das ganze mit dem "Devices" Adapter zu verheiraten wird schwierig weil wir hier von einer unterschiedlichen Sicht auf ein "Gerät" reden. Bei "Devices" geht es um die "effektiven nutzbaren Geräte" auch aus Sicht von Visualisierungen, Assistenten und so.
Wir hier reden über die "Hardware-Sicht" auf ein Gerät. Der Unterschied kommt vor allem bei Kombigeräten zum Tragen wo zB Sensoren in einer Lampe stecken ... Das sind für "Devices" ggf zwei oder mehr "Geräte", aber in einer Hardware. Wie man diese Unterscheidung nennt das User das kapieren wird auch ne Challenge
(aber eine zu lösende).Die Idee einen solchen "Gerätehardware-Management" Tab zu haben wo man die Adapternamespaces sieht die das können und nach Auswahl eines davon die zugehörigen "device"-ObjektBasierte Ansicht und Daten sieht und einheitliche Funktionen hat und einen Konfig dialog der per jsonconfig "einfache konfig" erlaubt wäre mal ein start. Alternativ kann ein adapter ne eigene "React komponente/Seite" mitbringen die die Konfig macht. Und am Ende weil man die Instanz gewählt hat gibt es ggf spezielle eigene Links /Netzwerkansicht seite) oder "Neue geräte anmelden/pairen" Möglichkeiten.
Also am Ende viel "konfiguration" die zentral verarbeitet wird und Adapter liefern und im Bedarfsfall mit eigenr React-Logik individualisierbar.
-
@jey-cee sagte in Generische Geräte Verwaltung:
Wie hast du das im Z-Wave Adapter integriert?
Noch gar nicht. Die Lib kann seit 2 Tagen endlich Security S2, es gibt noch keine released Version dafür.
Mein Plan war es, Z-Wave ebenfalls auf nen Tab umzubauen, um Nutzern eine bessere UI zu bieten, als die Mischung aus Adapter-Konfiguration und Objekt-Browser es derzeit tut. In diesem Zuge wollte ich das mit einbauen. -
@apollon77 sagte in Generische Geräte Verwaltung:
aber ob man es im Führenden System darüber auch pflegt wird eher unterschiedlich sein - und denke in den meisten Fällen nicht gehen.
Da seh ich jetzt kein Problem, hiermit ist festgelegt das die Geräteverwaltung nur die Geräte Innerhalb von ioBroker Verwaltet.
In der Adapterkonfiguration kann es dann eine Checkbox geben "ioBroker verwaltet die Geräte des Systems".
Damit kann der User frei entscheiden ob er die Geräteverwaltung an ioBroker abgibt, wenn das möglich ist.@apollon77 sagte in Generische Geräte Verwaltung:
Auch Einstellungen oder so wird man hier ggf nicht so einfach machen können.
Gleiches Thema wie für das Anlernen von Geräten. Und nur weil es vielleicht nicht ganz einfach ist ist das noch kein Grund es nicht zu machen
@apollon77 sagte in Generische Geräte Verwaltung:
Bei "Devices" geht es um die "effektiven nutzbaren Geräte"
Eigentlich geht es da um Virtuelle Geräte die man in ioBroker erstellt, das wäre meiner Meinung nach der Richtige Name dafür.
@apollon77 sagte in Generische Geräte Verwaltung:
Alternativ kann ein adapter ne eigene "React komponente/Seite" mitbringen die die Konfig macht. Und am Ende weil man die Instanz gewählt hat gibt es ggf spezielle eigene Links /Netzwerkansicht seite) oder "Neue geräte anmelden/pairen" Möglichkeiten.
Ganz schlechte Idee, das gibt wieder nur Wildwuchs.
-
@alcalzone sagte in Generische Geräte Verwaltung:
Mein Plan war es, Z-Wave ebenfalls auf nen Tab umzubauen, um Nutzern eine bessere UI zu bieten, als die Mischung aus Adapter-Konfiguration und Objekt-Browser es derzeit tut. In diesem Zuge wollte ich das mit einbauen.
Na da kommt die Diskussion ja noch gerade Rechtzeitig
-
Ich fände es besser wenn die Konfiguration der devices bei den jeweiligen Adaptern bleibt. Das ist auch für Anwender einfacher zu verstehen und verhindert ein Wechseln zwischen Adapter config und device config.
Um Einheitlichkeit zu erhalten, wäre eine tab innerhalb der Adapter config denkbar, deren grundkonstrukt von Iobroker (evtl per react+weitere Adapter Funktionen) vorgegeben wird. Wahrscheinlich wird das aber nur eine Liste sein, bei der die üblichen crud (create,read,update,delete) Operationen angewendet werden können. 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.)
Auch sollte man daran denken, das manchmal eine 2 stufige Verwaltung innerhalb eines Adapters notwendig ist (bspw verschiedene Anbieter,mit jeweils eigenen Geräten)
-
@jey-cee sagte in Generische Geräte Verwaltung:
Na da kommt die Diskussion ja noch gerade Rechtzeitig
Ich glaube der Scope geht aber noch über das hinaus, was du planst, aber ja - wäre definitiv interessant, das ggf. gleich zu berücksichtigen.
-
@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.
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.
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.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.
Die Adapterkonfiguration fasst man ja nur bei der Einrichtung der Instanz an, danach sollte man dort nie wieder rein müssen.@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.
@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. -
@jey-cee sagte in Generische Geräte Verwaltung:
Eigentlich geht es da um Virtuelle Geräte die man in ioBroker erstellt, das wäre meiner Meinung nach der Richtige Name dafür.
naja, zu spät, heisst jetzt anders ... also muss was anderes neues nen sinvollen Namen für sich finden
-
@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. -
@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.
-
Na dann bin ich mal gespannt
-
@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.
-
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.
-
@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.
-
@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
-
@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:
-
@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
