Devices, Alias, Assistenten + Visualisierungen + die Zukunft

[Videonisse]

(feel free to write in German, this is still the Deutsche Abteilung )

I believe that the proposed Device Templates are similar to what OCF has defined with their Device Types and the mandatory, as well as optional, Resource Types. For example, the Device Type Light that has 1 mandatory and 5 optional Resource Types. Each of them has a machine-readable template available.

Would be interesting to hear if @apollon77, or the other core developers, thinks this is something interesting for ioBroker or a plan is already set?

Example

{
     "devicename": "Light",
     "devicetype": "oic.d.light",
     "vertical":   "Smart Home",
     "resources": [
       {"resourcetypetitle": "Binary Switch", "resourcetypeid": "oic.r.switch.binary"}
     ],
     "recommendedresources": [
       {"resourcetypetitle": "Colour Hue Saturation", "resourcetypeid": "oic.r.colour.hs"},
       {"resourcetypetitle": "Colour Space Co-ordinates", "resourcetypeid": "oic.r.colour.csc"},
       {"resourcetypetitle": "Colour Temperature", "resourcetypeid": "oic.r.colour.colourtemperature"},
       {"resourcetypetitle": "Dimming", "resourcetypeid": "oic.r.light.dimming"},
       {"resourcetypetitle": "Ramp Time", "resourcetypeid": "oic.r.light.ramptime"}
     ]
   }

Source: https://github.com/openconnectivityfoundation/devicemodels/blob/master/oic.devicemap-content.json

Example oic.r.light.dimming:

{
  "swagger": "2.0",
  "info": {
    "title": "Dimming",
    "version": "2019-02-15",
    "license": {
      "name": "OCF Data Model License",
      "url": "https://github.com/openconnectivityfoundation/core/blob/e28a9e0a92e17042ba3e83661e4c0fbce8bdc4ba/LICENSE.md",
      "x-copyright": "copyright 2016-2017, 2019 Open Connectivity Foundation, Inc. All rights reserved."
    },
    "termsOfService": "https://openconnectivityfoundation.github.io/core/DISCLAIMER.md"
  },
  "schemes": ["http"],
  "consumes": ["application/json"],
  "produces": ["application/json"],
  "paths": {
    "/DimmingResURI" : {
      "get": {
        "description": "This Resource describes a dimming function.\nThe Property \"dimmingSetting\" is an integer showing the current dimming level.\nIf Property \"step\" is present then it represents the increment between dimmer values.\nWhen the Property \"range\" is omitted, then the range is [0,100].\nA value of 0 means total dimming; a value of 100 means no dimming.",
        "parameters": [
          {"$ref": "#/parameters/interface"}
        ],
        "responses": {
            "200": {
              "description" : "",
              "x-example":
                {
                  "rt": ["oic.r.light.dimming"],
                  "if": ["oic.if.a", "oic.if.baseline"],
                  "dimmingSetting": 30,
                  "step": 5,
                  "range": [0, 100]
                },
              "schema": { "$ref": "#/definitions/Dimming" }
            }
        }
      },
      "post": {
        "description": "Sets the desired dimming level.\n",
        "parameters": [
          {"$ref": "#/parameters/interface"},
          {
            "name": "body",
            "in": "body",
            "required": true,
            "schema": { "$ref": "#/definitions/Dimming" },
            "x-example":
              {
                "dimmingSetting": 40
              }
          }
        ],
        "responses": {
            "200": {
              "description" : "Indicates that the dimming was changed.\nThe new dimming level is provided in the response.\n",
              "x-example":
                {
                  "dimmingSetting": 40
                },
              "schema": { "$ref": "#/definitions/Dimming" }
            },
            "403": {
              "description": "This response is generated by the OCF Server when the client sends:\n  An update with an out of range property value for dimmingSetting.\nThe server responds with the current resource representation.\n",
              "x-example":
                {
                  "dimmingSetting": 40
                },
              "schema": { "$ref": "#/definitions/Dimming" }
            }
        }
      }
    }
  },
  "parameters": {
    "interface": {
      "in": "query",
      "name": "if",
      "type": "string",
      "enum": ["oic.if.a", "oic.if.baseline"]
    }
  },
  "definitions": {
    "Dimming" : {
      "properties": {
        "rt": {
          "description": "The Resource Type.",
          "items": {
            "enum": ["oic.r.light.dimming"],
            "maxLength": 64,
            "type": "string"
          },
          "minItems": 1,
          "uniqueItems": true,
          "readOnly": true,
          "type": "array"
        },
        "dimmingSetting": {
          "description": "The current dimming value.",
          "type": "integer"
        },
        "n": {
            "$ref": "https://openconnectivityfoundation.github.io/core/schemas/oic.common.properties.core-schema.json#/definitions/n"
        },
        "id": {
            "$ref": "https://openconnectivityfoundation.github.io/core/schemas/oic.common.properties.core-schema.json#/definitions/id"
        },
        "range": {
            "$ref": "https://openconnectivityfoundation.github.io/IoTDataModels/schemas/oic.baseresource.properties-schema.json#/definitions/range_integer"
        },
        "step": {
            "$ref": "https://openconnectivityfoundation.github.io/IoTDataModels/schemas/oic.baseresource.properties-schema.json#/definitions/step_integer"
        },
        "if": {
          "description": "The OCF Interface set supported by this Resource.",
          "items": {
            "enum": [
              "oic.if.a",
              "oic.if.baseline"
            ],
            "type": "string"
          },
          "minItems": 2,
          "uniqueItems": true,
          "readOnly": true,
          "type": "array"
        }
      },
      "type": "object",
      "required": ["dimmingSetting"]
    }
  }
}

