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.

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?

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.

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.

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.

FWIW, I sent a comment to the new Insteon company about product quality and the longevity of the PLM in particular. Steve Lee responded back, who mentioned that the PLM quality has improved significantly over past several years, to the point where the Insteon company has a negligable return rate on the devices. I did stress the importance of product reliability and stability in terms of a product line's reputation in the email thread.

Instead of using a single motion sensor, you can use two for attempting to detect detection. The sequence of motion sensor triggers will provide the direction one is walking. I say "attempting" because in real life, people walk back and forth before the sensor times out for detecting the next event. You can set each motion sensor to have a short timeout cycle to address this.

I'm not in the same boat as you are. I am still using an ISY994i with a Z-Wave board. But I had a communication issue with one device and nearby devices would also not operate correctly when toggled off. The solution for me was to delete the device having communication errors and then add it back as a new device. This cleared the problems. The options to repair links or to update them were useless. It might be worth a try to delete one of the devices that you lose and add it back to see if it sticks around.

I was able to address the issue with odd behavior in the Admin UI with respect to the state reporting of Z-Wave devices recently added to my setup. The Admin UI was not correctly displaying the state information from one of two Aeotec Trisensors I added. One of the sensors would toggle on a motion sensing flag then toggle the flag off after the timeout period was reached with no additional motion sensed. The other sensor would toggle on like the first one on motion detection but would fail to toggle off on timeout. At the same time I was having this issue, one of my Z-Wave devices kept reporting communication errors. The option to repair links or update neighbors didn't do anything to resolve the communication errors. So I deleted and added the device back, then restored any links or references in programs that were broken when the device was deleted. This cured the communication error, and also corrected the state information reported in the Admin UI. For whatever reason, UDI Mobile was reporting the correct state information from both Trisensors. FWIW, this is what I found as a solution. If you have Z-Wave devices and get communication errors, don't ignore them - other devices in your Z-Wave network may be impacted if you leave the error(s) unresolved.

I have an ISY994i with version 5.3.4 firmware. I have the Z-Wave Plus board installed in the controller.

Thank you for this reference!

I recently added several more Z-Wave devices to my setup and ran across some interesting behaviors. The two Aeotec Trisensors I added behaved differently from each other if the Admin UI is assumed to be accurate with respect to device state. On motion detection, each sensor changes its motion state from off to on. Upon reaching the timeout period, only one sensor reverts back to an off state for its motion state. The other sensor remains in an On state with respect to motion detection. All of this was reported in the Admin UI. I tried modifying the parameter of the motion sensor, but upon choosing (Write Changes), the Admin UI returned a communication error for the sensor. I assumed this was due to the proximity of the sensor from nearby Z-Wave devices. For a completely different reason, I installed UD Mobile on my phone. I looked at the device state for the motion sensors and noticed that both motion sensing states were now off. I triggered each of the sensors and waited for the timeout period to be reached. In the mobile app, both sensors reverted back to an off state after the timeout period was reached. There were no communication errors. What can account for the difference in reporting from the Admin UI and UD Mobile? Why am I getting communication errors in the Admin UI with these devices but not in the mobile app?

thanks, but I still get a 404 error after modifying the url