ELA

Thank you for sharing your work kclenden, This is very interesting. I have yet to upgrade to an eISY and have never seen such a thing with my ISY994. The "link Info" messages are new to me, should they be of concern ? Does not appear like any of the older All/ON , ALL/OFF issues from my experience. It might be interesting to send the invalid message "02 62 00.11.00 CF 13 00" (A group broadcast to group zero to turn off) directly to the PLM to see how it responds. If you were to open a ticket with UDI ... I would be curious what they think?

Hello Kclended, Could you please post an example of your capture where you see the corrupted echo? Out of curiosity, how log is your cable from eISY to the PLM?

I have had a few older icon devices go bad of late. Just bought a replacement last week. It was not worth it to send back the old device as you pointed out return shipping nearly wipes out any gain. If they had records of previous purchases could they not offer decent credits for new purchases when you have spent over $2k on product over the years?

The filter discussion was primarily for the OP -Richtimpa. He stated the communications issue was important to him. Flickering or strobing could possibly be improved with the appropriate filter at the Power Wall. For Flickering - As a first attempt I would try the Jasco LED bypass that I referred to in my first page post. Have you tried those? They are mounted directly at each Dimmer or its load. They can be a big help in some cases but not all. Unfortunately they are showing out of stock presently. They are most helpful when the dimmer is lightly loaded with an LED load. A dimmer is susceptible to having its triac triggering upset when there is "noise" or " a "zero-cross waveform distortion" occurring with a minimal LED load. The Jasco device turns on only near the zero-cross point in the waveform to provide a more stable load for the dimmer triggering circuit, - at a time when the LED load is not yet conducting much current.

EMI filter vs Insteon: While in general, adding an EMI filter at the service entrance may be good for protecting electronics, it may be a negative for Insteon communications. Often times Insteon users with communications issues complain about "Noise" when the real issue is often that a device is a "signal sucker". Often times it is not all that important to understand which of those two that the offending device is. Adding an Insteon Filterlinc can be the solution for either. The Filterlinc both filters Noise from the line side and can also "isolate" a signal sucker from the line. With a large current device like the Power Wall it is much more important to attempt to understand whether it is a noise issue, a signal sucker issue or both. From the descriptions written here thus far it does sound like it may be a little of both. It is important to be clear on the terms Surge Suppressor vs. EMI filter. There are lots of Surge Suppressor -only devices that can be added without affecting Insteon communications. However there are a lot of EMI filters, especially those with a simple capacitor only filter, that will degrade Insteon comms. If Insteon offered a Filterlinc with large enough current capability that could be a solution. Since they do not, finding a custom EMI filter that that both suppresses noise from the line, but also isolates the load side may be difficult to identify and expensive. The M2120 mentioned does not provide enough data as to what the EMI portion of it consists of. Many inexpensive EMI filters are simply a capacitor. The capacitor alone suppresses a wide range of frequencies, usually including the Insteon freq. That makes it a "signal sucker" to insteon. So adding an EMI filter at the service may actually degrade the Insteon performance unless it is one that also incorporates large inductors to isolate the load side from the capacitance. The Power Wall vs Insteon issue is much more difficult due to the high currents involved. An Insteon user can buy a filterlinc and install it as a fix without incurring a large expense. If it does not work they are not out all that much. A Power Wall size filter would be very expensive to purchase in "hopes" that it might help.

Ask the installer/Tesla rep. if the Powerwall 3 is "CE" marked? I took a quick look and it looked as if that is planned ? Or maybe what I saw was old data so I am curious. CE marking allows them to be sold in Europe and CE marking requires a much more stringent series of Electromagnetic Emissions testing. It may be that they will need to install the filter the installer mentioned in order to meet the CE standards. Ferrite cores are generally only effective at higher frequencies, those much greater than the Insteon 131Khz. To attenuate or isolate the emissions from a device in the Insteon range requires a larger inductance. Like the Line reactor(inductor) I mentioned in my earlier post. IndyMike posted an interesting link. It would be nice to have a plot of the emissions from the Powerwall 3 showing what the offending frequencies are. If the installer/Tesla rep could provide some emissions test data that might be helpful. Best of luck to you all.

