NEWS
Tester gesucht: Zigbee 3.2.x
-
@Asgothian so Test beendet. Ich bestätige das dieser Fehler durch deinen Workaround behoben ist. Hab jetzt alle Geräte wo das war umgestellt, blöd nur das ich sie dann auch erst löschen musste im Matter Adapter.
Sollte man apollon77 das evtl. mitteilen? Ist das überhaupt ein Bug? Erst mal herzlichen Dank melde dich wenn du Zeit hast.👌
Grüße Fabio@fabio sagte in Tester gesucht: Zigbee 3.2.x:
@Asgothian so Test beendet. Ich bestätige das dieser Fehler durch deinen Workaround behoben ist. Hab jetzt alle Geräte wo das war umgestellt, blöd nur das ich sie dann auch erst löschen musste im Matter Adapter.
Sollte man apollon77 das evtl. mitteilen? Ist das überhaupt ein Bug? Erst mal herzlichen Dank melde dich wenn du Zeit hast.👌
Grüße Fabio- das der Type detektor den
availablestate als 'SET_ACTUAL` deklariert ist unglücklich. Das der Matter Adapter den einfach so übernimmt auch. - Das der Matter Adapter nicht von sich aus auf geänderte Rollen reagiert ist meiner Meinung nach ein Bug - allerdings kann es sein das @apollon77 das absichtlich so umgesetzt hat.
Nen Issue ist das auf aber jeden Fall wert - dann kann geschaut werden ob das absicht, versehen oder bug ist.
Zum Thema Type Detektor (das ist denk ich nicht apollons direkte Baustelle) - das was da gemacht wird ist denkbar unschön:
Lt. der Rollen definition soll ein Datenpunkt dessen Role nicht zu den vordefinierten passt die Role
statebekommen:- state - very common purpose. If you don't know which role the state has, use this one.
Die Doku zum Type-Detector für lights sagt in der Tabelle das der Wert für
ON_ACTUALein Boolean mit der Rolesensor.lightsein soll. Leider sagt das Match-Muster das daneben auch Boolean states mit der RolestateoderswitchalsON_ACTUALgenommen werden.In der Kombination muss das eigentlich schief gehen. Ob das ein Fehler im Matter Adapter, im Type Detektor oder in der Role Definition ist weiss ich nicht.
Ich kenne verschiedene Zigbee Devices die als Light erkannt werden sollen, die aber weitere boolean States beinhalten - nicht nuravailable. Bei einigen davon gibt es sogar mehrereread onlyboolean states.In der 3.2.6 wird jedenfalls zumindest der state
availableeine andere Role bekommen:indicator.reachableTrotzdem ist die Kombination von Role definition, Device-Detektor und Matter Adapter in der Form mindestens mal unglücklich.
A.
- das der Type detektor den
-
@fabio sagte in Tester gesucht: Zigbee 3.2.x:
@Asgothian so Test beendet. Ich bestätige das dieser Fehler durch deinen Workaround behoben ist. Hab jetzt alle Geräte wo das war umgestellt, blöd nur das ich sie dann auch erst löschen musste im Matter Adapter.
Sollte man apollon77 das evtl. mitteilen? Ist das überhaupt ein Bug? Erst mal herzlichen Dank melde dich wenn du Zeit hast.👌
Grüße Fabio- das der Type detektor den
availablestate als 'SET_ACTUAL` deklariert ist unglücklich. Das der Matter Adapter den einfach so übernimmt auch. - Das der Matter Adapter nicht von sich aus auf geänderte Rollen reagiert ist meiner Meinung nach ein Bug - allerdings kann es sein das @apollon77 das absichtlich so umgesetzt hat.
Nen Issue ist das auf aber jeden Fall wert - dann kann geschaut werden ob das absicht, versehen oder bug ist.
Zum Thema Type Detektor (das ist denk ich nicht apollons direkte Baustelle) - das was da gemacht wird ist denkbar unschön:
Lt. der Rollen definition soll ein Datenpunkt dessen Role nicht zu den vordefinierten passt die Role
statebekommen:- state - very common purpose. If you don't know which role the state has, use this one.
Die Doku zum Type-Detector für lights sagt in der Tabelle das der Wert für
ON_ACTUALein Boolean mit der Rolesensor.lightsein soll. Leider sagt das Match-Muster das daneben auch Boolean states mit der RolestateoderswitchalsON_ACTUALgenommen werden.In der Kombination muss das eigentlich schief gehen. Ob das ein Fehler im Matter Adapter, im Type Detektor oder in der Role Definition ist weiss ich nicht.
Ich kenne verschiedene Zigbee Devices die als Light erkannt werden sollen, die aber weitere boolean States beinhalten - nicht nuravailable. Bei einigen davon gibt es sogar mehrereread onlyboolean states.In der 3.2.6 wird jedenfalls zumindest der state
availableeine andere Role bekommen:indicator.reachableTrotzdem ist die Kombination von Role definition, Device-Detektor und Matter Adapter in der Form mindestens mal unglücklich.
A.
@asgothian
Type detektor available wird als state als 'SET_ACTUAL` deklariert
https://github.com/ioBroker/ioBroker.matter/issues/618 - das der Type detektor den
-
Hey. Ja das an einigen stellen im type detector auch generische „state“ rollen genutzt werden sind der vergangenheit geschuldet. Kann ich leider so einfach nicht ändern. Alternative sind aliase oder Rollen korrigieren. Aber ja man kann gern type detector issue mit Beispiel Objekt Export anlegen dann kann man das diskutieren.
Das der matter Adapter (oder auch iot) nicht auf sich ändernde Rollen reagiert ohne restart bzw neustarten der Bridge liegt einfach daran das sich Rollen im Normalfall nicht einfach so ändern. Also für so einen Sonderfall Logik zu bauen empfinde ich daher als eher unnötig um ehrlich zu sein.
-
Hey. Ja das an einigen stellen im type detector auch generische „state“ rollen genutzt werden sind der vergangenheit geschuldet. Kann ich leider so einfach nicht ändern. Alternative sind aliase oder Rollen korrigieren. Aber ja man kann gern type detector issue mit Beispiel Objekt Export anlegen dann kann man das diskutieren.
Das der matter Adapter (oder auch iot) nicht auf sich ändernde Rollen reagiert ohne restart bzw neustarten der Bridge liegt einfach daran das sich Rollen im Normalfall nicht einfach so ändern. Also für so einen Sonderfall Logik zu bauen empfinde ich daher als eher unnötig um ehrlich zu sein.
@apollon77 ich bin nur ein einfacher Nutzer und kein Developer und verstehe auch nicht immer die Zusammenhänge.
Aber, ich persöhnlich finde das sehr merkwürdig, das An sich ändert wenn der State dafür aber nicht geschaltet wurde, sondern nur weil value generated 'true' from device a4c1389893367f90 for 'Available' geändert sprich abgefragt wurde, so weiß man letztendlich nicht wie in der Apple Home App, ist das Gerät nun wirklich An oder Aus. Und das finde ich ist ne Dikussion oder Änderung alle mal wert. ;-)Herzliche Grüße
Fabio -
Hey. Ja das an einigen stellen im type detector auch generische „state“ rollen genutzt werden sind der vergangenheit geschuldet. Kann ich leider so einfach nicht ändern. Alternative sind aliase oder Rollen korrigieren. Aber ja man kann gern type detector issue mit Beispiel Objekt Export anlegen dann kann man das diskutieren.
Das der matter Adapter (oder auch iot) nicht auf sich ändernde Rollen reagiert ohne restart bzw neustarten der Bridge liegt einfach daran das sich Rollen im Normalfall nicht einfach so ändern. Also für so einen Sonderfall Logik zu bauen empfinde ich daher als eher unnötig um ehrlich zu sein.
Das der matter Adapter (oder auch iot) nicht auf sich ändernde Rollen reagiert ohne restart bzw >neustarten der Bridge liegt einfach daran das sich Rollen im Normalfall nicht einfach so ändern. Also für so einen Sonderfall Logik zu bauen empfinde ich daher als eher unnötig um ehrlich zu sein
Nur als Klarstellung - beim Neustart des matter Adapters werden die Änderungen der Role erkannt ?
A.
-
Das der matter Adapter (oder auch iot) nicht auf sich ändernde Rollen reagiert ohne restart bzw >neustarten der Bridge liegt einfach daran das sich Rollen im Normalfall nicht einfach so ändern. Also für so einen Sonderfall Logik zu bauen empfinde ich daher als eher unnötig um ehrlich zu sein
Nur als Klarstellung - beim Neustart des matter Adapters werden die Änderungen der Role erkannt ?
A.
@asgothian Sogar beim "Nur neustarten (einmal aus und an) der Bridge" weil dann wird alles eingelesen und gemappt. Ja
-
Ich hab mal https://github.com/ioBroker/ioBroker.type-detector/issues/155 angelegt. Gern dort Meinungen rein hauen
-
Hab da ein Problem weis aber nicht Obs hier rein Passt.
Zumindest ist es die Testversion die ansonsten zuverlässig geht.
Hab angefangen zu Basteln, dazu wollte ich einen Externen Converter einbinden. Denke er wird auch gefunden nur der zugriff wird verweigert.
Das ganze läuft auf aktuellem Ubuntu unter Docker, ioBroker ist auch aktuell.

