matapan

When using a UPS, is it a good idea to plug the UPS into a Filterlinc? This is presuming that the modem is not plugged into the UPS, but the eISY's power supply is.

Out of curiosity, how does one assess the computing requirements for these VM setups? For example, if you're running HASS and Frigate, would one run these in their own separate VM instance? How would you evaluate if the resources were sufficient for running something very CPU intensive like Frigate? Would one be able to throw in a TPU into the mix in such setups?

It seems like the response for existing companies with home automation products will be to produce a bridge that allows existing products made by a vendor to operate with Matter/Thread products. That is what I think most vendors will term their support for Matter/Thread. Another avenue a vendor can take is to just produce native Matter/Thread compliant products. Just go "all in". But this risks becoming a vendor known for making a commodity product indistinguishable from the next Matter/Thread vendor's product. The home automation vendor landscape has companies that make very unique products - Insteon with its dual band technology and formerly large product range. Yolink with the lo-ra technology advertising reliable device to device communication using low power and long range. I'm curious how vendors will try merging their unique technologies into products that support Matter/Thread beyond just employing a bridge type product. Maybe the answer is they won't.

The pros of a walled garden approach is that by limiting the selection of devices to a single vendor, you can contain the support required to help users and keep the costs reasonable. Open the door to the world outside that walled garden is risky for the walled garden vendor if they can't confirm that support for something outside the garden won't be a support nightmare and a major drain on resources. You can't be assured that some inconsistency a user experiences outside the walled garden won't be characterized as a poor reflection on the vendor's product and support. Matter is an alpha level product now and there are no real products on the marketplace that can qualify an answer to the support question. It makes sense for a vendor with limited resources to wait it out and let the bugs shake out before providing any support. Look at Z-Wave and how they kludged scene support in the third iteration of their standard. Three major revisions and it's still a kludge, by design!!! In this particular case, I think Insteon is far superior in the way it supports scenes. Someone who knows a lot about Matter can probably speak to some of this. The reality in the home automation landscape is that the people that get into it like to tinker and desire to mix and match. Perhaps support for this can be managed in a reasonable manner if manufacturers design protocols detailed enough to avoid technical support headaches. But the desire to bring to market inexpensive products in the hopes that you will get a good sales rate on those products can lead to a lot of variation in product quality. If one mixes some of those substandard products in their HA setup, it becomes crap from the average user's perspective. The oft used mantra that "it just works" is violated, much to the consternation of non-technical folks and to the glee of some technical users who I think believe having a working setup has to be earned. Have the time and energy to experiment. If something doesn't work, drop it and find the next product that might work.

Seems like the easiest way to test the hypothesis is to swap out the Switchlinc relay and see how the existing bulbs last. I'd note the revision number of the 2477S and see if you can swap it out with a later revision.

I think the original poster stated they're using a relay switch.

The Ra3 line is very nicely designed. Good design meets proper engineering. The best of all worlds, if you can afford it.

The i3 offering looks very clean and well designed. Something equating to products Apple might have offered if they produced switches and plugs. Nothing on the market I've seen so far looks as clean as this offering, other than maybe those touch sensitive display switches from one of the myriad of Chinese vendors out there. Another reason I personally would hesitate moving away from Insteon is the lack of nicely designed product. So much of what is out there looks amateurish in design. Z-Wave switches in particular are just awful in this respect. Head scratching proportions, supersize indicators that aren't to proper scale. How much does it cost for any of these major companies to hire a proper industrial designer?

While listening to the Insteon webinar about Insteon Technology's latest feature for reporting low battery status in their mobile app, the idea of a feature for checking for communications issues programmatically came to me. Basically, the idea is for the controller software to check communications between each node on a network with other nodes using the link table generated and to report back nodes and specific links that were problematic, communications-wise. I know that the ISY will report failures communicating to a specific node by putting an exclamation point next to the device having issues. It would be nice to be able to provide a little more information that might help someone figure out the root cause of the communcations failure and how to fix it. What do people think? Same idea for reporting devices and which phase they are on. Any way to determine this programmatically?

