z.b dein attr. das beginnt nicht immer mit _Illuminance - es wird mittlerweile mit nur Illuminance im dp geschrieben, dafür ist es in einem anderen ordner in der sonoff-instanz

aber das ist doch der Sinn der Klasse! Du möchtest einen DP abfragen der irgendwas mit illuminance enthält, entweder _illuminance oder Info1_Illuminance oder auch Info2.illuminance usw. Mit der Klasse werden die Attribute vereinfacht zu illuminance, egal in welcher Hierarchie sie stehen. Alles vor und incl. _ wird gelöscht. Das wäre auch schon der Nachteil, im tr-064 Adapter gibt es jede Menge json DP, da klappt das nur wenn man nicht den gesamten Adapter durchsucht sondern nur den nächst höheren Level. Für normale Geräte sollte es aber nur ein on oder rgb oder volume etc. geben und da ist es dann egal wo sie stehen.

In einer 2ten Version habe ich die Getter dynamisch erstellt, d.h. man muss die Klasse nicht anpassen sondern greift einfach auf NeuesLicht.NeuesFeature zu und erhält den Wert ohne ihn vorher in der Klasse explizit definiert zu haben und ohne zu wissen wo er genau steht. Auch ist es so erweitert dass man auch auf den Originalnamen zugreifen kann, also device.hostname und device.Info1_hostname liefern den gleichen Wert

Ich habe mir Teile deines Skriptes angesehen und denke immer noch dass das genau das ist was du brauchst. Allerdings müssen die DP eindeutige Namen haben, rgb etc darf nicht zweimal erscheinen.

habe das nochmal angesehen - habe nicht so viel erfahrung mit class. habe mal vor langer zeit ein java project gemacht - ist lange her.
das gefällt mir besonders:

 states.each(state => {
            const dp = state.split('.').pop();
            let attr = dp.slice(dp.indexOf('_') + 1);
            this.dp[attr.toLowerCase()] = state

leider bin ich da am selben problem - ich muss die abfragen, um was es für dp geht , auch auf alle möglichkeiten hin abfragen. z.b dein attr. das beginnt nicht immer mit _Illuminance - es wird mittlerweile mit nur Illuminance im dp geschrieben, dafür ist es in einem anderen ordner in der sonoff-instanz

letztlich ist aber dein vorschlag interessant - man kann mit einer klasse alles abdecken - muss halt gut geschrieben sein - ändert sich was, muss nur die class geändert werden und nicht überall mit if gearbeitet werden

in meinem tabellescript werde ich das nicht verwenden - ist mir im moment zuviel anpassung

aber ich versuche gerade ein neues project - ich habe den firetv adapter nie stabil zum laufen bekommen - evtl versuche ich da mal was mit class und einem script ans laufen zu bekommen

auf jeden fall danke für die idee

aber dann muss ich die klassen auf die unterschiedlichen möglichkeiten anpassen

eigentlich ist dafür getId() vorgesehen. Statt unterschiedliche Pfade abzufragen frägst du nur den Statenamen ab, also zB rgb, on etc.. In der Klasse sind die Datenpunkte dazu gespeichert. In den gettern sind halt nur die hier im Thread behandelten Info-Punkte implementiert

@haselchen danke fürs testen

/**
 * Zweck:   Leichterer Zugriff auf Tasmota Info DP
 * Datum:   09.11.2011
 * Autor:   @fastfoot
 * Forum:   https://forum.iobroker.net/topic/49205/tasmota-10-und-sonoff-adapter/34
 */
const dbg = true;
const DevicesBasePath = '0_userdata.0.Forum.MQTT.Tasmota';

class Tasmota {
    constructor(id) {
        this._getDps(id);
    }
    get hostname() { return getState(this.dp.hostname).val; }
    get ipaddress() { return getState(this.dp.ipaddress).val; }
    get module() { return getState(this.dp.module).val; }
    get version() { return getState(this.dp.version).val; }
    get restartreason() { return getState(this.dp.restartreason).val; }
    getId(state){return this.dp[state]}
    _getDps(id) {
        const states = $(`${id}*`);
        this.dp={};
        states.each(state => {
            const dp = state.split('.').pop();
            let attr = dp.slice(dp.indexOf('_') + 1);
            this.dp[attr.toLowerCase()] = state;
        })
    }
}
const l1 = new Tasmota(DevicesBasePath + '.Licht1');
const l2 = new Tasmota(DevicesBasePath + '.Licht2');
log('hostname: ' + l1.hostname)
log('ip: ' + l2.ipaddress)
log('rgb: ' + getState(l2.getId('rgb')).val)
log('version: ' + getState(l1.getId('version')).val)

Ganz geschmeidig im Sonoff Adapter.
Der MQTT hatte rumgezickt, wurde immer grün gelb grün gelb...

Scheint bei den Adaptern MQTT und Sonoff eine verschiedene Herangehensweise zu sein, wie Datenpunkte bzw Ordner angelegt werden.

und so sieht es bei jmd anders mit tasmota 10 aus:

Ab Version 9.3.1 , ja

ich denke, ich werde diese form einfach escapen - sind bei dir alle so ? mit dem Info_...

Ändert sich nichts.
Nach dem Anhaken in den Settings ist ein Datenpunkt dazugekommen.
Energy Period
Leider keine Ahnung was der aussagen soll.

ich würde gerne das INFO.Module oder INFO.Info1.Module sehen

das Info1_Module als dp mag ich nicht :-)

welches Ergebnis möchtest du denn?
Ich kann das gerne auch einstellen.

WICHTIG für Nachmacher:

Energy gestern und heute gehen nach dem Update flöten.
Für wen das wichtig ist, sollte sich vielleicht die Daten vorher notieren.

ich habe das eingestellt

kann das der unterschied sein ?

Ich muss immer die gz. Dateien nehmen, weil sonst das Update fehlschlägt.

http://ota.tasmota.com/tasmota/release/

Hab für Dich mal ne Dose upgedatet.....

das habe ich auch über tuya gemacht - mit 'ner 8er version

Alles von der "offiziellen" Seite.
Geflasht über TuyaConvert, da war glaube ich die Version 7.42?? drin.
Hab dann paar Mal upgedatet bis sie vernünftig liefen.
Jetzt lass ich die Gosund Dinger bei 9.31 bzw. 9.5.0

wenn du mal einen auf tasmota 10 umstellst, wäre echt interessan, zu sehen, ob das Info1_Module wieder verschwindet

man kann das doch nirgends definieren - denke ich - oder hast du ein selbstgemachtes bin file zum flashen

und könntest du mir bitte alle dp von stromverbrauchpumpe zeigen - als bild reicht

danke