Source: https://openconnectivityfoundation.github.io/IoTDataModels/DimmingResURI.swagger.json

[bungee71]

@apollon77
Hallo, ich habe Anfang Dezember 2020 mit ioBroker begonnen und seit dem einiges getestet. Den Ansatz mit den Alias finde ich sehr gut, ähnlich einer Variablentabelle, allerdings habe ich noch einige Lücken im Verständnis der Philisophie des Adapters.
Soweit ich es bisher Verstanden habe erstellt man unter "Geräte" ein Alias Gerät (Geräte denen ich vorher schon Raum und Funktion zugeordnet hatte erscheinen automatisch in der Liste - allerdings nicht als Alias - was hat es damit auf sich wie sieht der Use case aus ?) hierbei kann man sich einen vorgefertigen Typ aussuchen.

Wenn man das neue Alias Gerät editiert sieht man, dass es eine vorgefertigte Struktur hat - welche sicherlich von dem zuvor gewaehlten Typ kommt.

Leider kann man in diesem Fenster nur die Quellen zu den einzelnen Tags/Members editieren, die Struktur selbst lässt sich hier nicht ändern genauso wie andere Parameter wie z.B. eine Konvertierung des Wertes.
Anpassungen der Struktur (Member hinzufügen) konnte ich nur unter Objekte durchführen und dort auch nur mit manuellen Anpassungen z.B. um diesen Fehler beim Anlagen eines neuen Datenpunkt unter dem Gerät zu lösen

erst wenn man den alias Parameter einfügt wird der Datenpunkt erkannt.

Legt man nun auf diese Weise mehrere Datenpunkte an funktionieren Sie in Objekte unter alias.0 auch wunderbar. Wenn man aber jetzt ein Geräte das entsprechende Gerät editiert sind die neuen Member zwar in dargestellt aber alle sind "scheinbar" mit der gleichen Quelle verbunden --> Darstellungsproblem ?

wie gesagt die Datenpunkte funktionieren.