Hello Richtimpa, I do not have a power wall but will try to offer some insights and/or questions you can ask the Tesla rep. 1) What type of lights are blinking more often? LED or Incandescent or both? Are the lights on Dimmers? From your description it sounds like it may be a combination of things. It is likely the Power Wall (PW.) has internal filtering (across the line capacitors) to reduce the noise level it puts onto the power line. We refer to those as signal suckers. A signal sucker can make the communications less reliable and result in the sluggish query you see. It would be somewhat difficult to find an Insteon filter large enough to "isolate" the PW signal sucker from your power line. A large "Line Reactor" or inductor-only filter could possibly help but identifying that would be difficult without Tesla's help. You may have had some other signal sucker issues in your home prior to the PW install so the PW may not even be at fault for that one. It also sounds like the Solar Install may be communicating with the PW over the power lines and sending signals near zero cross that cause the lights to Flicker. LED would tend to be the most sensitive to this. If the biggest issue were with LED then a different brand might be less sensitive. If on Dimmers then adding a device such as a "Jasco lighting bypass" might help. If at all possible to get input from a Tesla expert that would be best as these types of issues can be difficult to resolve without knowing more about the Solar-PW interconnections. Having an Oscilloscope to observe the power line requires a device to filter out the large 60hz waveform in order to observe low level power line noise interference. Best of luck to you.

Hello and Welcome to this forum, Are you willing to become an Automation Hobbyist? If not then I would recommend you stay with the Hub. I may be incorrect but I would think that most here would consider their automation interest a hobby. It definitely demands a bit of your time if you want to explore all the powerful features that an ISY/EISY can add to your existing automation installation. If you are willing to spend the time required the people on this site are great at offering their time to help you along the way. As already mentioned it would be helpful if you described a bit about your existing installation. I would suspect that you had to spend some time getting your existing installation up and running reliably. You say you are having some issues now with the Hub. Are you sure it is the hub? Many experience issues with getting their communications between devices reliable. If existing issues are communications related, then changing to an EISY alone may not be all that is required. Having to resolve communications issues can make you a hobbyist :)

Thanks for the Zooz information IndyMike, My wife had bought me a T-shirt years ago that says "I Void Warranties" I find my enthusiasm for changing/adding new automation types is waning. Will stay with the ISY994 as long as it allows me to.

Thanks Brian, With prices as they are now it might be tempting to replace the pushbutton switches but enforcing Dual Band coverage I felt was worth the cost. Unfortunately I have also just had an older In-Linelinc go bad. I have ordered a Micro Module for it as a replacement. $60 each fail is not been very kind to my retirement fund

I have a few older devices that have begun to fail recently. For the most part I had escaped the original devices "infamous Paddle Failures" but now some older devices are starting to fail in similar ways. I had just replaced two 2476D's that started requiring multiple taps to turn on. I did not mind that so much as the older units (R5.15) were not dual band and I liked the idea of improving my RF coverage with more dual band devices. Right after replacing the second unit, in a two gang box, another 2476D next to it failed in the ON position. I could not turn it off manually, but could turn it off via the ISY. The paddle felt very stiff when trying to push the bottom section ( off). I was hopeful that I could simply replace the Paddle section only with some color replacements I had. After changing out the paddle the 2476D worked once again. What was strange to me is that after removal of the original paddle, that paddle itself seemed to work just fine when no longer mounted. Being curious I cut open the paddle to see what was going on. As you can see in the picture one of the two "D-shaped rockers" had broken off and lodged itself in the bottom section of the switch. This prevented the paddle from being able to depress in the down position(off). Once the paddle was removed the D-shaped piece had migrated again and thus freed up the down position operation once again.

Your last line may be where the confusion comes in. IndyMike and I are saying that the MSII can be retriggered once the ON time has timed out at 40 sec+ ... your last line is now attempting to retrigger the device BEFORE the On time times out and thus it will not send more ON commands. If you don't wait you are re-extending the ON time by restarting it. Anytime you wait long enough for the ON timer to expire then a retrigger can be created and once again an ON command is sent. When configured for ON-ONLY there is NO OFF time. You must wait for the ON time to expire before retriggering if you want additional On commands to be sent.

One more data point for reference in hopes might help: MSII: R3.3 , date code 3418 , V.47 Initially set for both on and off with a 10sec timeout. Measured actual on time at 14sec ( when off command is sent) Re- Set for On only with same 10sec timeout Actuate and wait 15 seconds then actuate again = will send another on status message.

Techman, What I was sharing has nothing to do with programs. The older style MS Sensor by default sends both ON and OFF commands. Link the MS sensor to the PLM via ISY994 - no programs created. Activate the sensor several times and read the excel log. You see both On and Off commands logged. Install jumper #4 for ON only mode. Activate the sensor several times and note that the log contains no commands from the MS sensor. This is what occurs in my ISY994 rev 5.0.15 firmware. I have always assumed this was a bug in the ISY firmware and that it was likely fixed in later versions. I was curious if this might be the case in the EISY and its versions of firmware or if it has been fixed.

Techman No I am not asking for assistance in debugging programs. I was sharing that two of my IR sensors, that are configured to report both day and night, and to send only the ON command, do not show up in the log. That fact can make debugging more complicated. I am just a little curious if that particular IR configuration, coupled with certain firmware versions, and failing to report to the log, is unique or if others may also have experienced this.

I am still running an older ISY994 running ver 5.0.15 firmware and noticed that some IR sensor on/off activations do not show in the log. I have 8 IR sensors total and 6 of those 8 report all on/off actions to the log. Those 6 are configured to only trigger at night. The 2 that do not report to the log are configured to be active both night and day and send On only. I have found that a little frustrating when trying to debug program issues. I am not sure why that the lack of reporting happens for that configuration. I always assumed it was a bug that was fixed in newer releases but perhaps not?

You suspect? NEC 250.118(A)(13) says it is ok.

Perhaps they are referring to the 4 button configuration with arrows shown here:? https://shop.insteon.com/products/mini-remote-control-keypad-4-scene

below is a page from some testing I did back in 2019 on the MSII current demand. Upon motion the sensor comes out of "sleep mode" and consumes a fairly large current while awake for 5 sec or so. Battery life will be directly related to the number of motions sensed. Likely more in a Hallway of course. Compare your settings of each sensor to see if one is different for some reason. I get fairly good battery life on mine but they are not used for Hallway type traffic. On my sensors I turn the LED brightness as low as it will go. Mine only report at night and only report the "On" to keep the number of wake cycles lower.

That unit says 0.5hp. How many horsepower is your pump motor? At 12-14 amps likely more than 0.5hp. Rough approximation = 12A*120V = 1440watts / 750W/hp = near 2 hp.

The Insteon Spec. sheet is insufficient. Simply stating "600W Incandescent 15A All Other Loads" does not address a motor load properly. The reason it is only rated for 600W incandescent is because of inrush current. 600W/120V = only 5Amps. They should be including a HP rating (horsepower rating for motor loads). I would not expect the Insteon device to last driving such a large motor load. I would suggest finding a larger capacity controller. Or drive a contactor from the outlet that then powers the motor.

Hello Merlin, Do you have any plug-in modules such as a Lamplinc? Did not see any in your list. Here is one test that might help you progress using a plug-in module ( maybe consider getting one if you do not have one). Create an isolated test network using your new filter. With the filter plugged into a wall outlet plug a power strip( ideally one not advertised as a suppression device) into its filtered output. This somewhat isolates everything plugged into that power strip from the rest of your home power. Now plug your PLM and the one pluggable device ( I will refer to it as "lamplinc") into that power strip. Now see if you can communicate between the PLM and that one device only. If you cannot then you may need a new PLM. If you can communicate between the two use the level 3 viewer and confirm that the "hops left" are 2 or 3. Next put the PLM back into its normal location ( no more filter used). Put the Lamplinc next to it in the same outlet. Use the level 3 viewer to see what the hops remaining are. If that does not work try the same at another outlet location. If it does work then you can start moving the Lamplinc to various other locations and use the hops remaining as an indicator of the quality of the communications at each new location. This could help you zero in on a problem area of the homes power distribution. Watch as the number of hops left decreases greatly.

One difference to be considered is cable length between PLM and ISY. Not usually a concern for most, however some have stretched their RS232 cable to near recommended maximums. If so, USB comms. has a recommended maximum length approx. 3 times less than that of RS232. ( of course data rates etc. affect this... just as a rough comparison).

Thankyou IndyMike for your efforts at documenting what devices ignore or respond to the All-On phenomenon. Ref: https://forum.universal-devices.com/topic/41651-all-on-removed-in-what-firmware-version-of-switchlinc-dimmers/?do=findComment&comment=369748 Since that thread was closed for further input I am inputting here to add to the list. I just received a new Lamplinc/Dimmer module #2457D Hardware Rev 4.2 , Firmware Ver. 43 - date code 4722. My older 2457D modules (Rev1.0, Ver. 3A) were degraded and causing their incandescent lamp load to blink periodically. This module was a replacement for that issue. Before installing I bench tested this new unit for its response to Group FF commands ( simulated All-On). I tested with both 02 62 00 00 FF CF 12 00 as well as 02 61 FF 11 00 group commands to group FF. Unfortunately this new module responded, turning its load on, to either of these commands. I was surprised as I had thought Insteon was removing the response to these commands in newer units?