Goose66

They use to do many (like 10+) press releases a year since their inception in 2005. But after just a couple in 2017 and 2018, they've been silent. I don't think they've been at CES since January of 2018, either.

But we are talking years of quiet at this point. I sent an email to Insteon support a week ago and received and answer from Smarthome support within 24 hours claiming they are still around but blaming the shortages on COVID-based supply chain problems and "overwhelming Q4 demand." ? I wonder when the patents are up - maybe we will see an explosion of cheap and compatible products like we did with X10.

@joekewe Yes - excellent suggestion. Did you (or anyone) find a device to diagnose 120-132 kHz line noise? Maybe one that could plug into any outlet?

None of this explains the lack of any news, announcements, new products, etc. out of Insteon/Smarthome in almost 2 years after Rob Lilleness's comments in first half of 2019. It could just easily have been decided that the whole product line was to be discontinued by they don't want to announce it until all of the inventory and contracted pipeline of existing products has been exhausted.

Choosing the right controller for a strip light is based on the type of LED chip. Look for the chip type on the packaging, e.g. SMD2835, SMD3528, SMD5050, etc.

I am always amazed at all the new functionality they try and add to these things. It's a garage door opener. I need to be able to open it. I need to be able to close it. I don't need an LCD screen with a menu of options. That's what I have my ISY for! But if you're going to add a lockout function, then make it accessible remotely. If I am at home and have access to the local keypad (or LCD screen), I probably don't want to engage my lockout. It's when I am sitting at the airport waiting for my plane to Fiji that I remember that I need to lockout my garage door openers (and adjust the thermostats, and turn on the random light routines, etc.).

Let me try just sending a "lock" and "unlock" action through the API just to see what happens. UPDATE: No joy ☹️

Those are the ones I have too. Yes, hacking these at the button level would be sketch. Hacking a menu button to step through a sequence on an LCD control pad is too messy even for my tastes. Really should be in the API, seems like something I would want to do from the mobile app.

Could you just hack the contact closure for the lock button and the led leads for lock status? As far as MQTT nodeserver and a remote raspberry pi, why not just implement a simple web server and host the Node Server REST API directly, and bypass Polyglot altogether.

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.

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.