Ok jetzt zu meinem Problem bzw. Verbesserungsvorschlag.
Die Vorgegebenen Typen finde ich gut jedoch sehe ich hier den generischen Ansatz als problematisch. Z.B. passt der Typ Jalousie von der Struktur her nicht zu meinen HomePilot20 RademacherGeräten. So wie ich das bis jetzt verstanden habe werden diese Typen Entwicklerseitig zur Verfügung gestellt ? Was im Grunde sehr gut ist da so eine gewisse Standardisierung rein kommt.

1. Vorschlag:
   Der Adapterhersteller z.B. hier Homepilot20 liefert den GeräteTyp mit - er weiss am besten wie dieser auszusehen hat.

2. Vorschlag:
   Der User sollte seine eigenen Typen erstellen können evtl. in einem Editor. In dem Editor können auch die Systemseitig gelieferten Typen dargestellt und verwaltet werden. Ich denke da an ein Typ --> Instanz Konzept. Das Gerät arbeitet nur mit der Instanz somit haben ich die Möglichkeit zentral den Typ zu editieren (single point of change)

Die Verknüpfung der Quellen mit den einzelnen Member des Gerätes muss mit jedem neuen Gerät (für jeden Member) auch neu durchgeführt werden. Man kann es etwas schneller gestalten indem man das Gerät unter Objekte als JSON exportiert und nach Anpassung wieder importiert, ist aber alles nicht sehr effektiv.
Beispiel: Ich habe 10 Rollos vom gleichen Hersteller somit haben alle die selbe Struktur

und ein möglicher Typ "Rademacher_Rollo" hat die Parameter des Gerät ("Position"; "Action"; etc ) schon vorverbunden da diese ja bekannt sind, Somit muss ich nach anlegen eines neuen Gerätes nur noch den richtigen Pfad auswählen.

3. Vorschlag: Zweistufige Projektierung
   Stufe Eins:
   Zuordnen eines GeräteTyp (oder User Defined Datatyp UDT) zu dem neu erstellten Alias Gerät.
   Stufe Zwei:
   Verschalten des Alias Gerät mit dem Pfad des realen Geräts.

Vorteil ist ich muss nur noch eine Verbindung herstellen und nicht jeden einzelnen Member einzeln verbinden. Diese spart sehr viel Zeit und ist weniger Fehleranfällig.

Ich hoffe ich habe es einigermaßen nachvollziehbar ausgedrückt sonst bitte einfach nachfragen. Gerne kann ich das auch in Github eintragen, möchte aber erst mal ein gemeinsames Verständnis und Wording finden.

Gruß Bungee

[Messiahs]

Einfach mal über den Tellerrand geschaut:
Habt Ihr mittlerweile eine Roadmap zu diesem Thema oder zumindest eine allgemeine Roadmap 2021 für uns ?

Gefühlt wurde in letzter Zeit viel am "Haus" gestrichen und auch das Dach mit einer Solaranlage ausgestattet ("Alexa Custom Skill") und sogar eine neue Dachterrasse geplant ("Text Kommandos für Alexa" ,... ) .
Aber gefühlt ist erstmal die Sanierung des Kellers notwendig, sonst bricht in den nächsten Jahren das Haus zusammen.

Neue Anforderungen/UserStorys bzgl. Alexa-Unterstützung machen zurzeit keinen Sinn (wg. ausstehendem Update auf V3-AlexaApi).
Selbst für simple Grundfunktionen fehlt anscheinend das Grundgerüst (Temperatur_Steuerung/_Sensor über Alexa-App, Rolladensteuerung, usw. ).

Das Basement bzgl. V3-AlexaApi sollte man schnellstens mit hoher Priorität angehen.

[apollon77]

@messiahs Hi, das Thema steht immer noch auf der Roadmap. Dein Vergleich mischt ein bissl ziemlich verschiedene Dinge. Der Custom SKill existiert seid über 2 Jahren quasi "ungeändert" und textCommands in Alexa2 ist ein Adapter Feature.

Aber ja, dieses Thema steht recht weit oben auf der Todo Liste ... so wie Zeit ist

[mlengen]