I don't see how having no concrete plans to support Matter right now can be construed as being left behind. If the support for Matter/Thread is in the form of an updated hub product, I personally think that Insteon Technologies is doing absolutely the right thing now just getting product back in stock, providing support for mobile apps, and just getting back on their feet again. Matter is vaporware and there are no real products on the market currently that would support any demand or focus of precious resources to something like this.

Out of curiosity, what exactly would support for Matter and Thread look like as it relates to Insteon? I'm having a hard time visualizing what this would look like. Would it be support for Matter and Thread in an Insteon Hub? Would existing devices remain the same?

Lutron Caseta has no keypad. They also don't offer outlets. If you don't need those types of modules, Lutron might be good for you. The deal killer for me would be n-way switching. Something Insteon is very good with, and something I use all over my house. Insteon offers a pretty complete range of automation modules. If you have a need for some of those modules, it makes sense to deploy them as Insteon devices. I noticed a very small latency difference between using an Insteon sensor and a Z-Wave sensor. Nothing significant but it's there. When you start mixing and matching products supported through nodes, I'd make sure performance is okay in terms of responsiveness. I'm playing with Wifi/Bluetooth locks with a different sort of aggregator application. It's magical to see it work under one system, but the responsiveness leaves something to be desired.

With respect to weather resistant plug in relays, I would primarily focus on the build and design quality of the modules themselves as to how truly weather resistant they are and how reliable the electronics are. Chances are you are probably going to control something important with those relays and you don't want them to fail. As long as the technology stack you're using to actuate that is pretty solid, I would just make sure that the stuff is solid. After just typing that response, I think the most reliable setup is to use a relay controller that is wired to a network and control it that way. I've never done what I'm proposing next, but have a backup failsafe method for control in case the network goes down. Not sure what that would look like, but it may be as simple as a centralized bank of switches you toggle manually that is easily accessible and clearly labelled for everyone to understand its function. As far as DIY home automation switches are concerned, I am somewhat of a born again Insteon supporter. Having played with X10, then Insteon, then finally Z-Wave after I grew tired of Insteon's shortcomings with product quality and reliability. But the inherent design flaw with Z-Wave with respect to creating scenes killed any interest I had for Z-Wave, which from at least a functional design perspective looks more like a hack job compared to Insteon. I have no energy or funds to really explore Zigbee, and if you go with a completely dual band Insteon setup with newer modules, Insteon works pretty well. If you have the energy to look into Zigbee, that might be a DIY avenue to explore. I'd look at how scenes are created and used with whatever UDI controller you plan on working with and see if the same controller/responder model used for Insteon scenes is supported with Zigbee devices. For me, the feature Insteon offers with n-way switches, where switches that don't control a load can toggle the switch that does is very useful. I kind of thought that competing protocols would provide support for such a great feature, but apparently this is not the case. Of course, with enough $$$, you can avoid all the questions about selecting the right technology stack and not worry about reliability to boot. Lutron is used in high end installations for a good reason. It works and it's reliable. You can't beat that if you can afford it.

I don't know what the cause might be, but I have a guess. A bad power supply for your ISY? Something I would try if I had a situation like this is to replace the power supply with a known good working one and see if that cures the reboot problem. I vaguely remember having some issue with my ISY a long time ago that was cured by replacing the power supply. I think most people at the time suggested the power supply or the memory card as being the culprits.

Thanks for pointing me in the right direction Mr. Bill!

Apologies in advance if this question is answered somewhere in existing documentation or post. I want to keep as much of the primary scripting control within the ISY. To that end, I plan to use the ISY's REST interface to set or get device states in Home Assistant using ISY variables as a placeholder for devices not supported in the ISY that are in HA. That said, what is the mechanism in HA in an automation script for taking the state of a non-ISY supported device and setting the value of a variable representing the state of that device in the ISY? Assuming it's some sort of curl script, how would this be specified in a HA automation script?

