childDevice.sendEvent no longer works as of 4 days ago

I have a DTH that has worked perfectly for the past year that suddenly stop updating properly a few days ago. For some reason I can’t send “switch” events to child devices. I can update all other custom attributes with sendEvents but not “switch” events. In the code below, it does not throw any errors in the logs but the “each loop” gets broken and does not update the switch attribute for all the child devices. If I remove the 2 lines (commented out below) the “each loop” completes. Anyone know what’s changed or how I can fix this?

def fanSync(whichFan) {
	def children = getChildDevices()
   	children.each {child->
       	def childSpeedVal = child.getDataValue('speedVal')
        if(childSpeedVal == whichFan) {
            child.sendEvent(name:"fanSpeed", value:"on${childSpeedVal}")
            sendEvent(name:"switch",value:"on")
           	//child.sendEvent(name: "switch",value:"on")
        }
        else {
           	if(childSpeedVal!=null){
                child.sendEvent(name:"fanSpeed", value:"off${childSpeedVal}")
           		//child.sendEvent(name: 'switch',value: 'off')
           	}
        }
        
   	}
    if(whichFan == "00") sendEvent(name:"switch",value:"off")
}
2 Likes

I think @joshua_lyon might be experiencing this same issue (in regards to building a Wink relay handler…)…

4 Likes

Thanks pointing that out. He is using the composite device setup as well.
@rajk did anything change recently with the functionality of composite devices…more specifically with sendEvent from parent to child in my case at least?

4 Likes

@stephack No, man. Nothing changed.

@rajk Other DTH’s that use the composite model are having similar issues. according to the post below, ST engineers are aware of this and are looking into cloud issues that may be at fault. Anything you can find out and share would be appreciated.

See also,

3 Likes

We are getting ActionTiles customers reporting experiencing this problem.

Not sure what to say except that it helps confirm the issue exists.

Since many of the Devices are non-“WWST”, is there any value to Customers contacting Support@SmartThings.com ?

I wish, here’s the canned response our customers are getting :confused:

Hello xxxxxx

Thank you for contacting SmartThings customer Support. I’m sorry you’re running into trouble with those plugs, but I’ll be happy to look into this with you!

I have pulled up your account and I see the plugs that are currently offline are Inovelli brand plugs, which we do not support on the SmartThings platform. If you are having trouble with these devices, the only troubleshooting steps I can offer is to remove the device from the account and rejoin it to bring it back online. To remove a device, select it from the My Home page and tap the settings Gear icon. From there, you will see the option to remove the device at the bottom of the page. Once the device is removed, go ahead and follow the manufacturer’s instructions to rejoin the device back to your account.

For a list of certified outlets that are supported on the SmartThings platform, please view the following page

Please let me know if you have any further questions or concerns. Thank you!

Hope you have a great day!

xxxxx


I’ve had about 5 people send me this. Hopefully we can figure this out soon!

1 Like

:persevere::persevere::persevere::persevere::persevere:

1 Like

I have the same problem.

Currently, a parent device’s parse() is handling an event from the childDevice.sendEvent().

The issue is with the isComponent=true on the call to addChildDevice. If you set it to false it should work. I understand this isn’t a workaround for most people, but the good news is SmartThings indicated that they expect the issue to be fixed in the next platform deployment.

IIRC, they used to do platform deployments each week on Tuesdays, but someone from ST would have to confirm.

4 Likes

A fix this issue has been rolling out for a few days and it should be fixed for most users already. However it’s possible that a few people won’t see the fix until early next week just do to the staged rollout.

4 Likes

@tpmanley Does the fix also fix the child creation problem that I have listed here Problems with child creation at the moment?
Thanks again

@cjcharles I tested your DTH and had the same issue you described. I am not having this issue with my composite DTH. I haven’t noticed anything obviously wrong with your code but there are a few differences. Take a look at my fan controller DTH and reverse engineer. It might be a simple syntax error or the fact that you didn’t provide component labels…or it might be a backend issue. I would try to find exactly where things break while reverse engineering my DTH and pass that info along.

1 Like

@cjcharles, this is something different than the isComponent issue. I responded over in that other thread.

1 Like