upstatemike

OK Like the failover on a dual band router. You are right when it talked about setting the time delay I didn't understand what it was doing. I'll slow down and read all of the words next time.

I'm not sure if I would dismiss land lines as 70s/80s technology as if they are no longer needed at all. Large businesses still use wired phone systems with multiple lines and extension to extension calling/transfer. I don't see the technology disappearing entirely nor the products thst support it. They might just be more expensive commercial devices rther than consumer oriented items. Small to Medium sized businesses can get a small PBX and 3 or 4 land lines cheaper than dealing with a VOIP system where you need to worry about a network designed for traffic prioritization and QOS.

The point is that there is no available Internet when the reboot is required so these will not work. It must be a technology that connects to the home without depending on the Internet at all.

So I will try to answer my own question from the top and suggest that while RA3 looks to be a big improvement in styling, security, and user access, the cost and trade barriers are still geared to support Integrators and these prevent it from being a good replacement for Insteon. My analysis of Insteon replacement options for Prosumers at this stage are: 1 Rule out most Integrator products such as C4, RadioRA, Homeworks, etc. as not practical for Prosumers because of the high cost and distribution constraints. 2 Rule out any vaporware that you cannot currently buy and for which there is no track record. These would include things like Z-Wave Long Range, Matter, and Nokia. 3 Rule out things that do not have a local API such as LoRa and most Wi-Fi offerings. (Lifx being an exception). Using Tasmota and other super techie ways to get around this are also ruled out as not being practical for most Prosumers and clearly not targeted for the same audience as Insteon. 4 Rule out anything that does not allow direct association between devices so they can work when the hub/gateway is offline. Zigbee is the most common example here. This leaves: Caseta - No way to control one device from another, must have a Pico to stitch the group together. Also kind of limited on device offerings. Z-Wave - Can mimic some qualities of Insteon but is a ridiculously complex protocol for what it does, with a configuation that can get corrupted and a reputation for being hard to back up and restore reliably. X-10 - Still has the same problems it has always had but these might be more manageable than the shortcomings in some of the newer platforms. Also still releasing new products and has a wider variety of devices than other platforms. Used Legacy Insteon - We should be able to find used stuff on ebay for quite awhile to hold us until a truly viable alternative finally reaches maturity.

I'm having trouble following this conversation. As I understand it RA3 uses LEAP. Any RA3 installation will be new so no need to be campatible with older Telnet installations of RA2. Some RA2 components can be used in RA3 installs as well but that has nothing to do with Leap vs Telnet. RA2/RA Select/ Caseta all can or must use Telnet. That will not change for existing installs or new installs using these lines for long as they are still available to use for new installs. Caseta will likely become a LEAP based Caseta2 at some point but new and existing switches will likely work in either version to preserve the ability to expand existing installations. There may or may not ever be a LEAP version of RA Select depending if Lutron feels that line performed well enough to continue. Either way the current version of RA Select is likely going to be terminated at some point. Am I understanding things correctly? If so I don't see what points are left to debate?

Still says "Email me when available". I wonder if they will launch in time for Black Friday? You would think Nokia would want to leverage the holiday season in introducing this new line.

So how much cheaper is DSC and why would a customer choose to go more expensive?

Then what is the value of LEAP if it is not meant to replace the current stuff?

Curious how you select between Elk and DSC for a given situation?

Aspiring Prosumer... I identify with that group but probably not there yet. What group do you picture me in?

Which is exactly why products for Integrators don't work for Prosumers and Vice Versa.

A flow meter tells me there is a problem someplace. A toilet sensor tells me the what and where of the problem. I'll provide a diagram of the music system if anybody is interested but it basically involves using relays and separate components and not just relying on a boxed solution with a lame API to link to.

Don't feel bad, I am in the same boat. I need to get up to speed on both of these next year after getting past a long list of other overdue projects. It will be awhile before I achieve my Prosumer certification!

