(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 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.
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.
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
───────────────────────────────────────────────────
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.
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).
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?
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
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
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.