IFTT Webhook vs direct HTTP call -- string comparison behavior differs


#1

1) Give a description of the problem
I am using $arg to pass some information to the piston via a query parameter in the direct URL to the piston. This is just adding ?target= to the URL. Based on the value of target the piston does various things.

All is well when the URL is loaded directly in the browser. When called (GET) from a Webhook via IFTT things don’t work. Everything is identical in the logs between the two ways of calling the URL, but you see this difference:

Webhook
Comparison (dynamic) sconces is (string) sconces = false (2ms)
^^ Isn’t that wrong??

URL
Comparison (dynamic) sconces is (string) sconces = true (2ms)

2) What is the expected behavior?
Comparison (dynamic) sconces is (string) sconces = true (2ms)

3) What is happening/not happening?
Comparison (dynamic) sconces is (string) sconces = false (2ms)
^^ this is evaluating to false

**4)

5) Attach any logs (From ST IDE and by turning logging level to Full)

Via Webhook

    11/5/2018, 9:15:14 PM +52ms
    +0ms ╔Received event [Moreland].execute = 18.232.81.157 with a delay of 46ms
    +100ms ║RunTime Analysis CS > 18ms > PS > 67ms > PE > 16ms > CE
    +102ms ║Runtime (37279 bytes) successfully initialized in 67ms (v0.3.108.20180906) (101ms)
    +104ms ║╔Execution stage started
    +110ms ║║Cancelling statement #1's schedules...
    +120ms ║║Calculating (string) $args.target = + (string) sconces >> (string) $args.target = sconces
    +123ms ║║Calculating (string) $args.target = sconces + (string) >> (string) $args.target = sconces
    +128ms ║║$args.target = sconces
    +131ms ║║Executed virtual command log (4ms)
    +141ms ║║Comparison (dynamic) sconces is (string) sconces = false (2ms)
    +143ms ║║Cancelling condition #5's schedules...
    +144ms ║║Condition #5 evaluated false (8ms)
    +145ms ║║Cancelling condition #4's schedules...
    +146ms ║║Condition group #4 evaluated false (state changed) (12ms)
    +149ms ║╚Execution stage complete. (46ms)
    +150ms ╚Event processed successfully (150ms)

Direct URL

+1ms ╔Received event [Moreland].execute = 173.49.151.15 with a delay of 38ms
+108ms ║RunTime Analysis CS > 29ms > PS > 66ms > PE > 13ms > CE
+111ms ║Runtime (37279 bytes) successfully initialized in 66ms (v0.3.108.20180906) (108ms)
+112ms ║╔Execution stage started
+118ms ║║Cancelling statement #1's schedules...
+128ms ║║Calculating (string) $args.target = + (string) sconces >> (string) $args.target = sconces
+132ms ║║Calculating (string) $args.target = sconces + (string) >> (string) $args.target = sconces
+136ms ║║$args.target = sconces
+140ms ║║Executed virtual command log (4ms)
+149ms ║║Comparison (dynamic) sconces is (string) sconces = true (2ms)
+151ms ║║Condition #5 evaluated true (8ms)
+152ms ║║Condition group #4 evaluated true (state did not change) (9ms)
+155ms ║║Cancelling statement #14's schedules...
+179ms ║║Executed physical command [BR Left Sconce].off() (15ms)
+180ms ║║Executed virtual command [BR Left Sconce].toggle (21ms)
+197ms ║║Executed physical command [BR Right Sconce].off() (10ms)
+198ms ║║Executed virtual command [BR Right Sconce].toggle (16ms)
+201ms ║╚Execution stage complete. (90ms)
+203ms ╚Event processed successfully (202ms)

#2

That’s a strange one… let’s see maybe @ipaterson can give input on why that is the case. I’m also curious.


#3

Is it possible that the URL in IFTTT includes a space following sconces? It would not show up in the logs but would cause the condition to fail. The URL could look like any of the following in IFTTT

  • ?target=sconces followed by a blank space
  • ?target=sconces%20
  • ?target=sconces+

#4

Excellent idea. After some experimentation it turns out that a space was being prepended, so the string coming through was actually " sconces". The only way I was able to see this in the console was when I logged just the argument by itself. It gave this:

+113ms ║║ sconces

When I was logging “the value is {value}” there wasn’t a space, you can see that in the Webhook example log in my original post, the two log entries are identical. So I never saw it. Just the value and it jumped right out. It’s as if the whitespace is being trimmed. I did this a few times to convince myself. Strange.

But all is well now, thank you so much for pointing me in this direction! (I used ?target=sconces&x=1 to test for a trailing space or character).


#5

Great! HTML usually eats up extra whitespace so it was just merged with surrounding spaces, the log format certainly didn’t do you any favors in tracking that down.