ELA

johnnyt, I would not move any of the filters you have listed for the chargers. So many things are signal suckers it is very difficult without the ability to measure them to gauge what equip. might require them. Hopefully the list will be of some help. The list you referred to is now available here along with some other info that might be helpful: http://www.elavenue.com/insteon_test_data.html Yes Filterlincs suck some signal as well so you do not want to waste them on something like a EMI filtered Surge-strip only. Unless of course there are large signal suckers plugged into it. I have an Ipad charger that I have never tested because it is on a plugstrip that is already filtered for a laptop power supply ( known sucker) that is also plugged into it. I will try to test the Ipad charger to let you know. Addition: 4/22/14: Tested small white cube style IPAD charger and did not detect any signal sucking properties.

Hello Johnnyt, I have experienced this "Duplicate" message phenomenon a few times in the past. The first time was with a problematic APL. It was having difficulties communicating. When monitored it exhibited these "duplicate" messages. That APL eventually failed and had to be replaced. During investigations at that time I found that I could readily reproduce that behavior with a known good device by purposely creating a marginal communications environment. In a more recent test I monitored a device immediately adjacent to a sending PLM using the extended "2F" command. When the communications environment was pristine the "duplicate" messages were never seen. I then moved that receiving device only 8 ft away from the sender ( as the crow flies) and about 30ft electrically. I moved it to an outlet with a computer and monitor that are large signal suckers (purposely left unfiltered). I would now readily get the "duplicate" messages. From my testing I am hesitant to refer to these extra message reports as duplicates since I have found that they are not so much extra messages as reports of other hops that are normally present, but not normally reported. I have referred to them as extraneous reports. The problem with the ISY logging is that it only provides a 1second resolution. I have logged these messages with a finer resolution and that shows that these extraneous reports occur at or near the normal time of the other hops that are always occurring when a message is sent with 3 max hops. Under normal circumstances the PLM only reports the message up to the host at the hop number and time occurrence that it first detects a legitimate message. Under abnormal communications situations the PLM is reporting some the other hops up to the host as well. It is not really slowing anything down ,as those hops are always present, just not normally reported. Not being privy to the the lowest level details of Insteon I am left to speculate as to why this occurs. I believe that it may be a timing issue caused by various delays in the Insteon network. These delays can be aggravated by a large capacitive load ( signal sucker) such as I introduced in my test. There is a finite time window in which the protocol expects to see hops. I am speculating that If they should fall just outside that window they may then be reported up to the host whereas they would not normally. I have observed "2F" message exchanges on an oscilloscope over extended periods in a marginal environment and you can observe time shifts as well as simulcast variations that occur at the time that the extraneous reports occur. As long as you are not experiencing outright communication failures I would chose to ignore it. As always I recommend identifying and filtering any large signal suckers to help a network perform at its best.

Hello johnnyt, I tried to sift through all the data you have posted. One thing stood out to me. The comment about an "otherwise pretty reliable comms-wise". The following is based on a quick review. If I miss read, or you feel it does not pertain then please ignore. It seems in several posts that you are getting very long delays in the response message. You cannot only look at the Max hops and hops remaining, you also need to look at the time delay. Such a long delay often indicates that retries are occurring at the Insteon device level. I have often observed strange occurrences when the communications gets marginal and retries are occurring. You often see several missed attempts and then you finally get a response on the max =3 ,remaining =2, on the last retry, thus the time delay. I would recommend that you ignore status for a bit and concentrate on something simple like a "get engine" request. Log as much data as possible and observe if you get excessive delays in the responses. If so then focus on how to get a more reliable communications to that device location.

