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!)
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?
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.
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?
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.
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.
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.
New at this--but, I just recalled that commands on the device prefs menu can have parameters. So, a "createChildDevice" command with string parameter is all I'd need.
Create one child device that handles the socket communication and then multiple children thar are just devices and these ask, via the parent for a command to be sent on to the X10 socket driver
