MWareman

Also, make and model of the garage door opener and type of wall controller is also needed. Some of the newer openers (especially the MyQ ones) don't play very nice with the IOLinc for controll...

Did you get 4.3.18 installed?

I think I'm going to ping Ben at Brultech and see if there is an option to switch out the WiFi module for wired Ethernet... Thanks!

In my case, I would lose my hardwire link... Currently, the GEM sends to the Dashbox over a hardwired serial connection (port 2 on GEM). Port 1 on GEM is the WiFi module - I don't use that at all because its been unreliable for me (even though my AP is fairly close). The Dashbox then sends the data onto SEG and my ISY (via state variables) using its hardwired Ethernet connection. I think this is likely a pretty common setup for those with the Dashbox. Basically, I'm trying to figure out how I'd replace the ISY variables currently being updated by the Dashbox with your node server. We may have to bug Ben at Brultech to see if he is willing to add more generic data forwarding to the Dashbox.

I have a feeling we cannot change the host name that the Dashbox sends SEG data to. The Dashbox config is simply enabled or not, and the site token.

Thanks. The Dashbox can send in SEG format - or write ISY state variables thru the ISY API. When 5.x becomes more stable I'll give your solution a try and see how well it works with my GEM on WiFi. Otherwise, I may have to look into converting my GEM to wired Ethernet.

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.