MWareman

Wireless garage door openers are, mostly, designed for security. Insteon is not (in fact it transmits without encryption, and devices don't authenticate incoming messages - so messages can be spoofed). There is a big difference between them, from a security perspective. Other than that, I fully agree with you @oberkc. It's somewhat nuanced, but given I've been able to observe and decode Insteon traffic, deduce important IDs and can (technically) issue commands without any kind of authentication required means any access control in my house is now either Elk managed or zwave (secure profile), where things are either hard wired or encrypted, meaning third parties cannot (easily) manipulate what's going on. To me, using Insteon for access control is rather like closing your front door but not locking it. Passers by will think your secure, but anyone trying the door is able to do bad things. Now, I hasten to add, this is my view. Personally, I automatically dismiss any Insteon access control from consideration now that I better understand the protocol.

To me, if an insteon command can open a door, then there is a security problem.... But that's just me.

The ISY is event based. The 'If' is evaluated on triggers contained within it (the KPL switched on or off locally, the beginning and end of the window in your case). If the 'If' evaluates to true the 'Then' is run. Otherwise 'Else' is run. This results in what you see. At the beginning and end of the window, the If is evaluated - but the KPL buttons are not true. So, Else is executed. The other ways to solve it are move the window to a folder condition and remove from the 'If'. This will restrict the KPL button from triggering evaluation outside of the window. Or have a separate program update an integer variable based on time of day (these don't trigger 'If' evaluation on change) and then use the variable as a condition in your 'If'.

When you hit the wait, the If will be reevaluated on any condition change. Closing the door within the wait period cancels the Then path and changes to executing Else, and the light won't get turned off. Either split it to two programs. One with your current Then (and no If) and change this program to 'RunThen' the new program. That way it won't get interrupted on the wait. Or, add a command to turn off the light in the Else, and it will get turned off as soon as the door is closed. Or, as above, use Control....

It does - yes. I have no delay in mine and the task runs perfectly every time. I have a Nexus 5 on AT&T if that makes any difference.

'Unknown host' means whatever you have for xxxxx.dyndns.org is not resolving in DNS on the network you are connected to after your WiFi disconnects. So - this could mean android has disconnected from wiFi (triggering the rule) but the phone has not re-established to the cell network. You could try adding a delay before the attempt to see if this is the reason. You should also ensure that your xxxxx.dyndns.org name is actually resolving to your external IP address. Michael.

As mentioned, deleting the PLM is a big no-no. It will remove all link records, rendering scenes useless. You are probable going to have to either restore a backup and then restore each device, or re-add each device individually.

Echo talks directly to the pseudo hue bridge, so I see no reason it cannot be done for ISY as well.... eventually.

An @ in the password will almost certainly cause it to fail. Instead, you'd need to be able do the base64 encoding and add an 'Authorization' header, but the HTTP Get action in Tasker does not allow the addition of arbitrary headers. There are many characters that are 'illegal' as part of the URL, and you'd need to avoid them in any username or password for the URL representation to work. Running programs and setting variables are all supported thru the REST API. They are all documented at http://wiki.universal-devices.com/index.php?title=ISY_Developers:API:REST_Interface

Have you actually been able to link Hue lights to the Hue emulator? I tried to link a Wink hub to it, and the two don't talk at all....

Odd - if the URL works in a browser it should in Tasker - especially if you are using http (as opposed to https). I have it running just fine on several Android devices that I use daily. Can I confirm that in the Tasker HTTP Get action you have: Server:Port http://xxx.xxx.xxx.xxx Path /rest/nodes/xxxxx/cmd/DON You need to split up the server:port from the path. Wanted to be sure you had done that. If you are using SSL - you may want to consider checking 'Trust any Certificate' (be aware that if you access via a malicious method of access a fake certificate will be trusted) as a diagnostic step. If this allows SSL to work then the issue is you don't have a trusted (to Tasker) SSL cert on your ISY. Finally - you can use the 'Run Log' in Tasker to better identify where the issue is. IF you are using variables to form the URL make sure that they are correctly set this way. Michael.

In the wiki, I had documented /rest/nodes/xxxx/DON for scene control, but I discovered this was in error (according to the REST interface doc - http://wiki.universal-devices.com/index.php?title=ISY_Developers:API:REST_Interface). I have fixed the page to include /cmd. Your post caused me to double check that... Thanks! As to your issue: http://xxx.xxx.xxx.xxx may be working from your browser because you have already authenticated. With tasker, you need http://user:password@xxx.xxx.xxx.xxx (where user and password are your ISY user and password). Also - I assume the xxxx is the scene ID you are trying to control (usually either 4 or 5 numeric digits). Michael.

No problem! I wrote various options up on the wiki. http://wiki.universal-devices.com/index.php?title=ISY-99i_Series_INSTEON:Networking:Mobile_Notification Now that ISY supports variable substitution in network resources I'm slowly replacing my final sms notifications. Hopefully, I'll add a quick note to the wiki page on this feature soon. Michael.

Many cell providers do this - nothing you can do from an ISY point of view. I switched to network based push notifications.

Here is my tweet... https://twitter.com/michaelwareman/status/604398079169662976

That is cool! Thanks @tezjet. I (finally) just received my echo yesterday so now I have something else to play with.

What is state variable ID 8 used for in your programming?

I stopped using Mobilinc on my Nexus a while ago (due to a bug in that if I renamed a device on ISY, Mobilinc got all confused with device IDs.) Mobilinc has apparently fixed that issue now, but I took the time to implement Tasker control via the REST interface instead, and it's worked flawlessly since. I wrote it up on the wiki. I have several Tasker scenes, all triggered from a notification bar. I can pull down, click a button and see a scene representing the status of my devices. Status is updated in near-real time (pushed via Autoremote). Although the user interface is very basic, it's functionally (for me!) way better than Mobilinc ever used to be. Sent from my iPad using Tapatalk

Sorry @02bnme, I'm mostly out of ideas. 404 is the error code returned by your camera - it's just being relayed to you by the ISY. It basically means that your server (the camera) cannot find the resource being requested (/cgi-bin/admin/setvi in this case). If it works from a browser but not the ISY then things like host header may come into play - but I don't see that issue here. Firebug seems to be reporting that the browser is making an HTTP/1.0 request (without a Host: header) - but your ISY network resource is sending a HTTP/1.1 request (with a Host: header as HTTP/1.1 requires). It might be just that simple - but I'm not sure how to change that on ISY's end. I wonder if you can craft a working command line with wget (so you can granularly play with the various options and headers) and experiment to find out what works..

Good to know! Thanks.

LeeG, will that test within the 'If' cause the program to trigger when the folder changes to 'True'? I didn't think it would.

I'm out at a conference this week - so it's difficult to keep up.... Just to confirm: http://username:password@192.168.1.42:8042/cgi-bin/admin/setvi?vi0=0 and http://username:password@192.168.1.42:8042/cgi-bin/admin/setvi?vi0=1 (from the screenshot) works in the browser? Or does this work in the browser: http://username:password@192.168.1.42:8042/cgi-bin/admin/set?vi0=0 and http://username:password@192.168.1.42:8042/cgi-bin/admin/set?vi0=1 Michael.

Sorry! I was typing on my cell phone...

I've also seen this symptom with an IP address conflict on the LAN, or a tight loop in programs. Sent from my iPad using Tapatalk

404 means 'not found'. What does http://username:password@192.168.1.42/cgi-bin/admin/set?vi0=1 return when called from a browser? (Substitute the correct username and password - and the smiley is : p without the space....). Oh, you may want to change those as well. The base64 encoding is easily reversed - you have effectively published your username and password in your screenshot. Sent from my iPad using Tapatalk