HTTPd Plugin (useful for IFTTT Maker integration)

[philipbasile]

Hi
I am using the latest version.
The login and password are there it just doesn't show it in that screen shot.

Philip

[FlyingDiver]

So this appears to be an issue with the browsers, not with the plugin. Apparently, the browser won't accept the username/password in the URL, but insists on prompting for them separately. It appears you're using Chrome for testing. Have you tried the same thing with Safari?

[FlyingDiver]

I might just go ahead and add digest to the plugin so users don't have to mix and match, in cases like yours.

I'm sure that would solve a lot of mucking around. Your plugin also works around the need to store the main indigo credentials in random IoT devices.

Digest is in the current pre-release version.

[cjp767]

After about a year of HTTPd working perfectly, everything just came to a screeching halt and I can't figure out why. Nothing changed with my router-- port 5566 is still forwarded to my Mac Pro on 10.0.1.11. The HTTPd plugin is setup to use port 5566 with http. (not https). And I know dyndns finds my router fine (I use it to find my Mac Pro Security Spy app)

I noticed my plugin was old-- so I updated to 1.4.1.

My IFTTT account activity shows the following:

Applet skipped
Mar 16 - 12:20 PM
Automatic (the name of the device sending to IFTTT)
Prime off, then tell Indigo (the name of my IFTTT applet)
Unable to make web request: Error: ETIMEDOUT

From the Event Log--
Starting plugin "HTTPd 1.4.1" (pid 52832)
HTTPd Debug logLevel = 10
Started plugin "HTTPd 1.4.1"
HTTPd Starting HTTPd
HTTPd Debug Started HTTP server on port 5566

Nothing is getting out of IFTTT and into the Indigo Plugin.

The URL in IFTTT is in this format (I triple checked the userid/password)
http://xxxx:[email protected]: ... r1test=yay
Method: Get
Content Type: Text/Plain

Again, things have been working for about a year--and there's something I'm missing... Any ideas? Thanks for any advice.

[FlyingDiver]

A couple things to try. Since there's no activity in the Indigo log, I doubt this is a plugin issue. But just to be sure, go back to 1.3.2 and try again:

https://github.com/FlyingDiver/Indigo-H ... /tag/1.3.2

Also, test the URL from the command line using curl:

Code: Select all

curl http://xxxx:[email protected]:5566/setvar?var1test=yay

[cjp767]

Here's a chunk from my Event Log. It shows me downgrading my HTTPd plugin to 1.3.2. After that, I tried to send the variable change from the maker channel, but nothing shows up in the log. Then, I tried to reload the plugin. One thing I noticed about both of today's tasks is that the process failed to quit-- Is it locked up? This is a tough thing to troubleshoot-- I'd agree that the problem is likely someplace other than the plugin, but with it failing to quit, that makes me concerned. I've done plenty of computer restarts and Indigo restarts. I'm lost in the wilderness. Thank you again for your guidance.

Mar 17, 2019 at 07:08:57
Error process (pid 27732) failed to quit after polite request -- forcing it to quit now
Stopped plugin HTTPd
Downgrading plugin HTTPd to older version 1.3.2 (previous version moved to trash)
Loading plugin "HTTPd 1.3.2"
Starting plugin "HTTPd 1.3.2" (pid 37655)
HTTPd Debug logLevel = 10
Started plugin "HTTPd 1.3.2"
HTTPd Starting HTTPd
HTTPd Debug Started HTTP server on port 5566
HTTPd Debug Started HTTPS server on port 5556

Mar 17, 2019 at 07:11:41
HTTPd Debug validatePrefsConfigUi called
HTTPd Debug logLevel = 10

Mar 17, 2019 at 07:12:08
Reloading plugin "HTTPd 1.3.2"
Stopping plugin "HTTPd 1.3.2" (pid 37655)

Mar 17, 2019 at 07:12:23
Error process (pid 37655) failed to quit after polite request -- forcing it to quit now
Stopped plugin "HTTPd 1.3.2"
Starting plugin "HTTPd 1.3.2" (pid 38173)
HTTPd Debug logLevel = 10
Started plugin "HTTPd 1.3.2"
HTTPd Starting HTTPd
HTTPd Debug Started HTTP server on port 5566
HTTPd Debug Started HTTPS server on port 5556

[cjp767]

And here is a snapshot of my router configuration inside Apple's Airport Utility. It's the same as I've used for the last year or so. Maybe it doesn't like my settings anymore? As usual, thank you.

