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.