@apollon77 Besteht den die Chance das dieses Jahr Zeit dafür ist?
Ohne Unterstützung der V3-Api fehlt einfach ein essenzieller Bestandteil bei Alexa.

[apollon77]

@mlengen Ich hoffe ja ... Das Jahr ist ja noch Jung und der controller 3.2 dann auch bald fertig

[Videonisse]

I added an Issue as a Feature Request for the Devices Adapter regarding enhancements in the GUI. It relates to this topic as well. I hope that the GUI for Devices, in the long run, will be as great as the rest of ioBroker. You guys are doing an amazing job with js 3.2.x and the maturity of the core features!

Are the suggestions useful?

https://github.com/ioBroker/ioBroker.devices/issues/55

Videonisse created this issue in ioBroker/ioBroker.devices

closed A more flexible GUI #55

[mlengen]

gelöscht

[mlengen]

Hallo,
ich habe mal wieder ein Frage.
Nachdem es hier ja in letzter Zeit so einige Fortschritte gab und man nun auch beim anlegen eines Devices sehen kann ob Alexa unterstützt wird habe ich das mal versucht und es klappt auch alles soweit.
Nur in der Alexa App erscheint immer noch nicht z.B. bei einem Dimmer der Slider zum Einstellen der Helligkeit.
Mache ich hier etwas Falsch oder wird aktuell die Alexa v3 API noch nicht unterstützt?

Auf alle Fälle sieht das ganze jetzt schon deutlich besser aus, weiter so

[apollon77]

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

Mache ich hier etwas Falsch oder wird aktuell die Alexa v3 API noch nicht unterstützt?

Ne dazu kamen wir noch nicht. Die neue Version des Devices Adapters ist eine vorarbeit dazu

[ple]

Moin Moin zusammen.
So nach 8 Jahren fange ich auch mal mit Alias an, die Sanierung ist fast fertig und das KNX geraffel läuft soweit.
Nun sollte auch mal eine Vis her. Meine alte aus Material Design Widget sollte nun abgelöst werden.
Also habe ich mal geschaut, was sich so getan hat in den letzten Jahren.
Zwischenzeitlich habe ich mal Homeassistant ausprobiert, Vis und App sind Top, der Rest ist viel Aufwand.
Gira X1 dümpelt hier auch noch rum, aber naja.
Lovelace hat mich bisher komplett überzeugt, eigene Cards können einfach importiert werden und sieht schick aus. Entitäten können auch automatisch gefunden werden, und da komm ich nun zum Problem.

Da ich all meine Datenpunkte, die ich brauche als Alias ausführen möchte, kann ich diese auch jetzt mit allen Daten füllen. Rule, Datentyp, Einheiten, Read, Write usw.
Auch das Verrechnen des Alias ist ne geniale Sache.

Ein kleiner Vorschlag, falls der überhaupt umsetzbar ist.
In den Ordner Alias und Userdata,
kann es für die "rule" eine fest vorgegeben Liste geben? Der Vorteil wäre dann, dass man für die Vis Adapter ein mapping machen kann und nicht gleich jeder sein eigenes Süppchen kocht. Somit würden die entitäten beim Lovelace auch autmatisch gemappt werden können, aktuell ist unklar, welche rule man da haben muss.
Das man nicht alle Adapterentwickler dahinbekommt ist mir schon klar und das die Arbeit beim User ist finde ich auch in Ordnung.

Oder ist mein Ansatz total über und der Post kann gelöscht werden

Gruß und Danke

[da_Woody]

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

der Post kann gelöscht werden

warum? du schreibst von vis, homeassistant, lovelace...

kann es für die "rule" eine fest vorgegeben Liste geben?

wenn ich dich nicht komplett falsch verstehe, JSON sollte sein, was du magst...

[apollon77]

@ple ich denke du meinest role (Rolle) und nicht rule. Wenn du den devices Adapter nutzt zum anlegen der aliase dann erkennt lovelace auch die passenden Typen.

