Goose66

So I disconnected my MyQ gateway from the LAN for 10 minutes, then plugged it back it. The first command to door 1 from the mobile App worked as normal. However, the first command to both door 2 and door 3 from the ISY through the API appeared to fail, but the second command to both was successful. The first command to the lamp module from the ISY through the API was also successful. So really, not a consistent result to report. I will try again later.

This program will only run if the "401 Lamp" device sends an on command - usually triggered from a switch. What kind of device is "401 Lamp". What you may want is status: If "401 Lamp" Status is On.

I don’t believe MyQ needs local operation before allowing commands after an outage. The commands appear to work whether the state is known or not.

When you login into the portal, up at the top right there is link for Polyglot Cloud. In the Polyglot Cloud Dashboard, go to the Nodeserver Store and install the MuQ nodeserver and follow the instructions from there.

Do you have either 1) the ISY Portal service or 2) a Polisy or Polyglot running on a local RPi or other computer?

"rock solid?" That has not been my experience with Insteon ever. I also have a SwitchLinc located in the electrical closet of my home along with the breaker panels and the PLM/ISY that has "rock solid" response from a KeyPadLinc key elsewhere in the house and remote control from my phone through Mobilinc, but only about 50% response reliability from a program that runs on the ISY every night. I can put WAITS in the program, put the SwitchLinc in a separate program at a different time, etc. but the reliability from programs on the ISY through the PLM stays around 50-80%. I don't think I have EVER hit the KeyPadLinc key and not had the SwitchLinc respond. Nor do I remember not having the SwitchLinc respond to Mobilinc (which I realize goes through the ISY/PLM). I believe these type of errors are timing errors - especially when the PLM has both a PLC path and an RF path directly to the device (SwitchLinc), it just seems not to work reliably. But I think Mobilinc must have some logic in it that if a command doesn't work the first time, it either retries or just shows absolutely no feedback on the screen, making you think you just didn't touch the right thing the first time. Not helpful in your diagnosis I know - but I think it's just an Insteon reality, especially when communication has to go through the PLM.

+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.