Calls to Pushover are failing


#1

My calls to Pushover from webCoRE started to fail after updating to the new webCoRE UI. Here is the log message:

Error executing external web request: com.amazonaws.services.cloudfront.model.InvalidArgumentException: Body parameter should be a string or if json a Map or List to auto convert (Service: null; Status Code: 0; Error Code: null; Request ID: null)


webCoRE Optional Update v0.3.111.20210130
#2

I use Pushover as well and noticed the same now that you mentioned it. The problem is actually more severe – it seems that the new networking code does not work with FORM requests. I’ve started working on a transformer for web requests to properly format form data.

FYI @E_Sch asynchttp_v1 supports automatic transformation of json only. I’m going to do a simple k=v&k2=v2 serialization (i.e. no support for one key with multiple values) but I’m not exactly sure if it did anything more complex before when this was handled by Groovy/ST.


#3

Is there a way to roll back to the previous version of webCoRE? I really don’t want to be without the Pushover notifications until a fix is made available.


#4

The fix is coming today, you can grab the code here if you don’t mind testing it out. The code can be pasted into the webCoRE Piston smart app at account.smartthings.com > SmartApps > webCoRE Piston, then save and publish. Here is the specific fix related to this issue.


#5

Sure, I’ll help by testing it out. I can either edit this message with my results, or add a separate reply. What are your preferences?


#6

Just reply here if you have any questions or to confirm that the API is working properly after the update.


#7

Are you sure your link is the new code? I still get the same error message. And when I click the “Compare versions” icon and scroll down to lines 7261 as per your specific fix link shows, the contents are the same as the original.


#8

So sorry about that, fixed link


#9

Thank you! Pushover is working again.

However, I used a test piston that simply sends a call to pushover and that worked fine. Then I tried to activate one of my pistons that reacts to my motion sensor and I noticed that the piston didn’t fire. This seems to be true of all of my pistons. I had to go into edit, then just save. Then they would fire. Then my real world piston also sent its message to Pushover. I don’t know whether the re-subscribing of my pistons is only my problem or not.

Update: Sorry, it’s not all my pistons. Some were firing, but not all. I’m not sure what was common between the ones that didn’t fire. I’m just going to edit all of them and then save to be safe.

Allan


#10

Interesting, I don’t think I’ve heard of that happening before. Would you be willing to share a green screenshot of one of the pistons that was not triggering? I would like to have a bit of data to compare in case anyone else reports something similar.


#11

Here’s a pretty simple one that wasn’t working until I re-saved it. However, now I’m not sure if the problem is related, because I went to test it again to make sure it was working before I sent you the screen shot of the code, and it DID NOT the fire. I checked my logs, and it had fired earlier in the day after I saved it. So I saved it again, and it started to work again. I think there might be a communication problem between SmartThings and webCoRE.


#12

Thanks! Sorry to hear that you’re still having trouble with it… I’ll be in touch if others report the same


#13

Thanks. I’d like to know that my problem is not unique. Makes it too hard to debug if it is.


#14

This error should be fixed in today’s 0.3.112 release.


#15

Thanks. I just ran the update from the repository. Pushover is being executed properly.

On pistons that call Pushover, the log file is showing the triggered piston, and a split second later another entry shows up:

02/02/2021, 21:53:44 +161ms
+0ms ╔Received event [Home].wc_async_reply = httpRequest with a delay of 1ms
+83ms ║RunTime Analysis CS > 16ms > PS > 5ms > PE > 62ms > CE
+86ms ║Runtime (41077 bytes) successfully initialized in 5ms (v0.3.112.20210202) (85ms)
+87ms ║╔Execution stage started
+96ms ║╚Execution stage complete. (10ms)
+102ms ╚Event processed successfully (102ms)

Is this expected behaviour?

Also, the log at the end of the piston that calls Pushover look like this

+151ms ║║Sending external web request to: api.pushover.net/1/messages.json
+242ms ║║Executed virtual command httpRequest (122ms)
+244ms ║║Requesting a wake up for Tue, Feb 2 2021 @ 9:54:07 PM EST (in 24.0s)
+249ms ║╚Execution stage complete. (174ms)
+251ms ║Setting up scheduled job for Tue, Feb 2 2021 @ 9:54:07 PM EST (in 23s)
+258ms ╚Event processed successfully (258ms)

The second last line of the log says it is setting up a scheduled job, but nothing shows up 23 seconds later. Anything to be concerned about?


#16

Yes, that is the response coming back from the web request.

That’s probably a fallback timeout in case the request hangs, so as long as the response comes back it looks good if it does not actually fire.


#17

Thanks again for the quick responses and repairs.

BTW, did a Force stop on the android phone, still didn’t load new version. Had to clear cache as well. And on the Chrome browser, logging out and re-registering didn’t work. Had to hit F12, then Ctrl-F5 to hard reload.

I always did hate upgrades (used to be in IT). :slight_smile: