schda12

Techman, My replacement power supply is a Magnitude 40-watt 12-volt DC E-series Recognized (https://magnitudeinc.com/wp-content/uploads/2023/07/E-Series-Recognized-Spec-Sheet-REV003.pdf). This has a small physical size to fit in an existing ceiling recessed lamp enclosure. The load is 3 9-watt MR16 12V AC/DC lamps. The total load of 27 watts would exceed the next-smaller 20-watt power supply. Previously I had a LightTech 151 R (probably this: https://ballastshop.com/let-151-lightech-ge66598-transformer-150w-12v/). That was a transformer to 12VAC relying on the rectifiers in each lamp. Although that capacity was way more than the load, the reduction in flicker with the new driver was less than I hoped. Apparently the design of the Leviton dimmer allows more of the Insteon interference to pass through than the Insteon device I replaced. I don't recall a flicker issue with the Insteon dimmer. The Leviton dimmer has an integrated timer. The Insteon dimmer was never part of a scene. I don't see flickering in a circuit with the same Leviton dimmer and a physically larger Magnitude LED driver (https://magnitudeinc.com/wp-content/uploads/2022/08/Lindrive-Spec-Sheet-REV010-1.pdf). I think that one is also 40 watts but not easily accessible. The load is larger (4 lamps instead of 3). Typical dimming level is for the flicking lamps is 35%. There is slightly less flickering when set at 100%. Might a resistor in series with the 12-volt circuit help in this case? If so, what size would you recommend? Thanks, David

Due to PLM communication issues, I swapped out three Insteon dimmers used with time-based programs but not scenes. The dimmer replacements were Leviton 26HD, which have basic device-level timing control such as on at 35% dimming 30 minutes before sunset. One of the the three introduced sensitivity to Insteon powerline signals (flickering) while the two others did not. That probably means the LED power supply for the one with the issue is more sensitive. Is there a type of filter that blocks Insteaon signals without absorbing them and thereby impacting the Insteon network? Based on comments in this forum, a simple EMI filter like Qualtek 851 (https://www.digikey.com/en/products/detail/qualtek/851-05%2F006/739530) seems likely to absorb Insteon signals instead of just blocking them to the LED driver. An alternative LED driver may be the simplest solution. Thanks for your thoughts.

Thanks for all your suggestions. I'll pursue once I get the remaining new Leviton devices installed.

Thanks again IndyMike, The Leviton products I purchased (D215S and D26HD) use bluetooth to setup and Wifi for control from the app. Since they store time-related programs in each device, there is no communication needed to execute the time-based programs. There are no scenes involved, which is why the partial converstion from Insteon was practical. I don't know what protocol they use for scenes. There is no equivalent of the Instean 6-button control for both scenes and a load. Until that is offered, migrating the rest from Insteon seems pointless. So far, I am impressed with the Leviton products. They are far more consumer-oriented than Insteon. I agree but it was workable. Changing scenes is infrequent. Eisy makes that part easier because the wifi is onboard. With the old ISY, I'm fairly sure I enabled the new PLM with all the old devices. It took a while from different places. Since I was able to get the Eisy to control devices at least some of the time, does that not mean the new PLM was connected to the devices at the time communication was successful? During the demise of the old PLM it may have added some phantom data that was preserved during backup and restore. Perhaps that is having some lingering impact, even if it does not explain all the communication issues. Is there a procedure for removing suspect links and other data which is reasonable to attempt? I forgot to mention that the Insteon device and the receptacle for the PLM were on the same breaker/circuit during that testing. Because PLM communication used to be reliable for the time-oriented programs, I doubt if the pattern of interference changed during the transition to the new PLM when used at the original location. I wonder if the new PLM is more cautious than the old one about stepping on other transmissions.

IndyMike, Thanks for your help. I think you missed the essence of my situation as refined through Brian H. Let me summarize. 1. Before my PLM failed, I had adequate but imperfect communication using ISY. The simple programs to turn on/off 5 circuits at various times worked reliably. That was my only dependence on reliability from the PLM / ISY. When changing some Insteon scenes I had to move the ISY and PLM. This was annoying but infrequent. Presumably my issue was noise. I did not try to identify or mitigate that noise. 2. With the new/replacement PLM there was no reliability from either the old location or any other I attempted. The timer programs performed so unreliably as to be useless. Due to the age of the ISY, UD and Insteon were unwilling to help. 3. I upgraded to a new Eisy and the PLM issues remained unchanged. 4. The example I described at the top of this thread seemed like a noteworthy type of PLM failure because: a. The PLM was adjacent to an Insteon device. Even with severe power line communication noise, I would expect reliable RF communication. b. The Insteon device responds reliably to scenes initiated from Insteon controllers much farther than the PLM, including at the same time the PLM is failing. c. The PLM alternated between successful and failed query with that Insteon device. The pattern of success and failure may or may not be related to what equipment is running at the time. I was initiating a device query and not attempting a scene or all-device query. I did observe the three attempts from Eisy. I confirmed that the Eisy status for the PLM was OK. 5. Since the pain point is the time-based programs, I plan to migrate from Insteon to Leviton for those circuits. Fortunately they do not particulate in Insteon scenes. Nevertheless, it would be helpful to restore the level of PLM reliability I used to have. 6. If there is evidence of that the PLM itself is the problem, I would like to try to get a replacement from Insteon. Thanks, David

Thanks Brian. Since newer PLM's are not supposed to perform far worse than older ones, does that mean I have a bad PLM or might there be other factors accounting for a substantial drop in reliability for me?

I got this impression from the following: This above is an old post. It includes "2) We know that the current PLMs (starting with Firm52) only put out about 75% of the signal that the previous PLMs did. I tested both the Firm52 and Firm58 beta PLMs, and the results were about the same for both of them." My experience replacing an old PLM (not sure how old or which one) with a new 2413S was a dramatic reduction in communication reliability. This reinforced my suspicion that my experience was caused by a product quality reduction. Why else would the same set of interference issues trigger a substantial reduction in PLM communication reliability?

I have read that newer PLM's are much more sensitive to electrical noise and their signal is much weaker than the old ones. I've been trying various locations with my new Eisy and PLM (2413S). I am surprised that the PLM typically failed to communicate with a Switchlink Dimmer (2477D) when the PLM is plugged into a receptacle in the same (plastic) electrical box and circuit as the switch. The Eisy event viewer shows three INST-TX-I1 requests with no responses. At the same time the switch responds as usual to the scene requests from a 6-button controller across the room. The interference pattern changes mysteriously and the query works along with on and off requests from Eisy. Possible intermittent noise sources are an Aprilaire Steam Generator on a different circuit about 10 feet away and a geothermal heat pump also about 10 feet away. Sometimes it seems to help to add an extension cord to the PLM to keep it away from the tiny Eisy power supply in the same receptacle. It also fails that way. Am I describing a typical PLM failure or an extreme one that suggests a bad PLM? Do other electrical devices often block both the powerline signals and the RF signals? Are there additional diagnostic steps that might reveal something useful? Thanks, David

Thanks Brian and Techman for helping me start my education.

I just migrated to Eisy with a new PLM. The migration is a partial success. My Insteon network continues to function independently without known damage from the migration. There are no nodes other than Insteon. I need to improve my knowledge of Eisy and Insteon. My programs with time-based events (e.g. select lights on at dusk) suffer from a non-ideal PLM location (including the old ISY/PLM location). Eisy is not communicating with some Insteon devices but that does not matter until I need to change their configuration in the network. With ISY I had to search for a temporary PLM location when making some network configuration changes. Thanks to those who helped me understand the importance of attempting this migration. I'm suspicious that I have carried over some unwanted garbage from my ISY backup. For example, I get empty message pop-ups reporting a communication error but not device/node ID). Is there comprehensive documentation for Eisy anywhere? The Wiki (https://wiki.universal-devices.com/Eisy:User_Guide) is bare-bones at best. For example, what is the purpose and behavior of "Refresh Device Status" in the file menu? I appreciate the challenge and expense of providing excellent technical documentation. I’m not trying to complain about the limitations of the Universal Devices budget. How can I learn about the Insteon communications protocol and how it interacts with Eisy and the PLM? That would help me diagnose issues and answer questions like: Why is there a PLM links table and a Device Links table? What is the command / acknowledge protocol? Why are frequent Time messages sent when (as far as I know) Insteon devices don't know anything about time? Why does EISY try to establish contact with many (all?) nodes/devices each time it restarts even though Insteon seems designed to function independently from a central controller like EISY (as my Insteon network usually does)? How do I determine the optimal location for EISY and the PLM? Why is EISY so dependent on perfect (or at least good) Insteon communication with every Insteon node instead of providing improved communication of essential commands (like device configuration changes) using multiple PLM's connected via the more reliable WIFI network (which might be overloaded by routine Insteon messages)? Why doesn't EISY discover the Insteon network instead of starting with a network definition from a backup that includes data from past failed PLM's? I want to be able to ask well-informed questions based on an improved understanding of the system I’m trying to use. Thanks, David

Thanks Geddy. I was unsuccessful in identifying the contexts where the new PLM triggered ISY "safe mode" and contexts where it did not. I tried different lengths of time between starting the PLM and starting the ISY. It seemed that the PLM just started working and would no longer fail. There's probably some other factor around restore sequences that I'm overlooking. I do not use Z-Wave devices, so that's a complexity eliminated. Thanks for suggesting taking another backup of the ISY even though I did not attempt any changes since the first failed restore and the second successful restore using the new PLM (both from the same backup). Hopefully that will eliminate any lingering unwanted data that the former / dead PLM may have introduced to the backup I used for the restores.

Regarding Gedddy's helpful concern "you think either it or the ISY are flaky": Is there a way to check a backup for obvious garbage apart from using it? After encountering repeated failures to use my brand new PLM after a device reset, the PLM started working again. I did another restore from the backup taken when the prior PLM had failed. This time I saw no evidence of issues. I tried multiple restarts with different sequences and could not reproduce the ISY declareing safe mode. That included simultaneous restart from the same power strip (apprantly not recommended). Insteon support is unimpressed by my issues, since they involved an ISY which is no longer supported. My prior backups were way too old. I welcome suggestions but don't see an alternative to using that latest backup with a new Eisy.

One note on Geddy's advice: make a "hard copy" of all your programs currently on the ISY994. On the Program tab right click on the root folder (usually "My Programs") and use the last menu item of "Copy to Clipboard". It looks like the option to get all programs in text is "Copy Folder to Clibboard".

Thank you all for your prompt and useful advice.

I am about to migrate for ISY to Eisy. I just replaced the PLM for the ISY with a 2413s (serial) . It seems flaky, although the problem might be the ISY. Apart from the need for an adapter when using a serial PLM, are there any significant distinctions between the supported PLM's? For example, are the serial PLM's slower? Is one PLM unreliable? Thanks for reading and especially if you reply.