[ple]

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

legen der aliase dann erken

Moin Moin,
ja ich dachte auch, dass es recht einfach mit dem Geräte Adapter geht, um eine saubere Struktur zu haben und auch alle Vorteile nutzen zu können.
Anscheinend ist es aber so, dass die States nur groß geschrieben werden können und es nur eine feste Vorgabe gibt.
Das hätte ich anders erwarten. Ich denke, es wird wohl einen Grund haben, warum das genau so gemacht worden ist, aber wäre vielleicht auch ein anderer Weg gehbar oder für die Zukunft eventuell.

Hier mal ein Beispiel.

Für die Visu ist doch eigentlich nur die Rolle (value.temperatur) + Raum + Datentyp (bool, integar ...) interessant. somit weiß die Visu zB. Lovelace, dass es eine Entität Sensor ist.
In meinen Beispiel könnte der Ordner WW das Device sein, somit wären alle drunterliegenden States, egal ob temp oder switch dem Device WW zugeordnet. Man könnte es auch dreistufig aufbauen.
Heizung = Device
WW =Channel
Kühlung = Channel
Heizen = Channel
und darunter dann die States jedlicher Art.

Für Räume wäre dann
Wohnzimmer = Device
Beleuchtung = Channel
Verbraucher = Channel
Sensoren = Channel
und darunter dann die States jedlicher Art.

damit irgendwelche Adapter die States mappen können und wissen was was ist ( type-detector ) bräuchte man doch nur Rolle, Typ, mappen.

Jetzt wäre es doch gut, wenn der Ordner Alias sowie Userdata nur die Rollen/Typen zulässt, die auch angedacht sind für iobroker, unabhängig welches Gerät verwendet wird. Aktuell ist es so, dass jeder da reinschreiben kann was er möchte.

Klar liegt die Arbeit bei User, aber das wärs mir Wert, damit nicht alles doppelt gemacht werden muss.

Gruß und Danke für die Infos.

[apollon77]

@ple type detector nutzt rollen und typen und auch die Strukturierung in Channeln beispielsweise (weil ja zb bei einer Farblampe mehrere States "zusammengehören"). Nur Rolle und Typ ist zu kurz gefasst. Die vorgegebenen "Standardnamen" für relevante States helfen weiter zu wissen was es ist, sind aber nicht sooo wichtig - war nur die Idee es einheitlich zu machen.

Ich würde auch keine Devices oder channels für Dinge "verschwenden" wo man enums nutzen kann . alles voran Räume oder Funktionen. Also wäre das für mich alles "folder".

[ple]

@apollon77
Ja das denke ich mir auch.
Aber noch mal auf mein Problem zu kommen.
ich teste gerade wie verrückt den Lovelace adapter, parallel teste ich ebenfalls Homaassistant.
ich komme schon so weit, dass der Lovelace adapter einen Sensor automatisch erkennt.
Die Angabe von value.temperatur + Raum + Funktion

Dabei ist es egal, ob übergeordnet ein Folder oder Device ist.
Soweit so gut. Im Thread vom Lovelace habe ich dann nachgefragt, warum z.B. die PV Anlage mit Energieertrag nicht automatisch gefunden werden kann. Meine Idee war ja, ich lege für alles Alias an und somit wird in der Visu und alles automatisch erkannt, kann aber nur funktionieren, wenn es Vorgaben gibt, von denen man nicht abweichen kann.
Ich dachte also, wenn ich für den Ertrag der PV Anlage die Rolle value.power.consumption vergebe + Raum + Funktion, dann würde dieses automatisch erkannt werden, das scheint aber nicht so, weil im type-detector dieser Typ noch fehlt.

Ich weiß, wir sind hier nicht bei "wünsch dir was" und es gibt bestimmt ne menge andere Baustellen und ich kenne nicht alle zusammenhänge im iobroker, aber wenn ich mir die Arbeit mache und Alias anlege für alle Datenpunkte, wäre es cool, wenn die anhand der vorgegebenen Rolle, Typ, Einheit erkannt werden können. Somit würde doch auch das automatische finden von Entitäten funktionieren wie beim switch oder value.temperatur.

