KeviNH

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.

Most "indoor" Insteon devices are rated +32°F to +104°F, many garages exceed both ends of the range at some point each year. While this is the official rating, I've had good luck running Insteon devices at much colder temperatures. I suspect there is something about the Dragon Tech PA-100 which causes the fault you experience. If you move it inside, does it work reliably at room temperature?

While ZigBee's Smart Energy Profile (SEP) is the most well-known radio link from meters, Itron ERT-enabled meters broadcast usage data using a simpler radio protocol meant for meter reading. Unlike ZigBee SEP, this transmitter is (usually) always on and does not require permission from your power company to "connect" to your meter. I see transmissions from not just power, but also water and gas meters! The most common Automatic Meter Reader (AMR) broadcasts current and historical readings via a simple cleartext RF transmission in the 900Mhz ISM band, can be decoded with a twenty dollar SDR dongle and some free software. I've tried setting up RTL-AMR receiving and decoding on a Raspberry Pi 3. The computer can handle the radio receiver code, but falls behind when trying to receive and decode the transmissions on a single rPi, realy needs a faster computer. You'd need to be running ISY v5 and set up a node server if you want to make use of AMR-received power data in your ISY programs. Agreed. If you decide to get serious about energy monitoring, you'll probably want to go with per-circuit "clamp on" CT metering in the breaker panel rather than whole-house totals at the meter, there's a thread about that: http://forum.universal-devices.com/topic/17817-suggestions-on-energy-metering/

Read up on the Portal module and what it does. It may be the solution to your requirement.

It can be difficult to work through setting issues without being able to run a packet sniffer to look at the actual transaction (and with TLS, it can be difficult even with a packet sniffer). I haven't used Cox's internal email servers, but I have set up a few ISY's to use Gmail. I created a separate gmail account just for notifications. With GMail you'll find a lot more people on the forums have set it up and know how to work through the connection/authentication issues.

I'm using the Honeywell TH8320ZW1000 (aka YTH8320ZW1007), have been very happy with it. I have the time-of-day changeover done by the thermostat, and use the ISY to set it to "energy save" mode based on occupancy sensors. Thermostat reports status to the ISY and I can trigger programs based on when the heat or AC actually is running, for example I have a program to track furnace runtime by day. Main reason I have the thermostat doing the time-of-day settings is because Honeywell thermostats include a feature called "Adaptive Intelligence recovery". when using the internal schedule. Each day, the thermostat tries to reach your set temperature for the set time, so if I set "Wake - 7AM - 66F" in the schedule, it will start the furnace at 6:50AM to try to hit 66F by 7AM. If it doesn't actually make that temp. until 7:05, then tomorrow it will start at 6:45. Communication shouldn't be an issue in that situation. I use a few Aeon multisensors with plug-in power to both get temp/humidity from other rooms and as repeaters.

While it sounds quite unlikely, if copying/editing programs reliably fixes the problem, it is possible there is a physical fault with the ISY or the SD card inside the iSY. Technical support may be your best option.

Specifically, you want a program that has Schedule set to "At Sunset", and has no other conditions, then the action in the program would be Wait ... Random (which may wait as briefly as zero seconds). If you have any other conditions set in the If clause, keep in mind that program Conditions are re-tested after a Wait or while Repeating, which could cause statements after the Wait not to be executed.

I do two kinds of logging, both use ISY994 features with variable substitutions to get data into a useful form. For Program events that are of interest to other systems in my house, I use Network Resources to generate a syslog packet, this can be received and handled by any Unix system, or even Splunk, etc. I use Notifications to append text to a webpage on the ISY994 when certain programs run, this gives me a HTML view of what's happened today, which I can view from any web browser, e.g. from a phone or tablet. Logfiles are named for the day of the week, and erased after 6 days. One use of these is to figure out what happened when I miss a notification I expected -- if I didn't get the email notification, I can check my webpage log to see whether that program sent a "notification" to the webpage, basically an execution history instead of just a "last run" timestamp. Say no, save to disk, then launch Excel, find the saved .csv file on disk and open it that way? Haven't tried SEG. I do track some things locally (temperature and humidity), and have been playing around with sending event timestamps and tracking/graphing variables using the free version of UbiDots.

Currently the IOT4R should work as a EZIO4O, per their website. If you have the Network Module, you could play an unlimited number of on-the-fly text to speech announcements with an rPi, for less $$ than either previously mentioned solution. It can also playback any MP3 or WAV file.

Hint: You can also use 'Beep' with a scene, causing multiple devices to sound off (nearly) simultaneously. The "beep duration" is value is ignored by all known Insteon devices, all durations give the same length and volume beep.

The main purpose of the internal speaker is to provide alarm/fire alerting inside the house, at a moderate volume. The speaker isn't really all that loud, you might not really hear it at all if you mount it in the attic instead of somewhere connected to the main living area. Sirens are much, much louder, and make sure all your neighbors know you have an alarm system. If your garage or attic has a open gable vent, it's common to mount a siren just inside the vent, aimed outwards. This protects it from the weather, critters, etc.

Google VAPIX. Axis publishes a full API spec, should make it easy to have the ISY994 send control commands. I don't know what camera models/firmware support the API.

Why not use an Open/Close sensor (2843-222)? Use it with the magnet to detect when the lid is opened, or better yet hardwire it to a tilt sensor to send a signal when they dump the can into the truck. With the latter option, could even seal it up completely against the elements and it'll still detect being tilted.

My plan is to network-enable control of Somfy using a RFXtrx433E. It translates 433Mhz network device data to and from serial (via USB).

The EZIO is certainly the cost-effective way to solve this. Using a scene would make the response time faster and more reliable than using a program.

Schlage BE469 are Z-Wave only; You wouldn't want to use traditional (insecure) Insteon signalling for a deadbolt. The 469 does eat batteries, but on the positive side the status in ISY994 includes battery level, so you can know in advance when to change out the AA batteries.