ELA

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.

Moderator, Please mark this thread as "Solved by MGustin"

A two wire device gets its power through its load. What type is the load and how many watts? If low wattage (25Watt minimum) Can you change the load to a higher wattage as a test? Capture a query of the device on level 3 comms viewer. Then capture a write changes comms on level 3.

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.

I have the same issue with either Chrome or Edge. Page forward or page back , or goto page# = none of them work and have not for a few weeks now. using either win 10 or 11.

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?