Recent Platform Update Broke Parse Method Response/Result (April 2017)

At this point, if you’ve already reported it to support and you’re not writing your own code, I’d just wait and let the coders work with support staff and hopefully it will be fixed, or at least workarounds put in place, in the next few days.

If you have an open support ticket I would point them to this thread.

If you are using a custom device type handler, and the author of that DTH is not already participating in this thread, you might also give them this link.

If you are using a stock device type handler, again, definitely report it to support if you haven’t already ( I know you have) and mention this thread.

But if you’re just a regular customer using someone else’s DTH, at this point there really isn’t anything you can do. But again hopefully it will be fixed soon. :sunglasses:

Thanks. Yeah, I haven’t gotten very far in smartthings as I am just using whatever comes up automatically when I add a thing.

I did report it to Smartthings, by phone and Chat, but chat blamed it on a bad switch, so I am sure it didn’t go any further on their end.

My devices really does seem to go offline…Halfway. Hopefully this can be fixed too.

1 Like

If you’re using a custom handler there’s a really simple fix to the original device offline problem.

Put // in front of the line capability “Health Check” like:

// capability "Health Check"

That will exclude it from the Health Check monitoring so you don’t have to disable it for all of your devices.

Edit: No errors are shown in the logs, it just doesn’t do anything.

The problem occurs when you’re trying to send commands to the device by returning them from the parse method. For example, when the device wakes up and you send it configuration changes.

You used to be able to wrap the commands with response and return them and the commands would get sent to the device. Now that doesn’t work if you’re returning more than one command.

I thought at one point during my testing that it worked if the list didn’t have delays in it, but last time I checked it didn’t.

I also thought at one point during my testing that wrapping each command with response before adding it to the list worked, but last time I tested that didn’t work either.

Those inconsistencies are the reason I modified my original post.

Example:

Code like the example below stopped working on 4/20/2017:

def zwaveEvent(physicalgraph.zwave.commands.wakeupv2.WakeUpNotification cmd) {
	def result = []
	result += configure()
	if (result) {
		result << "delay 1200"
	}	
	result << nomorewakeup.format()
	return response(result)
}

private configure() {
	def cmds = [
		somecommand.format(),
		anothercommand.format()
	]
	return cmds
}

To workaround the problem and make it easy to put it back later I’ve been changing it to:

def zwaveEvent(physicalgraph.zwave.commands.wakeupv2.WakeUpNotification cmd) {
	def result = []
	result += configure()
	if (result) {
		result << "delay 1200"
	}	
	result << nomorewakeup.format()
	return sendResponse(result)
}

private sendResponse(cmds) {
	def actions = []
	cmds?.each { cmd ->
		actions << new physicalgraph.device.HubAction(cmd)
	}	
	sendHubCommand(actions)
	return []
}

private configure() {
	def cmds = [
		somecommand.format(),
		anothercommand.format()
	]
	return cmds
}

This is just an example so I didn’t use actual commands

2 Likes

As another poster says, no errors in the log, but my first attempt was just to use the documented sendHubCommand(list , timeout) and providing an actual list of commands with a timeout resulted in the cast exception.
My guess is that under the hood, my original response() with a list of the commands was generating a sendHubCommand with a list of commands and getting the same cast error but not logging it.

Shorter version that I wrote when I encountered this bug:

private hubResponseEncap(cmds, delay=250) {
    sendHubCommand( cmds.collect{ response(encap(it)) }, delay)
}

encap() is my encapsulation function that automatically decides between secure, crc16 and no ecnap. If you are passing already encapsulated commands just use ‘it’

Thanks for the details everyone. I found a bug with commands returned by parse and am working on the fix.

10 Likes

… Because I don understand all the ins and outs of smartthings and what “phrase” is, will this discovery once fixed, resolve the issue I am having?

This is off topic, but how do you determine whether to use crc16, secure or no encap?