I should have been more specific. I used two relays to switch power and thus they were activated as part of each group command leaving 64 binary combinations. How many different scenes do you need total for the EZIO8SA? If I remember correctly I ended up with an ISY limit of 8 scenes after having gone through all the link record edits. It has been a long while since I worked with the EZIO8SA. I will give you an overview as best I can recall without setting it up again to review. LeeG is the best resource for these things and hopefully he can provide better detail where I am missing something. 1) Set up the unique scenes in the ISY with just 1 relay per scene ( 1-8 ) scenes. 2) Connect directly to the EZIO8SA PLM with the SHN utility. 3) Use Manage device links ( ALDB medium I think it was). 4) Display the link records. 5) Use "write link records" to change each individual link record's data bytes #2 & 3 format = Responder, Group#, 3 address bytes, data byte1, 2, 3 for ex. the existing link record might be: A2, 3B, xx, yy, zz, FF, 00, 01 change data byte @2 & 3 : A2, 3B, xx, yy, zz, FF, 80, C1 ( for relays 8,7,1) I believe the data byte #2 was always "80" and byte #3 is the relay "snapshot" you desire for that group Good luck should you decide to decide to implement this.

Hello mschwab, I had bought the EZIO8SA with the intent of being able to use the full 64 binary combinations of relays from the ISY. I was disappointed to find out that was not something the ISY supported. Depending upon how badly you want to pursue it there is a possible work around discussed here: http://forum.universal-devices.com/viewtopic.php?f=5&t=9888&hilit=snapshot I tested it and it worked well. The downside is as LeeG pointed out that if you do a restore you will loose the custom links you had created using the utility.

Hello RLIKWARTZ, I am one that has experienced this as well. I attributed mine to an Electrostatic Discharge upsetting a device in such a way that it sent an erroneous message. LeeG explained in the thread below that a group 255 exists that could cause all devices to respond. Unknown as to why or how the device might formulate to send such a message , whether or not the checksum would be valid, or if the CRC should have prevented it from being acted on. http://forum.universal-devices.com/viewtopic.php?p=73544#p73544

Hello Teken, I re-installed the module into my home install last night as I missed having one of my mood lights operating. I also wanted to see if the random beep returns. I have elected not to attempt to investigate the smarthops option any further. I do not see that as a simple task to determine via testing. I had hoped for someone in the know to offer up the answer. It miffs me how Smartlabs will introduce features such as this but offer no guidance on how they might be used for the average user. My guess is that they may not be intended for the average user? It sounds like you are very active doing installs for others? I understand where information such as that might be very helpful to you. Have you considered joining the developers group?

Thanks Brian, I guess the answer to Smarthops will remain a mystery for now apostolakisl, I have factory reset the module several times now as I have tested and been distracted by these new features. I have yet to re-install it into the home environment so I will see how it behaves when I do.

Just a follow up on the "Device Options" for the new ON/OFF module. I tested the "RF" and "PowerLine" check boxes and they do indeed do what one might expect. This enables you turn on and off either the RF or Powerline transmissions. I am not recommending anyone use these. Just providing this for information sake. You do have to be careful ... if you uncheck both boxes you will have to do a factory reset to recover

My new On/Off module is randomly sounding a beep from time to time. I have enabled the beep in the Device options, however there is only one program that activates that and I am sure that program is not running when I hear the beep. I had sensed that it was beeping every now and then but just this evening it beeped twice while I was sitting near to it so now I am sure. I checked the log and there was no traffic during that time. The module was on at the time and it has not appeared to fail in any other way thus far so it is a minor nuisance only at this point. Still a little disconcerting. Is there a list that explains what the "device Options" in the ISY do for this newer module? There are check boxes for "RF" and "Powerline". Anyone know what these mean?

Hello Shannong, The thread referenced was a bit long and bit technical at points. Sorry you did not find it helpful. I have been setting up a site to compile my personal experience and to talk about the tester I developed. It may not be ready for prime time and I am definitely not equipped at this point to produce or sell the testers. If you care to have a look here: http://www.elavenue.com/automation.html If hope there might be something there that could be helpful in the "Test Data Area". Please address any questions related to the tool itself at that site rather than here. The biggest hurdle is low volume costs do not make for a very marketable tool. I hope to make a very limited number of them some day if I can just get around to building my 4th (final) prototype. I participate here in hopes of helping others, and to learn from others, as time permits. Now that I have that site all my efforts here revolve around providing diagnostic assistance without using my tool. I see you have two similar threads. Understood that a oscope is a bit much for most. That was one of the intents of the tool design was to avoid the need for one.

