Utilizing the new composite device type

Developer Programs Writing Device Types
1

I’m working with @ranga and @dalec on the Home Decorators Fan Controller (Alpha) and plan to incorporate the new composite device functionality into it that will expose the different fan speed modes. I’ve made a little progress but my lack of programming skills have me stuck when it comes to the parent child communication and zigbee commands in particular.

Where I am right now:

parent DTH is called Home Decorators Module
child DTH is called Home Decorators Mode…I realize these aren’t very good names but I just wanted to get something together to test.
HD Module successfully creates the 5 HD Mode children when “initialized” and each is named as follows
{HD Module label} (Fanmode1)
{HD Module label} (Fanmode2) etc
I have tested using both isComponent true and false and both work as designed.
true - child devices do not show up in the Things view but are available to SmartApps
false - child devices show up in the Things views and in smartApps
I prefer false for the final code as it leads to a cleaner Things view but I’m leaving it as true for now because it allows for easier testing of the code.
Here’s where my lack of programming skills are showing :slight_smile:

My understanding is that commands can be passed from the child to the parent using the parent.childOn() method in the child DTH and the childOn() method in the parent DTH.
For example: when the “fanmode1” child is set to “on”, it should send “parent.childOn()” which in turn should execute childOn() in the parent DTH.
So, in the parent DTH I have added fanOne() command to the childOn() method.
When the child fanmode1 DTH is turned on, fanOne() does execute (as per the logs) but none of the zigbee commands execute. See code excerpts below and links to my github at the end of this post.

CHILD DTH

void on() {
parent.childOn(device.deviceNetworkId)
}

PARENT DTH

void childOn(String dni) {
fanOne()
}

As a work around I did the following and it works works, but I have my doubts that this is the correct way to use this new functionality:
CHILD DTH

void on() {
parent.fanOne()
}

PARENT DTH

childOn() is not utilized/called and so is irrelevant

Any ideas?

Module code (Parent)
https://github.com/stephack/NotMyCode/blob/master/devicetypes/stephack/home-decorators-fan-module.src/home-decorators-fan-module.groovy

Mode Code (child)
https://github.com/stephack/NotMyCode/blob/master/devicetypes/stephack/home-decorators-fan-mode.src/home-decorators-fan-mode.groovy

2

I am really excited with this new parent/child feature in the device handlers because it looks to be perfectly suited for this ceiling fan/light controller. Can any of you help us beginners in tackling this problem? I wish there was an existing ZigBee device handler utilizing this feature that we could at least try to learn from but the documentation doesn’t give any good examples for @stephack or I to learn from.

@krlaframboise @erocm1231 @tgauchat @Sticks18 @johnconstantelo

1 Like
3

I have some Z-Wave and LAN examples, but no Zigbee. :frowning:

4

Please send me the links to the zwave. At least that way I can see if it’s just a simple syntax error or something specific to zigbee.

5

The zigbee commands aren’t getting returned by the on and off commands because they’re declared as void.

6

I’ve tried with and without the “void”. Neither seems to work.

7

Here, here, and here.

Child here and here.

3 Likes
8

Danke…I will check them out shortly.

9

I’m pretty sure childOn has nothing to do with the composite device type, they just happened to use that as the name of the method.

I recommend doing something like the following because I’m not sure if the result will automatically get returned by the method because of the break line below it.

def on() {
log.info "CHILD PUSH RECEIVED"
	sendEvent(name: "switch", value: "on")
	//sendEvent(name: "switch", value: "off", isStateChange: true, displayed: false)
	//sendEvent(name: "momentary", value: "pushed", isStateChange: true)

	def myChildId = device.deviceNetworkId
	def myParentId = parent.deviceNetworkId
	
	def cmds = []
	switch(myChildId) {
		case "${myParentId}-1":
    		cmds += parent.fanOne()
    	break
    	case "${myParentId}-2":
    		cmds += parent.fanTwo()
    	break
    	case "${myParentId}-3":
    		cmds += parent.fanThree()
   		break
    	case "${myParentId}-4":
    		cmds += parent.fanFour()
    	break
    	case "${myParentId}-5":
    		cmds += parent.fanOff()
    	break
 }
	return cmds
}
2 Likes
10

@krlaframboise thanks for the suggestions. I may not have been clear in my original post. All the code in the switch/case statement work as expected. This is what I did to “workaround” the fact that using the childOn() method was not working. I wanted to use the standards outlined by the docs but I guess you are saying that the childOn method is more of a guideline. If that’s the case then I guess we’re good to go (till my next newbie roadblock anyway). Thanks for the feedback.

11

I’m almost positive that the reason your original example with childOn didn’t work is that the parent’s childOn is declared as void.

I know that the Zooz handler declared it as void, but they’re using sendHubCommand so the command doesn’t have to be returned by the method.

1 Like
12

I tried it with void and with def. I tried it with and without passing the device.NetworkId parameter. The result was the same. I even copied the code from the fanOne () command directly into the childOn () , with and without the return command, with and without void, with and without passing the parameter. Nothing seemed to work. I was stumped. Thats why I went with pointing directly to the command from the child DTH and that worked.

13

Here’s a question.
Look at the fanOne () command code.
If I want to have another method or command execute the fanOne command, is there any special syntax needed?

Example

def childOn() {
fanOne ()
}

def fanOne () {
Zigbee command here
}

14

fanOne is declared as a command at the top of the page, childOn isn’t so maybe that had something to do with it. It’s annoying when things don’t and there’s no reason why…

Besides returning it, I don’t think you have to do anything special.

1 Like
15

I haven’t tested it (because thanks to your info I now know that childOn isn’t needed at all) but it just occurred to me that it probably didn’t work because I didn’t declare the childOn method as a command in the Parent DTH. It’s the only thing I can think of.