How to convert driver to parent and child

[rumbleschad]

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?

[JasonJoel]

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.

[djgutheinz]

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.

Dave

[rumbleschad]

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

[ogiewon]

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

hubitat/HubitatPublic/blob/master/examples/drivers/genericComponentParentDemo.groovy

[rumbleschad]

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

[ogiewon]

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!)

[rumbleschad]

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

[davethomaspilot]

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?

[davethomaspilot]

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?

[kevin]

Are you adding a child device to an app ?

If so use addChildDevice

https://docs.hubitat.com/index.php?title=App_Object#addChildDevice

If it's a driver use

https://docs.hubitat.com/index.php?title=Driver_Object#addChildDevice

[672southmain]

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.

[RELEASE] GE Z-Wave Plus Motion Switch Component Driver

GE/Jasco Z-Wave Plus Motion Switch Driver This is a driver for the GE Motion Switch device. It differs from the in-box driver in that it exposes all of the device parameters, and uses a parent/child structure to put the switch and motion sensors in their own child devices. It has been tested with a GE 26931 motion switch. Example: [image] Features: ON/OFF Configuration of button inversion variable. Configuration of motion and light parameters. Light Off Time, Motion sensor on/off, Mo…

[RELEASE] GE/Jasco Z-Wave Plus Motion Switch Driver

GE/Jasco Z-Wave Plus Motion Switch Driver I got tired of the generic built-in driver missing features that are on the GE/Jasco switches. This was loosely derived from the ST device handler, but mostly re-written. NOTE 1: This is for the motion GE/Jasco Z-Wave Plus Switches only . It will not work with the non Z-Wave Plus models (12xxx), it will not work with any dimmer model, and it will not work with the non-motion Switch (14291). It has been tested with a GE 26931 switch. It should also …

[davethomaspilot]

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?

[kevin]

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

[672southmain]

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

[davethomaspilot]

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.

Thanks!

[672southmain]

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.

[davethomaspilot]

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.

[672southmain]

@davethomaspilot

Somehow, the devices need meaningful names to use those mechanisms.

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

[davethomaspilot]

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.