upstatemike

Years ago when I moved to ISY from another system I recall it using existing links in the first few devices I added to identify and add those additional linked devices. Does that no longer work? I think I got at least half of my devices moved that way.

For your application I would consider Yolink LoRa devices before resorting to Z-Wave.

I wish the M1 had more output options. I have some areas where I want to hear all chime announcements during the day and others where I want to Disable Non-Alarm voice messages 24/7.

All On and All Off cannot be programmed as far as I know. They simply act on all of the devices linked to the RemotLinc. I don't use dim and bright much but I assume they act on the devices associated with the last button you pressed on the RemoteLinc. I'll give it a try and confirm that this evening.

Are you asking if he did a double blind test?

I just got a reminder that my trial will expire tomorrow and that I need to purchase the Elk PG3 Node server. I went through the purchase process and got a reminder that after the purchase I need to reinstall with the paid version. I hit install and selected "install into the same slot" and everything seemed to go OK except when the Node Server restarted I got a bunch of messages saying it could not start because configuration was not complete. I looked at the configuration and sure enough all the fields were blank and I had to scramble to find all that info again since nothing had warned me that it would be erased so I did not jot it down before installing the paid version. My questions are: Did I do something wrong that caused me to lose the configuration when moving to the paid version? If not, isn't there a way to make the transition to paid Node Servers preserve the configuration? If not, couldn't a warning popup be put into the upgrade process to let you know you need to write down your configuration information and add it back after the licensing is finished? I think I got the right info back into configuration but now I have to do some testing to be sure since I seem to recall there were quirks about my settings to get it working before. Was not expecting to have to do this.

Why? It's not like Google has a history of abandoning things and just walking away from them or anything. I wonder if they will add Matter to the Google Home Max? (You can contact me on Google Hangouts if you want to discuss further)

I'm not saying there is no need to use Insteon with Matter. I am saying there is no need to translate Insteon devices so they appear and communicate as Matter devices in order for them to work together. You can let each device speak its native protocol and still do what you want at the Controller.

OK then to restate the OP's original question I guess the ask is "Will folks who rely on Alexa as their primary automation platform be able to use Polisy as a way to talk locally to Insteon devices using Matter?" But even from the perspective of a consumer who is not deep into automation like us it still confuses me some: If you do not want to use Polisy for automation because you are an "Alexa Consumer" why would want to buy and learn one just to expose Insteon devices as Matter devices? If you are using Polisy (or Homeseer, or Home Assistant, etc.) then why do you need devices to be tralated to Matter since these platforms will communicate with Insteon and other non-Matter devices using their native protocol? If you are starting fresh and want to use Matter/Thread exclusively with Alexa etc. then there is no need to expose Insteon as devices as Matter devices. I'm just struggling to identify a use case for publishing Insteon devices as Matter devices. There is no combination of platorm and user type that would utilize that functionality.

OK so Polisy would just do translation and the event engine used for actually automating the devices will reside in some native Matter Controller someplace else. Ignoring cloud based platforms such as Alexa, have any native Matter local controller platforms with robust event engines been announced yet? Everybody talks about Matter being the universal standard for communication between devices but the logic to control those devices has to reside someplace.

So I understand all of the above but don't see how it relates to Insteon any differently than any other protocol or standard. If you substitute Lutron RadioRA3 for Matter would you ask the same question? "Can Polisy expose Insteon (via PLM) lighting as Radio RA3 devices?" What would that even mean? Is the question whether Insteon devices connected via Polisy + ZMatter will automatically appear in some Matter Controller as Matter devices? In other words Is Polisy publishing Insteon devices as Matter devices on a Matter network? If so then I just wasn't understanding the question correctly.

