sorka Posted February 1, 2014 Posted February 1, 2014 I bought some nifty 100 watt LED flood lights. They are *very* bright. However, I have noticed that my ISY fails to communicate with the switchlincs they are plugged into about 20% of the time when turning off. They are 100% fine when moving from off to on state. I recently installed a new dual mode PLM which made no difference. I also recently replaced the switchlincs these LEDs are on with the newer dual mode versions. Still no difference. I have about 70 insteon devices in my house. About 25% of them are dual mode. I also have 6 APs. The 3 switch lincs these 4 LED floods are on are the only comm failures and only when going from on to off. I never get failures anywhere else. So I'm concluding that the power supplies for the LEDs, which are quite large, are somehow sucking the signal when on. But can that happen on the load side? Shouldn't the switchlincs have their own filter to prevent what they're powering from sucking signal? What's the solution? The LEDs are hardwired, so I can't just add filterlincs on them. Is there an inline filterlinc product that would do it? Is that even my solution assuming that the LED power supplies are indeed the problem? I have filterlincs on anything else in the house that might suck signal which means I have a dozen plus. i.e. one on any UPS and one on any large appliance or home theater receiver with a big power supply. Also, is there a way to get the ISY to retry? I know this is built into the insteon standard, but couldn't the ISY try the whole thing all over again? When comm does fail, a dialog box pops up telling me so and I simply manually click the switch on the screen to turn it off and it works. Why can't the ISY do this for me when insteon has reached it's max retries?
sorka Posted February 1, 2014 Author Posted February 1, 2014 I thought the dual mode might help alleviate the issue but it didn't. I put an AP on a different circuit but within 6 feet of one of the switchlincs so that it was close but not on the same circuit. This still made difference. If the switchlinc received the command over RF, the powerline signal strength wouldn't even be an issue here, so if the LED power supply is causing an issue, it must be interfering directly with the circuitry of the switchlinc.
LeeG Posted February 1, 2014 Posted February 1, 2014 The inability to turn a load Off is not uncommon. There are inline filters that can go between the Insteon device and the load. I'm not familiar with the actual filter, there are references on this forum and the Smarthome forum. There is a "is/is not Responding" condition that can be checked and the Set 'xxxx' Off issued again. EDIT: this link discusses inline filters viewtopic.php?f=28&t=10903&p=83208&hilit=inline+filter#p83208
ELA Posted February 1, 2014 Posted February 1, 2014 Hello Sorka, Your LED power supply most certainly can be a "signal sucker". It is also possible that it could generate noise. As LeeG said inability to turn off certain loads is a common issue. I have one LED power supply that is a large signal sucker and another that is not. "filters" are best when the issue is a noise generator or for convenience of installation, using a filterlinc. When the issue is known to be a signal sucker then an "isolator" may be a better choice. I recently installed a new garage door opener that is a major signal sucker. Knowing that signal attenuation was the issue, as opposed to noise, I chose to install just the inductor of a ZNF10A filter set. This provides more of an "isolator" than a filter function. In fact it is a much better isolator than a filterlinc. Installing is a bit of effort but worth it in the end. Here is a picture of the "Inductor only" installed in a small box ( ignore the surge suppressor (with EMI filter cap. removed) .
Brian H Posted February 1, 2014 Posted February 1, 2014 ELA; Looks like a good solution for some problems. The wired in ZNF10A-W is the one you used? As I see they also make a ZNF10A-P Plug in version.
ELA Posted February 1, 2014 Posted February 1, 2014 Hi Brian, Yes I used the inductor from the wired in kit. The garage door opener has a large capacitor at its input which makes it such a larger signal sucker. For that reason there was no reason to add another capacitor. This inductor then presents approximately 1/5 as much of a load to the Insteon signal as a Filterlinc does.
sorka Posted February 2, 2014 Author Posted February 2, 2014 The inability to turn a load Off is not uncommon. There are inline filters that can go between the Insteon device and the load. I'm not familiar with the actual filter, there are references on this forum and the Smarthome forum. There is a "is/is not Responding" condition that can be checked and the Set 'xxxx' Off issued again. EDIT: this link discusses inline filters viewtopic.php?f=28&t=10903&p=83208&hilit=inline+filter#p83208 Is this a setting somewhere in the ISY or a setup command that has to be issued to the insteon modules themselves? I couldn't find anything in the ISY on such a setting.
LeeG Posted February 2, 2014 Posted February 2, 2014 It is an option available in an ISY Program If section. It allows a check for 'is not responding' for example and take whatever action you want to take. If Status 'SwitchLinc Relay' is not Responding Then
IndyMike Posted February 2, 2014 Posted February 2, 2014 Also, is there a way to get the ISY to retry? I know this is built into the insteon standard, but couldn't the ISY try the whole thing all over again? When comm does fail, a dialog box pops up telling me so and I simply manually click the switch on the screen to turn it off and it works. Why can't the ISY do this for me when insteon has reached it's max retries? Sorka, The ISY will retry direct commands (default is 2X). The number of retries can be set using the ISY shell "CR command":http://wiki.universal-devices.com/index.php?title=ISY-99i/ISY-26_INSTEON:Advanced_Configuration_Guide I do not believe the ISY will retry scene commands - it does not request status from the scene devices.
Recommended Posts
Archived
This topic is now archived and is closed to further replies.