MWareman

I don't think the tinyurl 'solution' will work either. They all send 3xx redirects - and we have already established that the Foscam will not follow a redirect. Really, either the ISY needs to be able to accept REST calls without a password (bad, bad idea!), or ISY needs to add an optional parameterized token authentication system (don't know if this is on the feature wish list for 5.x or not), or, frankly the best solution, the Foscam needs to be fixed to allow all RFC compliant URLs, which it currently does not. This is a Foscam RFC non-compliance issue, not an ISY issue. However, its also a 'beta' feature of Foscams we are trying to figure out, so its not that surprising that Foscam have not fully implemented the feature yet.

That's fine, but the Foscam can't run that. The Foscam can only call a simple URL without a username or password, and a simple GET request. Not much the ISY can do without a correctly supplied username and password. Hence the need for an intermediate script.

I agree. I don't think the Foscam will follow a 3xx redirect presented by the server. Nor do I think you can have the ISY username and password passed to the REST api of the ISY as parameters.

I went one further - wireshark on a monitor port on my switch. The Foscam works as expected when a simple URL is present, however when the URL contains a username and password it does not even establish a TCP connection with a SYN packet. The camera just send to think the URL is invalid and refuses to use it.

Sorry, I meant to say neutral, not ground. Oops... Also, hadn't realized that there were not any KPLs without a neutral either.

Sounds like you might be using the KPLs without a ground wire. They won't work with very low current devices, like LED bulbs, because the voltage drop is insufficient to power the KPL.

Yes, It shows the URL as I want, but nothing actually happens (wireshark trace). The Foscam seems to be ignoring what it considers to be an invalid URL.

Oh, and it would be better to set the cam to trigger a program. Then you could set your own timeout.

Did this work for you? I cannot get the camera to work with alarm URLs containing a username and password.

I use an Apache instance with a wildcard SSL cert (from cacert), external DNS cname records for cam1.domain.com, cam2.domain.com etc all pointing to my dynamic DNS name where my Apache listens on 443. Apache unwraps the SSL, receives the name requested, routes the request to the appropriate name base vhost then forwards the request to the non-SSL port on the cam using mod_proxy. This results in SSL wrapped access, all thru standard port 443 (no matter how many cameras). Sound does not work though, but I don't need that. Just secured access thru a standard SSL port. My ISY REST and SOAP interface can be accessed this way as well, but the GUI does not work (due to the way the event subscription works). You need an Apache server to run as a proxy, but I'm happy to help you set this up is you have a machine available. It needs much more horsepower than the likes on a Pi or similar can deliver, unfortunately. I run it only MythTV back end which has horsepower to spare, and is running all of the time anyway. I really should just setup a VPN though... Much easier. Michael.

Use a router that supports dns-o-matic (like Asus and many more - I use pfSense on an Alix device). Then choose from one of the many free dynamic DNS providers. I use dns.he.net. Dynamic DNS is properly placed at your router, not a device behind your router. Michael.

Welcome! Allow me to regurgitate my wish list... Personally, I'd like to see the admin console and dashboard completely go away, and all config manageable via the web ui. This should be coded using responsive techniques (viable for mobile and desktop browsers), modern (html5) and themeable (allow third party themes to be uploaded and selected). Next request is multiple user accounts, with a permissions model in place (monitor/read only, can control, admin). Allow a user account/password to have one or more strong, random 'tokens' that can be passed into the REST API as a parameter so that devices that cannot basic with can also be functional. Next, newer authentication possibilities with the network module. It really hurts currently to configure resources that talk to oAuth secured REST APIs. This should be a solvable problem, along with variable substitution in network resources. A portal module to integrate with IFTTT (triggers and actions). Finally, on a newer hardware design, a crypto chip to offload certificate operations to a DSP. Sometimes, SSL negotiation just seems to take FOREVER. Apps like MobiLinc will be much more responsive if the SSL negotiation were hardware assisted. I know, not many wishes huh? I know most of these are also scattered around this forum, and some may already be on the 5.x roadmap. I just wanted to get this out there, again. Can you tell how much I *hate* Java.. Looking forward to GREAT things! Michael.