I’m working on a device handler and the commands sent by the device are encapsulated with crc16, but it only accepts commands that aren’t encapsulated. I’ve tried crc16 and secure and it just ignores those commands.

It may or may not. Your problems are with the group documented by @XFighter that started early in the month, but do seem to have something to do with refresh. Or device health. Or both. :disappointed_relieved:

Then there’s the second group of problems that started on April 20.

So you may just have to wait until the fix being discussed in this thread is released and see if it fixes the problem you had.

1 Like

I just discovered this thread, which actually explains what was making me crazy since Friday 21st (the problem did NOT exists by Thursday 20th).
I can confirm that OUTGOING messages from a Device DO continue to work, but INCOMING commands into a Device never arrive, and thus are never executed.
I have tried everything I could, including power off / on of the Hub, repairing the Z-wave network, unpairing / repairing the Device, resetting the Device to factory settings, nothing works.
Which is normal, since it is a SmartThings cloud problem, as I lately suspected.
This happens with plenty of Devices since the Response/Result is used in most/all standard Device Handlers.

I submitted a Support Request (#345940: Z-Wave Device Turned Deaf Since 2 Days Ago) on Saturday 22nd, but got nowhere since.

I find quite disheartening that the SmartThings Status is currently “all green”, but I suppose it is kind of normal since their watchdogs are likely improved as newer bugs are found.
It would be nice if SmartThings DID acknowledge they have had a MAJOR cloud/platform problem since the last 4 days !!! :rage:

2 Likes

The problem reported in this topic started on the 20th and it has to do with commands returned from the parse method not being sent to the device. They’ve found the problem so it will probably be fixed within a couple of days, but in the meantime use sendhubaction instead of returning the commands.

That is strange. I’m just checking if the device reports support for crc16.

There is a function provided by SmartThings ‘zwaveInfo’ that parses device.rawDescription. So i’m just checking if zwaveInfo.cc.contains(“56”) (56 is crc16 command class).

Are you sure that your commands are received by the device? Maybe you are encountering a bug discussed in this thread. Try sending it using sendHubCommand. What function are you using to send crc command?

Thats nice to know, thanks for the information Kevin.

But in the meantime, I still find scandalous that the SmartThings Status continues to display an “all green” while likely 90% or more of Devices/Handlers have abnormal behavior.
And this has been going on for 4 days !!!
Likely, this Status is automatically updated through a “return response(…)” command :wink:

1 Like

@tpmanley Any word on when a fix for this is expected? I have a dozen or more handlers that are affected and am reluctant to modify them if a fix is coming soon. If the ETA is “this week” or something similar I may look into updating them all, but if it soon then I’ll ride it out.

1 Like

I’ve added the workaround to 16 of my handlers, but I’m wonder if there’s any reason to change them all back once the problem has been fixed.

Is there a benefit to returning createEvent and cmds wrapped in response or does it essentially do the same exact thing as sendEvent and sendHubAction?

SawJust got an email with this -

Hello,

On Tuesday, April 25, between 12:00 pm EDT and 4:00 pm EDT, we will automatically update your SmartThings Hub to the latest firmware (version 17.13).

A brief summary of the changes is as follows:
Numerous stability improvements and bugfixes
New diagnostics for hub problems
Ability to selectively enable automatic updates for some devices
New, more reliable update delivery mechanism

Hopefully this might fix the issue?

1 Like

I’m hoping the fix goes out today and will update here when it does.

It does the same thing so I think it’s fine to leave the changes in your code.

The bug that will be fixed is on the cloud side. I don’t think there is a thread about the 17.13 release, but it’s basically the same as the 17.12 release which was discussed here: Hub Firmware Release Notes - 17.12/17.13/17.14.

5 Likes

The hot fix has been released.

7 Likes

Thanks Brad, I confirm the “Parse Method Response/Result” works again for me.

It would also be nice if SmartThings did enhance its “SmartThings Status” dashboard : for the last 4 days it has shown “all green”, while 99% of devices were actually deaf and only half worked.

1 Like