One example is I have a large home that is mostly guest areas that I rarely visit so I create automations that help alert me to issues that might otherwise go unresolved for quite awhile before I happen along to notice them. If a guest leaves a toilet running because the handle stuck I wouldn't realize until I notice the softner cycling more often than normal so I fix that by having water level sensor in the toilet tank. If the sensor is dry for a period much longer than it takes for the tank to refill normally after a flush i am alerted to go check on it. Very much a prosumer one off kind of application that no integrator would want to offer because of the initial fiddling to get the detection right plus the risk of callbacks on something like that. Another pet peeve is music integration, For me the very minimum basic basic requirements for a music system is: -Must provide good multi-room performance... no glitching or sync issues and no time delay on local sources. -Must support local library as well as streaming -Must have at least 4 levels of hierarchical priority 1 emergency messages like fire alarms, 2 alerts like doorbels and driveway sensors, 3 local to that room music and voice assistant interaction, and 4 shared multi-room music program. Each level should automatically override anything playing from lower level sources. -Must have true voice assistant integration... not the half assed integration you get from the API offered from Sonos etc. All voice assistant audio should utilize the sound system speakers, not just music. -Program muting or ducking for voice assistant interaction or playing of alarms or alerts should work regardless of program source, whether local or shared multi-room. -Muting and ducking functions should be smart enough to work automaticlly if a phone rings or is picked up, a TV is turned on, or the room becomes unoccupied, all without disrupting music in other rooms. None of these are hard but in most of the high end systems I have seen there are a couple of keypad buttons to select music mode or TV mode and that's it. Voice assistant integration is limited to the restrictions of a poor API from Sonos or Heos or whatever and the integrator has no desire to offer or maintain anything more complex.

Less about the capabilities and more about how they are implemented. Because they are dealer installed they are not really available/affordable to Prosumers who might actually want some of the complex capability while dealers tend to avoid anything too wild to avoid the potential service issues. I am not saying these products don't have capabilities but that they are rarely implemented to do anything very interesting.

I was on the fence about including those but I think they are becoming more common with this group while still maintaining a clear line between those skills versus scripting/programming expertise in the hardcore group.