[FlyingDiver]

All that looks normal. The failure to quit is not unusual. I think I improved that in later versions, but I need to check.

Try the curl command in a terminal window and see what happens.

[cjp767]

I copied/pasted the command I use in IFTTT to Terminal. curl http:// (etc.) The command never completes-- I don't get a prompt again. I tried to quit terminal-- "Do you want to terminate running processes in the window? Closing this window will terminate the running process curl." And I Terminated it so I could try again.

I started Terminal again and sent the command again using my resolved dyndns address (24.18.151.....), in case there's a problem there. Same hung up Terminal.

I'm wondering if I should do another complete computer and router restart, just because. I'm still quite lost.

[FlyingDiver]

I would definitely reboot the router.

Then try pinging your DDNS address and see if it resolves properly.

[cjp767]

After both a router and computer restart, nothing has changed. The Terminal curl command hangs up and doesn't return to the prompt even when I type in my router address instead of dyndns.org (24.18.151.xxx).

I used Network Utility to ping my dyndns.org address and it seems normal.
--- cjp767.dyndns.org ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.063/1.989/2.915/0.517 ms


I'm going to take a break on this for a while. There's nothing obvious wrong, but with the curl command not getting out/in correctly, there's clearly a problem-- even though the port forward looks OK. Thank you for your time-- and let me know if you think of something I've overlooked. Again, It's been working for about a year now, and I don't think anything fundamental has changed... But I'm missing something.

[cjp767]

As a final summary, before I pull my remaining hair out, here is a screen shot of the players-- Network Utility shows my address resolved properly with port 5566 open. My Airport Utility shows TCP Port 5566 sent to my MacPro that lives on my network at 10.0.1.11. And finally, the settings for the HTTPd plugin are shown, with the userid/password x'd out. This has worked for the last year or so... I'm missing something very basic. Unless Comcast has locked port 5566-- or should I adjust the port forward?



And now this, from the log. It' s a successful variable change. It happened while I was taking the screen shots-- And I don't know where it came from (probably an earlier request). Now I'm more confused. I'll see what happens throughout the day. But something started to work.

Mar 17, 2019 at 10:33:46
HTTPd Debug AuthHandler: GET from 24.18.151.132:46862 for /setvar?var1test=yay
HTTPd Debug AuthHandler: Request has correct Authorization header
HTTPd Debug AuthHandler: setting variable httpd_var1test to 'yay'

[FlyingDiver]

That GET looks like it came from your IP address, so I’m thinking that was the curl command. Which leads me to think that there’s something going on with IFTTT.

Getting on an overnight flight in a few hours, so probably won’t be back until tomorrow afternoon.



Sent from my iPhone using Tapatalk

[mundmc]

After about a year of HTTPd working perfectly, everything just came to a screeching halt and I can't figure out why. Nothing changed with my router-- port 5566 is still forwarded to my Mac Pro on 10.0.1.11. The HTTPd plugin is setup to use port 5566 with http. (not https). And I know dyndns finds my router fine (I use it to find my Mac Pro Security Spy app)

I noticed my plugin was old-- so I updated to 1.4.1.

My IFTTT account activity shows the following:

Applet skipped
Mar 16 - 12:20 PM
Automatic (the name of the device sending to IFTTT)
Prime off, then tell Indigo (the name of my IFTTT applet)
Unable to make web request: Error: ETIMEDOUT

From the Event Log--
Starting plugin "HTTPd 1.4.1" (pid 52832)
HTTPd Debug logLevel = 10
Started plugin "HTTPd 1.4.1"
HTTPd Starting HTTPd
HTTPd Debug Started HTTP server on port 5566

Nothing is getting out of IFTTT and into the Indigo Plugin.

The URL in IFTTT is in this format (I triple checked the userid/password)
http://xxxx:[email protected]: ... r1test=yay
Method: Get
Content Type: Text/Plain

Again, things have been working for about a year--and there's something I'm missing... Any ideas? Thanks for any advice.

I hope I’m not muddying the waters, but some of my Indigo actions that utilize Maker Webhooks stopped working as of 3/15. I am curious if this is something on their side.


MunDMC
Fitter. Happier. More productive.

[FlyingDiver]

I hope I’m not muddying the waters, but some of my Indigo actions that utilize Maker Webhooks stopped working as of 3/15. I am curious if this is something on their side.


MunDMC
Fitter. Happier. More productive.

I suspect that's what it is.