Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Flaterick]

Das ist schon mal der Konverter wurde von PTVO erzeugt.

const zigbeeHerdsmanConverters = require('zigbee-herdsman-converters');
const zigbeeHerdsmanUtils = require('zigbee-herdsman-converters/lib/utils');


const exposes = zigbeeHerdsmanConverters['exposes'] || require("zigbee-herdsman-converters/lib/exposes");
const ea = exposes.access;
const e = exposes.presets;
const modernExposes = (e.hasOwnProperty('illuminance_lux'))? false: true;

const fz = zigbeeHerdsmanConverters.fromZigbeeConverters || zigbeeHerdsmanConverters.fromZigbee;
const tz = zigbeeHerdsmanConverters.toZigbeeConverters || zigbeeHerdsmanConverters.toZigbee;

const ptvo_switch = (zigbeeHerdsmanConverters.findByModel)?zigbeeHerdsmanConverters.findByModel('ptvo.switch'):zigbeeHerdsmanConverters.findByDevice({modelID: 'ptvo.switch'});
fz.ptvo_on_off = {
  cluster: 'genOnOff',
  type: ['attributeReport', 'readResponse'],
  convert: (model, msg, publish, options, meta) => {
      if (msg.data.hasOwnProperty('onOff')) {
          const channel = msg.endpoint.ID;
          const endpointName = `l${channel}`;
          const binaryEndpoint = model.meta && model.meta.binaryEndpoints && model.meta.binaryEndpoints[endpointName];
          const prefix = (binaryEndpoint) ? model.meta.binaryEndpoints[endpointName] : 'state';
          const property = `${prefix}_${endpointName}`;
	  if (binaryEndpoint) {
            return {[property]: msg.data['onOff'] === 1};
          }
          return {[property]: msg.data['onOff'] === 1 ? 'ON' : 'OFF'};
      }
  },
};


const switchTypesList = {
    'switch': 0x00,
    'single click': 0x01,
    'multi-click': 0x02,
    'reset to defaults': 0xff,
};

const switchActionsList = {
    on: 0x00,
    off: 0x01,
    toggle: 0x02,
};

const inputLinkList = {
    no: 0x00,
    yes: 0x01,
};

const bindCommandList = {
    'on/off': 0x00,
    'toggle': 0x01,
    'change level up': 0x02,
    'change level down': 0x03,
    'change level up with off': 0x04,
    'change level down with off': 0x05,
    'recall scene 0': 0x06,
    'recall scene 1': 0x07,
    'recall scene 2': 0x08,
    'recall scene 3': 0x09,
    'recall scene 4': 0x0A,
    'recall scene 5': 0x0B,
    'dimmer': 0x0C,
    'dimmer (hue)': 0x0D,
    'dimmer (saturation)': 0x0E,
    'dimmer (color temperature)': 0x0F,
    'intruder alarm systems (ias)': 0x20,
};

function getSortedList(source) {
    const keysSorted = [];
    for (const key in source) {
        keysSorted.push([key, source[key]]);
    }

    keysSorted.sort(function(a, b) {
        return a[1] - b[1];
    });

    const result = [];
    keysSorted.forEach((item) => {
        result.push(item[0]);
    });
    return result;
}

function getListValueByKey(source, value) {
    const intVal = parseInt(value, 10);
    return source.hasOwnProperty(value) ? source[value] : intVal;
}

const getKey = (object, value) => {
    for (const key in object) {
        if (object[key] == value) return key;
    }
};

