Piston Fails when using Parse JSON with Wait


The following piston fails when the Wait on Line 27 is enabled. The items above the Wait execute, but the items below do not. I cannot attach a log, as no log appears when the Wait is enabled.

When I disable the Wait, the piston runs to completion per this log.


The JSON (the device is a Sonos speaker) has been confirmed as valid and parses correctly. But a Wait of any kind—from a Wait Statement, a GET request, etc— causes the piston to terminate without completing all of its tasks.


Same result when all the tasks are in one statement?


Yes, no change. I divided the statements simply so I could enable and disable the wait statement more easily.

FWIW, I’ve encountered this at least once before with different JSON, but this was my first opportunity to do more testing and really pin it down.


This one worked, although it’s not exactly like how yours is… I just finally got to a computer to mess with this.



I have not encountered a similar issue with $response in any of my pistons.

Again, when my piston is executed with Parse JSON and the wait present, the dashboard doesn’t even produce a log of the events.


Will try Parse when I get a chance.


In my testing, yesterday a simple JSON string like


didn’t cause the same issue.


I beat this pretty hard again last night from a number of different angles, my curiosity overcoming the more rational impulse to force yet another workaround.

The biggest problem in tracking this down is that there is no run log produced when the error occurs. Is there another way for me to peek at what’s going on behind the scenes?


That would be more of an @ipaterson question I think. See if he can give some insight.


Does this piston exhibit the problem you are describing? If so, which shard are you on (i.e. what is the web address of the page that loads after you log in at account.smartthings.com)?

I think we’ll need some idea of the amount of data coming out of presets for that device.


I’m just going to guess that one works fine. This beast, however, is showing the behavior you describe for me:

With that particular piston I see an error in account.smartthings.com > Live Logging > webCoRE:

physicalgraph.exception.DataCharacterLimitExceededException: Handler data length (15912) cannot be greater than 2500 characters. @line 1148 (processSchedules)

I recommend that after you pull what you need out of JSON, try doing another Parse JSON action with an empty object \{\} to clear the $json variable so that the piston does not attempt to store it before sleeping.


No. I’ve experimented with escaped strings and had not any issues.

In terms of data, the data by presets is an array of the format:

[{“id”: “74”, “name”: “Joe Smith”, “mediaSource”: “Amazon Music”}, {“id”: “83”, “name”: “My Playlist”, “mediaSource”: “Google Play”}]

There are currently 43 items in the array, each containing at least two of the items above, for a total of 2934 characters. That size could change as I add or subtract presets.


Confirmed, this works for me with the sample piston above. Here it is with the extra line to clear $json:


That works … :+1::grinning:


I love happy endings :smiley: – and learning new things


It’s odd, however, that I was able to store the entire response as a constant variable (with escape characters added, just as you did) and use it, but it fails there. I actually tried that because I had considered the length of the response being a possible issue. :thinking:

That aside. I’m happy too. :grinning:


And how did I ever forget to look at Live Logging in the IDE. grrrr


I did not know this… Good to know.


Yes, so apparently the JSON itself can exceed this length and can be parsed without any problem, but if the piston tries to store the $json variable due to any kind of wait, then the 2500 character limitation applies.

I’ve run across a similar issue before but can’t remember exactly where, as I was able to work around it more easily (or was simply less stubborn about tracking the problem down). I’m just thinking this 2500 character limit might apply elsewhere as well. It almost certainly applies to $response as well.


It makes sense if the total piston size is limited to 10KB