Goose66

The KeenHome is considerably more expensive than Flair vents and works with my ecobee thermostat(s). I am not sure I can justify the additional expense of the KeenHome just to write a nodeserver.

I was going to say why would anyone want their ISY to know that a "Fancy turtleneck with deer on it" went on sale for $469.50. ? Actually, I've been wanting zone my three bedroom upstairs with the attic furnace because my son's room closest to the furnace runs a good 8 to 10 degrees warmer to my daughters room down the hall and over the garage. I was thinking I needed a whole new plenum and duct work, but smartvents could be a good way to go.

So you specify one or more "spokens" to each ISY device when adding them to the Echo integration (the first one defaults to the device name, I believe). When you perform a device discovery in the Alexa app or through the Echo, it queries the integration for the names of devices and an address. Each "spoken" is added as a device and resolves to the same address of the ISY device. If Alexa is giving you a "did you mean error," it most likely is confused by the name of the device with some other device (ISY or otherwise). Could be a TV from Roku skill, a thermostat, a Wemo outlet, etc. I explain this only to say the problem is more likely with Alexa and all of the devices discovered by Alexa in your setup then with the ISY or the ISY's Echo integration.

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.