tz.ptvo_on_off_config = {
    key: ['switch_type', 'switch_actions', 'link_to_output', 'bind_command'],
    convertGet: async (entity, key, meta) => {
        await entity.read('genOnOffSwitchCfg', ['switchType', 'switchActions', 0x4001, 0x4002]);
    },
    convertSet: async (entity, key, value, meta) => {
        let payload;
        let data;
        switch (key) {
        case 'switch_type':
            data = getListValueByKey(switchTypesList, value);
            payload = {switchType: data};
            break;
        case 'switch_actions':
            data = getListValueByKey(switchActionsList, value);
            payload = {switchActions: data};
            break;
        case 'link_to_output':
            data = getListValueByKey(inputLinkList, value);
            payload = {0x4001: {value: data, type: 32 /* uint8 */}};
            break;
        case 'bind_command':
            data = getListValueByKey(bindCommandList, value);
            payload = {0x4002: {value: data, type: 32 /* uint8 */}};
            break;
        }
        await entity.write('genOnOffSwitchCfg', payload);
    },
};

fz.ptvo_on_off_config = {
    cluster: 'genOnOffSwitchCfg',
    type: ['readResponse', 'attributeReport'],
    convert: (model, msg, publish, options, meta) => {
        const channel = getKey(model.endpoint(msg.device), msg.endpoint.ID);
        const {switchActions, switchType} = msg.data;
        const inputLink = msg.data[0x4001];
        const bindCommand = msg.data[0x4002];
        return {
            [`switch_type_${channel}`]: getKey(switchTypesList, switchType),
            [`switch_actions_${channel}`]: getKey(switchActionsList, switchActions),
            [`link_to_output_${channel}`]: getKey(inputLinkList, inputLink),
            [`bind_command_${channel}`]: getKey(bindCommandList, bindCommand),
        };
    },
};

function ptvo_on_off_config_exposes(epName) {
    const features = [];
    features.push(exposes.enum('switch_type', exposes.access.ALL,
        getSortedList(switchTypesList)).withEndpoint(epName));
    features.push(exposes.enum('switch_actions', exposes.access.ALL,
        getSortedList(switchActionsList)).withEndpoint(epName));
    features.push(exposes.enum('link_to_output', exposes.access.ALL,
        getSortedList(inputLinkList)).withEndpoint(epName));
    features.push(exposes.enum('bind_command', exposes.access.ALL,
        getSortedList(bindCommandList)).withEndpoint(epName));
    return features;
}




const device = {
    zigbeeModel: ['Mat-LED'],
    model: 'Mat-LED',
    vendor: 'Mat',
    description: '[Configurable firmware](https://ptvo.info/zigbee-configurable-firmware-features/)',
    fromZigbee: [fz.ignore_basic_report, fz.ptvo_on_off, fz.ptvo_multistate_action, fz.ptvo_on_off_config, fz.electrical_measurement,],
    toZigbee: [tz.ptvo_switch_trigger, tz.on_off, tz.ptvo_on_off_config,],
    exposes: [e.switch().withDescription('Impulsschalter').withEndpoint('l1'),
      e.action(['single', 'double', 'triple', 'hold', 'release']),
      ...ptvo_on_off_config_exposes('l1'),
      e.voltage().withAccess(ea.STATE).withEndpoint('l3'),
],
    meta: {
        multiEndpoint: true,
        
    },
    endpoint: (device) => {
        return {
            l1: 1, l3: 3,
        };
    },
    configure: async (device, coordinatorEndpoint, logger) => {
      const endpoint = device.getEndpoint(1);
      await endpoint.read('genBasic', ['modelId', 'swBuildId', 'powerSource']);
    for (const endpoint of device.endpoints) {
        if (endpoint.supportsInputCluster('haElectricalMeasurement')) {
            endpoint.saveClusterAttributeKeyValue('haElectricalMeasurement', {dcCurrentDivisor: 1000, dcCurrentMultiplier: 1,
                dcPowerDivisor: 10, dcPowerMultiplier: 1, dcVoltageDivisor: 100, dcVoltageMultiplier: 1,
                acVoltageDivisor: 100, acVoltageMultiplier: 1, acCurrentDivisor: 1000, acCurrentMultiplier: 1,
                acPowerDivisor: 1, acPowerMultiplier: 1});
        }
        if (endpoint.supportsInputCluster('seMetering')) {
            endpoint.saveClusterAttributeKeyValue('seMetering', {divisor: 1000, multiplier: 1});
        }
    }
    },

};

