HTTPd 2 plugin

Hi Joe,

I saw the instructions and I'm a bit confused -
1.) should I be using my external duckdns site for the address to activate the HTTPd?
a.) what does activate really mean?
b.) I didn't set var on anything, because I don't have/know any variables that need to be passed.
2.) the external site (using http://) redirects in my browser to secure connection with safari stating that it can't connect
a.) I used a self signed cert and placed it into the 7.5 folder as was described, but this didn't solve the safari error message
3.) do I need both a HTTPd server device and a webhook device?
4.) this is the log info:
Rachio Sprinklers Rachio Sprinklers Started
HTTPd 2 Warning getWebhookInfo failed, invalid ddnsName
Rachio Sprinklers Error Error getting user data from Rachio via API.

I appreciate some direction here as obviously I'm missing some key set up steps.

Thank you,
Daniel

1.) should I be using my external duckdns site for the address to activate the HTTPd?
a.) what does activate really mean?

Yes, you need a DDNS name in the HTTPd-2 plugin config. DuckDNS should work fine, I've used it for other things.
Where are you seeing the word "activate"? That word is not in any of my docs. You need a DDNS name for webhooks, because you have to provide the the domain name to the server generating the webhook calls. They usually won't take an IP address, and in any case that could change at any time.

b.) I didn't set var on anything, because I don't have/know any variables that need to be passed.

You don't need to do anything with available actions. That's done by the Rachio plugin. You just need to get the port forwarding set up and an HTTPd device to listen on that port.

2.) the external site (using http://) redirects in my browser to secure connection with safari stating that it can't connect
a.) I used a self signed cert and placed it into the 7.5 folder as was described, but this didn't solve the safari error message

You can't use Safari to test (very easily) because it insists on switching to https even if you don't want it to. I use a Terminal session and the 'curl' command.

3.) do I need both a HTTPd server device and a webhook device?

No, Webhook devices are for Python scripts that don't run all the time and can't receive the webhook calls directly. Plugins (like Rachio) don't need them.

4.) this is the log info:

Code: Select all

   Rachio Sprinklers               Rachio Sprinklers Started
   HTTPd 2 Warning                 getWebhookInfo failed, invalid ddnsName
   Rachio Sprinklers Error         Error getting user data from Rachio via API.


This should be step by step. Confirm each step is complete and if there's any doubt, show a screenshot or similar.

1. Set up port forwarding on your router. The default port for HTTPd-2 is 5555, but you can use something else.
2. Make sure you have a valid DDNS name in the plugin config. Confirm that resolves to the WAN address of your router. Turn on debug level logging in the plugin.
3. Create an HTTP server device listening on 5555 (or whatever you picked in step 1). You don't need HTTPS. Put in a username and password (only used for this one thing).
4. At this point, you should be able to do something like this in a Terminal window:
   

   Code: Select all

   curl http://myname.duckdns.org:5555/


   
   And see this in the Indigo log:
   
   

   Code: Select all

      HTTPd 2 Debug                   MyRequestHandler: GET to port 5555 from 192.168.111.1:62028 for /
   HTTPd 2 Debug                   MyRequestHandler: Request has no Authorization header:
   HTTPd 2 Debug                   {'host': 'myname.duckdns.org', 'accept': '*/*', 'user-agent': 'curl/7.64.1'}


5. Now if you restart the Rachio plugin, it should work.

Hi Joe,

Wildly successful, although I didn't turn debug messages on (which means I didn't see the response from curl) - the config pointers and understanding the different components entry points (where to place the ddns ultimately) got me up and running! I tested it out and have full functionality, now fingers crossed - this eliminates my rate limiting on the Rachio API.

Thank you for all your help,
Daniel

The only thing that gets updated from the webhooks is zone or schedule on/off changes. You'll still need to poll occasionally (hourly or so) to get the current data or forecast info, if you need that.

Hi, great plugin and I use it for many things!

