Generische Geräte Verwaltung
-
@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
-
@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 -
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.
-
@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?
-
@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. -
@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.
-
@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:
