I'm trying to write a driver for a 2 gang zigbee light switch. Here are my questions:
Is it best to use the parent/child component driver, so that each gang is exposed as a separate device?
if so, should i use Generic Component Switch driver for the child device?
if so, how can i send event from parent as if it was send by the child?
alternative to the above is to have a single driver with commands line "on1", "on2", "off1" and "off2". is it possible to expose such device as 2 independent switches to Google Home?
That's a personal choice as "best" is subjective. In my opinion, the parent with child component is best because it gives you the most options. It also gives you more code to write.
I'm not sure what the Generic Component Switch driver was designed for, but in the cases where I didn't write my own child driver, I used the Virtual drivers (Virtual Switch, in this case).
The actual device commands (zigbee, zwave, LAN) should all go through the parent device. For example, the child device for switch 1 would have an on() command that would simply execute a parent.on1() command. In the parent driver, the on1() command would send the actual device command to turn on switch 1. Same for switch 2.
One device can't be exposed as 2 independent devices to GH/Alexa/etc. That is one of the primary benefits of using the child component model.
You can still have the on1 on2 off1 and off 2 commands in the parent device. This way you can control both switches easily from the parent device page AND still have individual control from each child device page.
Does this mean that the parent driver is responsible for publishing events on behalf of the child, i.e. sendEvent(name: "switch", value: "off")? Is it simply the case of calling child.sendEvent.. or is there another method?
Correct...Simply a case of sending child.sendEvent.
There are a few drivers out there you can use as a reference. There is an Inovelli outdoor 2 outlet driver and the Hampton Fan driver.
Yes, then you can use the switch command in the parent as an all on, all off.
Yes
Component devices use a special form of parse.
That way the child logging options are respected.
From the parent, cd.parse([[name:"switch", value:value, descriptionText:descriptionText]])
Where the parameter to parse is a list of maps, so you can send multiple events in one shot.
The parent implements methods for each child capability command in the form:
Where d is the child device wrapper, which can be used or not depending on the need.
In the case of the above, it's being used to extract the endpoint Id that was appended to the dni when the child device was created.
There are a number of user made patent/child drivers out there. But since they are done various different ways, if there is a preferred method that matches up to how the in-box drivers are done, that would be my preference. I'm fine with following the go-by in terms of structure.
Looking at it though it seems me ( i am a groovy novice) all the "child" directed commands are from an internal (to the hub) source. If the light switch were to send an unsolicited current state report. How could the parent determine which "gang" was generating the report?
I ask this because I have an illumination sensor that outputs two different measurements of Lux. It was suggested I use a parent-child structure but I can't see it. What am I missing?
My current more basic approach is to send the two Lux readings concatonated by some character then splitting them in the parse routing. I would then send one to a virtual device.
The parent receives and sends commands to the device. Every multi endpoint device I've worked with provides some means of identifying the source endpoint for the reports it sends, I usually make the child dni using the parent device id plus the endpoint Id, ie 234-01, that way when the payload comes in I can figure out which child to route the message to.
