apostolakisl

I suppose it would be identical to current node servers. The difference would not be in the node server, but rather the route to the device.

Sorry, I mis-read. Thought you said "bulb".

It would be rather discombobulated to control some Insteon devices using one protocol and others using a different one. For this to work, you would have to have something like an ISY as your gateway. If you were an Insteon user, having Matter on some devices and not others without an ISY or similar would mean controlling some of the devices using a Matter controller and some using an Insteon controller. Unless the Insteon Matter devices themselves acted as gateways for all the non-Matter Insteon devices.

Not sure how that would work if some of your Insteon stuff integrates to Matter and some doesn't. Seems like the best way to handle this would be what I said about making the entire Insteon network a single Matter IP address via a Matter enabled hub/plm/whatever you want to call it.

They only need to make a single device Matter, likely the hub, then the whole thing is Matter. Every single Insteon device would be a target within the single Matter IP address. The packet content is undefined as I understand, so you could have essentially an infinite number of nodes within the single Matter endpoint. So, it would just be the Matter formatted IP address, and the content would probably be the exact current Insteon language. This should work the same for z-wave.

I fear you may be correct. My main hopes for this protocol would be 1) encrypted. I think for sure this is handled. 2) A local and open API. If you are going to join the Matter framework, then it seems like publishing a detailed api and supporting it would be part of the deal. Node server creators often are struggling to reverse engineer it or are dealing with talking to web based server that might simply not be accessible. 3) Everyone joins it. If everyone doesn't join it, then it just complicates things as one more protocol to support. With seemingly all the big guns pledging support, this might just catch on. I really don't see any issues for current protocols to join it. Insteon and Zwave can easily join it by just adding a Matter enabled device into the mix. It could be a hub, or just any device that "hops" the message to the Matter IP framework. Could just be adding a new light switch that has Matter on it. You have to be of the mindset that your entire Insteon or Zwave network is a single Matter end point, not each device. Since the message content in Matter appears to be unrestricted, I see no reason this could not be the case.

1) This is academic. The user doesn't know, doesn't need to. It will probably make the back-end easier, so it really is about simplifying integration for the manufacturer, not about improving the user experience. The user interface can be made to work ~ identical regardless of what protocol you are connecting to. I can't imagine that connecting a matter device will be any different than an Insteon device. I'm sure you will click an "add device" button on your Matter User interface, then click a button on the device itself. Then you will need to label it, categorize it and link it to whatever devices you want it to work in concert with. 2) And this effectively makes it another PLM or Z-wave module, a module that every device that uses Matter will have. It really comes down to trying to get everyone on the same system so you only need 1 "dongle". Z-wave and Insteon protocol both have their short-comings, and perhaps Matter will not have any. We shall see, but not having any short-comings is unlikely. EDIT: Just recalling some of the comments Michel made when they were looking into acquiring Insteon assets. One of the main things was "can Insteon protocol implement encryption". In my opinion, this is really the issue with Insteon. Otherwise, it checks all the boxes. Low power, simple, latency less than human threshold of notice, excellent range/penetration. It does suffer from power line noise but I am convinced that some minimal engineering where power line signal is decoupled from radio signal would fix that. I suspect that encryption is not in the cards for Insteon. I dont' know how z-wave could ever be fixed regarding the popcorn affect. After trying a few z-wave devices, I uninstalled them. I would use z-wave, perhaps for things where a secure protocol is needed and synchronization isn't an issue, like a door lock. But my house has fancy door locks that can't be replaced. I use Elk to control anything secure and was in a position to hardwire all those things during construction. IN SUMMARY: I hope that Matter does take off. Reason is that it will force the hand of most companies into published "API". I put API in quotes because I suspect it won't be considered an API over the Matter protocol. But the biggest issue I hear from node server development is that they get no support from the manufacturer re API and thus have to do a lot of reverse engineering and sometimes just can't get things to work.

I have had to re-connect my UD to Google too many times to count. To me, this is a failure. It may be on Google, it maybe on UD, I don't know. But if I were a professional installing this at a customers house, they would not be happy, nor would I. I don't really have issues with my thermostat in the middle of the night. I occasionally need to go to the bathroom, maybe I can ask Alexa to do that for me? And I'm not blaming UD for Google issues. It is on Google. I have no way of stopping my phone from trying to do something I want my google home to do or vice versa. I can't tell my phone to make a phone call because my google home will invariably try to make the call instead. I have just given up on it. Same with Alexa.