Sounds perfect - thanks! For the time being, I'm going to change my code to check for 404, and just instance zero byte variables so that the rest of my code simply sees these as empty values, as it was doing before. That way it will keep functioning g for now and if you change the response in the future it will keep on working. Thank you very much for working thru this with me! Michael.

Michel, The more I think about it, the more I feel 404 is the correct response. I'm asking for properties, and if none are defined they don't exist. 404 'seems' correct. I should be checking that in the code though - and its certainly a change in behavior at some point. ISY used to return XML, just with empty strings. Now it returns 404. So that I don't have to change the code again, is this current behavior the design - or a feature that will be rectified in a future version? Thanks for all your help, it helped me get to the root of what seemed to me like a very strange issue. Michael.

Mystery Solved... I edited the node in question - went to 'Notes' and entered something in the 'Location' string. Now - I don't get the 404 - for that device. I realize that the properties file does not exist unless there are properties to store - but it seems really odd that ISY would return 404 to a request for properties like that. Is there any way ISY could simply 200 the request - and return XML indicating that the properties are empty? It certainly used to work that way.. Michael.

Michel, I'll get the log to you in email (it's pretty small). I wanted to post what I saw. I ran the exact program posted in this thread (the single node version) - and each time it runs I get this is the log: [FileOpen ] Open failed for [CONF/47.PRP] ® Do you know what this means? Thanks, Michael.

Everything is already sent without a '.'. The '.' in the tcpdump represents an 'unprintable' character - you have to look at the hex code on the left. In this case it's ACSII code 20 - a space. Do you want me to try it with a '.'? Thanks, Michael.

No problem at all with the admin console. I'm baffled - this used to work (4.0.something....)

