MWareman

I building my Android control of ISY around Tasker, AutoRemote (to allow ISY to adjust Tasker variables in response to device state changes), PowerToggles (to launch Tasker scenes) and Pushover (for ISY to User notifications). Its working great so far - using nothing more than the REST API. I use Tasker Scenes to present a UI. For instance, I have a 'Door' button on my notification pull down. If I click it, I get a scene show asking 'Sure you want to operate the door?' With a large 'No' and a small 'Yes' button. Pressing 'Yes' calls my ISY program to operate the door. Open and close events are sent by Pushover (to alert me) and AutoRemote to update a Tasker variable, and that variable is used to show door state in another scene - without having to poll. I provide a 'Refresh' button that calls an ISY program to cycle thru all the status programs, to re-push all status. Its great that state of devices gets pushed with AutoRemote to variables, so widgets show status immediately without have to do polling or subscriptions. The thing that will *really* supercharge this is variable substitution in network resources. That way instead of device state in Tasker being 'On' or 'Off', I'll be able to send the actual value. I'll be able to display thermostat settings etc etc. Just cannot do that now without hundreds of rules, or externalizing ISY->AutoRemote. Some day (hopefully), I'll write it up.... I was rather hoping for the network module / variable enhancements first.

Assuming you can find stuff that still works with the 3.x firmware that the ISY99i is capped at. Many newer devices won't work with the older firmware.

Yes, I have an ISY99i. Currently, I only use Insteon products and new to this. I don't know how I woiuld program the Vivinit ZWave items. They also still talk to the security thing on the wall, but that is not activated with the alarm company. As far as I know, the ISY99i cannot be extended to do z-wave. You'll need to upgrade to a ISY994i and then add the z-wave module. That might get quite expensive for something you don't know will work afterwards though.

...assuming of course it is a dual band PLM. I believe that you can still buy single band ones, and they won't be able to work with wireless sensors without at least one other dual band device, like an access point.

I'm at a brick wall, until there is new Foscam firmware, when I will test again..

To run the dashboard, try this link if you are running 4.2.3: http://isy.universal-devices.com/994i/4 ... board.jnlp

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.