Not advocating anything, just exploration into an answer to the original question. Would never be intended to communicate via PLC when "on Battery", only to be able to capture asynchronous RF messages. When "on-line" it would still be mostly RF only due to signal sucker nature of most UPS's Surge/EMI front ends. A nearby DB or Access point device would do the synchronous translation back to PLC. The point proven was that the PLM requires a zero cross signal of some sort, even to receive an asynchronous RF signal. However it may not necessarily need be accurate, or in sync with, the power companies 60HZ in order to satisfy an asynchronous RF receive capability within the PLM.

The zero cross is surely used for a reference in the PLC communications. For timing outside of zero cross they would be relying on the micro-controllers clock. RF only devices can send at any given time since they do not have the zero cross reference. Therefore I would expect when the PLM receives a RF only message that it "could" pass that message up to the host (without a zero cross ref)- Given additional engineering. I liked the idea of a DC UPS ... too bad. The reason I was curious if there are some using a PLM on the output side of a UPS is wondering how well that works. Especially if it is not a "true Sine Wave" UPS. Most cheap household units are the "simulated sine" type that look more like a square wave. I picked up a used APC550 UPS for $5 that I captured the output waveform on and it was pretty nasty looking. It does at least provide the zero cross reference required. The PLM did pass the RF only message up to the host in my limited testing. Just not sure how well that might work long term and if there would be any additional wear and tear on the PLM circuitry over time. ( sorry about the different time scales)

I read this post a few weeks back and it peaked my interest. It seemed logical that the dual band PLM should be able to communicate via RF only, without an AC zero cross reference, since RF only devices communicate asynchronously. I ran a test to confirm what Xathros has said. Using a Triggerlinc I set up a link to communicate with a PLM. I then shorted the opto-coupler secondary pins so that the micro-controller no longer had a zero cross reference. One would expect the power line comms to cease of course, but why not keep RF only comms alive? The result was that the PLM would no longer pass the RF only messages up to the host without the zero cross reference present. I have read about a number of people forcing the PLM to communicate via RF only by isolating it with a filterlinc from the power line - non UPS related. Are there some here that are currently running a PLM on the output (inverter side) of a UPS to provide backup capability ( for RF only messaging) as well?

To be clear those are words you chose and not how I phrased the question. I apologize to ejh3 and the community for my part in taking this post to a place it did not need to go.

Proof you are not aware and contributes nothing to anyones better understanding.

Here is the proper quote: apostolakisl, Would you please name a few of these many things, please include both frequency and amplitude values for reference. Looking for what is the amplitude at the Insteon Frequency of ~131Khz. There is a clear history of GFCI breakers nuisance tripping due to fluorescent lights ,tread mills, tools etc. The specification is mostly common knowledge around these Insteon forums that the ~131Khz signal is ~3.2Vp-p into 5 ohms. Now for comparison what is the amplitude from a very noisy fluorescent light at 131Khz? Do you understand what it takes to trip a GFCI? I have done extensive diagnostic/test work on GFCI's for various projects including EMI stress testing over several years. For example: Insteon transmitter driving a light load = 3.2vp-p/5 ohms = 640 milli-amps p-p What it takes to trip a GFCI = 5-6 milli-amps RMS (differential current) or 14ma p-p Now take a look at how much voltage would one need to drive a 5ma current into a 5 ohm load. = .005 * 5 = .025V RMS More than 25mv ( or 71mv p-p) could easily be produced by many noisy devices but when compared to an Insteon signal they pale. It does get much more complicated but this is just meant to present an order of magnitude comparison. Data vs. conjecture. Edited 12/14/13 as apostolakisl was kind enough to point out my example did not include the units to provide a more accurate comparison.

Hello Teken, I searched for a picture to help: http://www.google.com/imgres?imgurl=htt ... CFwQ9QEwBw Any load wire must connect to the neutral terminal on the GFCI breaker itself as opposed to the same place that the breakers curled up neutral wire connects.