It seems to me that UD already has all of this handled. The have nodes that work with anybody who has an API and someone willing to write a node for it. They have standard definitions for various node parameters (like on or off) and then an ability to add however many unique node definitions for the odd ball device that does something no one ever thought of. The only place I find that UDI comes up short is integration with google and Amazon. But the whole yelling at my google home or Amazaon Alexa kind of lost its appeal a long time ago. The "ok google" or "Alexa" thing just doesn't work. I have my phone, my google home, my wife's phone, my kids phone, etc. Seems like every time I say "ok google" either none of them or all of them respond, either way it screws up. I find myself whispering "ok google" into the microphone of my phone to get my phone only to respond, then my phone doesn't respond and my google home that is 50 feet away somehow hears me and responds, but then doesn't hear me when I tell it what I want. OK google is good for one thing, setting a timer for whatever you just put in the oven. Alexa is good for the shipping list. I love my Harmony Hub with its ISY node server, I don't have to look at it, I don't have to worry about background noise, I just push a button that my finger knows well and it does what I have programmed the button to do, and it does it instantly, and without any need for confirmation. It is way faster than I could ever speak a command and it works every time, no worries about my screaming kids messing it up. I don't get any popcorn affect, it just happens as if the button in my hand was a hardwired light switch, or tv power button, or whatever. And all the stuff I just want to happen at a certain time or when I open a door or a window, or whatever, it just happens as programmed. For the life of me, I can't figure out what any of this matter is going to do better than I already have. Until I can say "ok google: rub my feet, bring me a beer, clean the house, and do my laundry", and have it actually do those things, I won't be any better off than I am right now.

So, I think I get it. But some of this is just academic. The fact that thread uses IP means that there need be no "hub". But you still have to have a "border router" to connect it to the traditional wifi/ethernet IP backbone or your phone/tablet/pc will never know it is there. So some products will have a border router built-in. Basically, this is a hub built into a product that also does something else. And what if you have multiple devices with built-in border routers? Must you designate one to do the job, or will you get multiple devices all trying to relay the same message from thread to wifi/ethernet? Functionally, I see no difference between a device (like say an Echo) with a built-in edge router and having a PolISY or Eisy with a built-in PLM. The main difference would be that each device is its own IP labeled target vs the entire system of pieces (light switches on your ISY) being a single IP target with the content of the message defining the individual device rather than the IP label. But the end-user should be oblivious to this. Assuming UD adds some of the final pieces to the phone app, adding an Insteon device would, for example, involve opening the app, clicking add device, then clicking the button on the device. As far as I can tell, with Matter/Thread, you would do the exact same thing using a Matter phone app. It just keeps coming back to me seeing only one real difference, and that is that Insteon mesh is not encrypted. Otherwise, the whole thing is all about the quality of the phone app. So, who is it that writes the phone app for Matter? Will there be lots of competing apps where each app is completely under the control of that developer? Will there be a generic Matter backbone app that each device manufacturer creates a plug-in with the specifics of their device? It could get very messy. Like if you have a bunch of lights all from different companies but you want to control them all with a single button. I know how ISY/UDI handles that, but how will Matter handle it?

I do believe it will use standard wired/wireless IP as well as this thread technology. Otherwise nothing that is already out there could use it since the "thread" radio would not be there, plus, somewhere, I read that. Kind of sounds a lot like Insteon with their low power limited data mesh network, along with a hub (plm + ISY + Node server) all controlled from the ISY phone app now doesn't it? Basically, if Insteon protocol were to be open sourced, and the PLM/ISY/Node server where all packaged into a single box, then it would pretty much be the same thing. EDIT: It did occur to me, however, that Insteon protocol doesn't have any security, and I am pretty sure that "thread" does. So that would be a significant difference. While I really don't think anyone would ever bother to hack my Insteon network just so they could turn lights on/off, if I had more important things on that network, I would want security.

I appreciate your tongue in cheek response. As I continue to look at this, I can see that if the format is truly embraced by the manufacturers, they would then use the Matter framework as the sole app to control their device. A universal GUI if you will. Matter would sort-of work like an OS where companies write their own "apps", or plug-ins that work inside the Matter framework. The Matter framework could make this look seamless to the end user, as if all the various manufacturers come together in a single GUI that seems like it is all from one company. All of this of course would be quite analogous to what UDI is doing with node servers and their app. UDI just doesn't have the clout and financial backing to drive their product to the fore-front.