Stargate is the most reliable piece of automation hardware ever made... I would not want change that by adding Matter to it. (Stargate is the thing that monitors my other platforms and tells me when they screw up) I'm just struggling with the terminology in this thread. What is difference between having Polisy provide interoperability between different protocols like Insteon and Matter/Thread (basically what we have now) and having it "Expose Insteon devices as Matter devices"? Insteon modules are never going to respond to Matter commands directly because there is no Matter spec to run on PLC or the RF protocol Insteon uses so it will always be a translation via Polisy. I guess you can call Polisy an Edge Router if it makes you feel better but beyond that I don't understand what is being requested here?

Still confused about what Matter will do for me. If a Zigbee device and an Insteon device are connected to Polisy then they can interact with each other. If the Zigbee device adds Matter and Polisy is upgraded to support Matter then the Zigbee/Matter device can interact with the Insteon device... just the same as before Matter was added to the equation. I guess I need an example of the specific use case where Matter will let me do something that I could not do before.

I keep an X-10 plug-in controller around for this kind of testing. Cheap and takes the ISY out of the equation so you can easily do pure signal testing isolated from any PLM issues.

Also not using thermostats with Elk.

OK, down from 399 nodes to 176. Much more manageable, thanks!

So if I delete them from Elk to keep them from coming back do I also need to delete them from the Nodes tab to actually get rid of them? Or do I uninstall and reinstall the Node server after they are cleared out of the Elk?

Actually these entries look like they were imported from the ISY994. Don't know when or why I would have done that... maybe to use Insteon lights in Elk rules? Still I don't need them in the Node Server so need to delete them one way or another.

I don't know why this topic submitted twice or why it is asking me which answer was most helpful when it is a new topic that nobody has relied to. Gremlins?

I just installed a trial of the Elk PG3 Node server and ended up with 399 Nodes. Investigating in ElkRP I see that I had 239 lighting devices defined from the old X10 days that I forgot were there. Instead of deleting them one by one on the Nodes tab of the Node Server I was thinking of unchecking "show" for each light in Elk RP and then uninstalling and re-installing the Node Server. Will this work to prevent them from being added? Can I install a second time under the free trial since I did not consume the 30 days?

So here is another way of looking at it. The other day I was watching a YouTube video of somebody who did an elaborate Halloween light show in their yard that included dozens of drones with coloer changinging LEDs forming giant figures in the sky. The control of all of these drones requires precise communication to move each one where they need to be for each scene as well as have all the lights on them work in perfect unison for color and on/off timing. I would like to know what RF protocol is used to accomplish this and why I can't have switches that use that protocol instead of ones that can't even turn on a group of four lights without popcorn effect delays?

Unfortunately that is the situation we find ourselves in. Hopefully something will change for the better but you can't make a safe investment in the future based on anything we know today. And yes my house is pretty dumb... except for my Stargate which still keeps rocking along.

Question has been asked to death with no clear answer. I would suggest the following guidelines: Do not switch to something based on future promises that may be delivered much later than forecast, if ever, or might deliver basic function with a promise of future features that never happen. (Matter, Zigbee 3.0, Z-Wave LR, etc.) Do not switch to anything that does not, or does not "yet", have an open API for local control: (Lutron RA3, Yolink LoRa, Control4, etc.) Do not switch to anything that has a cloud dependency (Most Wi-Fi,) Do not switch to anything that assigns IP addresses to IoT endpoints (Unless you are running a Layer 3 core switch in your house) Do not switch to anything that has known problems that have persisted a long time with no resolution such as the Z-Wave popcorn effect (If it hasn't been fixed in all these years it likely never will) And most important do not switch to anything that does not have drop in equivalents for your existing Insteon devices such as hybrid keypad/switches, wire-in fixture modeules, etc.

OK but I am also struggling to get Homeseer to talk to IoP and I think it defaults to 80 with no option to adjust it on that side. EDIT: You were right about 8080 getting rid of the red banner. Thanks! Now I just need to get Homeseer connected and figure out how to kill these ghost nodes in P3

Did you get this working? Did you have to change the port on the configuration page of the homeseer plugin?