module.exports = device;

[Flaterick]

Hat leider etwas gedauert.
Ich Finde keine Entsprechenden Einträge.
Unter zigbee2mqtt funktioniert es.

[Flaterick]

Habs Hinbekommen, Hatte in der Konfiguration in der Zigbeeinstanz einen Schreibfehler.
Danke

[Asgothian]

Ok.. jetzt bin ich verwirrt. Das Problem lag nicht am externen Konverter, sondern ?

A.

[Flaterick]

Ich war hier zu doof den richtigen Namen einzutragen (Schreibfehler).
Und ja es sind nur ein Paar Buchstaben.

Wieso allerdings die Fehlermeldung Illegal operation on a directory read,
gekommen ist weiß ich auch nicht.

[Asgothian]

ok.. Dann bin ich ja beruhigt :)

Ich hatte am Konverter nix auffälliges gefunden, und die Fehlermeldung sah seltsam aus.

A.

[Flaterick]

Trotzdem Danke fürs Drüber schauen.

[Asgothian]

Dafür nicht.

Noch ein Tip:

Wenn du den device = Teil des Konverters so anpasst wie unten gepostet, und du parallel zum Konverter auch noch ein Icon (PNG Format, max 512x512 px, am besten mit transparentem Hintergrund) hinterlegst (z.Bsp. als Mat-LED.png), dann sollte der Adapter das Icon automatisch auch einbinden.

const device = {
    zigbeeModel: ['Mat-LED'],
    model: 'Mat-LED',
    vendor: 'Mat',
    description: '[Configurable firmware](https://ptvo.info/zigbee-configurable-firmware-features/)',
    fromZigbee: [fz.ignore_basic_report, fz.ptvo_on_off, fz.ptvo_multistate_action, fz.ptvo_on_off_config, fz.electrical_measurement,],
    toZigbee: [tz.ptvo_switch_trigger, tz.on_off, tz.ptvo_on_off_config,],
    exposes: [e.switch().withDescription('Impulsschalter').withEndpoint('l1'),
      e.action(['single', 'double', 'triple', 'hold', 'release']),
      ...ptvo_on_off_config_exposes('l1'),
      e.voltage().withAccess(ea.STATE).withEndpoint('l3'),
     ],
    meta: {
        multiEndpoint: true,
    },
    endpoint: (device) => { return { l1: 1, l3: 3,}; },
    configure: async (device, coordinatorEndpoint, logger) => {
      const endpoint = device.getEndpoint(1);
      await endpoint.read('genBasic', ['modelId', 'swBuildId', 'powerSource']);
      for (const endpoint of device.endpoints) {
        if (endpoint.supportsInputCluster('haElectricalMeasurement')) {
            endpoint.saveClusterAttributeKeyValue('haElectricalMeasurement', {dcCurrentDivisor: 1000, dcCurrentMultiplier: 1,
                dcPowerDivisor: 10, dcPowerMultiplier: 1, dcVoltageDivisor: 100, dcVoltageMultiplier: 1,
                acVoltageDivisor: 100, acVoltageMultiplier: 1, acCurrentDivisor: 1000, acCurrentMultiplier: 1,
                acPowerDivisor: 1, acPowerMultiplier: 1});
        }
        if (endpoint.supportsInputCluster('seMetering')) {
            endpoint.saveClusterAttributeKeyValue('seMetering', {divisor: 1000, multiplier: 1});
        }
    }
  },
  icon: "./Mat-LED.png",
};

[JLeg]

@Asgothian - vielleicht hast du einen Tipp, wie ich dieses akute "Phänomen" untersuchen/beheben könnte: Seit ~3 Jahren laufen ~12 gleichartige Zigbee-Thermostate (Moes/Tuya) recht problemlos. Temperaturen und "Betriebsmodus" lassen sich setzen und lesen, beim Setzen der Absenktemperatur hörte man quasi sofort die Ventile schliessen.
Wenn die Batterie "alle" ist, geht "available" auf "false", das Gerät wird gemeldet, Batterie getauscht, und weiter gehts. So bis vor ein paar Tagen - kann das leider nicht mehr genau eingrenzen, da der Effekt nicth gleich erkannt wurde.