Here is the reference: https://wiki.universal-devices.com/index.php?title=ISY_Portal_Amazon_Echo_Integration_V3 Under the heading "Instructions for using Multiple Echos Smart Home": To support multiple Echos with different Smart Home devices, you need multiple ISY Portal sub-accounts with each their own user profile. Have your Echos tied to different amazon accounts In ISY Portal, configure a sub-account and user profile per echo: <etc> <etc> <etc> Is this no longer relevant, as oberkc suggests?

Thanks to all who replied. There is a reference in the wiki page about the need to create separate accounts for each Echo device. Can anyone explain the rationale behind this?

But a poor quality product virtually guarantees a loser, unless you can overlook the negative quality and tolerate it.

I think there's supposed to be a way to say simple references to turn on lights in a room that has an Echo in it without using the long name and unique name we all give to different lights in the house. I did read the wiki article on Amazon Echo integration, which suggests setting up each Echo with different accounts to do this. Isn't there a less complicated way of doing this with groups? If what I'm asking isn't clear, let me provide an example: If there is an Insteon dimmer switch called "Master Bedroom Light", I'd like to be able to say: "Alexa, turn on the lights" in the Master Bedroom, but also be able to say the same thing when I'm in the garage to turn on the lights there, without having to say "Alexa, garage lights on" I have a Alexa group called "Master Bedroom" and another called "Garage", in which "Master Bedroom Light" is in the group "Master Bedroom" and "Garage Lights" is in the group "Garage". There is an Echo in each of these rooms.

You made my point. No such stack exists. The closest thing to an ideal stack is Lutron Radio Ra3. For my investment in Insteon, I can't justify the spend to move to that, and I'm perfectly satisfied with my current install with 95% dual band devices. So why pine for something that's vaporware? New PLM's are coming next year from Insteon. The company offers a repair service for existing units. There's also an eBay seller who repairs PLM's too.

For a developer I can see jumping on board new technology, to check out the possibilities and develop something that couldn't be developed easily or at all using mature technology stacks. But to pine for compatibility with Matter or the next new protocol when no compelling use case exists right now to warrant full bore development with limited resources seems so illogical. Personally, I'd wait for some compelling, realized use cases using Matter to come into existence before I would even think about it. I'm not a developer though so my perspective is really different from their perspective. They want to develop the next big thing, whatever that may be in Home Automation. Personally, I would be looking at some protocol that was ultra-reliable, deterministic and solid, not affected by wireless interference or power line noise, with hardware that is solid and very resistant to real world residential electrical conditions, available from multiple vendors who produce products that are fully compliant with a published standard, that is easy to debug failures with a system when they occured. It would support scenes in the way Insteon models scenes, which is very logical. This along with an easy to use, solid controller hub that could operate locally/independently and on the cloud. Does this protocol exist now? I don't think so. Does Matter support these kind of user functional requirements? Who knows? That's up to developers to figure out. Hopefully not in the same way they figured out what a hack Z-Wave is.

I truly think it's comical reading these posts about the desire for simplicity and looking towards a new, unqualified protocol for salvation. How on earth would anyone want to jump on the bandwagon of a protocol for which there are no road tested, released products that have been widely adopted, where most of the user scenarios people expect to work have been deemed by the masses to be stable and usable? I honestly think some people are glutton for punishment in somehow thinking the latest is the greatest. The race to the bleeding edge is solely the domain of true coders and designers that like to tinker and expect to fail often.

If you have a multimeter, you can check the output of the power supply you have. I believe tip is positive and the ring is negative. I believe the power supply from UDI is 12 volts, 1 amp. If you find a similar power supply with a plug that has the correct polarity that fits in your controller's power plug it should work.

Out of curiosity, I checked out the eBay listing for the refurbishing service. The seller has different grades of service offered, from the basic electrolytic capacitor replacement to "the works", where additional components are replaced, working or not. The listing begs the question: Does a component upgrade make the PLM a reliable unit for say, 10 years? 25 years? Or does the design need to be revamped to ensure long module life? I figured from reading past comments about the capacitor replacement that this is a maintenance thing; you replace the caps every 3-5 years to keep it going. Is this the case? Electronic design and repair is above my pay grade apart from the manual labor involved.