Michel, Here is a packet dump: (I obfuscated the actual URL and the basic auth header - but kept the byte counts matched by replacing with x's and 0's..) tcpdump -s 0 -X host [ip.of.isy] 22:20:05.300192 IP linux.domain.com.33959 > isy.domain.com.http: Flags [s], seq 301973918, win 29200, options [mss 1460,sackOK,TS val 199734276 ecr 0], length 0 0x0000: 4500 0038 759a 4000 4006 6ad4 ac14 0115 E..8u.@.@.j..... 0x0010: ac14 0114 84a7 0050 11ff c19e 0000 0000 .......P........ 0x0020: 9002 7210 5a7c 0000 0204 05b4 0402 080a ..r.Z|.......... 0x0030: 0be7 b404 0000 0000 ........ 22:20:05.300686 IP isy.domain.com.http > linux.domain.com.33959: Flags [s.], seq 3358484315, ack 301973919, win 4644, options [mss 1460,sackOK,nop,eol], length 0 0x0000: 4500 0030 ded9 0000 3c06 459d ac14 0114 E..0....<.E..... 0x0010: ac14 0115 0050 84a7 c82e 675b 11ff c19f .....P....g[.... 0x0020: 7012 1224 8e7a 0000 0204 05b4 0402 0100 p..$.z.......... 22:20:05.300727 IP linux.domain.com.33959 > isy.domain.com.http: Flags [.], ack 1, win 29200, length 0 0x0000: 4500 0028 759b 4000 4006 6ae3 ac14 0115 E..(u.@.@.j..... 0x0010: ac14 0114 84a7 0050 11ff c19f c82e 675c .......P......g\ 0x0020: 5010 7210 5a6c 0000 P.r.Zl.. 22:20:05.300793 IP linux.domain.com.33959 > isy.domain.com.http: Flags [P.], seq 1:26, ack 1, win 29200, length 25 0x0000: 4500 0041 759c 4000 4006 6ac9 ac14 0115 E..Au.@.@.j..... 0x0010: ac14 0114 84a7 0050 11ff c19f c82e 675c .......P......g\ 0x0020: 5018 7210 5a85 0000 504f 5354 202f 7365 P.r.Z...POST./se 0x0030: 7276 6963 6573 2048 5454 502f 312e 300d rvices.HTTP/1.0. 0x0040: 0a . 22:20:05.301569 IP isy.domain.com.http > linux.domain.com.33959: Flags [.], ack 26, win 4619, length 0 0x0000: 4500 0028 deda 0000 3c06 45a4 ac14 0114 E..(....<.E..... 0x0010: ac14 0115 0050 84a7 c82e 675c 11ff c1b8 .....P....g\.... 0x0020: 5010 120b bb3d 0000 0000 0000 0000 P....=........ 22:20:05.301594 IP linux.domain.com.33959 > isy.domain.com.http: Flags [P.], seq 26:302, ack 1, win 29200, length 276 0x0000: 4500 013c 759d 4000 4006 69cd ac14 0115 E.. 0x0010: ac14 0114 84a7 0050 11ff c1b8 c82e 675c .......P......g\ 0x0020: 5018 7210 5b80 0000 4175 7468 6f72 697a P.r.[...Authoriz 0x0030: 6174 696f 6e3a 2042 6173 6963 2000 0000 ation:.Basic.xxx 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 xxxxxxxxxxxxxxxx 0x0050: 0000 0000 000d 0a48 6f73 743a 2069 7379 xxxxx..Host:.isy 0x0060: 2e00 0000 0000 0000 0000 0000 0000 2e63 .xxxxxxxxxxxxx.c 0x0070: 6f6d 0d0a 436f 6e74 656e 742d 4c65 6e67 om..Content-Leng 0x0080: 7468 3a20 3135 330d 0a43 6f6e 7465 6e74 th:.153..Content 0x0090: 2d74 7970 653a 2074 6578 742f 786d 6c0d -type:.text/xml. 0x00a0: 0a0d 0a3c 733a 456e 7665 6c6f 7065 3e3c ...< 0x00b0: 733a 426f 6479 3e3c 753a 4765 744e 6f64 s:Body> 0x00c0: 6550 726f 7073 2078 6d6c 6e73 3a75 3d22 eProps.xmlns:u=" 0x00d0: 7572 6e3a 7564 692d 636f 6d3a 7365 7276 urn:udi-com:serv 0x00e0: 6963 653a 585f 496e 7374 656f 6e5f 4c69 ice:X_Insteon_Li 0x00f0: 6768 7469 6e67 5f53 6572 7669 6365 3a31 ghting_Service:1 0x0100: 223e 3c69 643e 3131 2033 3120 4443 2031 ">11.31.DC.1 0x0110: 3c2f 6964 3e3c 2f75 3a47 6574 4e6f 6465 0x0120: 5072 6f70 733e 3c2f 733a 426f 6479 3e3c Props>< 0x0130: 2f73 3a45 6e76 656c 6f70 653e /s:Envelope> 22:20:05.302007 IP isy.domain.com.http > linux.domain.com.33959: Flags [.], ack 302, win 4343, length 0 0x0000: 4500 0028 dedb 0000 3c06 45a3 ac14 0114 E..(....<.E..... 0x0010: ac14 0115 0050 84a7 c82e 675c 11ff c2cc .....P....g\.... 0x0020: 5010 10f7 bb3d 0000 0000 0000 0000 P....=........ 22:20:05.389336 IP isy.domain.com.http > linux.domain.com.33959: Flags [P.], seq 1:91, ack 302, win 4343, length 90 0x0000: 4500 0082 dedd 0000 3c06 4547 ac14 0114 E.......<.EG.... 0x0010: ac14 0115 0050 84a7 c82e 675c 11ff c2cc .....P....g\.... 0x0020: 5018 10f7 6d2c 0000 4854 5450 2f31 2e31 P...m,..HTTP/1.1 0x0030: 2034 3034 204f 4b0d 0a43 6f6e 7465 6e74 .404.OK..Content 0x0040: 2d4c 656e 6774 683a 2039 300d 0a43 6f6e -Length:.90..Con 0x0050: 6e65 6374 696f 6e3a 204b 6565 702d 416c nection:.Keep-Al 0x0060: 6976 650d 0a43 6f6e 7465 6e74 2d54 7970 ive..Content-Typ 0x0070: 653a 2074 6578 742f 6874 6d6c 0d0a 0d0a e:.text/html.... 0x0080: 0d0a .. 22:20:05.389357 IP linux.domain.com.33959 > isy.domain.com.http: Flags [.], ack 91, win 29200, length 0 0x0000: 4500 0028 759e 4000 4006 6ae0 ac14 0115 E..(u.@.@.j..... 0x0010: ac14 0114 84a7 0050 11ff c2cc c82e 67b6 .......P......g. 0x0020: 5010 7210 5a6c 0000 P.r.Zl.. 22:20:05.389445 IP linux.domain.com.33959 > isy.domain.com.http: Flags [F.], seq 302, ack 91, win 29200, length 0 0x0000: 4500 0028 759f 4000 4006 6adf ac14 0115 E..(u.@.@.j..... 0x0010: ac14 0114 84a7 0050 11ff c2cc c82e 67b6 .......P......g. 0x0020: 5011 7210 5a6c 0000 P.r.Zl.. 22:20:05.389915 IP isy.domain.com.http > linux.domain.com.33959: Flags [.], ack 303, win 4342, length 0 0x0000: 4500 0028 dede 0000 3c06 45a0 ac14 0114 E..(....<.E..... 0x0010: ac14 0115 0050 84a7 c82e 67b6 11ff c2cd .....P....g..... 0x0020: 5010 10f6 bae3 0000 0000 0000 0000 P............. 22:20:05.396763 IP isy.domain.com.http > linux.domain.com.33959: Flags [F.], seq 91, ack 303, win 4342, length 0 0x0000: 4500 0028 dedf 0000 3c06 459f ac14 0114 E..(....<.E..... 0x0010: ac14 0115 0050 84a7 c82e 67b6 11ff c2cd .....P....g..... 0x0020: 5011 10f6 bae2 0000 0000 0000 0000 P............. 22:20:05.396791 IP linux.domain.com.33959 > isy.domain.com.http: Flags [.], ack 92, win 29200, length 0 0x0000: 4500 0028 0000 4000 4006 e07e ac14 0115 E..(..@.@..~.... 0x0010: ac14 0114 84a7 0050 11ff c2cd c82e 67b7 .......P......g. 0x0020: 5010 7210 59c8 0000 P.r.Y... In 22:20:05.302007, the ISY ACK's the SOAP POST to /services, then replies (22:20:05.389336) with a 404. Not sure why ISY is 404'ng this... but it seems to be an issue somewhere... This is the PHP code I used that produced this tcpdump (you should be able to put this into a .php file on a PHP enabled server and replace the variables at the top): <?php ini_set("display_errors", 1); error_reporting(E_ALL); ob_end_flush(); $ISYuser = "isy_username"; $ISYpassword = "isy_password"; $ISYurl = "isy.domain.com"; $node_address = "11 31 DC 1"; $node_name = "Master BR Light"; echo "Getting advanced node properties from ISY. \n"; echo "Getting details for: $node_address ($node_name) \n"; $SOAPreq = ""; $SOAPreq .= $node_address; $SOAPreq .= ""; $opts = array('http' => array( 'method' => 'POST', 'header' => 'Content-type: text/xml', 'content' => $SOAPreq )); $context = stream_context_create($opts); $url = "http://$ISYuser:$ISYpassword@$ISYurl/services"; echo "POST URL: $url \n"; $xml = simplexml_load_string(file_get_contents("http://$ISYuser:$ISYpassword@$ISYurl/services", false, $context)); $isLoad = $xml->isLoad; $location = $xml->location; $desc = $xml->description; echo "$SOAPreq \n"; echo "$desc \n"; echo " \n"; echo "Reached end!"; ?> As you can see - I don't calculate content length in code - the stack does this for me (and is likely to be correct I suspect..) The HTML the browser sees from this: Getting advanced node properties from ISY. Getting details for: 11 31 DC 1 (Master BR Light) POST URL: http://isy_username:isy_password@isy.domain.com/services Warning: file_get_contents(http://...@isy.domain.com/services): failed to open stream: HTTP request failed! HTTP/1.1 404 OK in /var/www/api/test.php on line 21 Notice: Trying to get property of non-object in /var/www/api/test.php on line 22 Notice: Trying to get property of non-object in /var/www/api/test.php on line 23 Notice: Trying to get property of non-object in /var/www/api/test.php on line 24 11 31 DC 1 Reached end!

Michel, sure 9 4A EF 1 I wasn't able to capture the header (yet). If there is nothing obvious here I'll tcpdump it and capture a full packet from the wire - rather that capturing it within the php code that's generating it. Michael.

Well, that explains that one then... Not sure it's a worthwhile test to be honest - every node is failing when I try to get the properties with a SOAP formatted POST (my code loops thru all of them - and I get the exact same error for all nodes) - and all are working in the admin console.. Strange indeed.. Maybe I'm formatting the node incorrectly - or not escaping it properly.. The nodes I get from the REST interface appear to be a simple string in the format '11 31 DC 1'.

...or is it a Beta issue. Not sure yet. I have a PHP script that mainly uses REST to connect to the ISY. However, I'm also obtaining the 'Description' 'Load' and 'Location' fields of objects via SOAP (since I cannot get these via REST apparently..). This has been working fine - until sometime in the last few versions.. Now on 4.2.1 and it's definitely broken currently. I don't know if it's my code - or the ISY.. So this is what I'm doing. Using REST I'm retrieving the devices (http://$ISYuser:$ISYpassword@$ISYurl/rest/nodes). I then loop thru the nodes, one at a time, and form a SOAP request - which I post to /services, extracting and parsing the XML returned to get the data I need: $SOAPreq = ""; $SOAPreq .= $node_address; $SOAPreq .= ""; $opts = array('http' => array( 'method' => 'POST', 'header' => 'Content-type: text/xml', 'content' => $SOAPreq )); $context = stream_context_create($opts); $url = "http://$ISYuser:$ISYpassword@$ISYurl/services"; $xml = simplexml_load_string(file_get_contents("http://$ISYuser:$ISYpassword@$ISYurl/services/", false, $context)); $isLoad = $xml->isLoad; $location = $xml->location; $desc = $xml->description; $ISYurl contains the IP address of the ISY, $ISYuser and $ISYpassword the user and password of the account to manage the ISY. As mentioned - this was working not so long ago on 4.0.3. Now (4.2.1), I get: Warning: file_get_contents(http://...@x.x.x.x/services/): failed to open stream: HTTP request failed! HTTP/1.1 404 OK in /var/www/api/refresh.php on line 80 Notice: Trying to get property of non-object in /var/www/api/refresh.php on line 81 Notice: Trying to get property of non-object in /var/www/api/refresh.php on line 82 Notice: Trying to get property of non-object in /var/www/api/refresh.php on line 83 Line 80 is the simplexml_load_string - so the request to /services is being rejected by ISY with a 404.. I have pointed my regular browser at http://ISY/services and get: /services not found Am I missing something? Thanks, Michael.

You could always use stunnel to create the SSL tunnel, then point eventghost at the local stunnal port.

All manufacturers - or just one or two of them? If not all, which ones will we be able to manage PINs on? (Hoping for Kwikset....) Thanks! Michael.

Disabling SSID Broadcast is really pointless - does nothing but make it more difficult for you. The SSID is still 'broadcasted' - its just suppressed from display.