Das volle Potential der Objekte nutzen!

[Jey Cee]

Immer wieder bekomme ich Anfragen (auch von Entwicklern) ob es nicht möglich wäre Statische Daten, also Namen, IP Adressen oder ähnliches in einem State aus zu geben.
Auch bei anderen Adaptern sehe ich öfter das Statische Daten in States aus gegeben werden, dabei ist das oft gar nicht Nötig. Damit verschwendet man unnötig Ressourcen und macht den Objektbaum unübersichtlich.
Deswegen möchte ich an dieser Stelle mal auf "native" einen Bestandteil der Objekte eingehen.

1. Basics
2. Verwaltung im Admin
3. Verwendung im JS Adapter
4. Verwendung in VIS

[Jey Cee]

1. Basics

• Ein Objekt ist kein State => Objekte dienen der Verwaltung, States zur Datenhaltung.

• Ein State Existiert nicht ohne Objekt => Bedeutet es wird für jeden State ein Objekt angelegt und sie sind miteinander Verknüpft.

• Ein Objekt in ioBroker ist eine JSON Struktur, die wie folgt aussieht:

{
  "type": "device",
  "common": {
    "name": "192.168.0.233"
  },
  "native": {
    "enabled": true,
    "ip": "192.168.0.233",
    "mac": "00:0e:58:35:e6:2a",
    "vendor": "Sonos Inc., 614 Chapala St., Santa Barbara CA 93101, United States"
  },
  "from": "system.adapter.net-tools.0",
  "user": "system.user.admin",
  "ts": 1599989452490,
  "_id": "net-tools.0.000e5835e62a",
  "acl": {
    "object": 1636,
    "owner": "system.user.admin",
    "ownerGroup": "system.group.administrator"
  }
}

Für unsere Betrachtung spielt nur der Key "native" eine Rolle.
Wie man in dem Beispiel sieht sind hier verschiedene Daten enthalten. In den meisten Objekten ist dieser Teil leer, aber er ist immer vorhanden.
Die Daten in native werden üblicherweise vom Adapter geschrieben und können für die Unterschiedlichsten Zwecke verwendet werden. Andere Adapter und der JS Controller ignorieren diesen Teil und verändern dort nichts.

Am häufigsten werden dort Daten abgelegt die der Adapter für Funktionen benötigt.
Es können jedoch auch Statische Daten in native abgelegt werden, die dann an verschiedenen Stellen angezeigt werden können, z.B. in der Adapter Konfiguration.

[Jey Cee]

2. Verwaltung im Admin

Die Objekte lassen sich im Tab Objekte verwalten. Bekannt dürfte vor allem die Möglichkeit sein Objekte an zu legen oder löschen. Für die erweiterte Verwaltung muss man auf das Stift-Symbol am Ende der Zeile neben dem Mülleimer Klicken.
Anschließen sieht man so ein Fenster:

Je nach Objekt Typ sieht man sehr Unterschiedliche Informationen oder gar keine.

Wechselt man in den Tab Nativ werden die Informationen aus native angezeigt. Hier kann man sie auch bearbeiten, löschen oder neue Hinzufügen. Hierbei ist Vorsicht geboten, das verändern oder löschen kann unerwünschte Folgen haben. Neue Einträge Hinzufügen hingegen ist mit geringem Risiko verbunden, trotzdem sollte man das nur bei Selbst erstellten Objekten machen.

[Jey Cee]

3. Verwendung im JS Adapter

Im JS Adapter gibt es die Funktion getObject(), diese liefert das gesamte Object als JSON zurück.
Dadurch kann man sehr einfach die Daten auslesen die man haben will.

Beispiel:

let obj = getObject('net-tools.0.000e5835e62a');
console.log(obj.native.ip);  //erwatete Ausgabe: 192.168.0.233

obj = ganzes Objekt
native = Key "native"
ip = Key "ip" ist ein Element von native

[Jey Cee]

4. Verwendung in VIS

Out-of-the-Box kann man nicht auf native eines Objekts zugreifen, dafür gibt es kein Widget, wäre aber wohl möglich.
Um das dennoch zu bewerkstelligen habe ich ein Skript erstellt das man im VIS Editor einfügen kann. Anschließend kann das "basic - String" Widget zum Anzeigen der gewünschten Daten aus native verwendet werden.

1. Skript einfügen (Code am Ende):
   

2. Dem Widget die CSS Klasse native-XXX zuweisen. XXX steht für den Key dessen Wert angezeigt werden soll.
   

3. Object Auswählen
   

---

Anmerkung: "Voranstellen HTML" und "HTML anhängen" Funktioniert nicht.

Skript:

const timeout = 50;

$(document).ready(function(){
    setTimeout( () => {
        getNativeData();   
    }, timeout)
    
});

function getNativeData(){
    
    const nativeElements = document.querySelectorAll('div[class*="native-"]');
    
    for (let i = 0; i <= nativeElements.length - 1; i++) {
        const arr = [ ...nativeElements[i].classList ];
        const propName = arr.find(checkForNative).replace('native-', '');
        const id = nativeElements[i].lastElementChild.lastElementChild.dataset.oid;
          
          vis.conn.getObject(id, true, (err, obj) => {
              if (!err){
                  nativeElements[i].lastElementChild.lastElementChild.outerText = obj.native[propName];
              }
                
            })
    }
}

function checkForNative(className) {
    const regex = new RegExp('native-');
    let finding = className.match(regex);
    
    return finding;
}

[paul53]

@Jey-Cee sagte:

Ein Objekt in ioBroker ist eine JSON Struktur

Nur die Darstellung in der RAW-Ansicht des Admin-Adapters ist ein JSON, das beim Speichern in ein Objekt gewandelt wird.

[Mic]

@Jey-Cee

Sehr coole, einfache Erklärung

Ich denke, "unser" Unverständnis bezüglich States (und dass dahinter ein Objekt ist) kommt sicherlich auch daher, weil viele, mich eingeschlossen, halt in ioBroker mit Blockly/JS des JS-Adapters einsteigen, und da wird dank dem Konzept von Bluefox und aller Core-Entwickler dem Anwender bereits sehr vieles abgenommen, d.h. etwa mit createState(), getState(), setState(), ohne dass man checkt und checken muss, was das so im Hintergrund bedeutet, es funktioniert halt einfach und logisch, etwa wenn man einen createState() losfeuert, etc...
Eigentlich erst mit Start in der Adapter-Entwicklung habe ich bzw. musste ich mich damit näher beschäftigen und hab anfangs auch nicht gecheckt, warum einerseits adapter.setObjectNotExistsAsync() notwendig ist um einen neuen "State" (also Objekt!) zu erzeugen (im JS-Adapter reichte da ja ein createState()), anderseits ich mit adapter.setStateAsync() ich einen State setzen kann...

[Jey Cee]

Nach Oben mit dir

[Jey Cee]

@jey-cee sagte in Das volle Potential der Objekte nutzen!:

Nach Oben mit dir

Und wieder mal hoch mit dir