How to convert driver to parent and child

Hi all been working on a driver for a moes light switch but am very lost how to do parent driver the child driver for each switch also how to get status of each switch. please can anyone help?

Fastest way is to go look at a user driver that is already in parent/child form as a go-by. There are oodles of them.

An example (created by me) can be found at : HubitatActive/bleBoxDevices/Drivers at master · DaveGut/HubitatActive · GitHub

Parent: wLightBox.groovy
Children: wLightBoxCt.groovy, wLightBoxMono.groovy, wLightBoxRgb.groovy, and wLightBoxRgbw.groovy.

The parent has a lot of logic you will not need; however, it has the basic strucure.


1 Like

Hi Dave thank you so much will have a look and try figure it out :crossed_fingers:

One thing I would strongly encourage you to do is to use the built-in "Generic Component ..." drivers. These are designed to be Child Devices, and are what Hubitat uses for their own Parent/Child device drivers (note: Parent drivers are unique, but the Child drivers are generic.)

There is even an example of how that are used in the official Hubitat Public GitHub repository.

Here is the example Parent

thanks but problem is i have a moes tuya light switch and it does not work with any of the drivers i have a bit of a driver but all i can do is switch each switch on from the driver page

Sorry if my post was confusing. My suggestion is for you to write your own Parent Driver that handles all communications with the Moes Tuya Light Switch. Have your custom driver, create child devices using Hubitat's built-in child drivers. The child drivers will only talk to the parent device. They will not communicate directly to the Moes Tuya Light Switch.

The advantage of doing this means you only have to worry about writing one driver, and the end users of your custom driver, will only need to install and maintain one custom driver. Everyone's hub already has the Hubitat Generic Component... set of drivers.

Here is a subset of the built-in child drivers that you can use... I circled the ones that 'might' be useful for your switch (I have no experience with what your switch is capable of!)

1 Like

Thanks I think I am going to look at replacing the switchs for I can get control of each gang from device page (with driver have made) but that is it. I just can't figure out the code or how to implement the child drivers etc. Thanks for your assistance

I also want to convert a custom driver to a parent child. I was advised to do this as a way to prevent all instances of my custom device getting the same rawSocket reply.

If I create a parent like the example referenced and use a generic component switch, do I create instances of those child devices just like I would a "non-child" generic switch? Or, do I need method(s) in the parent driver's code to create component devices with user input name, etc?

So, I grabbed the generic parent driver from above and created a device of that type.

I then created a generic Component switch device.

But, I see no way to associate the child with the parent.

Do I have to pre-define children instances in the parent? Or, have a custom app to associate child devices with a parent?

Are you adding a child device to an app ?

If so use addChildDevice

If it's a driver use

1 Like

There is a good example to compare. Jason Bottjen (@JasonJoel) has both component and non-component versions of his driver for the GE/Jasco 26931 switch. Both versions have the same functionality.

Thanks for the method documentation.

That seems to suggest my driver would have to do the addChildDevice after getting user input for the child device name, etc. Is my understanding correct?

It can create child devices automatically - you don't need to get user input

1 Like

That’s exactly why I suggested Jason Bottjen’s drivers as an example.

This looks like I'd need a unique device for each parent.

I don't think that will useful for resolving the issue.

I think I can see how to make it work if the parent device creates the children. Then, the socket communication is done only in the parent. The children go through the parent for the message sends.

But, if create a parent+child(s) for each physical device, it doesn't eliminate the problem.

I don't think the issue is troublesome enough to deal with having to create new devices in the driver (or a custom app). I can just ignore the message replies from the rawSocket instead. Increases traffic on the socket by a factor of 10 (the number of devices that uses the rawSocket interface), but still, not a big deal.

Please correct me if I don't have it right.


No, I think you have it correct. I believe everything does have to go through the parent. I didn’t realize that you simply were trying to get more sockets.

It can create child devices automatically - you don't need to get user input

By automatically, you mean the parent driver could make the addChildDevice without a user supplied name, maybe just create sequence number prefix/or suffix?

Still, it seems this would really mess up how groups, scenes, and rules would work. Somehow, the devices need meaningful names to use those mechanisms.

Well, the user can always go in and edit the device label.

1 Like

I didn’t realize that you simply were trying to get more sockets.

Well, not so much that.

My driver uses a custom driver with a rawSocket interface to send messages to a server for X10 device communication. I have 10 devices of that type.

What's weird is that the reply from a single message send is sent to parse() function of every device of that type. Like they all share the same socket, at least on the read side.

But, I now know they don't really share the same socket, since when I don't have enough delay between device on/off actions, I get "broken pipe" messages. But, that happens on only one or two devices--the rest continue working.

And, the ones with the broken pipes work again if their initialize method is called (which does the rawSocket close and reopen.

Maybe it's a problem in the rawSocket implementation or that's the way it's supposed to work. Had another thread on this last week and someone suggested using a parent/child driver implementation to address it. Probably would, but with the trade-offs discussed earlier in this thread.

1 Like