Goose66

Is "heater room" a device name you have defined in the Echo integration, and is it appropriately unique?

I think the arguments of legal liability for Smarthome show a lack of knowledge of consumer products law. More likely that they engineered the product to act appropriately to its task, in there opinion. Why not always default to user configurable?!?

Standalone MyQ with the gateway device connected to the LAN by ethernet and corresponding MyQ-ready keypads that control older (purple button) LiftMaster openers. I also note that, despite the failure of the first commands to doors 1 and 2 through the API, the status reported through the API remained correct. So you could have a control mechanism that closed the doors, and then a few minutes later, if the status was still open, closed them again. But you would want some independent way to verify the door state IMO, like alarm system sensors (very common these days). I also also note that I don't count on my automation for security in this instance. I am old school - I don't move the car towards the driveway without visually confirming the door is coming down. Taught my kids the same thing. I mention this only to say that I haven't done a thorough investigation of the fail-secure nature of the MyQ system.

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.

In the context of the ISY ecosystem, I'm a big fan of having dedicated equipment for a system as complex as a pool, with the ISY playing a monitoring and high-level control role. I have a Jandy Aqualink RS that controls the pool, spa, spillover, lights, robotic cleaner, heater, freeze-protect, chemicals, etc. The ISY can monitor the system for problems as well as control modes and lights for large context control. For example, with the push of a KeypadLinc key (or a command to Alexa) I can put the system in spa mode, engage the heater, set the setpoint based on outdoor temperature, adjust the backyard lighting based on time of day, and then turn on the spa light when the spa reaches a minimum useable temperature so I don't run out in the backyard naked only to find the spa is too cold to get it.

Does it (or can it) have RSSI or other diagnostic information?

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

I love this: Randall Munroe, xkcd

Also, this is another long shot, but I was fiddling around in my pump house the other day and I noticed all of my pumps are grounded through an external lug to a grounding post, this is in addition to the ground wire in the power lines from the breaker panel. Another poster referred to it as a "bonding ground." Does your pump have this as well? I know when I was working the sound board for a theater back in the day we had to connect the "bonding ground" (what we called chasis ground) to a decent ground or we could get some pretty bad 60 Hz hum at high volumes.

I am not an AC expert (I actually got one of my worse grades in college in Power Systems), but it seems like you will need to attenuate noise between each of the two phases and the neutral - not just between the two phases.

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.

@ELA Just trying to be helpful - not looking to argue with you. 131.65 MHz is the band for PLC for Insteon. @pgershon You said something about controlling the lights in your pool house through Insteon. Is that the pump house, and is that Insteon controller dual-band? Perhaps it's actually RF interference from the pump that's causing problems in the dual-band switch or module.

Oscilloscope (or PC-based software equivalent). Has to be able to handle 240V (preferably 400-600V). You'll want to run traces in between neutral and each phase as well as across the two phases at the panel where the breaker for the pool equipment sub-panel is. Each trace should be run while you turn on and off various equipment and lights from the subpanel. Keep tracking of the timing of the on/off of each piece of equivalent and then let the oscilloscope do a frequency component analysis (Fourier transform) for the period of operation of each device on each trace. A lot of work, and I don't know that the answers you will get will point to a solution. You know that you have to filter out interference around the 131.65MHz band. The question is where do you put the filter, and what type of filter must you buy to put it in that spot. Again, my suggestion is a 60-100A bi-pole filter at the main panel that feeds the pool equipment sub-panel. But that will also block your Inseton controlled lights in the pool house, so you will probably want a separate 20A feed to the pool house for lights and such that will work with Insteon.

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.

If the noise filters didn't work, I don't know what will. I use 20A X10 noise filters in my installation in several places, and they work fine for Insteon's frequency (131.65MHz). The noise could be bleeding over into unprotected circuits that run close to the pump. Maybe something larger installed back where the pool system subpanel comes off the main panel? My Jandy FloPro variable speed pump may interfere on wind up, but doesn't seem to cause problems normally throughout the day. Due to the nature of a variable speed pump that it runs so many more hours than a regular pump, I can see why interference could really be a problem.