(EDGE Driver-Mc). New Zigbee Device Config Mc driver

(EDGE Driver-Mc). New Zigbee Device Config Mc driver

Similar to Z-wave Device Config Mc, it is a tool to configure options or atributes settings in devices that do not exist in the edge drivers.

It has integrated almost all the standard clusters from the lua libraries and several custom clusters, lumi, ikea libraries,… to be able to offer information on the device’s responses to the commands sent.

It is also useful to use the CLI logs simultaneously to see response messages or errors in the commands that are not captured by the driver.

It has three selectable profiles from the preference settings:

  • Device Fingerprints Info: This is the default profile and is the same as Zigbee Thing Mc. It shows the device’s fingerprints, clusters, and endpoints.

  • Device Attribute Read or Write: This profile allows you to read or write values ​​from clusters and their attributes to be able to configure operating options, such as:
    • Restore device status after a power loss.
    • Configure the status of the LED indicator, child lock or any other cluster, attribute, data type and values ​​that we know.
    • some Tuya examples:

DP38 Relay status

Direction Cluster ID Command/Attribute ID Value
server 0x0006: On/Off 0x8002: Tuya-specific attribute
Data type : enum8 (0x30)
  • 0: Off.
  • 1: On
  • 2: Last on/off state|

DP40 Indicator mode

Direction Cluster ID Command/Attribute ID Value
server 0x0006: On/Off 0x8001: Tuya-specific attribute
Data type : enum8 (0x30)
  • 0: Off.
  • 1: Indicates status. The indicator comes on when the switch is turned on.
  • 2: Indicates position. The indicator comes on when the switch is turned off.|

DP41 Child lock

Direction Cluster ID Command/Attribute ID Value
Client to server 0x0006: On/Off 0x8000: Tuya-specific attribute * 0: Release* 1: Lock
Data type : boolean (0x10)
  • In devices with battery, which are asleep, we normally have to wake them up before sending the read or write command so that they respond.

  • For custom cluster and attributes you need write the Manufacturer Code in Hexadecimal format

  • For standard zigbee clusters and attributes the manufacturer code field must be nil

  • Device Attribute Configure Reporting: This profile allows reading and writing the configuration of cluster report intervals and their attributes.

    • This configuration report should not be changed in devices that work with drivers that have the Health_Check function activated.

    • With firmware version 55.x smartthings have announced that in the stock drivers they are going to disable the Health_check function,
    • In my Mc drivers I am also going to disable it, for the moment, in devices with battery, in which it never served any purpose.
      In several Mc drivers already have preferences to customize the report configuration to save battery and in general to unload the zigbee network from repetitive messages and reduce the work of the Hub and therefore it is not necessary to use this driver.
      You can modify interval reports from preferences and since when you go back to the Mc driver, the settings in preferences will be reset or may become out of sync

The easiest way to use it is:

  • Write the cluster and attribute fields you want to configure in hexadecimal format.
  • Select the Read Attribute option
  • Click on execute action

  • With the device’s response you will know the current configuration, minimum interval, maximum interval, reportable change and data_type and the Success or error status.
  • If you want you can change any value
  • Select Write Attribute and click on action.
  • The new values ​​will be sent and the SUCCESS status or an error will be displayed if there is one.

  • For custom cluster and attributes you need write the Manufacturer Code in Hexadecimal format
  • For standard zigbee clusters and attributes the manufacturer code field must be nil

When Cluster info capability remains in Waiting…Info then and error message and does not captured by driver, you can see it in cli logs

If you detect any operating error I will try to solve it.

This is the driver version

───────────────────────────────────────────────────
 Name         Zigbee Device Config Mc
 Version      2024-11-23T12:32:32.575573315        
───────────────────────────────────────────────────

My Beta Drivers channel link: SmartThings. Add a little smartness to your things

As some users have asked me, if you find these Mc drivers useful and wants to invite me to a coffee, Thanks

14 Likes

Awesome! This driver looks like a game changer for devices that should work as documented but simply don’t. Reduces the turnaround time to a few clicks. I wish I had it a week ago.

A week ago it didn’t exist and if smartthings hadn’t announced that they will disable the health_check feature in stock drivers I wouldn’t have done it, since it would generate unnecessary work for the hub and an increase in network traffic polling devices if it doesn’t receive messages at the default intervals.

Therefore, if you extend more of 1.5 x max interval report the intervals in the standard or custom capabilities with respect to your driver configuration and monitoring values, you have to disable health_check in the driver.

Setting health_check = false in your driver template.

1 Like

@Mariano_Colmenarejo

For some reason, I’m unable to use this to read or update the ‘detach_relay’ for the ZBMINIR2.

Cluster: 0xfc11
Attribute: 0x0017
Manufacturer: 0x1286

Also, is there any way you could get the ZBMINIR2 into the ZigBee Switch driver fingerprint? I was digging through the GH repo code to try to make sense of it to potentially write my own driver that would allow me to control my smart bulbs without the physical switches turning off the circuit.

@cookopotamus Mariano is currently not active in the forum so you probably won’t get an answer.

I’ve never used this driver but what you need to know is the cluster, the attribute and the value you have to write. Looks like you have the cluster and the attribute but not the value.

Edit: According to another platform it’s just a boolean, so true or false. But that’s for switches with only one relay… if there are two relays I believe it’s a bitmap.

So, that’s a bitmap where each bit determines the detach state for each relay. If there are two relays you should need to write the hex value 0x03 (that would be in binary 11 meaning both relays detached), or 0x00 (both normal).

They also have mentions in the code of

detachRelayMode: {ID: 0x0017, type: Zcl.DataType.BOOLEAN},
detachRelayMode2: {ID: 0x0019, type: Zcl.DataType.BITMAP8},

So the attribute is 0x0019 when there are two relays or more and 0x0017 when there’s only one.

Ah dang, that’s sad to hear.

But also, if I’m just trying to read a value… I don’t need to know those, right?

It returns the type and current value for other attributes I look at (like the ones listed in his post).

But when I do the one I mentioned it gets stuck on “Waiting” indefinitely.

Since it’s a private cluster / attribute it may not support reading operations. Eve for instance has an attribute to write configurations and another to read the configuration.

Try writing a boolean true to 0x0017 and see what happens. Your switch has only one relay, right?

I’ve got it hooked up in a 3-way circuit (two switches, one light). So I’m guessing that means two relays? Or is the relay just the ZBMINIR2.

What is the data attribute type for writing bitmaps with this tool?

Yes, it’s just one relay.

No bitmaps then, just the boolean in 0x0017.

I’ve got it hooked up in a 3-way circuit (two switches, one light).

For a 3-way is enough with one since they have switch inputs, isn’t it? Guess you meant you have one ZBMINIR2 and two switches. OK, forget it :rofl:

Hah, yeah. Two physical rocker switches controlling a single smart ceiling light in a stairway. I’m trying to put this ZBMINIR2 in so that if I’m not near my phone or feeling lazy (or forget because of muscle memory) I can also flip the rockers and not have it ruin the entire smart setup :skull:

I tried setting the boolean for 0017 to 1, but not getting any feedback that anything happened and since I can’t read from it I have no clue. But it also never changed from “Waiting…”

Honestly, looking into Home Assistant, I might just switch to that. SmartThings is too limiting for my software developer brain and DIY mindset :sweat_smile:

It’s hard for a driver to get feedback on what happens when sending a write command, and it’s also hard to communicate errors to the user. You should be able to see what’s happening in the logcat with the SmartThings CLI. At least you’ll know if it arrived, it if succeeded or if it failed and the reason.

You may even discover why the reading operation seems to fail.