KeviNH

oberkc is correct -- one of the more important idiosyncrasies of ISY programming is condition re-evaluation, it takes a little getting used to the Wait behavior and the difference between state and integer variables. Based on the above behavior, this is how I wrote my "Notify Garage Door" program (I use the $GarageOpen state variable in other programs and other notifications): If Status 'Outside / System Devices / Garage Door IO Sensor' is On Then $GarageOpen = 1 Wait 7 minutes Send Notification to 'BenInsteon' content 'GarageDoor Open' Repeat 5 times Wait 30 minutes Send Notification to 'BenInsteon' content 'GarageDoor Still Open' Else $GarageOpen = 0 Send Notification to 'BenInsteon' content 'GarageDoor Closed' At the end of each Wait or Repeat, the program condition is re-checked, and if the garage door has closed in the meantime, execution of Then immediately stops short, and Else code (if any) runs. Lastly, if the program is in the middle of a Wait and a change causes the conditions re-evaluate to false, the Wait will end early and the Else code will run immediately. See above for why this re-evaluation happens with state variables, but not integer variables.

As mentioned above, double-check that GarageOpen is a state variable, otherwise Program 2 won't trigger. Instead of using a third program, why not put it into the "Else" for Program 1? Program 1 [Notification.GarageOpen.1] If Status 'Outside / System Devices / Garage Door IO Sensor' is On Then Wait 15 minutes $GarageOpen = 1 Else $GarageOpen = 0

It should survive exposure to salty water. These"reed switch" type flow sensors are very simple devices, there's a plastic-encapsulated captive magnet in the switch body; when water is flowing, it pushes the magnet in the direction of flow, bringing it into range to close the sealed reed switch. Sometimes it is returned by gravity, sometimes by a metal spring.

There are a few WiFi-enabled water softeners, but as far as I can tell, no WiFi or Z-Wave enabled control head to retrofit a standard water softener.

You're basically hitting a "race condition" in the ISY. While you expect the tests triggered by incoming "is switched off" event to be fully processed before the incoming "Status is off" event, there is no guarantee this will be the case, as the internal evaluation of "if" conditions is not perfectly atomic. You may be able to work around it by using multiple programs and/or variables.

If you have the Z-Wave module for your ISY994iZw, there are several threads discussing the various Z-Wave brands of locks. Without Z-Wave, your best option is the MorningLinc (MI) controller and locks

ISY994 can also add a custom "From" address for the notification. So, for example a different sender for "Lock" versus "Unlock", then many smartphones let you set a custom message notification sound if you add each of these From addresses as a contact. So I have a creaky door opening as my "Unlock" notification sound, and a door closing ("thud")as the "Lock" sound, so I don't even have to look at my phone to know which event just happened. I do something similar with my garage door alert.

Another good reason to add a "Beep", notification, or log to the first program, as shown above. With the original single program, conditions are re-evaluated (including at the end of each Wait). Program will stop early if the conditions are false, which is why statements after the wait sometimes do not execute. Go with the two program solution, so "Last trigger it should complete with any amounts of retriggering".

Yes, you're good. For testing out programs like this one, try making the sensor trigger a noise or notification, for example: Front Security Switch - [ID 0030][Parent 0001] If Control 'Front House Security-S' is switched On Then Run Program 'Front Security' (If path) Set Scene 'Dining Room' Beep The "Beep" line will cause any beep-enabled controller (e.g. a lightswitch) in the scene to emit a single chirp. I like to use a notification which writes a timestamped line to a logfile for this kind of execution tracking. The second program, below, is disabled (You'll need to right click on the program and select 'Disable') and has the time range as the conditions, so when 'If' is called by the first program, it will only run if the time condition is true. NOTE: Disable this program!!! Front Security - [ID 0031][Parent 0001] If From 12:00:00AM To Sunrise (same day) Then Set Scene 'Front House Lights' On Set Scene 'Dining Room' On Set Scene 'Foyer' On Wait 5 minutes Set Scene 'Dining Room' Off Wait 5 minutes Set Scene 'Foyer' Off Wait 5 minutes Set 'Front House Lights' Off Else - No Actions - With the above, anytime the motion sensor is triggered, you will get a beep, but only when it is triggered at night will it turn the lights on, then off.

Anytime you have problems with statements after a "Wait" not running, suspect the issue raised above. The quick and dirty workaround is to move all the actions into a separate program. Front Security Switch - [ID 0030][Parent 0001] If From 12:00:00AM To Sunrise (same day) And Control 'Front House Security-S' is switched On Then Run Program 'Front Security' (Then path) Else Run Program 'Front Security' (Else path) The second program, below, has no conditions, so it will only run when it is called explicitly, in this case, by the first program: Front Security - [ID 0031][Parent 0001] If - No Conditions - Then Set Scene 'Front House Lights' On Set Scene 'Dining Room' On Set Scene 'Foyer' On Run Program 'Front Security' (Else path) Else Wait 5 minutes Set Scene 'Dining Room' Off Wait 5 minutes Set Scene 'Foyer' Off Wait 5 minutes Set 'Front House Lights' OffBecause the second program has no conditions, there is nothing to be reevaluated after the wait, it will always run all the way to end.

Larry, you are quite frustrating! There are good reasons to want to have the temperature in a variable, for example if you want a program that only runs if one room is more than 10 degrees warmer than the others. Broyd, what you are asking may be doable the Network Module if your device reports the raw temperature as an integer variable. For example, my Aeotec shows RAW as "66.40" so it doesn't work to store in a variable, but my Honeywell thermostat reports "67", no non-integer characters. The trick is to use this integer to update a variable by making a REST call from the ISY back to itself (don't use 127.0.0.1, use your intranet IP). You create a network resource that looks kind of like this (you'll need to supply the hostname, node, and your ISY's username and password): You'll need a program which sporadically calls this network resource so the value gets updated on a regular basis. This does not require V5, the screenshot above is from V4.5.4 and works fine for any device where the .RAW is a pure integer value.

