Devices, Alias, Assistenten + Visualisierungen + die Zukunft

[lemonbiter]

@ 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

[Garfonso]

@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.

[Garfonso]

@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.

[Stephan Schleich]

@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]

@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

[Stephan Schleich]

@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]

@Stephan-Schleich Aliasse sind nicht weg wenn DU Devices löschst. Wie kommst Du darauf?

[Stephan Schleich]

@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

[apollon77]

@Stephan-Schleich Nur states die unter den Instanzobjekten des Adaters abgelegt sind. deviecs hat da nichts. Was sagt die Browser Konsole?

[Stephan Schleich]

@apollon77 sagte in Devices, Alias, Assistenten + Visualisierungen + die Zukunft:

Browser Konsole

@apollon77 Achso okay - danke, wusste nicht das diese nicht zusammen hängen.
In der Browser Konsole hatte ich nicht nachgesehen als ich das Problem hatte, aber es lag am Browser Cache nun läufts wieder.

Eine Frage noch sofern es hier rein gehört:
Ich hab meine Klimaanlage via Alias angebunden nun würde ich im selben Objekt gerne noch die IP mit dazu nehmen ohne extra ein neues Objekt anzulegen, theoretisch müsste es doch mit z.b. working gehen da der typ any ist oder? es kommt aber nur true als value und nicht die IP

[apollon77]

@Stephan-Schleich Bitte nicht anfangen irgendwelche States zweck-zu-entfremden WORKIGN hat eine semantische Bedeutung

[Stephan Schleich]

@apollon77 okay, könnte man ne Möglichkeit bieten selber weitere Felder mit hinzuzufügen bzw ein paar freie?

[apollon77]

@Stephan-Schleich Feature Request bitte im Github beim Devices Adapter

[Stephan Schleich]

@apollon77 Wollt ich gerade machen, gibt es bereits - https://github.com/ioBroker/ioBroker.devices/issues/18

sbormann created this issue in ioBroker/ioBroker.devices

closed Allow adding more states to device #18

[apollon77]

@Stephan-Schleich Dann hinterlass ein "Daumen hoch" im ersten post

[mlengen]

@apollon77 Es ist hier so still geworden. Geht es hier noch weiter oder ist dieser Weg eine Sackgasse?

[braindead]

@mlengen In einem der letzten Dev Meetings wurde betont, dass Alias die Zukunft ist und der momentane Stand nur ein Zwischenstand ist. Was genau erwartest Du denn, was hier passieren soll?

[apollon77]

@mlengen Tage ... 24h ... Privatleben ... andere Prios ... such Dir nen Grund aus ... ja es ist immer noch der Plan ...

[kubi]

Ich habe mal eine Frage zum Adapter Devices, wie kann ich selbst Aliase zusätzlich anlegen ?

[Videonisse]

Sorry for late feedback but I just found this thread. I hope it's okey that I write in english as mein deutch ist leider nicht sehr gut (ich kann aber deutch gut lesen).

I'm thrilled to read about the enhancements in this area! This enables ioBroker to become smart

However, I would not use the Alexa Skills as a great Taxonomy for how to implement the metadata in ioBroker. Alexa is great and very flexible, but it lacks a good structure. For example, it only specifies 15 different Device types (Skill Device Templates). Google Assistant is much better; they have currently 78 Devices types for smart home area. Apple HomeKit has 23 (Accessory types).

Have I understood the proposed structure correctly that the Device top level will be called "Alias" and an alias then has a "Function", and below this, it will have one or more "Roles/Types" and these have different "States"?

Could you share how those different levels map to the Taxonomy used by, for example Alexa and Google?

Something else I would suggest is to not focus too much on Alexa and Google but use as much as possible from the already standardized and open framework from OpenConnectivity Foundation, the OCF Specification. The latest release is from July this year. They have already a huge amount of Devices types specified, 54 types for smart home and another 127 for appliances and other IoT devices. For the next level, they call it "Resource Types", they have specified 169 types. Most of the big players are members of OCF. Have you guys already looked at this spec and if so, what is your opinion about it?

For my own benefit, I have put a table together with how I understand the used Taxonomy and how they map. I also counted all the standardized types they currently have officially documented. Please, let me know if I misunderstood something.

Many thanks for the impressive work with ioBroker and all of the adapters!