Well I can say this. The name "matter" is just a terrible name. You should never name something using a word that already means something totally different, especially something as bland as matter. And then it confounds doing searches on it. Yes, you can google "matter home automation", but still, for God's sake, just have some imagination and make up a new word. "Matter", come one, how freakin boring. The drug companies have this one figured out. If you ever need a good family dinner entertainment game, play "what's that drug" where each person makes up a name for a drug and the other people have to figure out what the drug theoretically does.

I'm pretty vague on how this matter thing works or makes things better. It sounds like it is an API standardizing protocol? Everything I read just says it will make things talk to each other using IP. That sounds a whole lot like API's to me. If it works over IP, what does the board do?

Just listened to it. Starts at the 44 minute mark. Nothing terribly interesting, except perhaps that they are looking into making Insteon connect to Matter. As I understand, Matter connectivity would be in the Hub, or I would assume it is something that UDI could implement into ISY. Of course ISY with node servers would seem to be its own Matter framework. Matter would seem to have nothing to do with the individual Insteon devices which would continue to talk to each other and a hub as per current framework. There was no mention of the Nokia designed devices and really nothing even about manufacturing of any devices except they are working on it. Ken reported that suppliers haven't been paid (big surprise), no mention as to whether the suppliers haven't been paid for products delivered or if they have shipping containers of built devices ready to go upon payment. My guess is probably some of both, but mostly the former.

Interesting. Never pealed the sticker off, just assumed it was hard coded, especially since they don't offer firmware updates.

Re: the $17b Samsung plant outside of Austin. . .from Samsung: "The manufacturing facility is slated to be fully-operational by the end of 2025."

Good news is that there are 10's of billions of dollars in new chip fabs in the works for the US. I believe the $17b Samsung fab in Austin is already underway and Samsung has declared that they would like spend more than $100b in new chip fabs in Texas. That is just Samsung. So perhaps in 2 or 3 years . . .

Could just be an announcement of a deal. Not that the chips are ready to go. Also, could be that the chip/part shortage was not the proprietary Insteon chip. We shall see.

Does this mean the new Insteon owners are selling/licensing the PLM chip to UD for the UD PLM?

Aha! I was just trying to figure this out and here it is. Thanks.

My personal experience is that an air compressor makes it very easy to remove components without damaging anything. I tape off the board with painters tape, then melt the solder with my iron and hit it with a pop from my air compressor and the solder goes flying leaving a perfectly clean hole with the wire lead loosely sitting in the hole. Super fast and easy. Just be aware of where the solder is flying so you don't short out something elsewhere on the board. Angle the air compressor gun such that your solder flies off onto the tape. If you do get some over spray on the board, it easily is removed with a fingernail or wooden q-tip handle. The solder spray will not bond when it lands, but certainly could create a short. though I have never had a short happen. I have replaced quite a number of capacitors on Insteon devices over the years and can repair an entire unit it just a couple minutes start to finish. Also, leave the wire leads long on the new ones until after soldered in. Once soldered in, I just bend it around a few times and it snaps off right at the edge of the solder.

"Recertified" is unlikely to mean that anything was done but testing. The PLM's are easily opened and inspected. There is a good chance you will be able to tell if it was recapped, even if the soldering was done by a pro as there will be subtle differences. Also, some of the recommended replacement caps don't fit in the orientation originally designed. If I were you, I would go ahead and buy a new set of caps for it now. You might decide to just let well enough alone until it fails, but seeing as failures like this always happen at the most inconvenient time, you might just recap it now.

You can factory reset the PLM and you won't lose anything. ISY has a "restore plm" command which will write all the links to a blank plm. I do believe your plm is quite old. Has it been recapped? PLM's from that vintage are like clocks. At exactly 2 years of being powered on, they die. The issue is bad capacitors which most people diy repair.

I have the Leviton units as well. I did have a lightening strike fry my well pump, but I suspect that surge did not go through the electric panel but rather directly through the Earth to the pump. Nothing else on that circuit was damaged and the pump is 3 phase. There is a single phase to 3 phase variable frequency drive controller that converts the single phase to 3 phase. So the pump motor doesn't see line voltage at all.