Harbor Freight sells a $5 bit assortment with pretty much every security screw type ever made.

There's not inherent "disable" command in the standard UI. Sounds like you're looking for a way to programmatically enter/exit vacation mode?

Personally, I try to avoid building anything reliant on cloud services, too many of them just disappear, the rest end up playing games with their pricing models, so I no longer trust anything cloudy. I'd rather self-host and deal with the overhead. I prefer VMs like Photon OS™ over Pi, unless I need the IO lines. They're HUGE if you click through all the way to the 1600x1400px originals.

I use two notifications -- one sends me a SMTP message, the other appends a log to a local HTML file on the ISY itself.. No cloud services involved.

Ethernet cables and RS-232 cables are by default wired straight-through, that is the standard cable type. When a crossover or "null modem" cable is needed, that is a special exception, and is usually labeled as such, or for Ethernet, might be colored red or yellow. Many modern Ethernet devices have automatic medium-dependent interface crossover (auto-MDIX) functionality in the device (not in the cable), that is the auto crossover. But the cables are not special, the port (driver chip) inside the computer or switch is.

Ethernet with A on one end and B on the other is called a crossover cable. A patch cable is wired with either A on both ends, or B on both ends. The "normal" use of an Ethernet cable is to connect a computer to a switch, in which case the transmit/receive pins are already different on the switch than on the computer (though modern Auto MDI-X takes care of this now). A third type of cable are the special flat RJ-45 cables (usually pale blue, sometimes black) you see for serial console on networking gear, popularized by Cisco. These are usually "roll" cables and should only be used for Cisco-style serial connections, never for networking.

No need for parens ,a chain of "And" statements is fine. In order to avoid to triggering this program if the light is already switched, I'd suggest changing "And Control 'Dining Room Switchlinc' is not switched On" to "And Status 'Dining Room Switchlinc' is Off".

After 30 seconds, the lock re-locks itself, and Status changes to "Locked" so program is terminated before it can reach the end of the Wait time. To confirm this, temporarily add "Set Scene 'Dining Room' Off" to the Else clause, you should see the light turn off when the lock changes state back to Locked. If you disable the 30-second re-lock, you could get the results you are looking for with this program. Front Door Unlock Lightup - [ID 003B][Parent 0001] If From 7:45:00PM To 3:00:00AM (next day) And Status 'ZW 002 Schlage Door Lock' is Unlocked Then Set Scene 'Dining Room' On Wait 3 minutes Set Scene 'Dining Room' Off Set 'ZW 002 Schlage Door Lock' to Locked Else - No Actions - (To add one, press 'Action') Comment (Make sure the command to lock the lock is the final line of the Then clause) There are other ways to accomplish what you are looking for by using a second program.

Insteon protocol is pretty much limited to the MorningLinc, and is not a popular solution for door locks. Many, if not most, Z-Wave door locks are supported by the Z-Wave enabled ISY994Z, the most popular choice does appear to be the Schlage BE469. Others, like the Kwikset 910, and Yale, are also discussed in various threads in the Z-Wave subforums, but aren't nearly as popular.

When unsuccessful, debugging serial can be non-trivial, especially without access to a oscilloscope, etc.. If the problem is induced noise,a shield cable might help but if the problem is capacitance, switching to a shielded cable will make it worse. Ultimately, if you have the ISY next to the PLM as a temporary setup and that is working, you might want to just make that permanent. I suggested the extender solution as a last-ditch option in the earlier thread, but those active converters are not cheap, and are usually only necessary for extreme distances (in the hundreds to thousands of feet), and/or at much higher baud rates. I've had no problems with regular Cat-5e at 30', other users here have gone to +60' successfully with just a long piece of Cat6 cable.

Interesting that your pre-made Cat5 cable failed to work. Maybe it is faulty, tried a cable tester on it? The PLM uses 3 wires, a different subset of the available lines compared to Ethernet, so a cable could work for 100Mbit networking yet fail when used for PLM. IIRC, the serial communication uses pins 1,7,8 at 19,200 bits/second (baud); slow enough that it should be generally forgiving of the usual issues that might come with long cable runs. My ISY994 is 30 feet from my PLM, extended using standard Cat5e off a bulk spool, via patch panels. See this old thread: http://forum.universal-devices.com/topic/18274-maximum-distance-between-isy-and-plm/?hl=serial&do=findComment&comment=168187

Very few cameras ship with a PIR motion detector, and in-camera motion detection varies from absolutely awful to merely lousy. The ability to have a camera trigger an ISY-994 action depends on the camera/firmware. Many advanced cameras have a feature where they can make an outbound HTTP call upon motion detection, this can be a REST command to the ISY to run a program, like so: This camera also has a digital I/O connector, such that it will close a circuit when it sees motion. You could wire that "alarm output" circuit to an IOlinc or Open/Close sensor and use that as a condition for a program.

You should do an autopsy on the failed sensor, determine the root cause. What are you trying to monitor? It would be a lot easier to seal the unit if you are using the built-in reed switch. Several companies make IP67 rated project boxes, but ones with a waterproof cable gland are much more expensive than plastic boxes without a cable entry.

I just use the built-in "UD Ajax" Web interface via the web browser on my Android device. Browsing to the web-based UI on the ISY-994 works great when you are at home; you can access it remotely once you have a way to do remote access (port forwarding, etc).