But it is slooooooow for some reason.
The roundtrip to the server from a computer on the same net (also from localhost) is about 4+ seconds for digest auth and anything from 0.02 to 2.5s using basic auth.
I have to set timeout to 10s in my external programs that talks to your plugin over http and I had to alter your plugin to use 10s timeout for your watchdog funktion or it would reload tha servers every time it runs the check. I guess this must be a problem on my end and it works ok for everyone else, but what could be the problem for me?

Test script result

Code: Select all

================ RESTART: /Users/love/Desktop/Temp/httpd test.py ===============
start basic
roundtrip basic: 2.4500579833984375
start digest
roundtrip digest: 4.676287889480591
>>>
================ RESTART: /Users/love/Desktop/Temp/httpd test.py ===============
start basic
roundtrip basic: 0.7479290962219238
start digest
roundtrip digest: 4.748175859451294
>>>
================ RESTART: /Users/love/Desktop/Temp/httpd test.py ===============
start basic
roundtrip basic: 0.018049955368041992
start digest
roundtrip digest: 4.685456991195679
>>>
================ RESTART: /Users/love/Desktop/Temp/httpd test.py ===============
start basic
roundtrip basic: 1.153913974761963
start digest
roundtrip digest: 4.784738063812256
>>>

What address are you using to reach the plugin? If you're using a reflector address, then you're going round trip to the Indigo servers (AWS?) in the US and back again.

And yes, Digest should take about double basic, because the client needs to contact the server once to get the "digest needed" reply, then a second time with the actual auth information.

I only use local lan addresses, I have the same problem trying from localhost. Regardless, 4+ seconds is very slow.

Post your http test.py

Can do!

Code: Select all

#!/usr/bin/env python3

import requests
from requests.auth import HTTPDigestAuth
import time

indigoURL = 'http://192.168.123.12:8911/setvar'
indigoURL2 = 'http://user:psw@192.168.123.12:8910/setvar'
indigoUser = 'user'
indigoPass = 'psw'

payload = {'test_state':'some_value'}

print("start basic")
start = time.time()
r = requests.post(url = indigoURL2, params = payload, timeout=10)
roundtrip = time.time() - start
print ("roundtrip basic: " + str(roundtrip))
time.sleep(2)
print("start digest")
start = time.time()
r = requests.post(url = indigoURL, params = payload, auth=HTTPDigestAuth(indigoUser, indigoPass), timeout=10)
roundtrip = time.time() - start
print ("roundtrip digest: " + str(roundtrip))

Hmm. That is strange. Put the plugin in debug logging mode and see what it spits out.

Your code works fine on my system:

Code: Select all

jkeenan@Kraken Desktop % python3 http-test.py
start basic
roundtrip basic: 0.010370016098022461
start digest
roundtrip digest: 1.3944027423858643


However, your URL2 works for both basic and digest. You don't need to do the extra setup for digest, Requests will do it for you if the server says that it requires digest auth.

The code is working here aswell, but I get much longer roundtrip times.

This is debug output:

Code: Select all

Digest:
30447262   2021-09-09 13:58:11.196   FALSE   7   HTTPd 2 Debug   HTTPd test device digest: MyRequestHandler: updating device
30447261   2021-09-09 13:58:11.195   FALSE   7   HTTPd 2 Debug   Myrequesthandler: digest authorization valid
30447260   2021-09-09 13:58:11.194   FALSE   7   HTTPd 2 Debug   MyRequestHandler: auth_map = {'username': 'user', 'nonce': '1c41e7261ddbb1272bfaca8f49373b08', 'realm': 'HTTPd Plugin', 'algorithm': 'MD5', 'qop': 'auth', 'cnonce': 'b0f7077cb0602b01', 'nc': '00000001', 'uri': '/setvar?test_state=some_value', 'response': '7e7baa9d4ec50e19e536a19e352dd64e'}
30447259   2021-09-09 13:58:11.194   FALSE   7   HTTPd 2 Debug   MyRequestHandler: POST to port 8911 from 192.168.123.200:54127 for /setvar?test_state=some_value
30447244   2021-09-09 13:58:06.567   FALSE   7   HTTPd 2 Debug   {'content-length': '0', 'accept-encoding': 'gzip, deflate', 'connection': 'keep-alive', 'accept': '*/*', 'user-agent': 'python-requests/2.24.0', 'host': '192.168.123.12:8911'}
30447243   2021-09-09 13:58:06.567   FALSE   7   HTTPd 2 Debug   MyRequestHandler: Request has no Authorization header:
30447242   2021-09-09 13:58:06.565   FALSE   7   HTTPd 2 Debug   MyRequestHandler: POST to port 8911 from 192.168.123.200:54126 for /setvar?test_state=some_value

