Goose66

+1 to what @JBanaszak said. Remember "Not, And, Or." It's going to look at NOTs first, then ANDs, and then ORs, when there are no parenthesis to control the order of evaluation. So in this case, the AND statements are evaluated with the "Time is 5:00 AM", and then ORed with the rest of the "Time is X:00" statements.

I didn't get I accidently posted before finishing my reply. But in further consideration, yes the last run time should be > and not =.

The conditions in a program's If statement are just that: conditions. They will be evaluated every time the program is triggered to determine whether the Then branch or Else branch of the program will be executed. The events that trigger a program are "divined" by the ISY from the If conditions. So in the case of the OP's program above, it will be triggered: 1) at 6:00 am; 2) at 6:00 pm; 3) the Last Run Time for the "Freeze Warning Day - Tag" program is updated; 4) the "Temperature" driver value for the the "Tags / Garden" device changes; and 5) the i_Ctl_Garage_Freeze_Switch variable changes. I don't imagine the OP wants the program to run all of these times. If I understand what the OP wants here (it wasn't specified), the solution is two programs: a first program that is enabled and that has the "Tags / Garden Temperature" condition along with a 6:00 AM condition that runs a second program in the Then branch, and the second program that is disabled and has all of the other conditions (time range, last run time, variable count) and performs the actual statements in the Then branch.

I have 3. It works but I have range extenders, the PLM (and the ISY), a dual-mode outlet module and a dual-mode switchlinc all installed in the closet with the breaker panels and on breakers to ensure bridging of separate phases of the separate boxes. Ironically, that dual-mode switchlinc is the most unreliable device in my system right now, at least in terms of consistent communication with the PLM.

If you are dead set on using Insteon despite its uncertain future, then the answer to this question is ABSOLUTELY NOT. To do so would completely negate one big positive of using ISY and Insteon. The ISY is, at its heart, a native Insteon controller. Sure, there is Zwave and nodeservers, but Insteon is what it has been all about from the get go. If you aren't leveraging the native Insteon features of the ISY, then you may as well be using any number of home controller devices, like Smarthings and Home Assistant, that have naive and low-capability Insteon interfaces. IMO, one of the best features in the ISY, made even stronger since 5.X firmware (more on that later), is recognition and integration of Insteon scenes. Programs are great when you have complex compound conditions and schedules, waits, repeats, and branches and all, but if you want one Insteon device to respond to another Insteon device instantaneously, then Insteon has a whole communication protocol built around that that is, in my experience, far more reliable than the ISY communicating through the PLM. The great thing about the ISY, though, is you create the scene right there in the ISY (similar to how you would create a program), and the scene utilizes all of the great, instantaneous Insteon scene protocols, while having configuration and status completely integrated in the ISY Admin Console. And now with the 5.X firmware, it's not even limited to Insteon. If the nodes in a nodeserver support the standard DON, DOF, BRT, DIM, DFON, DFOF commands (either sending or receiving or both), then you can drop a nodeserver node into a scene (as responder or controller) with Insteon devices and get all the instantaneous, integrated goodness of Insteon scenes along with interoperability with non Insteon devices through nodeservers. I believe it even works the same way with ZWave devices, although I can't confirm that. The ISY handles all of the plumbing - no programming required! So use programs when complex conditions and schedules and compound actions and else statements are necessary, but don't forego the power of Insteon (and integrated) scenes for simple linking of devices. EDIT: In other words, exactly what @simplextech said. ?

That's not entirely true. It will go through all of the commands in the Then branch or Else branch every time the status changes. The "re-trigger" of a program (specifically the program halting mid-stream and re-evaluating the conditions - called "reentry") can only occur when the program hits a WAIT or REPEAT command. You are correct that, since the program changes the status of the Center Ceiling, that the program will run in a loop continuously, but each individual run won't be interrupted when the status changes. As far as the OP, I think what may be missing here is logic as to what you are trying to do. What do you want to trigger the program, a voice command from Google? If that's the case, take the condition out all together. Tell Google to "Turn On TV Mode" and the ISY will run the Then branch of the program. Tell Google to "Turn Off TV Mode" and the ISY will run the Else branch. The condition is not needed.

If you use Polyglot, you can get a Venstar Color Touch and it has a local API that doesn't require access to the cloud service (SkyPort). It's s great thermostat and offers full control through Polyglot nodeserver developed by some really smart people ?. If you later decide cloud-based access is not a bad thing, it has a great iOS app and Alexa control available as well.

