Goose66

This forum may be one of the largest grouping of Insteon users there is (or I am delusional). Perhaps we should sign a petition or demand for a local TCP/IP-based API for a PLM or Insteon Hub to be added to the mix. I would develop and implement it if they would give me the Hub source code. Or better yet, put Node Server API support right in the thing!

But, again in the context of "full automation being the goal," manufacturers have done little to help by keeping their systems closed. The promise was the "Internet of Things" - everything online and talking to each other. The reality is that most manufacturers don't want anything to talk their things but their own things. Whether it is inability to provide interfaces or unwillingness to lose potential revenue streams, this tendency of manufacturers to lockdown their devices and ecosystems has been a thorn in the side of true home automation enthusiasts for decades.

And with full automation being the goal of some over the last 25+ years or so, there's been nothing but disappointment coming from manufacturers. In my first house in 1995 I had X10 switches and modules w/ a PC controller that output a GUI interface to my projection TV and a IBM voice processing card allowing for voice control. I ran VBscripts with time and event processing that allowed some real "automation" of the house. The problem then, of course, was that while I could control what X10 allowed, I couldn't really integrate it with a lot of other things in my house. Fast forward 25 years to today and all the new great technology has brought us...

What I would REALLY like to see (assuming, of course, the demise of the ISY/Insteon "partnership") is a local API for the Insteon hub - ideally two-way, realtime, and REST/UDP-based. That way, the hub would contain all the vagueries of PLM communications and device-specific data interfaces. A nodeserver could be developed to allow the ISY to continue to support Insteon and the Hub/app could be used for Insteon configuration (and, potentially for non core-ISY folks, local and remote control, Alexa/GH support, etc.) That way, when new Insteon devices were made available, support for them would be immediate - no need for Insteon to communicate details to third-parties (which they are evidently very bad at) or waiting for new ISY firmware for support of the new devices. Seems to make perfect sense to me for a hardware manufacturer to want this too, but based on what most of them end up doing, I obviously don't get it!

Link?

If there was going to be a new PLM, wouldn't @Teken have posted something by now?

Has this thread devolved into a lottery pool? I'm in. ?

You're going on my "I told you so" list! ? In the interest of full disclosure, I am 100% Insteon here (meaning no Zwave or other lighting/switches/modules). $3500+ worth, I would imagine.

If you think the idea of hardware manufacturer closing their system in favor of pushing adoption of their own ecosystem is "outrageous," then you haven't been paying attention to the home automation industry for very long. It happens all the time. Is it likely to happen with Insteon? Don't know. But it's far from an outrageous possibility. You and I may wish they would "stay in their lane," but manufacturers rarely do when there are monthly subscription fees for cloud services to be had.

Let's hope that relaunch doesn't mean hub only (no PLM) and access limited to app.

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.

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.

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.

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.