Suggestion to multi endpoint DTHs (Solution to only child switches being offline)

Multi endpoint DTHs, such as “zigbee multi switch”, uses parent & child system.

Let’s say, for 2 gang switch,
when parent dni(device network id) is A123,
child dni is named as A123:02

But in some situations, such as instability in zigbee network, parent device gets rejoined, and dni of the parent gets changed, let’s say to B456

However, in this situation, dni of the child device remains with old dni prefix, A123:02,
so this makes the problem of child device being offline.
Child dni should be changed to B456:02, when parent dni gets changed to B456.

I have heard from lots of people that are suffering from this problem in Korean Smartthings community, especially in “DAWOS DNS In-Wall Switch”, a Korean WWST product.
(Unlike in United States, where most wall switches are 1 gang switches, almost all wall switches in Korea are multi gang switches. cultural difference.)

So I suggest that it would be better to change child dni of the multi switch, when parent dni gets changed.
One solution would be adding following code to configure() function or updated() function in “zigbee-multi-switch.dth”

childDevices.each {
def childEndpoint = getChildEndpoint(it.deviceNetworkId)
if (it.deviceNetworkId != “$device.deviceNetworkId:$childEndpoint”) {

Thank you.

I believe you’ll have to detect the change in the DNI and have the DTH change the DNI for the child devices. The platform does not make assumptions about child devices because some child devices have virtual DNI’s and may need a change even if the parent DNI changes.

1 Like

Yes. That is exactly what I am saying.

The additional code above for “zigbee-multi-switch” dth is doing that job in DTH level.

When rejoin happens, configure() function would be called, and when dni changes, updated() function would be called.

the code above is changing each of child device’s dni according to parent’s dni, when parent and child dni does not match.

So it would solve the problem if you put the code above in configure() or updated(), child dni problem will be solved.

FYI, DAWON in-wall switch is a wall switch that works without neutral wire. So it works as SLEEPY END DEVICE, which makes it more likely to be unstable than switches with neutral wire that work as zigbee ROUTERs.

Since I cannot change the built-in “zigbee-multi-switch” dth of the WWST product, which makes probem for lots of people using DAWON in-wall switch, I’m suggesting the solution to Smartthings team.

1 Like

This is good work, hopefully the SmartThings team will test this out and update the DTH

To Smartthings team.
Thank you very much for your immediate response.

1 Like

Regarding the new changes in Zigbee Multi Switch,

There seems to be some problem, when creating child devices without leading zero, as you mentioned in github thread above.

addChildDevice(“Child Switch Health”, “{device.deviceNetworkId}:{i}”,…

If there’s no leading zero, there might be some problem in parse() method.
In parse method, eventDescMap?.sourceEndpoint and eventDescMap?.endpoint used to tell which endpoint is used, and these are texts with leading zero, such as “01”, “02”.
But if the child devices are created without leading zero,

		def childDevice = childDevices.find {
			it.deviceNetworkId == "$device.deviceNetworkId:${eventDescMap.sourceEndpoint}" || it.deviceNetworkId == "$device.deviceNetworkId:${eventDescMap.endpoint}"

the code above, which finds childs devices with DNIs, might not work properly.

Please revise the source code, if needed.

And please consider that, devices already paired with this dth, have child device DNIs already created with leading zeros.

So if you consider to create the child devices DNIs without leading zero, then, there must be some consideration with already created child devices with leading zeros.

For now, because parse() function is written assuming leading zero, so, I don’t have any problem with my zigbee multi switch device for now, because my child switch devices are already created with leading zeros. But if I pair another device now, then child DNIs will be without leading zero, and this could make some problem.

Thank you.

Thanks for catching this. I’ll make sure it’s addressed.


Quick update.

I just finished deploying a hotfix of this change:

I also called updated() on all installed devices using this DTH. This should have both fixed any errors caused by the bad DTH deployed on Tuesday as well as fixed any existing devices that had not yet been fixed.

We appreciate you pointing out this mistake for us.