If you are going to use LED bulbs (which I hope you are), you can also use this: https://www.smarthome.com/collections/insteon-switches/products/insteon-2442-222-micro-dimmer-module Fits in any box. I agree with keeping the module in the box at the fixture since you should always have access to that. It's not Insteon, but you could also just put some Wi-Fi bulbs in a regular fixture. In either of these situations, you are going to want the fixture/module to be on a line with its own breaker, or you are going to want a conventional switch somewhere upstream.

Did not know that. This is good information!

@carealtor Perfect. My Z-wave module is currently in a cardboard box in the basement next to where the ISY is mounted. I just didn't want to have to go down there - it's dark and scary.

I put in a ticket but never got an answer to this question (and I don't see it here): if I upgrade my ISY with my series 300 Z-Wave module installed to 5.2.0, do I just lose Z-wave functionality or does my ISY explode and take out a corner of my house (or some third thing)?

And that's going to pass the WFT (wife-factor test)?

Answer is yes - it will write the proper links to the PLM even without the battery devices in program mode. You then have to restore each of the battery devices individually. I usually go around and take all mine down, bring them into my office, and go through the restore one-by-one. I take that opportunity to replace the batteries as well. Then go put them all back up.

I just got a 12-zone b-hyve controller from Orbit that has Wi-fi and a website for $99 (got it for my parents so I can make adjustments to their system over the web). The 6 zone is even cheaper. I will see if it has an API for ISY.

@Chris Jahn Any additional details for the Date/Time NTP UOM, like what's that? Here's hoping it's a timestamp.

Those were the events during the PLM Restore?

My PLMs have lasted about three years. On my fourth one. Backup your ISY, open the Event Viewer, Set the level to 3, and then try doing a Restore Modem (PLM). If you get a bunch of errors or unacknowledged writes, or just general hanging of the process, good chance the PLM is bad.

It doesn't have a noticeable button to initiate such a check, like my rackmount UPS in my wiring/network closet does. Just glancing at the user manual and the unit itself, I'm guessing is not very sophisticated from a firmware perspective.

So it was installed a few days ago and I just got around to mounting it (and putting in the second outlet) yesterday. Assuming it was fully charged when I started, it went through one very short (maybe a minute or two) charging cycle when I unplugged it from the old outlet and plugged it into the new. Then, while I was running the network cable and mounting the ISY and UPS (approx. 25 minutes), it went through at least one more charging cycle (green -> red -> green). My comment was based more on how short the charging cycles were and how closed together they were, rather than how many times it charged. It has 4 screws on the bottom in the corners, but mine looks to have at least one spot where the bottom appears to be welded to the rest of the enclosure. That may just be physical damage, however. I didn't try to take the bottom off.

2-3 years is not very long, especially without a replaceable battery. Also, I am noticing it is essentially an "online" UPS, where the ISY (or whatever) is 100% fed by the battery, and the battery is periodically recharged by the supplied charger. I don't what the low and high thresholds are for charging, but they are close enough that it switched on and off at least once (red light/green light) while I was installing a second outlet and mounting it in my utility closet. If it is going to go through charging cycles like this several times a day, especially if it's charging to 95% or 100%, then I can see why the life would be limited. Li+ batteries need limited charging cycles and should be kept between 20% and 80% charged for longest life.

Should I be using the 9V output for my ISY or one of the 12V outputs?

It seems to me that this is a problem with authentication to the ISY. Since NodeLink is now running, go to System Config and ensure your ISY credentials are correct, then restart NodeLink from the web interface.

@Teken Don't know how one tests and validates long term impact on anything Insteon given the lack of diagnostic tools and the fact that Insteon is so flaky, varying in performance from day-to-day.

Does it avoid the need to use a FilterLinc to protect Insteon? That would reduce the total price. Also, I was comparing VA to mAH, which obviously (to me now) is not comparable. I moved my ISY to the utility closet with my electrical panels recently and was just searching for UPSes for it this morning! EDIT: For anybody finding this post in the future, the 700VA UPS I was considering in the same price range has a 108Wh battery compared to a 98Wh battery for this unit. I am sure there are additional losses in all the conversion from AC-DC-AC-DC and 120V to 12V to 120V to 12V so this is a pretty good solution cost-per-Wh wise.

Just out curiosity, why would one want this device over a more traditional line interactive UPS that had 25x the backup capacity for the same price or less?