ejh3, Glad to hear it is working but confused by your last post. Does the GFCI only trip when the Insteon device is sending or any time it was "connected correctly" and idle? Are you saying you fixed the problem by connecting it incorrectly? From what you describe, with the device neutral direct to the neutral block ( as opposed to the neutral lug on the breaker itself) I would expect it to trip constantly due the to idle current from the device? GFCI's will trip on 5-6ma or only about 1/2- 3/4 watts. Din Rail on/off module lists its idle consumption at <1W . If I understand correctly, and it is connected incorrectly, then you are likely on the very boarder line of tripping all the time and you may be revisiting nuisance tripping in the future.

Hello smorgasbord, If you decide to use an Insteon device/s I would recommend the EZIO8 rather than the bank of IOlincs. Especially if the "bank" of IOlincs were to be located all in one area. One of the big advantages of an EZIO8 would be a single PLM "signal loading" of the power line at that point. Putting several IOlincs in one place would create a heavy "signal load" at that point.

My earlier tests also suggested ~3K internal pull-up. To confirm what Brian has already said Looked like ~700 ohm pull down would trigger. A quick look indicated about 100ft of #24awg to be ~2.5 ohms ( 5 ohm round trip). I agree that noise could be an issue as 100 ft makes a pretty good antenna. Many have reported success with long runs between Insteon devices. Curious if you could possibly make it work over the power line by making sure there is a " repeater device " Near to where each end of the cable enters/leaves the buildings?

Hello ejh3, While the probability of success is high and many have good luck with Insteon and GFCI's be advised that it is entirely possible for the GFCI to trip on either an X10 or an Insteon signal. I have tripped a newer Leviton GFCI a couple of times now that was directly related to an Insteon signal. There are several factors that figure into success vs. failure. Too difficult to predict in advance you may have to do a minimal install and test to know. A few of the factors that determine the results are length of the signal stream, amplitude and frequency of the signal or "noise". Other factors are location of the transmitter relative to the GFCI and receivers/signal suckers. It is well known that any electronic device can be upset by a high enough level of EMI ( noise at a certain amplitude, frequency and duration or repetition rate). I am not aware of "all kinds of things producing noise at the same freq. as Insteon"). Certainly not at the amplitude that Insteon transmits. There are however many transmitters at widely different frequencies and power levels that have also been known to trip GFCI's, if positioned close enough to them. That is the technical explanation just to be clear that it can and does happen. Based on a wide installed base the success rate is very much in your favor however.

Hello Neilp, Sorry to hear you are still having issues. I just purchased a 2413S a couple of weeks back. It reports as Firmware rev 9B. It is an i2CS device and reports as so. As a test I just connected it to my EZ8IO8SA and added it to the ISY. It reported as i2CS, added all links fine and the inputs update as they should without a need to query. Looks like you have something else going on. LeeG is the best at resolving these issues so hopefully he can direct you further. I just wanted to offer that data point to help. As LeeG suggested some level3 traces are probably required to diagnose further. Perhaps a trace of the links present in the EZIO8SA ?

Hello Bilsk, On the Rj45 connector, are there any wires connected to pins 2, 3,4,5 & 6? If so are they all isolated from each other and not connected to any pins on the db-9 connector?

NeilP, The only reason I asked what the ISY showed is to see if it for some reason showed something other than the Ver.FF that my 9B also shows when read via the ISY. I was hoping we could identify some reason that your ver9B is acting more like my previous 9C rather than a 9B. Out of the box ( or after a factory reset) the EZIOCOMM shows its "PLM" version of 9B. Once connected to the EZIOS8A via the serial cable the EZIOS8A rewrites the version information (device ID). If you were to factory reset the EZIOCOMM and then add it to the ISY, without having first connected it to the EZIO8SA, it would report the 9B. Sorry I cannot be of more help. Pretty strange that we both have 9B versions and yet they are clearing not the same.