KeviNH

Comcast is forthcoming about what inbound ports they block, see https://www.xfinity.com/support/internet/list-of-blocked-ports/ If you want to set up an port forwarding for inbound connections, choose a random high port. You can run HTTPS on any port you want. ISY Portal does not require any inbound ports open nor port forwarding; when using the portal your ISY994 connects outbound to the cloud server.

As an alternative, has anybody done any work with electromagnetic locking systems? Obviously the biggest downside to these is that they need a bypass option to be code-compliant (OSHA, etc) and always will "fail safe". Any other considerations when looking at using mag locks with an automation system?

Easiest option is to give the Smartenit EZSnsRF a chance, but bear in mind Smarthome's 30-day refund policy. If you just need one channel from the Dakota, you could buy the DCR-2500 and an Insteon wireless open/close sensor and connect the two with a short piece of low voltage wire and some double-sided tape. Kind of like this.

Seem Ninety bucks!?! Hopefully the price for a WiFi->IR module will come down soon. Funny that you can get the same WiFi connectivity at less than half the price by using a Raspberry Pi 3, an IR expansion board, and LIRC. Or you could get the cost down around ten bucks with an NodeMCU or ESP8266 solution. (google “esp8266 ir” or "esp8266 ir station") Looks like there are pre-written ESP8266 packages to make it easy to have Network resources with TCP to send any arbitrary IR code you like from the ISY994. Hopefully somebody will roll these together with english language instructions and sell them at around the $19.99 price that the Chinese-language-only units go for.

Another option is to have a program that is "True" if the program you don't want to re-run has been run recently, and check the program status as part of your conditions: Dehumidify ran recently - [ID 00A8][Parent 00A1] If From Last Run Time for 'Dehumidify' To Last Run Time for 'Dehumidify' + 1 hours (same day) Then Wait 1 second Else - No Actions - (To add one, press 'Action') Program logic to not run again if Dehumidify ran recently looks like this: Dehumidify - [ID 00A7][Parent 00A1] If Program 'Dehumidify ran recently' is False ...

The power LED is not software controlled, and does serve a useful purpose -- if the ISY power supply is faulty, the power LED will go dark or just faintly lit. There are some Layer-1 approaches to reducing the brightness, see this thread: http://forum.universal-devices.com/topic/20474-isy994-power-led

You can do this with a separate program. I moved "Open Starboard Garage Door" into a program of it's own, which opens the door, updates a variable, writes a log, etc. This program gets called from anything that wants to open the door. Then I made a program to track if the garage door opening program ran recently: Starboard Garage Door was opened within 15m - [ID 00E2][Parent 00E1] If From Last Run Time for 'Open Starboard Garage Door' To Last Run Time 'Open Starboard Garage Door' + 15 minutes (same day) Then Wait 15 minutes and 1 second Else - No Actions - (To add one, press 'Action') Now you can add an additional condition to any program which wants to open the garage door, like this: And Program 'Starboard Garage Door was opened within 15m' is False The condition is False if that garage door was not opened in the last 15 minutes.

I was thinking of doing the "hang a tennis ball from a string" parking aid, but using a triggerlinc.

Perhaps look at the problem from the other direction? A beacon or other mechanism detects if her car is already in/near the garage. Geofence application on her phone (e.g. IFTTT) triggers an event when she enters the immediate area. So if her phone enters the area, and her car isn't already in the garage, then open the garage door.

If your car has a USB port designed to work with Apple music players, maybe just get a cheap used iPod touch and leave the wifi turned on?

You can use the "-x" option (e.g. "bash -x scriptname" or at "set -x" near the top of the script) to run the script with tracing so it shows you execution progress as it runs, this will often show where things are going off the rails.

Pretty sure OP is saying the BASH script is constantly looping -- 'bash' on rPi is not event triggered. He could enable a network service on rPi and have ISY make a network resource call out to the Pi when the event is triggered, but that requires considerably more advanced skills to build.

This works fine for setting $Home=1 when I arrive at home, but IFTTT falsely detects a disconnect randomly in the middle of the night, ( Due to Android turning WiFI off when charging is complete and phone is asleep). I could disable the feature in Android, at the expense of much higher battery usage, shorter battery life.

