NEWS
Devices, Alias, Assistenten + Visualisierungen + die Zukunft
-
@apollon77
+1 (ich finde das Konzept sinnvoll)
wie kann man als "normaler User" bei der Umsetzung helfen ? -
Was ist der genau Vorteil von aliases außer die Austauschbarkeit? Denn ich zb bin sehr faul und habe noch nie ein alias angelegt.
Würde es nicht reichen die device typ von Amazon/Google als Type für ein IoBroker device zu setzen ?
Denn das devicemapping unter commons ist ja implizit schon bei den meisten Adaptern enthalten die gut gepflegt roles haben. Man müsste nur den type fest definieren anstatt den device detector es raten zu lassen.
Natürlich könnte man die gut gepflegten devices Prominenter anzeigen aber das wird viele neue User verwirren die sich fragen wo ist denn mein schlecht gepflegtes device oder meine mqtt states.Vielleicht ist das auch zu kurz gedacht einfach ein device Type einzuführen der mandatory roles hat.
-
Was ist der genau Vorteil von aliases außer die Austauschbarkeit? Denn ich zb bin sehr faul und habe noch nie ein alias angelegt.
Würde es nicht reichen die device typ von Amazon/Google als Type für ein IoBroker device zu setzen ?
Denn das devicemapping unter commons ist ja implizit schon bei den meisten Adaptern enthalten die gut gepflegt roles haben. Man müsste nur den type fest definieren anstatt den device detector es raten zu lassen.
Natürlich könnte man die gut gepflegten devices Prominenter anzeigen aber das wird viele neue User verwirren die sich fragen wo ist denn mein schlecht gepflegtes device oder meine mqtt states.Vielleicht ist das auch zu kurz gedacht einfach ein device Type einzuführen der mandatory roles hat.
@tombox sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Was ist der genau Vorteil von aliases außer die Austauschbarkeit? Denn ich zb bin sehr faul und habe noch nie ein alias angelegt.
Naja am Ende siehe oben :-)
Austauschbarkeit und die Möglichkeit "zusammengepuzzelt" ganz eigene Geräte bzw Objektstrukturen als Mischung aus verschiedenen Adaptern zusammenzubauen.Denn das devicemapping unter commons ist ja implizit schon bei den meisten Adaptern enthalten die gut gepflegt roles haben. Man müsste nur den type fest definieren anstatt den device detector es raten zu lassen.
Ich glaube das ist zu kurz gedacht (meiner Meinung nach). Vor allem zeigt die Erfahrung das sehr viel Raten und interpretieren nötig ist und wenn ich mir die 60 Gerätetypen von Amazon ansehe bin ich nicht sicher ob es reicht ... Du hast das alles für Google-Home gebaut und weisst an sich daher wie schwierig es ist das sicher zuzuordnen, oder ?!
eine Rolle value.temperature kann die aktuell gesetzte Temperatur sein, die Zieltemperatur sein und vllt min und max oder sonst was ... Rollen sind aus der aktuellen Erfahrung nicht eindeutig genug. Man kann das ggf nur lösen indem man die Rollen massiv erweitert, was es dann am Ende wieder auch nicht einfacher macht.
-
Ich finde das erstellen der Geräte eine super Sache, gerade der neue/unerfahrene Nutzer wird von der Menge an States erschalgen.
Muss aber auch sagen, dass ich bis lang mit dem "Geräte" Adapter noch nicht gearbeitet habe:
a: findet man ihn ganz schlecht in der Adapterliste
b: ist mir der Unterschied zwischen linkeddevices und devices nicht ganz klar, braucht man beide?
c : ist bei mir im Gerätetab alles zugespamt nach der Installation mit ca 100 Geräten die ich auch nicht löschen kann.
Das ist auf jedenfall ein Mamutprojekt was viel Arbeit sein wird. Aber für die Übersichtlichkeit wird es ein großer Gewinn sein.
-
Ich finde das erstellen der Geräte eine super Sache, gerade der neue/unerfahrene Nutzer wird von der Menge an States erschalgen.
Muss aber auch sagen, dass ich bis lang mit dem "Geräte" Adapter noch nicht gearbeitet habe:
a: findet man ihn ganz schlecht in der Adapterliste
b: ist mir der Unterschied zwischen linkeddevices und devices nicht ganz klar, braucht man beide?
c : ist bei mir im Gerätetab alles zugespamt nach der Installation mit ca 100 Geräten die ich auch nicht löschen kann.Das ist auf jedenfall ein Mamutprojekt was viel Arbeit sein wird. Aber für die Übersichtlichkeit wird es ein großer Gewinn sein.
Ich habe mich gestern noch etwas mit dem Devices Adapter beschäftigt. Je länger ich damit gespielt habe, desto besser gefällt mir das Konzept. Meiner Meinung nach sollte das integraler Bestandteil von ioBroker sein und nicht ein separater Adapter, den man installieren kann (oder auch nicht).
Bei mir ist es im Grunde so, dass ich in der Visualisierung und in Alexa fast 1:1 die selben Geräte benötige. Momentan muss ich diese mehrfach konfigurieren. Wenn der Devices Adapter zwingend in ioBroker integriert ist, dann können andere Adapter diese Geräte nutzen und als Adapter Entwickler spart man sich einen großen Teil Arbeit für die Konfiguration und kann sich dadurch auf die wesentlichen Teile des Adapters konzentrieren.
Bzgl. der zu implementierenden Gerätetemplates muss es in jedem Fall die Möglichkeit geben ein Gerät komplett selber zu definieren, weil wir am Ende ziemlich sicher nicht alle Geräte implementieren können die die User so haben werden und evtl. steuern möchten. Ich denke da z.B. an die jetzige Implementierung eines Thermostats vs. HomeMatic Thermostat mit seinen unterschiedlichen Modi (Party Mode, etc.).
Rund wird die Sache, wenn der Devices Adapter andere Adapter erkennen könnte, die zusätzliche Konfigurationsmöglichkeiten bieten: z.B. zusätzliche Aliasnamen für Alexa ("Schlafzimmer Rolladen" und "Rolladen Darkroom" :-) ) oder das Ausblenden von Geräten in einer Visualisierung. Alternativ (aber nicht so schön) könnte es auch anders herum sein indem zusätzliche Konfigurationsmöglichkeiten in die Geräte Objekte geschrieben werden.
Die Punkte von @Meistertr möchte ich noch ergänzen um
d: Was sind Info-Geräte und wofür braucht man die? -
@tombox sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Was ist der genau Vorteil von aliases außer die Austauschbarkeit? Denn ich zb bin sehr faul und habe noch nie ein alias angelegt.
Naja am Ende siehe oben :-)
Austauschbarkeit und die Möglichkeit "zusammengepuzzelt" ganz eigene Geräte bzw Objektstrukturen als Mischung aus verschiedenen Adaptern zusammenzubauen.Denn das devicemapping unter commons ist ja implizit schon bei den meisten Adaptern enthalten die gut gepflegt roles haben. Man müsste nur den type fest definieren anstatt den device detector es raten zu lassen.
Ich glaube das ist zu kurz gedacht (meiner Meinung nach). Vor allem zeigt die Erfahrung das sehr viel Raten und interpretieren nötig ist und wenn ich mir die 60 Gerätetypen von Amazon ansehe bin ich nicht sicher ob es reicht ... Du hast das alles für Google-Home gebaut und weisst an sich daher wie schwierig es ist das sicher zuzuordnen, oder ?!
eine Rolle value.temperature kann die aktuell gesetzte Temperatur sein, die Zieltemperatur sein und vllt min und max oder sonst was ... Rollen sind aus der aktuellen Erfahrung nicht eindeutig genug. Man kann das ggf nur lösen indem man die Rollen massiv erweitert, was es dann am Ende wieder auch nicht einfacher macht.
@apollon77 ok verstehe ich aber ich würde soviel Verantwortung wie möglich in die Hand der Adapter Entwickler geben damit der Endnutzer nur noch alias benutzen muss wenn er basteln will. Das heißt jedes device und Channel muss ein smarthome Type haben. Jeder der Types hat mandatory roles die an states vergeben werden müssen. Wenn das nicht passiert gibt der Js Controller warnings aus.
-
Devices, Aliasses, Assistenten und Visualisierungen und die Zukunft
Die Einführung von Aliasses in den js-controller und die ersten Versionen des "Devices"-Adapters waren nur der Anfang. WIr haben einiges damit vor.
Dieser Beitrag soll einige der Ideen und Gründe darstellen und zur Diskussion einladen. Noch ist nichts in Stein gemeisselt und das alles umzusetzen wird auch nicht wenig Aufwand, aber gemeinsam können wir in diese Richtung arbeiten.
Aktuelle Realität und die Probleme ...
Ein grosser Vorteil von ioBroker ist seine Flexibilität. Jeder Adapter kann seine Objekte und Zustände frei strukturieren. Das wird auch fleissig angewendet :)
Die Große Herausforderung ist allerdings, das Visualisierungs-Adapter und auch die Assistenzsystem-Adapter - iot vor allem für Amazon Alexa und Google/Next Home, aber auch yahka für Homekit - Informationen brauchen was einzelne Zustände darstellen und ob/wie mehrere Zustände zusammengehören. Ziel ist ja, dass diese Adapter mit wenig zusätzlichem Aufwand für den User Ihr Arbeit verrichten und die Geräte bedienbar machen.
Über Objekttypen wie "device" und "channel" oder im Notfall "folder" kann ein Adapter Zustände gruppieren und do dem User und auch anderen Adaptern mehr Informationen zu den Zuständen geben. Die Idee von "device" und "channel" kommt aus der Homematic Ecke und funktioniert dort recht gut. Ob ein Adapter das nutzen kann hängt aber stark von den Geräten und Kommunikationsprotokollen ab. Auch Adapter wo eine Instanz nur ein Gerät anbindet hat üblicherweise dann kein "device" Objekt.
Die Rollenangabe bei den Zuständen sind ein weiterer Weg Informationen darüber bereitzustellen was ein Zustand darstellt und bedeutet. Wir ersuchen bei allen Adaptern darauf zu achten das die Rollen Sinn machen. Ob aber eine Rolleninformation zur Verfügung steht ist auch eine Frage des Kommunikationsprotokolls. Der mqtt Adapter könnte gar keine Rollen für die Zustände bereitstellen, weil er es selbst nicht weiss.
Die aktuellen Visualisierungs- bzw. Assistenten-Adapter benötigen daher aktuell entweder umfangreiche Konfiguration oder können immer nur einen einzelnen State steuern oder müssen "Zusammenhänge erraten". Material als Beispiel nutz eine sog. "type detector" Library die versucht anhang von Rollen UND Device/Channel Strukturen zu erkennen was zusammen gehört und wie man es sinnvoll darstellen kann. Damit das aber immer funktioniert müssen die Zustände auch eine entsprechenden Aufbau haben - im Zweifel müssen also Adapter aufwändig angepasst werden.
Bei Amazon Alexa gibt es inzwischen für die Smart-Home-Skills die Version 3 (ioBroker nutzt noch Version 2) - hier sind es anstelle der ca. 10 Gerätetypen von v2 plötzlich ca. 60! Das ganze auf die gleiche Weise zu Mappen wir aktuell ist unmöglich. Daher müsste man die ganze Arbeit auf den user abwälzen.Weiterhin war es bisher auch beim Tausch von Geräten (z.B. wegen Defekten) immer schwierig in Bezug auf eigene Skripte oder z.B. Szenen. Meist ändert sich mit der Seriennummer des Geräts auch die Objekt-ID - oder Sie ändert sich beim Wechsel des Protokolls ganz. Dann muss man alle Skripte und auch die Visualisierungen bzw. andere betoffenen Adapter raussuchen und anpassen. Das ist recht aufwändig.
Erste Schritte: Aliasses und der Basis-Devices Adapter
Bei der Einführung der Aliasse haben wir bisher primär den einfachen Gerätetausch und weniger nötige Anpassungen an Skripten oder Visualisierungs-Adaptern propagiert. Und ja, diese Themen können damit bereits umgangen werden.
Unter dem reservierten Namensbereich alias.0 können Objekte angelegt werden, die auf ein anderes Objekt vom Type "state" verweisen. Dabei kann das neue Objekt auch einen anderen Datentyp o.ä. anbieten und auch Werte in beide Richtungen umrechnen. Der Zustand dieses Alias-Objekts hängt immer an dem Zustand des entsprechenden Quell-Objekts.
So weit so gut.
Um das wenigstens rudimentär zu bearbeiten wurde der Devices-Adapter programmiert, der versucht Geräte im System zu finden. Er beachtet dabei "device" Objekte und unterstützt auch Quasi-Aliasse vom "linkeddevices"-Adapter. Das ganze wirkt etwas Chaotisch und da muss garantiert noch viel dran getan werden.Beim Anlegen eines neuen Geräts wird dieses in alias.0 angelegt und man kann den Gerätetyp wählen. Passed zu diesem werden dann eine Liste von "Standard"-Objekten/Zuständen angezeigt die man mit den verlinkten IDs füllt. Diese Standard-Objekte haben das Ziel das am Ende alle über Devices angelegten "Schalter" bzw. "Lampen" o.ä. identisch aussehen, die korrekten Rollen und Datentypen haben. Somit kann man auch ein Licht welches zB per mqtt angebunden ist eine Definition verpassen, sodass Visualisierungs- bzw. Assistenz-Adapter wissen was es ist und wie es dann angezeigt werden muss.
Aktuell ist die Anzahl der Gerätetypen noch eher überschaubar, aber es ist ja auch nur der Anfang. Es gibt auch Helfer-Skripte im Forum die in alias.0 einfach Erlauben verknüpfte Objekte anzulegen.
Aber ja, so richtig gross ist der Mehrwert aktuell noch nicht, das ist uns bewusst.... aber die Zukunft wird besser
In den nächsten Abschnitten möchte ich Euch so ein bisschen über die Pläne und Ideen erzählen die wir auf dieser Basis angehen wollen.
Schritt 1: Gerätetypen und "Objekt-Templates"
Wie oben schon erwähnt, definiert Amazon für die Alexa Welt aktuell über 60 Gerätetypen, die alle unterschiedliche Werte als nötige bzw. optionale Felder haben. Bei Google gibt es ähnliches. Viele davon sind auch für Visualisierungen interessant, weil man am "Typ" eines Geräts sehr gut entscheiden kann wie man es anzeigen und bedienen sollte - und das viel besser als zu raten :-)
Daher ist die Idee das wir, angefangen mit den Amazon- und Google Objekttypen den Devices Adapter um diese erweitern und in diesem Zuge für ioBroker Standardisieren - Standard bezüglich Pflicht und Standard-optionalen States(z.B. SET, ACTIUAL, COLOR, STATE ...). Gern kann man überlegen dazu weitere States "nutzerdefiniert" hinzufügen zu lassen, die aber dann von den ganzen nutzenden Adaptern ignoriert werden!
Das ganze wird dann als alias angelegt. Zusätzlich speichern wir im "device"-Objekt die Information zum genutzten Template. Dann muss man das danach nicht nochmals raussuchen.
Das bringt uns schon mal einen großen Schritt weiter: In Adaptern wählt man das "Device" Objekt aus und alle Informationen sind bekannt und ebenso welcher State-Name in dem Device Objekt was bedeutet. So muss kein Adapter mehr raten. Dem Type-Detector können wir auch so beibringen alles viel besser zu erkennen. Der grosse Vorteil ist aber das Adapter wie z.B. iot das ganze dann auch sehr gut zu den relevanten Amazon bzw Google-typen zuordnen können.
Die "Magie" liegt nur darin die Templates sinnvoll zu defineren. (Und natürlich muss iot irgendwie noch Rückwärts-Kompatibel bleiben damit alles noch so funktioniert wie aktuell - aber hier könnte man durchaus einmalig mit einer neuen Version automatisch aus allen zugeordneten Smart-Devices einmalig kompatible ALias Objekte anlegen, sodass iot danach direkt damit arbeiten kann).Weiterhin sind so angelegte Aliasse unabhängig von den originalen Objekten und ein solches Alias-Gerät kann bei einem Gerätewechsel einfach mit einem neuen Objekt-Mapping versehen werden und schon ist das Gerät getauscht - ohne das sich die Objekt-IDs des Alias-Geräts ändern.
Auch könnte man in den Templates (oder auch so generell) Objekte die im Admin nicht für "jedermann" angezeigt werden sollen über "common.expert=true" verstecken. Ein Objekt mit dieser Information wird seit Admin 3.4.8 nur noch im Expertenmodus angezeigt.
Schritt 2: Geräte-Guidance durch Adapter
Wenn das alles mal implementiert ist kann man Adapter-Entwicklen anbieten Ihre "device"/"channel"-Objekte um Meta-Daten zu erweitern. So könnte man zB seinen Geräten mitgeben was Sie für ein Gerätetype sind und wie die eigenen States zugeordnet sind zu den States die das Geräte-Template bietet. Das ist natürlich optional, aber bietet die Möglichkeit bei der Zuordnung direkt ein sinnvoll passende vorausgefüllte Maske anzubieten.
Zum Beispiel im "common" Bereich des Objekts sowas (am Beispiel einer Daikin-Adapter Objekts, State angaben relativ zum Device-Objekt):
"deviceMapping": { "template": "thermostat", "fields": { "SET": "control.targetTemperature", "ACTUAL": "sensorInfo.indoorTemperature", "HUMIDITY": "sensorInfo.indoorHumidity", "BOOST": "control.specialPowerful", "POWER": "control.power" } }Mit so einer Definition könnte müsste ein User sogar nicht einmal Alias-Geräte nutzen, weil auch hier alle Informationen für Visualisierungs- oder Assistenten-Adapter vorhanden wären. Dann könne auch das State direkt genutzt werden.
Schritt 3: Der "Geräte-Posteingang"
Aktuell haben wir 40k ioBroker Installationen, die alle noch keine solchen Gerätedefinitionen und Aliasse haben. Ebenso neue User kenne sich mit der Idee noch nicht so aus.
Die Idee wäre also hier, dass der Geräte Adapter mittelfristig standardmäßig mit installiert wird. Und wir ändern die UI: Die Standard-Ansicht zeigt nur Aliasse an und alles was keine Aliasse sind landet in einer zweiten Ansicht ... einer Liste wie ein Posteingang. Alle neuen "Device Objekte" von Adaptern werden dort aufgelistet und können zu einem Alias-Gerät gemacht werden. Am Ende ist das natürlich kein "muss" sondern ein Kann ... vllt finden wir auch einen neutraleren Namen als "Posteingang" ;-) Aber alles was hier drin ist kann man auf Klick und mit Wahn eines Gerätetyps und dann zuordnen von States in ein neues Alias-Gerät überführen. Ja die UI wird etwas Tricky das das sinnvoll bedienbar wird, da muss etwas Gehirnschmalz rein. Für einen neuen User kann man das in den Standardprozess mit einbauen: Adapter findet neues Gerät, gehe zu "Geräte" und ordne es zu (wenn er will). :-)
Schlussworte
So, das wäre die große Idee. Jetzt kommt Ihr? Macht das sinn? Ist das eine sinnvolle Richtung?
Bevor wir jetzt aber beginnen über Namen von States o.ä. zu diskutieren, lasst mal mit dem generellen Konzept beginnen. :-) Also bitte diskutiert (noch) nicht zu "Kleinteilig" ...
Nächste Schritte
Sinnvolle nächste Schritte wären genau das erste Set von Gerätetypen und deren States, Pflicht oder Optional und Bezeichnungen zu diskutieren. In meinen Augen sollten wir hier, auch in Richtung des grossen Amazon-v3-Skill-Vorhabens, mit den Geräte-Definitionen von Amazon und Google starten. Im Devices Adapter können wir ein Projekt anlegen. Pro Gerätetype ein Issue und dort einzeln finalisieren. Danach kann man die Implementieren.
Danach würde man die nächsten Schritte finalisieren.
So, jetzt... viel Spass beim (konstruktiven) Feedback geben und mitdiskutieren!
Ingo
Randbemerkung:
@apollon77 sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:Der mqtt Adapter könnte gar keine Rollen für die Zustände bereitstellen, weil er es selbst nicht weiss.
Da kann man sicher eingreifen und zumindest teilweise Rollen Automatisch durch raten vergeben genau so wie andere commons. Die Funktion um Objekte durch raten zu ergänzen könnte einfach in den js-controller integriert werden, dann würden alle Adapter davon Profitieren ohne daß jeder Entwickler sich darum kümmern muss.
Mein Ansatz dazu wäre die Auswertung der gelieferten Daten. Also Name des Objekts, Werte Typ, Kategorie des Adapters, und was man noch so finden kann an Informationen.
Beispiel: Objekt mit dem Namen (oder darin enthalten) Temperatur -> Rolle value.Temperatur -> übernehmen aller mandatory commons -> Unit: Standard der ioBroker InstallationEine weitere Idee: Die Objektdefinitionen sollten in einer Objekts.js(on) im Adapter abgelegt werden so daß es einheitlich ist und auch von nicht Entwicklern bei der Pflege geholfen werden kann. Aktuell ist es teilweise schwer bis unmöglich bei manchen Adaptern heraus zu finden wo und wie die Objekte aufgebaut werden. Was keinen Spaß macht wenn man eine Definition anpassen will.
Einige Adapter verfolgen diesen Ansatz mit der Zentralen Objektdefinition ja schon, bis jetzt gibt es da noch kein einheitlichen Standard. Ich würde mich freuen wenn das in Zukunft vereinheitlicht und zur Pflicht wird. Es ist klar das gleich wieder einige rufen werden daß geht nicht weil... Sehe ich nicht so, das es geht und Praktikabel ist sehe ich ja an meinen Adaptern.
Meiner Meinung nach sollte auf Adapter Ebene noch deutlich mehr Wert darauf gelegt werden daß die Definitionen da sind und eine Grundstruktur ein gehalten wird. Ganz klar das geht nicht immer, aber es wird noch lange nicht so gut genutzt wie möglich.
Zum Thema:
Ich bin kein Fan von davon so viel zu Überhauen und deswegen sollte das minimiert werden. Da wo es eben nicht geht sollte es so gestaltet werden daß User davon nur etwas sehen wenn es wirklich nötig ist. Und Adapter Entwickler sich damit nicht beschäftigen müssen, außer natürlich sie müssen damit direkt Arbeiten, was dann eine Ausnahme sein sollte.Das Konzept ist sonst in Ordnung, weil es wohl keine bessere Lösung gibt.
@braindead sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Meiner Meinung nach sollte das integraler Bestandteil von ioBroker sein
Dem Schließe ich mich an.
-
Ich finde das erstellen der Geräte eine super Sache, gerade der neue/unerfahrene Nutzer wird von der Menge an States erschalgen.
Muss aber auch sagen, dass ich bis lang mit dem "Geräte" Adapter noch nicht gearbeitet habe:
a: findet man ihn ganz schlecht in der Adapterliste
b: ist mir der Unterschied zwischen linkeddevices und devices nicht ganz klar, braucht man beide?
c : ist bei mir im Gerätetab alles zugespamt nach der Installation mit ca 100 Geräten die ich auch nicht löschen kann.Das ist auf jedenfall ein Mamutprojekt was viel Arbeit sein wird. Aber für die Übersichtlichkeit wird es ein großer Gewinn sein.
@Meistertr
a) Kann man ja verbessern :-)
b) AM Ed eist es das gleiche, nur anders gemacht - einmal über adlias (Devices) oder über einen Adater (linkeddevices).
c) Das wäre ja genau eins der Themen. Das aktuelle wäre quasi der Posteingang :-) -
@apollon77 ok verstehe ich aber ich würde soviel Verantwortung wie möglich in die Hand der Adapter Entwickler geben damit der Endnutzer nur noch alias benutzen muss wenn er basteln will. Das heißt jedes device und Channel muss ein smarthome Type haben. Jeder der Types hat mandatory roles die an states vergeben werden müssen. Wenn das nicht passiert gibt der Js Controller warnings aus.
-
Ich bin gerade vom Zigbee Stick auf das Board umgestiegen und hatte exakt das Problem. Viele Skripte funktionieren nicht mehr, Alexa findet meine Geräte nicht. Ich finde den Ansatz super, besonders mit dem Fokus auf Alexa und Google.
Programmieren kann ich leider nicht, aber helfen würde ich sehr gerne!
Wie wäre es die 60 Gerätetypen von Alexa in einer Google Tabelle (o.Ä.) zu erfassen?Der Geräte Adapter ist für mich aktuell noch nicht ganz klar: z.B. bei einem LED RGB Lightstrip. Muss ich Licht, RGB-Licht, Farbtemperatur oder RGB-Licht single nehmen? Die darauf folgenden Typen sind mir auch nicht ganz verständlich.
-
Ich bin gerade vom Zigbee Stick auf das Board umgestiegen und hatte exakt das Problem. Viele Skripte funktionieren nicht mehr, Alexa findet meine Geräte nicht. Ich finde den Ansatz super, besonders mit dem Fokus auf Alexa und Google.
Programmieren kann ich leider nicht, aber helfen würde ich sehr gerne!
Wie wäre es die 60 Gerätetypen von Alexa in einer Google Tabelle (o.Ä.) zu erfassen?Der Geräte Adapter ist für mich aktuell noch nicht ganz klar: z.B. bei einem LED RGB Lightstrip. Muss ich Licht, RGB-Licht, Farbtemperatur oder RGB-Licht single nehmen? Die darauf folgenden Typen sind mir auch nicht ganz verständlich.
Hallo zusammen
@apollon77Ich finde die Idee des Adapters wunderbar, aber ich kann ihn leider nicht testen / nutzen.
Wenn ich ein Gerät hinzufügen möchte, ist die Liste quasi nicht sichtbar. Zoomen im Browser hilft nicht... Leider
Hier ein paar Screens dazu
Systeminfo
Debian Betriebssystem linux Betriebssystem linux Architektur x64 CPUs 4 Geschwindigkeit 2096 MHz Modell AMD Opteron 22xx (Gen 2 Class Opteron) RAM 17.64 GB System Betriebszeit 4 T. 04:35:55 Node.js v12.18.2 NPM 6.14.5 Festplatte Größe 80.21 GB Festplatte frei 66.92 GB Anzahl der Adapter 355 Betriebszeit 00:14:46 Aktive Instanzen 33 Hostname DebianKann mir da jemand helfen bitte?
Dankesehr!!!
-
@lemonbiter Das Problem liegt wahrscheinlich an dem Darkmode Deines Browsers. Der ioBroker scheint damit nicht richtig umzugehen. Probier mal, ob es funktioniert, wenn Du den Darkmode deaktivierst.
P.S.: Ich freu mich schon auf die Zeit nach Corona, wenn wir uns wieder bei Dir zum HomeMatic Stammtisch treffen können. :-)
-
Hallo zusammen
@apollon77Ich finde die Idee des Adapters wunderbar, aber ich kann ihn leider nicht testen / nutzen.
Wenn ich ein Gerät hinzufügen möchte, ist die Liste quasi nicht sichtbar. Zoomen im Browser hilft nicht... Leider
Hier ein paar Screens dazu
Systeminfo
Debian Betriebssystem linux Betriebssystem linux Architektur x64 CPUs 4 Geschwindigkeit 2096 MHz Modell AMD Opteron 22xx (Gen 2 Class Opteron) RAM 17.64 GB System Betriebszeit 4 T. 04:35:55 Node.js v12.18.2 NPM 6.14.5 Festplatte Größe 80.21 GB Festplatte frei 66.92 GB Anzahl der Adapter 355 Betriebszeit 00:14:46 Aktive Instanzen 33 Hostname DebianKann mir da jemand helfen bitte?
Dankesehr!!!
@ Braindead
Hat sich erledigt, sehe gerade, dass Du mir dieselbe Auskunft gibst, auf die ich eben auch kam ... :-) Dennoch Danke Dir!
Ist tatsächlich ein Darstellungsfehler: Wenn man den Script Adapter auf "Dunkler Stil" stehen hat, dann kommt es zu diesem Darstellungsproblem im Devices Adapter.
Habe nun im Scripte Adapter die Darstellung wieder auf "Heller Stil" stehen und nun ist die Anzeige hier auch korrekt.
Viele Grüße
Lem -
Ich bin gerade vom Zigbee Stick auf das Board umgestiegen und hatte exakt das Problem. Viele Skripte funktionieren nicht mehr, Alexa findet meine Geräte nicht. Ich finde den Ansatz super, besonders mit dem Fokus auf Alexa und Google.
Programmieren kann ich leider nicht, aber helfen würde ich sehr gerne!
Wie wäre es die 60 Gerätetypen von Alexa in einer Google Tabelle (o.Ä.) zu erfassen?Der Geräte Adapter ist für mich aktuell noch nicht ganz klar: z.B. bei einem LED RGB Lightstrip. Muss ich Licht, RGB-Licht, Farbtemperatur oder RGB-Licht single nehmen? Die darauf folgenden Typen sind mir auch nicht ganz verständlich.
@adsfa said in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Der Geräte Adapter ist für mich aktuell noch nicht ganz klar: z.B. bei einem LED RGB Lightstrip. Muss ich Licht, RGB-Licht, Farbtemperatur oder RGB-Licht single nehmen? Die darauf folgenden Typen sind mir auch nicht ganz verständlich.
Ja, da fehlt leider noch eine Beschreibung der Geräte und auch der States, finde ich... aktuell muss man viel raten.
Was du in deinem Fall nehmen musst ist RGB-Licht oder RGB-Licht Single, das hängt davon ab, ob du einzelne States für r/g/b hast oder einen in den RGB als Hex-String eingetragen wird. Farbtemperatur enthalten beide als optionalen Zusatz. -
Devices, Aliasses, Assistenten und Visualisierungen und die Zukunft
Die Einführung von Aliasses in den js-controller und die ersten Versionen des "Devices"-Adapters waren nur der Anfang. WIr haben einiges damit vor.
Dieser Beitrag soll einige der Ideen und Gründe darstellen und zur Diskussion einladen. Noch ist nichts in Stein gemeisselt und das alles umzusetzen wird auch nicht wenig Aufwand, aber gemeinsam können wir in diese Richtung arbeiten.
Aktuelle Realität und die Probleme ...
Ein grosser Vorteil von ioBroker ist seine Flexibilität. Jeder Adapter kann seine Objekte und Zustände frei strukturieren. Das wird auch fleissig angewendet :)
Die Große Herausforderung ist allerdings, das Visualisierungs-Adapter und auch die Assistenzsystem-Adapter - iot vor allem für Amazon Alexa und Google/Next Home, aber auch yahka für Homekit - Informationen brauchen was einzelne Zustände darstellen und ob/wie mehrere Zustände zusammengehören. Ziel ist ja, dass diese Adapter mit wenig zusätzlichem Aufwand für den User Ihr Arbeit verrichten und die Geräte bedienbar machen.
Über Objekttypen wie "device" und "channel" oder im Notfall "folder" kann ein Adapter Zustände gruppieren und do dem User und auch anderen Adaptern mehr Informationen zu den Zuständen geben. Die Idee von "device" und "channel" kommt aus der Homematic Ecke und funktioniert dort recht gut. Ob ein Adapter das nutzen kann hängt aber stark von den Geräten und Kommunikationsprotokollen ab. Auch Adapter wo eine Instanz nur ein Gerät anbindet hat üblicherweise dann kein "device" Objekt.
Die Rollenangabe bei den Zuständen sind ein weiterer Weg Informationen darüber bereitzustellen was ein Zustand darstellt und bedeutet. Wir ersuchen bei allen Adaptern darauf zu achten das die Rollen Sinn machen. Ob aber eine Rolleninformation zur Verfügung steht ist auch eine Frage des Kommunikationsprotokolls. Der mqtt Adapter könnte gar keine Rollen für die Zustände bereitstellen, weil er es selbst nicht weiss.
Die aktuellen Visualisierungs- bzw. Assistenten-Adapter benötigen daher aktuell entweder umfangreiche Konfiguration oder können immer nur einen einzelnen State steuern oder müssen "Zusammenhänge erraten". Material als Beispiel nutz eine sog. "type detector" Library die versucht anhang von Rollen UND Device/Channel Strukturen zu erkennen was zusammen gehört und wie man es sinnvoll darstellen kann. Damit das aber immer funktioniert müssen die Zustände auch eine entsprechenden Aufbau haben - im Zweifel müssen also Adapter aufwändig angepasst werden.
Bei Amazon Alexa gibt es inzwischen für die Smart-Home-Skills die Version 3 (ioBroker nutzt noch Version 2) - hier sind es anstelle der ca. 10 Gerätetypen von v2 plötzlich ca. 60! Das ganze auf die gleiche Weise zu Mappen wir aktuell ist unmöglich. Daher müsste man die ganze Arbeit auf den user abwälzen.Weiterhin war es bisher auch beim Tausch von Geräten (z.B. wegen Defekten) immer schwierig in Bezug auf eigene Skripte oder z.B. Szenen. Meist ändert sich mit der Seriennummer des Geräts auch die Objekt-ID - oder Sie ändert sich beim Wechsel des Protokolls ganz. Dann muss man alle Skripte und auch die Visualisierungen bzw. andere betoffenen Adapter raussuchen und anpassen. Das ist recht aufwändig.
Erste Schritte: Aliasses und der Basis-Devices Adapter
Bei der Einführung der Aliasse haben wir bisher primär den einfachen Gerätetausch und weniger nötige Anpassungen an Skripten oder Visualisierungs-Adaptern propagiert. Und ja, diese Themen können damit bereits umgangen werden.
Unter dem reservierten Namensbereich alias.0 können Objekte angelegt werden, die auf ein anderes Objekt vom Type "state" verweisen. Dabei kann das neue Objekt auch einen anderen Datentyp o.ä. anbieten und auch Werte in beide Richtungen umrechnen. Der Zustand dieses Alias-Objekts hängt immer an dem Zustand des entsprechenden Quell-Objekts.
So weit so gut.
Um das wenigstens rudimentär zu bearbeiten wurde der Devices-Adapter programmiert, der versucht Geräte im System zu finden. Er beachtet dabei "device" Objekte und unterstützt auch Quasi-Aliasse vom "linkeddevices"-Adapter. Das ganze wirkt etwas Chaotisch und da muss garantiert noch viel dran getan werden.Beim Anlegen eines neuen Geräts wird dieses in alias.0 angelegt und man kann den Gerätetyp wählen. Passed zu diesem werden dann eine Liste von "Standard"-Objekten/Zuständen angezeigt die man mit den verlinkten IDs füllt. Diese Standard-Objekte haben das Ziel das am Ende alle über Devices angelegten "Schalter" bzw. "Lampen" o.ä. identisch aussehen, die korrekten Rollen und Datentypen haben. Somit kann man auch ein Licht welches zB per mqtt angebunden ist eine Definition verpassen, sodass Visualisierungs- bzw. Assistenz-Adapter wissen was es ist und wie es dann angezeigt werden muss.
Aktuell ist die Anzahl der Gerätetypen noch eher überschaubar, aber es ist ja auch nur der Anfang. Es gibt auch Helfer-Skripte im Forum die in alias.0 einfach Erlauben verknüpfte Objekte anzulegen.
Aber ja, so richtig gross ist der Mehrwert aktuell noch nicht, das ist uns bewusst.... aber die Zukunft wird besser
In den nächsten Abschnitten möchte ich Euch so ein bisschen über die Pläne und Ideen erzählen die wir auf dieser Basis angehen wollen.
Schritt 1: Gerätetypen und "Objekt-Templates"
Wie oben schon erwähnt, definiert Amazon für die Alexa Welt aktuell über 60 Gerätetypen, die alle unterschiedliche Werte als nötige bzw. optionale Felder haben. Bei Google gibt es ähnliches. Viele davon sind auch für Visualisierungen interessant, weil man am "Typ" eines Geräts sehr gut entscheiden kann wie man es anzeigen und bedienen sollte - und das viel besser als zu raten :-)
Daher ist die Idee das wir, angefangen mit den Amazon- und Google Objekttypen den Devices Adapter um diese erweitern und in diesem Zuge für ioBroker Standardisieren - Standard bezüglich Pflicht und Standard-optionalen States(z.B. SET, ACTIUAL, COLOR, STATE ...). Gern kann man überlegen dazu weitere States "nutzerdefiniert" hinzufügen zu lassen, die aber dann von den ganzen nutzenden Adaptern ignoriert werden!
Das ganze wird dann als alias angelegt. Zusätzlich speichern wir im "device"-Objekt die Information zum genutzten Template. Dann muss man das danach nicht nochmals raussuchen.
Das bringt uns schon mal einen großen Schritt weiter: In Adaptern wählt man das "Device" Objekt aus und alle Informationen sind bekannt und ebenso welcher State-Name in dem Device Objekt was bedeutet. So muss kein Adapter mehr raten. Dem Type-Detector können wir auch so beibringen alles viel besser zu erkennen. Der grosse Vorteil ist aber das Adapter wie z.B. iot das ganze dann auch sehr gut zu den relevanten Amazon bzw Google-typen zuordnen können.
Die "Magie" liegt nur darin die Templates sinnvoll zu defineren. (Und natürlich muss iot irgendwie noch Rückwärts-Kompatibel bleiben damit alles noch so funktioniert wie aktuell - aber hier könnte man durchaus einmalig mit einer neuen Version automatisch aus allen zugeordneten Smart-Devices einmalig kompatible ALias Objekte anlegen, sodass iot danach direkt damit arbeiten kann).Weiterhin sind so angelegte Aliasse unabhängig von den originalen Objekten und ein solches Alias-Gerät kann bei einem Gerätewechsel einfach mit einem neuen Objekt-Mapping versehen werden und schon ist das Gerät getauscht - ohne das sich die Objekt-IDs des Alias-Geräts ändern.
Auch könnte man in den Templates (oder auch so generell) Objekte die im Admin nicht für "jedermann" angezeigt werden sollen über "common.expert=true" verstecken. Ein Objekt mit dieser Information wird seit Admin 3.4.8 nur noch im Expertenmodus angezeigt.
Schritt 2: Geräte-Guidance durch Adapter
Wenn das alles mal implementiert ist kann man Adapter-Entwicklen anbieten Ihre "device"/"channel"-Objekte um Meta-Daten zu erweitern. So könnte man zB seinen Geräten mitgeben was Sie für ein Gerätetype sind und wie die eigenen States zugeordnet sind zu den States die das Geräte-Template bietet. Das ist natürlich optional, aber bietet die Möglichkeit bei der Zuordnung direkt ein sinnvoll passende vorausgefüllte Maske anzubieten.
Zum Beispiel im "common" Bereich des Objekts sowas (am Beispiel einer Daikin-Adapter Objekts, State angaben relativ zum Device-Objekt):
"deviceMapping": { "template": "thermostat", "fields": { "SET": "control.targetTemperature", "ACTUAL": "sensorInfo.indoorTemperature", "HUMIDITY": "sensorInfo.indoorHumidity", "BOOST": "control.specialPowerful", "POWER": "control.power" } }Mit so einer Definition könnte müsste ein User sogar nicht einmal Alias-Geräte nutzen, weil auch hier alle Informationen für Visualisierungs- oder Assistenten-Adapter vorhanden wären. Dann könne auch das State direkt genutzt werden.
Schritt 3: Der "Geräte-Posteingang"
Aktuell haben wir 40k ioBroker Installationen, die alle noch keine solchen Gerätedefinitionen und Aliasse haben. Ebenso neue User kenne sich mit der Idee noch nicht so aus.
Die Idee wäre also hier, dass der Geräte Adapter mittelfristig standardmäßig mit installiert wird. Und wir ändern die UI: Die Standard-Ansicht zeigt nur Aliasse an und alles was keine Aliasse sind landet in einer zweiten Ansicht ... einer Liste wie ein Posteingang. Alle neuen "Device Objekte" von Adaptern werden dort aufgelistet und können zu einem Alias-Gerät gemacht werden. Am Ende ist das natürlich kein "muss" sondern ein Kann ... vllt finden wir auch einen neutraleren Namen als "Posteingang" ;-) Aber alles was hier drin ist kann man auf Klick und mit Wahn eines Gerätetyps und dann zuordnen von States in ein neues Alias-Gerät überführen. Ja die UI wird etwas Tricky das das sinnvoll bedienbar wird, da muss etwas Gehirnschmalz rein. Für einen neuen User kann man das in den Standardprozess mit einbauen: Adapter findet neues Gerät, gehe zu "Geräte" und ordne es zu (wenn er will). :-)
Schlussworte
So, das wäre die große Idee. Jetzt kommt Ihr? Macht das sinn? Ist das eine sinnvolle Richtung?
Bevor wir jetzt aber beginnen über Namen von States o.ä. zu diskutieren, lasst mal mit dem generellen Konzept beginnen. :-) Also bitte diskutiert (noch) nicht zu "Kleinteilig" ...
Nächste Schritte
Sinnvolle nächste Schritte wären genau das erste Set von Gerätetypen und deren States, Pflicht oder Optional und Bezeichnungen zu diskutieren. In meinen Augen sollten wir hier, auch in Richtung des grossen Amazon-v3-Skill-Vorhabens, mit den Geräte-Definitionen von Amazon und Google starten. Im Devices Adapter können wir ein Projekt anlegen. Pro Gerätetype ein Issue und dort einzeln finalisieren. Danach kann man die Implementieren.
Danach würde man die nächsten Schritte finalisieren.
So, jetzt... viel Spass beim (konstruktiven) Feedback geben und mitdiskutieren!
Ingo
@apollon77 said in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:
Schritt 1: Gerätetypen und "Objekt-Templates"
Wie oben schon erwähnt, definiert Amazon für die Alexa Welt aktuell über 60 Gerätetypen, die alle unterschiedliche Werte als nötige bzw. optionale Felder haben. Bei Google gibt es ähnliches. Viele davon sind auch für Visualisierungen interessant, weil man am "Typ" eines Geräts sehr gut entscheiden kann wie man es anzeigen und bedienen sollte - und das viel besser als zu raten
Daher ist die Idee das wir, angefangen mit den Amazon- und Google Objekttypen den Devices Adapter um diese erweitern und in diesem Zuge für ioBroker Standardisieren - Standard bezüglich Pflicht und Standard-optionalen States(z.B. SET, ACTIUAL, COLOR, STATE ...). Gern kann man überlegen dazu weitere States "nutzerdefiniert" hinzufügen zu lassen, die aber dann von den ganzen nutzenden Adaptern ignoriert werden!
Das ganze wird dann als alias angelegt. Zusätzlich speichern wir im "device"-Objekt die Information zum genutzten Template. Dann muss man das danach nicht nochmals raussuchen.
Das bringt uns schon mal einen großen Schritt weiter: In Adaptern wählt man das "Device" Objekt aus und alle Informationen sind bekannt und ebenso welcher State-Name in dem Device Objekt was bedeutet. So muss kein Adapter mehr raten. Dem Type-Detector können wir auch so beibringen alles viel besser zu erkennen. Der grosse Vorteil ist aber das Adapter wie z.B. iot das ganze dann auch sehr gut zu den relevanten Amazon bzw Google-typen zuordnen können.
Die "Magie" liegt nur darin die Templates sinnvoll zu defineren. (Und natürlich muss iot irgendwie noch Rückwärts-Kompatibel bleiben damit alles noch so funktioniert wie aktuell - aber hier könnte man durchaus einmalig mit einer neuen Version automatisch aus allen zugeordneten Smart-Devices einmalig kompatible ALias Objekte anlegen, sodass iot danach direkt damit arbeiten kann).
Weiterhin sind so angelegte Aliasse unabhängig von den originalen Objekten und ein solches Alias-Gerät kann bei einem Gerätewechsel einfach mit einem neuen Objekt-Mapping versehen werden und schon ist das Gerät getauscht - ohne das sich die Objekt-IDs des Alias-Geräts ändern.
Auch könnte man in den Templates (oder auch so generell) Objekte die im Admin nicht für "jedermann" angezeigt werden sollen über "common.expert=true" verstecken. Ein Objekt mit dieser Information wird seit Admin 3.4.8 nur noch im Expertenmodus angezeigt.Also ich habe noch nicht wirklich verstanden, wo die "Objekt Templates" sich von den "Types" unterscheiden, die wir aktuell im type-detector haben (außer, dass es viel mehr sind, wenn man Google/Alexa als Grundlage nimmt). Oder gibt es da gar keinen fundamentalen Unterschied?
Wäre dann das Neue dann "einfach" viel mehr Types zu haben und den Typ statisch im Device zu speichern? grübel
Beim aktuellen System muss man ja darauf achten, dass es keine Mehrdeutigkeiten gibt bzw. wenn es die gibt, dass die Erkennung in der richtigen Reihenfolge passiert. Das erscheint mir, wenn man das deutlich erweitert, als üble Fehlerquelle. Die wird entschärft durch den fixen Typ, der dann durch Devices-Adapter oder, wenn Schritt 2 kommt, vom original Adapter definiert wird. Gibt es dann keine automatisierte Erkennung mehr?
Grundsätzlich gefällt mir das Konzept von alias & type-detector ganz gut. Das fix im Device zu speichern finde ich sehr sinnvoll. Das sollte man ganz sicher weiter entwickeln und eine Geräteansicht als zentralen Bestandteil für die User platzieren.
-
@apollon77 Ich wollte eben einen Eintrag mit dem Typ Instanz erstellen, seit dem kann ich kein Gerät mehr hinzufügen weil ich nur noch eine weiße Seite bekomme - Reboot brachte auch nichts und im Log steht auch nichts
-
@apollon77 Ich wollte eben einen Eintrag mit dem Typ Instanz erstellen, seit dem kann ich kein Gerät mehr hinzufügen weil ich nur noch eine weiße Seite bekomme - Reboot brachte auch nichts und im Log steht auch nichts
@Stephan-Schleich Typ Instanz??? Was wolltest Du damit ... ds ist reserviert für Adapter Instanzen!
Brower Konsole irgendein Fehler?
ggf an der Kommandozeile das Objekt wieder löschenBeitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@Stephan-Schleich Typ Instanz??? Was wolltest Du damit ... ds ist reserviert für Adapter Instanzen!
Brower Konsole irgendein Fehler?
ggf an der Kommandozeile das Objekt wieder löschen@apollon77 hab mich verklickt, es wurde kein Objekt angelegt zumindest seh ich keins.
Wenn ich den Adapter lösch sind alle aliase weg, kann ich die davor sichern? -
@apollon77 hab mich verklickt, es wurde kein Objekt angelegt zumindest seh ich keins.
Wenn ich den Adapter lösch sind alle aliase weg, kann ich die davor sichern?@Stephan-Schleich Aliasse sind nicht weg wenn DU Devices löschst. Wie kommst Du darauf?
Beitrag hat geholfen? Votet rechts unten im Beitrag :-) https://paypal.me/Apollon77 / https://github.com/sponsors/Apollon77
- Debug-Log für Instanz einschalten? Admin -> Instanzen -> Expertenmodus -> Instanz aufklappen - Loglevel ändern
- Logfiles auf Platte /opt/iobroker/log/… nutzen, Admin schneidet Zeilen ab
-
@Stephan-Schleich Aliasse sind nicht weg wenn DU Devices löschst. Wie kommst Du darauf?
@apollon77 in den Objekten verschwindet doch immer alles was mit dem Adapter zu tun hatte, den man deinstalliert.
Edit: Das Problem lag am Browser, Chache gelöscht und jetzt gehts wieder, so sah es aus
Support us
762
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge