MWareman

Make sure you are using the Dashboard (correct version for your running code version) to manage certificates - not the admin console or the http interface.

Was the certificate on your lighttpd HTTPS server issued by a well known (paid) CA like Thawte or Verisign? If not, your probably running into a certificate trust issue. You can relax the SSL client settings in ISY Dashboard, but it would be better to have a SSL cert on your Lighttpd server that's trusted by ISY. Either that, or exempt your ISY from the SSL redirect....

You should be aware that trusting any certificate gives you a false sense of security. It leaves you just as potentiality vulnerable as if you have no certificate at all. Any intermediate provider can intercept your connection and recover you credentials without you knowing. Michael.

Glad I could help! Michael.

You may be running into a couple of things. First - SSL trust. Is it a trusted cert. If not - you'll need -k to ignore that - but it's not *that* secure to do that. Second - with curl you don't put the username and password on the URL. You specify the -u parameter. Try it from the shell on your Asterisk system first: curl -k -s -u user:pass https://test.dyndns.biz:1234/rest/vars/set/2/88/1 If this works, I included it in my dialplan like this: exten => s,n,system(curl -k -s -u user:pass https://test.dyndns.biz:1234/rest/vars/set/2/88/1) I'm not using the curl Asterisk command. Not sure why (it way a while ago!) Michael.

May be even simpler than that if this is true.. http://gizmodo.com/report-apples-home-a ... 1583413379

I do this with an earlier version of Asterisk, by incorporating calling curl into my dialplan IVR menus. Works well. I think the URL you mention is the other way around, having Asterisk provide a REST api for things like call placement, queue management etc.

You'll have an IP hat can talk to the ISY, but not your (new) router.

I'm sorry not sure what this means. I'm new at all this and knowledge is limited. I was able to do it for my ELK M1 but I'm nit sure what you are referring to. Hope you can break it down for me please I'll try. I don't know specifics on your addressing (other than what was posted above) - or the specific operating system in use (assuming windows - but exact procedure and terminology varies with edition). I'll try to keep it generic... Your PC is probably getting an IP address from your new DHCP service (running on your new router) that is giving it an IP address that cannot connect to your ISY (which has a static address on your old network). You need to (temporarily) change your PC away from DHCP and, instead, assign it a static IP address in the range of your old network. So, let's say your old router was 192.168.0.1 and you set ISY to 192.168.0.2 - you should (temporarily) change your PC from 'Automatic' to use something like 192.168.0.3 (just make sure it does not conflict). For the 'Subnet Mask' put '255.255.255.0'. Do not worry about the 'Default Gateway' or 'DNS servers' for the temporary step. Your PC will lose access to the Internet during this temporary step. Now - connect to the ISY with your browser on it's IP address and change it's IP from (in my example) 192.168.0.2 to 192.168.1.2 - and the 'Default Gateway' to '192.168.1.1' from '192.168.0.1'. You will likely need to change the DNS address as well. When you save, ISY will reboot and you wont be able to access it again. Please ensure you map the made-up addresses I gave here to your actual situation! Then - simply change your PC back to 'Obtain address automatically' again - and you should be up and running again on the new subnet.

In that case, simply add a hard address in your old IP range to your PC, access the ISY and change it to work for your new subnet range, finally removing the had address on your PC.

If ISY is DHCP, power cycle it (so it's forced to renew, and get a new IP from your new router) and look at the DHCP logs on your router to see the IP that was assigned.

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.