-
Bitte posten:
- den externen konverter den du nutzt
- die Einträge zum externen Konverter beim Start des Adapters. Da muss so etwas (o.a.) stehen
2025-11-23 20:12:40.755 - info: zigbee.0 (983320) Adding code from './../zigbee-herdsman-converters/dist/lib/modernExtend' as 'm' to sandbox -- success 2025-11-23 20:12:40.756 - info: zigbee.0 (983320) Adding code from './../zigbee-herdsman-converters/dist/lib/types' as 'type {DefinitionWithExtend}' to sandbox -- success 2025-11-23 20:12:40.757 - warn: zigbee.0 (983320) Trying to run sandbox for /opt/iobroker/iobroker-data/zigbee_0/shelly.js 2025-11-23 20:12:40.759 - info: zigbee.0 (983320) Model S4SW-001X8EU defined in external converter /opt/iobroker/iobroker-data/zigbee_0/shelly.js 2025-11-23 20:12:40.759 - info: zigbee.0 (983320) added external converter using addExternalDefinition (0 ms) 2025-11-23 20:12:40.760 - warn: zigbee.0 (983320) Trying to run sandbox for /opt/iobroker/iobroker-data/zigbee_0/esp.js 2025-11-23 20:12:40.763 - info: zigbee.0 (983320) Model ZBColorLightBulb defined in external converter /opt/iobroker/iobroker-data/zigbee_0/esp.js 2025-11-23 20:12:40.763 - info: zigbee.0 (983320) added external converter using addExternalDefinition (0 ms)A.
-
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; -
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. alsMat-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", };