Basic:
30447237   2021-09-09 13:58:04.482   FALSE   7   HTTPd 2 Debug   HTTPd test device basic: MyRequestHandler: updating device
30447236   2021-09-09 13:58:04.48   FALSE   7   HTTPd 2 Debug   Myrequesthandler: basic authorization valid
30447235   2021-09-09 13:58:04.48   FALSE   7   HTTPd 2 Debug   MyRequestHandler: auth_map = {'username': 'user', 'password': 'psw'}
30447234   2021-09-09 13:58:04.479   FALSE   7   HTTPd 2 Debug   MyRequestHandler: POST to port 8910 from 192.168.123.200:54123 for /setvar?test_state=some_value

And script output:

Code: Select all

================ RESTART: /Users/love/Desktop/Temp/httpd test.py ===============
start basic
roundtrip basic: 2.359177827835083
start digest
roundtrip digest: 4.673550128936768
>>>

In debug (timestamp is time for insertion to postgresql) one can see that from request to update of device there is about:
0.03s for basic and
4.63s for digest

Script calculates roundtrip to 2.36s and 4.67.

For digest the times are "the same" but for basic there is something going on. I cant say if the differens is a delay in the request to the server or in responce from the server, there is anyway a difference of 2.33s.

Secont try (basic):

Code: Select all

30448296   2021-09-09 14:12:22.862   FALSE   7   HTTPd 2 Debug   HTTPd test device basic: MyRequestHandler: updating device
30448295   2021-09-09 14:12:22.861   FALSE   7   HTTPd 2 Debug   Myrequesthandler: basic authorization valid
30448294   2021-09-09 14:12:22.86   FALSE   7   HTTPd 2 Debug   MyRequestHandler: auth_map = {'username': 'user', 'password': 'psw'}
30448293   2021-09-09 14:12:22.859   FALSE   7   HTTPd 2 Debug   MyRequestHandler: POST to port 8910 from 192.168.123.200:54208 for /setvar?test_state=some_value

0.03s from request to update and script reports 0.29s this time.

Strange...

Regarding the URLs I have 2 different server devices for them, thats why I have different URLs w/ different ports.

Regarding the URLs I have 2 different server devices for them, thats why I have different URLs w/ different ports.

My point there was you do not have to do the explicit HTTPDigestAuth coding. You can use the same URL format and request call for both ports, and the requests library will handle all that. Like:

Code: Select all

#!/usr/bin/env python3

import requests
import time

indigoURL = 'http://user:psw@192.168.123.12:8911/setvar'
indigoURL2 = 'http://user:psw@192.168.123.12:8910/setvar'

payload = {'test_state':'some_value'}

print("start basic")
start = time.time()
r = requests.post(url = indigoURL2, params = payload, timeout=10)
roundtrip = time.time() - start
print ("roundtrip basic: " + str(roundtrip))
time.sleep(2)
print("start digest")
start = time.time()
r = requests.post(url = indigoURL, params = payload, timeout=10)
roundtrip = time.time() - start
print ("roundtrip digest: " + str(roundtrip))


I wonder if the delay is caused by the time to update the postgresql database? Like it's synchronous with the return from the call? I don't use postgresql and I'm not seeing that delay.