It is interesting the different groups represented here and the dramatic difference in priorities. While it would be nice to identify the best automation protocol and best controller to serve all or most of these use cases I'm beginning to think there is no chance for that kind of consolidation simply because the requirements are so different and to some extent mutually exlusive. The first group (in no particular order) is the "Integrators" who are well represented here and who favor super reliable systems that have a low liklihood of generating service calls. This group is well served by protocolos like RadioRA and C3 which are rock solid but don't really do very much. Once you get past setting scenes by varying the relative dim levels of a group of lights and triggering those scens by timers or geofencing or keypad buttons you have pretty much exhausted their bag of tricks. The device selection tends to be limited for retrofit situations where you need to rely on fixture modules and other special parts to complete your install, focusing instead primarily on dimmers, switches, and keypads. The controllers from Lutron, RTI, C4, etc, likewise are reliable but pretty basic in adding security cameras, touch screens, thermostats, and rudimentary music control into the mix but not really doing anything very exciting, whether due to platform limitations or simply by design to keep things simple and avoid service headaches. These systems tend to seem both expensive and incredibly boring to the other groups. The next group is the "Hardcore Hobbyist". These are the folks flashing light switch firmware with Tasmota, building custom hardware interfaces with Arduinos and Ras-Pi's, sifting through pages of code on Github, and writing their own Node servers. This group will gladly spend hundreds of hours creating a custom $6 module to automate a light switch rather than pay $30 for a plug and play unit from Amazon. This is the group best served by products like Home Assistant, Shelly, and Sonoff, which demand a level of time commitment that the other groups are not interested in making. Another group is the "Perpetual Entry Level Consumer". These are the folks who go to Home Depot or Best Buy to pick up a few switches or bulbs that will work with Alexa. If they are particularly ambitious they might go for a video doorbell or smart thermostat but they don't want to commit to anything that can't be completed in a weekend and likely will never expand into anything more complex. If they ever do upgrade their system it will just be replaceing what they have with a new set of entry level products. Wi-Fi and Zigbee (Hue) are targeting these folks and this probably also the target demographic for Matter. Because this group is so large and lucrative it has a huge influence on what automation products are produced and what the capabilities and limitations of those products and their associated eco-systems are. Then there is the "Casual Hobbyist" group. These are the folks using Smarthings or Hubitat or even advanced routines in Alexa. They are looking to do more than the entry level products offer out of the box. They are comfortable with "trigger plus conditions" type logic but do not have the tech savvy or tme to go full "Hardcore Hobbyist". This group uses Z-Wave and Zigbee and higher end Wi-Fi (Lifx) to create cool custom actions to meet their specific needs and are willing to expand and tweak their systems on an ongoing basis but not to the point where it consumes all of their spare time. Finally there is the "Prosumer" group. These are folks who like to do fairly elaborate things with Home Automation but not down to the technical level of "Hardcore Hobbyists" nor at the limited simplistic level of "Casual Hobbyists". They want hardware that works out of the box but also want a logic engine that can handle complex nested "if-then" and "or" commands. They want this extended logic in a GUI interface without having to resort to manual scripting so their time is focused on the logic rather than syntax and debugging. They want to integrate with a wide variety of things beyond wireless protocols and expect dry contact inputs and relay outputs and serial connectivity as well. They are generally comfortable with MQTT and Node Red but not neccessarily Python or Json. This group often starts with Smartthings or Hubitat and then migrates to Homseer or Polisy. So what are the upcoming protocols and standards and platforms that are finally going to consolidate the Home Automation universe and end the market fragmentation and uncertainty we are now experiencing? Is improvement even possible without leaving one group or the other abandoned?

It will go in a box to keep my ISY-26 company.

But if Lutron is moving from Telnet to SSH with LEAP wouldn't that be a dead end? What is Hubitat doing about the change?

Yes. At this point in time RA3 is less useful for ISY/Polisy integration and therefore less functional than RA2. It doesn't matter what new features it has if it cannot be utilized by this community at this time. It does not matter what other demographic it serves or what business priority it addresses if that doesn't apply to current users and current requirements. It doesn't matter (to us) how many new customers it attracts or how commercially successful it becomes if it does not have the functionality that we need to use it.

As I have stated many times before the API is part of the functionality. Not releasing an updated API is the same as removing functionality. One last time, I am not arguing, just engaging in a discussion. My purpose is to improve my understanding (or sometimes provide amusement) not promote a point of view. I am old so sometimes I am slow to grasp certain points and need additional clarification so I guess that is on me. Manual linking is not, and never has been a practical way to manage Insteon devices. Lack of access to manual status changes or additional buttons or features is a loss of functionality from original Insteon. It does not matter why; Smartlabs business decisions, UDI business decisions or whatever. For me it is a moot point because the Nokia stuff remains Vaporware unless they ever manage to ship any of it and X10.com is adding new products to their lineup even as Smartlabs slashes their offerings. I'm going to use X10 to cover the fixture and plugin products that Smartlabs has abandoned and just get on with my life without worrying about the future of Insteon... except as a running joke of course.

Functionality like integration with other systems like with a PLM.

Lower frequencies have longer range and better penetration but the trade off is usually antenna length. That said the original Clear Connect as well as standards like LoRa do very well at lower frequencies so I guess the antenna design issue can be managed somehow.

Of course we expect Polisy will replicate all of the current functionality that the 994 has so nobody will have a reason to miss it. Will Nokia eventually have all of the functionality that Insteon has? Will there be a Nokia PLM or Nokia fixture modules?

Smartlabs could shut down Insteon and still continue to make the Nokia product. They could license other partners in arrangements similiar to Nokia and completely exit the retail and marketing parts of the business.