That's one of the reasons I avoid Foscam, they have different families of software on different camera models, so features and API that works for one model do not apply to others. One workaround is use a NVR that does publish a featureful API, do your scheduled recording in the NVR instead of on camera. Preferably ONVIF Profile S cameras, but anything supported by your NVR would be usable. Even the free NVR from Milestone or ZoneMinder could suffice for a small deployment.

Depending on the make and model of your alarm, you might be able to use something like DSClink to get events into ISY.

I looked into this when it first came out, but Honeywell doesn't provide much technical documentation. As I recall, Honeywell does not recommend making the Tuxedo a Secondary Z-Wave controller, so I gave up on the idea and just went with a really basic Honeywell Z-wave thermostat instead.

I haven't looked at "alarm" sensors with Z-wave, but in general, professional alarm system sensors will be better for security than consumer-targeted Z-Wave sensors, while the latter works better in an occupancy sensing role, as alarm sensors often have built-in delays before triggering or re-triggering. Commercial alarm system sensors often come with adjustable lenses and masking strips. This allows the installer to adjust the coverage area (e.g. to eliminate false alarms from hot objects). They are designed to be "supervised" and otherwise tamper-evident, security features not usually found in Z-Wave sensors. Personally, all the sensors that trigger my alarm are hardwired to the alarm panel, then I forward events from the alarm panel to the ISY994 so I can use my alarm sensors to augment my small number of Insteon and Z-Wave motion sensors. I use Insteon sensors where I want the sensor to be a controller in a scene, e.g. turn on a light with minimal delay.

I agree -- it does take effort to think about coding in an event driven environment compared to traditional programming flow. I've worked with other systems and intepreters which are also event-driven, and while that helps, I still sometimes have to stop and rethink my approach when implementing something complex with ISY994. On a related note, if the second program should never run on it's own, but only when "Run IF ..." is called from another program, you can disable the second program. A program that is not enabled only runs when called explicitly (e.g. from a program or via REST), never is automatically run by the ISY, see http://forum.universal-devices.com/topic/14904-disabled-program-run-if-by-another-program-does-not-revaulate-if-conditions-change-while-it-is-in-running-then-state/ for more.

If the delay is acceptable, then my script already caches the generated audio as MP3, so tying it to Sonos would be trivial to code. I am looking at the line-in option because I also want to connect the line-out from my weather radio.

Should be straightforward to playback the audio through a single chromecast from Linux by using something like CastNow. Not sure about sending to a group of Google speakers simultaneously, but I could see enhancing the script to allow selecting which cast device to target when playing.

If you have the Network Module and a spare rPi, I built a simple voice announcement program for Unix which uses free Text to Speech software to take a string sent via the network module and speak it. It can also playback any MP3 file. Since so many free Internet-based text to speech services have become unreliable, my solution uses a local speech synthesis program (The free 'espeak' open source application). espeak takes a second or two to convert text to speech, so I cache each phrase locally, this way the next time it needs to say the same thing, playback is nearly instantaneous. I have mine working with an Apple airplay speaker. I think it is possible to make the announcements play over a google device (Chromecast/CCast Audio) but not via Amazon Echo/Dot/Tap. It should also work with Sonos (needs a Sonos device with line in).

Got a hole punch and a roll of electrical tape? Make your own light dims.

Short answer: Yes. Long answer: Yes, but... for each communication path (Z-Wave, Insteon RF, Insteon Powerline) the separate "networks" will be using the same frequencies as one another, so there is an added chance of collisions (mostly missed transmissions). Probably won't be noticeable if the second network has just a few devices on it.

The "2634-222 Plug-in On/Off Module, Outdoor" is the most likely to work reliably in this application, is officially rated for -4° F to 122° F (-20° C to 50° C). I use the outdoor outlet module in my unheated garage year round, never had any issues with it.

If it's right next to the garage door opener, why not just hardwire to the button terminals on the GDO instead of using a transmitter? I would tap DC voltage off the existing battery backup and run it through a step down buck converter to regulate the battery voltage (probably 12 or 24VDC) down to 3VDC with very little standby loss.