MWareman

Quick question... Are you getting data directly from GEM (via the network interface) - or via the Dashbox? The reason I ask - my GEM interface is WiFi - and less reliable. My Dashbox is hard wired and provides much more reliable data. Even better - maybe you could reach out to Ben and have the ISY Node Server for GEM be integrated directly into the Dashbox.... (wishful thinking maybe!)

Nice!!!

Upnp allows programs on internal machines to setup port forwarding without any authentication - by design. Imagine what malware could do! It's one of those 'what could possibly go wrong?' technologies....

Upnp is a security risk. As @LeeG said - best to leave it off and manually map the port. A routers listing of devices is often flawed and incomplete. I would never rely on this.

All 'Enable Internet Access' does is use upnp to setup a port forward in your router, and report the external IP and port the router assigned. If your router didn't do upnp (most are defaulted not to these days) then 'Enable Internet Access' will fail, and that's expected. I believe if ISY already has a port mapping it will also display the failed message.

I disagree. Staying with the same functionality would necessitate not upgrading your mobile device. Things would have kept working if not for that. You did that (via Apple) - and that means you now have other things to upgrade for them to remain compatible with changes you introduced. Removal of the crypto algorithms has been well documented by both companies due to the security issues. UDI, for their part, realized years ago that they couldn't continue development on the 99i - it simply ran out of space. This is why newer versions of firmware with the additional compatibility needs the newer hardware. It's not a conspiracy! UDI does offer a VERY attractive upgrade offer on their sales page.

I'd clear out both 'Else' branches in your first example and create a third program triggering on 'Sunrise' to handle turning off the light...

Copied from the other thread where this was asked... Newer IOS likely removed the only cryptographic algorithm available on the now deprecated 99i (SSL3 and/or SHA1). These were removed from both IOS and Android because they are now considered insecure. You'll likely either need to roll back IOS, or move to a newer ISY firmware (which will likely need a hardware upgrade to the 994i).

I guess I've figured my own experimental results. The time based triggers are 'true' only at the specified time, and non-triggering 'False' at all other times. This is different from devices 'status is off' (for example) - which will trigger 'true' when the device changes to 'off' - but will also trigger 'false' when the device changes to anything else. Hence my statement of time triggers being a special case. They can never trigger false. So, @LeeG is correct (as always!) in the statement made that all triggering events will interrupt a wait or repeat and force a reevaluation. Apologies for the doubt... Edit: Yes. The wiki does seem to add to the confusion. The wait does not 'cause' the reevaluation. It 'allows' it to occur if any triggering status changes while the wait is waiting.

Not quite true.. New Program - [ID 0245][Parent 0244] If Time is 5:30:00PM Then Resource 'Pushover - TriggerThen1' Wait 4 minutes Resource 'Pushover - TriggerThen2' Else Resource 'Pushover - TriggerElse' At 5:30PM I received the 'Then1' pushover notification. At 5:34PM I received the 'Then2' pushover notification. The 'If' was NOT reevaluated at 5:31PM, 5:32PM or 5:33PM - despite being triggered at 5:30PM. The 'Else' condition was never triggered. I have not dug (experimentally) into other triggering conditions (like Elk zones, weather variables etc). I do know from memory that 'Control', 'State' and 'State Variables' all trigger evaluation AND interrupt 'wait' and 'repeat'. Other than time, I am now wondering what other triggering conditions will not break a 'wait' or 'repeat'. Michael. Michael.

Only if the specific event type is one of the several that will actually interrupt the 'wait' or 'repeat'. If not, the program continues atomically. Only those events that are allowed to interrupt the 'wait' will cause the reevaluation, and restart the 'then' or 'else' as the evaluation dictates.

I have some, but I've never really dug into this. There are only some triggering conditions that will interrupt a 'wait' or 'repeat'. Not all of them will. I believe time is one of the triggering events that will not interrupt a wait or repeat.

I don't think time change causes reevaluation of the program. Otherwise many of mine wouldn't work!

To further LeeG's statement. One condition is the Temperature >40. Let's say the program triggers one day and the temp is 46. We get to the wait and start waiting. 4 mins later,z the temp updates to 47. This will terminate the wait and cause the If to reevaluate. At this point, the time won't match and 'Else' will be executed instead, doing nothing.

Yep - agreed. However, this is an Insteon limitation not an ISY one. You cannot send direct messages to KPL keys (other than the primary node) so you have to put the node into a scene as a responder then send the scene command.

Or maybe this (assuming it works with ISY Zwave) http://www.thesmartesthouse.com/collections/aeotec-by-aeon-labs/products/aeotec-by-aeon-labs-z-wave-plus-dry-contact-sensor-gen-5

Or use one of the several inexpensive web control boards that you can wire the sensors to and have it set and under ISY State variables based on the state... Or a team of iolinc devices (one for each wired sensor)...

No, does not run on Android tablets, IOS devices or Windows Phone. It needs either Windows, OSX or Linux and a full Java runtime environment.

We have one of the HP streams (well, its my daughters!). The console runs fine once you install Java. I have a Surface 3 at work - again also works fine once you install Java.

Using an app password that's unique to the ISY and not used for anything else prevents that password from being phished. The longer, random nature makes it infeasible to brute force. This allows you to use a weaker main password with two step auth to protect you day to day, yet remain useless to an attacker if you are phished. You can also use an app to generate codes for you, eliminating the need to receive SMS messages. Much more convenient IMO.

@Teken, the Google help and info page on this is here: https://support.google.com/accounts/answer/185833?hl=en Michael.

As I mentioned, you'll need the network resource... 'http' 'GET' 'Host' [iP of ISY] Port [80 or non-ssl port of ISY] Path Example: /rest/vars/set/2/128/${sys.node.27 FA 4D 1.ST.raw} Encode URL: Unchecked Timeout: 500ms In the Headers, add: Authorization Set the username and password to your ISY username and password Save it, and test. Details of the Path: /rest/vars/set/ tells ISY 'I want to set a variable' 2 tells ISY 'set a state variable' (use 1 for an integer) 128 is the variable number (look this up on your ISY admin console variables tab) ${sys.node.27 FA 4D 1.ST.raw} is the substitution variable for the device. Watch out - this needs to be an integer - Insteon devices are normally ranged 0-255. The .raw means 'an unformatted raw value'. Note: Do *not* use 127.0.0.1 for the IP address! There is a limitation in the networking stack of ISY that means this will not only not work - it can actually hang the ISY. Michael.

Who said SMS? I agree, SMS is sometimes delayed. I use a combination of Pushover and Tasker/Autoremote and both are virtually instant.

If you have 4.3.10 and the network module, you can have anything that's substitutable in email set as a variable by using a network resource and variable substitution calling the rest interface directly on the ISY to set the variable.

I thought about doing this as well, but decided against it. How would a visitor know that the doorbell was working? Most people I know would, upon pressing the button and not hearing the chime start pounding on the door. Thus negating the whole reason! I have a motion sensor on my porch that pings my phone and flashes a light. This usually means I can get to the door before the visitor needs to push the Bell.