Goose66

All this technology built into these things and no Wi-Fi? $229 for the sensor and you have to pay another $80 for a hub to connect it to the Internet and use it outside of the Bluetooth range of your phone? If I had a tiny house over a fracking site, maybe, but I wouldn't buy this for my home on the engineering principles alone!

The are in the Installation and Programming Manual available online.

Never done it on a Vista. I factory reset my DSC PowerSeries 1832 with 16 zones, 5 smokes, 3 heats, and 4 keypads and reprogrammed it from the worksheets in an evening. The worksheets were key!

I really don't know much about tuxedo touch keypad. I imagine the 4-wire bus for the connection of keypads to Honeywell/Ademco systems is pretty universal, and is the same four wires as needed for keypad connections to other systems (GEM, Elk, DSC, etc.). As long as the keypad says it supports the panel then it speaks the right language. The main point I wanted to make was try factory reset before abandoning your current Vista board.

It is possible that the panel may still be functional (i.e. capable of working) but that water damage caused problems with the memory/configuration. Before abandoning the panel altogether, I would try factory resetting and reprogramming the panel. You should be able to do this if you know the installer code. The installer code may stay the same after the reset, or may go back to factory default installer code. If the panel turns out to be bad, I would favor a different system over the Honeywell if interfacing with the ISY is desired. The EnvisaLink interface to the DSC Powerseries is far more functional than the EnvisaLink interface to the Honeywell Vista. Of course, then you are replacing keypads too, which makes it more expensive. You could also look at going to something completely different with built in Ethernet connectivity and home automation integration, like Elk M1 or Ring w/ Retrofit kit.

Ok, now we've really gone off the rails...

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.

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