Aus dem nichts heraus (glaube ich - habe eigentlich nirgends gross geschraubt - letzte Aktivitäten waren tatsächlich Zigbee-Adapter-Updates, aktuell auf 3.2.5) kann bei keinem dieser Thermostate irgendein schreibbarer Parameter mehr gesetzt werden (Zieltemperatur etc.). Während alle Read-only-Parameter nach wie vor mit aktuellem Timestamp reinkommen, sind die schreibbaren irgendwann in der Vergangenheit "stehen geblieben".
Allerdings - verstelle ich die Temperatur am Thermostat selbst, wird das zugehörge Objekt aktualisiert - genau einmal, auch danach erfolgt kein Update des Timestamps mehr.
Andere Zigbee-Greräte (~50) scheinen bislang nicht betroffen.
Habe einen Thermostat mal exemplarisch in den "Debug"-Modus eingetragen, Log u. Gerätekachel s.u.
Natürlich ist auch in der Vergangenheit mal das eine oder andere Zigbeegerät aus dem Netz gefallen, oder nach einem Batteriewechsel nicht mehr "online" gegangen - aber dann war immer auch "available" auf "false", und nach einem "Re-Pair" war das Gerät wieder da.

Dass aber alle Geräte eines Typs auf einmal "partiell verschwinden", ist neu für mich - irgendwelche Tipps, wie ich da weiter vorgehen sollte? (werde mal einen versuchen, neu zu pairen - ist bei diesen Dingern leider relativ umständlich)

Ich vermute mal, das Log entspricht genau dem zu Beobachtenden - Gerät nicht erreichbar:

