Parent/Child driver using Generic Component Switch

My first attempt at writing a parent/child driver...

I'm starting with an example from here:

But, my parent device has an addChild command (String name, String station). The idea is to create a child switch component with the specified name and station string. "station" is a string that is part of a message that must be sent over a socket to turn the child device on and off. The parent will send the message over a raw socket.

The motivation for having a parent/child implementation is to have a single socket connection for every child device.

If I used a custom component switch, I'd have a pref for the station string. Then I could (I think) set that preference after creating the child device and access it in he parent in something like a componentOn or componentOff method. Or, have the custom child pass the station string in a custom method in the parent.

But, I saw advice to use generic component devices for children, so I'm trying to do that.

I could keep a map in the parent device that has the station strings and is keyed by child device id.

Or, I could include that station string in the device name, and parse it out in the parent.

But, my first instinct would be to save the station string in the newly created child.

Is there a way to save data in newly created, generic component child devices? (Other than label and pre-defined prefs for the component device)?

Thanks!

Can I create an attribute that doesn't already exist in a child device by using sendEvent?

child.sendEvent(name:"attrubuteName", value:"value")

No you can’t really do that but you can create named data elements that are stored per device and listed in the data section at the bottom of the device.

device.getDataValue(valName)
device.updateDataValue(valName,value)
2 Likes

Ok, looking for an example of that now.

I assume you can create a new data item (something that doesn't exist) using updateDataValue? I saw this earlier, but assumed (based on the "update" in the name) that it had to exist.

It will create it for you

1 Like

Thanks to the help here I got the parent/child implementation working. But, for some reason the "Amazon Echo Skill" is behaving differently. Not sure whether I should continue in this post, since the issue occurred only after using a parent/child implementation, or start a new post in Community Apps. Let me know if I should move it.

In my original implementation (not Parent/Child) an utterance like "Alexa, turn off back" would result in an immediate "OK" response from the Echo and the associated switch would turn off.

Now, there is no "OK' reply from the Echo. The light still turns off. Several seconds later the Echo says something like "I'm not sure what went wrong".

So, there must be some sort of reply from my driver or the Amazon Skill immediately after receiving the message from the echo. But, I didn't (knowingly) do anything like that in the original implementation. Here's the "off" implementation in the one that results in the "OK":

def off() {
   if (logEnable) log.debug "Sending off request to [${settings.ip}, station ${settings.station}]"
   sendEvent(name: "switch", value: "off", isStateChange: true)

   interfaces.rawSocket.sendMessage("rf ${settings.station} off\n")
  pauseExecution(2000)
  //refresh()
}

Here's the componentOff implementation in the parent/child implementation:

void componentOff(cd){
    
      station = cd.getDataValue("station")
   
      if (logEnable) log.debug "Sending off request to [${settings.ip} ${station}]"
          
      interfaces.rawSocket.sendMessage("rf ${station} off\n")
      log.info "before pause"
      pauseExecution(2000)
      log.info "after pause"
      sendEvent(name: "switch", value: "off", isStateChange: true)
}

I tried moving the sendEvent before doing the write (so it would occur before the 2 second delay) but that didn't change anything.

Checking the "respond immediately without waiting for device" eliminated the anomaly:

But, why is that only required in the parent/child implementation? (I still have devices from the original driver and they don't need that box checked).

Is it possible that it's because the sendEvent is issued from the parent instead of the child?

Alexa knows nothing about the parent--only the child devices were added to the Amazon Echo Skill.

Or, is the sendEvent event relevant? Is there something else in a driver that must be done for Alexa to get the expected response? Or, should the Amazon Echo Skill (in Hubitat) take care of that?

Reposting the last few posts of this thread to the Community Apps forum...

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.