Könnte dann so aussehen.

Mit den Daten sollte doch alles abgefangen werden können, oder nicht.
role = bestimmt ob es ein bool ist, oder Zahl
Raum = EG Wohnzimmer
Beleuchtung = Funktion Licht

Für den User ist nur wichtig, dass es nur bestimmte Rollen / Funktionen gibt, damit das Mapping funktioniert.
Da darf nicht von abgewichen werden.
Funktionen wären z.B.

• Licht
• Beschattung
• Sensoren
• Verbraucher
• Energie
• usw

Bei Rollen wäre die Liste sicherlich länger und man müsste 3 mal überlegen welche alle gebraucht werden.
in diesem Link ist schon ne Menge.
https://github.com/ioBroker/ioBroker.type-detector/blob/master/index.js#L30

Oder man orientiert sich an Homeassinstant. HA finde ich nicht schlecht, nur ist es ein riesen Aufwand.

[da_Woody]

@ple irgendwie versteh ich dein prob nicht. lovelace und homeassistant haben doch nichts mit alias direkt zu tun.
der alias adapter nimmt die DP wie sie sind. gibt halt dann einen alias namen, der bei kaputten geräten einfach ersetzt werden kann. keine änderungen in scripts und co.

[ple]

@da_woody
Sorry, bin nicht gerade der beste Erklärbär.
Alias könnte nicht nur einen Gerätetausch vereinfachen, sondern, ich denke, noch viel mehr.
Oft ist es so, dass bei den Adaptern die States falsch oder gar nicht komplett mit Metadaten ausgestattet sind.
Bis dato hat es nicht gestört.
Jetzt habe ich KNX im Haus, eine Nibe Wärmepumpe, eine PV usw.
Also bin ich neu angefangen und wollte eine saubere Struktur und das z.B. Lovelace die Geräte automatisch erkennt. Daher der Weg über Alias und da ist es mir aufgefallen, dass die Datenpunkte nicht komplett gemappt werden können.

[da_Woody]

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

Sorry, bin nicht gerade der beste Erklärbär.

da sind wir 2!
mir ist aber trotzdem noch nicht klar welches prob du hast.
du machst im alias adapter: automatisch erstellen. dann werden dir alle DP angeboten. klar, du musst dir deine struktur vorher mal überlegen.
ich kenn lovelace zu wenig, aber wenn du das gerät angibst mit dem alias, sollte das doch genau so übernommen werden.
ich befürchte, das das so wie mit homeassitant ist, einfach einlesen, aber keine alias daten, sondern direkt aus dem adapter.

[ple]

@da_woody
Ja, du nutzt den Alias Adapter. Den hatte ich mir auch schon angesehen. Klar, wenn die originalen Datenpunkte soweit schon bereits gut aufgearbeitet sind, dann werden die Rollen, Typen, Einheiten auch übernommen.

Es gibt im iobroker aber noch mehr, iobroker versucht anhand der Metadaten zu mappen. zb. was ist eine Steckdose, was ein Licht usw.
und das versuche ich zu verstehen, warum einige gehen und andere nicht.
Für mich sind die Typen, Rollen, Funktionen eindeutig um zu bestimmen, ob es ein Licht mit Dimmer ist, oder Steckdose schaltbar mit Energiemessung.
Und genau das wollte ich mit Alias abdecken und hatte gehofft, Lovelace erkennt es anhand der Metadaten.

Der Jarvis Adapter macht es ähnlich, aber dort müssen die Geräte erst mal händisch angelegt werden, dort wird auch angegeben was der Datenpunkt ist, Blind.Level usw.

Und genau die doppelte Arbeit wollte ich mir ersparen, wenn ich den Alias alle mitgeben kann.
Das mache ich ein mal fertig.