2025-11-26 13:41:40.260  - ESC[33mwarnESC[39m: zigbee.0 (3734244) ELEVATED:O01 (0ca4) User state change of state zigbee.0.040d84fffe5f5fcc.min_temperature with value 12 (ack: false) from system.adapter.admin.0
2025-11-26 13:41:40.263  - ESC[33mwarnESC[39m: zigbee.0 (3734244) ELEVATED:O02 (0ca4) Change state 'min_temperature' at device 0x040d84fffe5f5fcc type 'BRT-100-TRV'
2025-11-26 13:41:40.263  - ESC[33mwarnESC[39m: zigbee.0 (3734244) ELEVATED:O03 (0ca4) Publishing to 0x040d84fffe5f5fcc of model BRT-100-TRV with min_temperature
2025-11-26 13:41:40.266  - ESC[33mwarnESC[39m: zigbee.0 (3734244) ELEVATED:O04 (0ca4) convert min_temperature with value 12 and options {} for device 0x040d84fffe5f5fcc with Endpoint min_temperature
2025-11-26 13:41:50.272  - ESC[33mwarnESC[39m: zigbee.0 (3734244) ELEVATED:EXSET (0ca4) caught error ZCL command 0x040d84fffe5f5fcc/1 manuSpecificTuya.dataRequest({"seq":389,"dpValues":[{"dp":109,"datatype":2,"data":{"type":"Buffer","data":[0,0,0,12]}}]}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Data request failed with error: 'Timeout' (9999)) when setting value for device 0x040d84fffe5f5fcc.
2025-11-26 13:41:50.272  - ESC[32minfoESC[39m: zigbee.0 (3734244) Send command to 0x040d84fffe5f5fcc failed with: Code 9999 (No response)

[Asgothian]

Zeig mal bitte wie das Device im Objektbaum aussieht.

Auch: Wann hast du as Update von 1.10.x auf 2.x und/oder 3.x gemacht ?

[JLeg]

@Asgothian sagte in Tester gesucht: Zigbee 3.2.x:

Zeig mal bitte wie das Device im Objektbaum aussieht.

um Protesten wegen kalter Bude entgegen zu wirken, habe ich gestern sämtliche Thermostate neu gepaired - danach sah und sieht es erstmal wieder "normal" aus. 2 musste ich zweimal pairen, da nach dem ersten Mal die Hälfte der DPs auf der roten "null" stand.
Im zigbee-Adapter gibt es ja eine "Struktur", die Geräte gleichen Typs summiert. Womöglich gibt's sowas auch im Koordinator selbst, und dieser hat inzwischen ein "Laufzeitproblem" oder so? Ist ein Selbstbau-Stick auf Basis eines CC2538...
Der Objektbaum sieht so aus - im Fehlerfall waren die Soll-Temperatur-DPs halt "rot", da per Script gesetzt, und nicht bestätigt:

Noch eine Beobachtung am Rande: Sobald ich ein Gerät in den "Pairing-Modus" versetzt hatte, ist dessen kompletter Objektbaum verschwunden.
Nach dem Pairing waren dann aber sowohl Bezeichner, als auch Einstellungen im "Schraubenschlüssel" bei den DPs (wie heissen die eigentlich?) wieder die alten. "Früher" war das afair anders, kann mich an Influxdb-Verluste erinnern nach Neu-Pairing.

Auch: Wann hast du as Update von 1.10.x auf 2.x und/oder 3.x gemacht ?

wenn ich das noch wüsste; im Nov. 24 war ich jedenfalls auf 1.10.13, und hatte dann recht lange gezögert mit dem Update; ich meine, ich wäre dann direkt auf 3.1 gegangen, auf jeden Fall hatte ich am 19. September auf 3.1.2 aktualisiert. Im Oktober dann auf 3.2.x.
Beim Sprung auf 3.1.2 hatte ich einiges getestet, und keinerlei Probleme festgestellt - im Gegenteil eigentlich nur Verbesserungen (ich hatte vorher Devices - einen Typ Rauchmelder - die max. 3 Tage nach Pairing grundsätzlich wieder "unerreichbar" waren; ausserdem bin ich nun die nervigen warn-Einträge im Log los, die durch semi-defekte Aqaras mit Werten ausserhalb der Limits erzeugt worden waren).

[bilberry]

Hallo @asgothian, ich habe gestern wegen meinem "undefined-devices-Problem" von v3.1.5 auf v3.2.5 gewechselt.
Anschließend habe ich zwei neue innr RS242C (GU10 RGB Lampen) erfolgreich und problemlos in Betrieb genommen (sind erst seit ZHC 25.37.0 enthalten).

Als ich diese dann in eine bereits bestehende Gruppe mit dem Vorgängermodell innr RS232C aufgenommen habe, fiel mir auf, dass die Gruppe nur noch weißes Licht steuern kann. RGB-Werte werden ignoriert.

Erst nahm ich an, dass die beiden Typen nicht kompatibel sind und habe eine neue Gruppe für die neuen Lampen erstellt. Aber der Datenpunkt "color" wird gar nicht angelegt. Dann habe ich eine dritte Gruppe nochmal nur für die alten Modelle angelegt. Und auch dort gibt es nun keinen Datenpunkt "color" mehr. Da ich die bisherige Gruppe im Februar 2025 angelegt habe, muss es wahrscheinlich sogar noch eine Version 1.x des Adapters gewesen sein. Deshalb kann ich auf die Schnelle nicht nachvollziehen, ob das erst erst mit der v3.2.5 oder schon einige Versionen früher gekommen ist. Fakt ist aber, dass ich bis einschließlich v3.1.5 zumindest den Datenpunk "color" in der Gruppe zum Steuern nutzen konnte, was nun definitiv auch nicht mehr funktioniert. Kannst Du das mal bitte prüfen? Wovon hängt es eigentlich ab, welche Datenpunkte in eine Gruppe übernommen werden?

EDIT: Das Icon der neuen Gruppe sieht auch andres aus - hat aber vielleicht dem Problem gar nichts zu tun (ist mir nur aufgefallen)

[Asgothian]

Kannst du mir bitte zeigen welche Cluster die INNR lampen unterstützen ? Die DP's der Gruppe sollten davon abhängen welche Cluster in den Geräten angegeben werden.

Auch - hast du die 3.2.5 aus dem latest oder von Github installiert ? In der Latest version ist ein Bug - der ist in der GitHub version bereits gefixed.

Der Unterschied der Icons ist irrelevant - du zeigst unterschiedliche Gruppen, eine mit 4 Mitgliedern, eine mit 2 Mitgliedern.

A.

p.s. ich bin gerade dabei auf Github eine 3.3.0 fertig zu machen.. die kommt gegen 1

A.

[bilberry]

Wo kann ich denn die unterstützten Cluster auslesen?
EDIT: über diesen Issue sind diese Modelle in den ZHC gekommen. Vielleicht helfen Dir die dort gemachten Angaben zum Cluster: https://github.com/Koenkk/zigbee2mqtt/issues/28819

Über diesem Weg habe ich den Adapter installiert - ist dann wahrscheinlich "latest":

[Asgothian]

Nein, das sollte der von Github sein. Installier den bitte jetzt nochmal - ich hab gerade den 3.3. RC da hin gepusht.

Die Cluster bekommst du aus der 'info' kachel vom Gerät (kachel umdrehen, das kleine (i) unten links)

[bilberry]

Ach das habe ich übersehen. Alles klar - Danke!
input clusters:

• genBasic (0)
• genIdentify (3)
• genGroups (4)
• genScenes (5)
• genOnOff (6)
• genLevelCtrl (8)
• lightingColorCtrl (768)
• touchlink (4096)

output clusters:

• genTime (10)
• genOta (25)

[Asgothian]

Hast du die aktuelle Version heute noch mal installiert? Ich habe aktuell Probleme mit NPM und kann die Version noch nicht erstellen. Es sollte aber auf jeden Fall für die Gruppen States ein fix in der aktuellen Version enthalten sein.
Zumindest werden bei mir die States für Color korrekt erzeugt.

[bilberry]

Über den oben beschriebenen Weg wir immer noch v3.2.5 ausgespielt. Kann das sein? Der Color-Datenpunkt ist damit noch nicht wieder da.

[Asgothian]

Zeigst du bitte das log vom Startup des Adapters ? Da steht genau welche Version installiert ist. Bevor ich die ins latest bringe sollte der color dp wieder funktionieren

Hat sich erledigt - ich denke ich hab den Bug gefunden. Wenn du nochmal von GitHub installieren kannst - dann sollten die Gruppen-States wieder da sein - und dann auch mit den Rollen für den aktuellen Type-Detektor.

Danke für den Hinweis - das die Farb-DP's nicht mehr verbunden waren ist nicht aufgefallen. Parallel damit ist auch aufgefallen das die Gruppen-States nicht mit auf 'noch verbunden sein' geprüft werden, sprich wenn da etwas wegfällt werden die nicht farbig dargerstellt. Das kommt auf die Liste der zu behebenden Fehler.

A.

[bilberry]

OK, prima. Hab noch mal installiert und der vorhandene Color-Datenpunkt funktioniert wieder und in der neuen Gruppe wurde er nun noch ergänzt.

Zwei andere Dinge sind mir aber aufgefallen:

• Nach der Installation wurde der Adapter nicht automatisch neu gestartet, was zu einem merkwürdigen Verhalten (u.a. fehlenden Icons) führte. Hab ihn dann von Hand gestoppt und neu gestartet.
• Version ist aber immer noch v3.2.5 - Sollte das so sein?
  Log: starting. Version 3.2.5 (non-npm: ioBroker/ioBroker.zigbee) in /opt/iobroker/node_modules/iobroker.zigbee, node: v20.19.6, js-controller: 7.0.7