ELA

Hi Mark, I can only speak to those devices that I have measured personally. There are a lot of posts here about people getting resolution to communication issues by filtering this or that. I was unhappy with the trial and error method. For that reason I developed the tester that I did. It quantifies just how much signal any one device "sucks", or how low of an impedance it appears to be at 131Khz. I posted several results for some newly tested loads in that other post I pointed to. (sorry but I do not have a pool) Having started out with X-10 I already had 3 filters (Computer, battery charger, LCD TV #1) left from those days that I did not remove when I changed to Insteon. While I am happy to now be aware of just how bad each "signal sucker" is, I would prefer not to blanket filter them all, even if they are above a certain "suck" level. I simply do not want to incur the expense and the ugly wall warts if I do not have to. I have just installed three new devices. I purposely picked one to be a dual band in hopes that the RF section would help me overcome one or more of the known suckers in that area. I am in the process of doing message reliability checking to help me determine if I can avoid installing some filters. Do you use Houselinc? I do not own a copy but hear it is a good test tool for message reliability testing. I have a similar feature in my personal tester. You can then add/subtract filtering and repeat reliability testing to evaluate the filtering effectiveness. All said I am not aware of any major problem with installing more filters if you feel you need them. (within limits of course). I do feel it is important to make the the power line carrier aspect of the dual mesh network as reliable as you can. I do not want to become too reliant on the RF section or visa versa. I like the idea that each is as strong as it can be in order to make the overall communications as reliable as possible. In my current install I am hoping that between adding devices (thus strengthening the power line via hop usage) and more dual band devices to beef up the RF, that I can avoid some filters on what are known and substantial signal suckers.

Thanks IndyMike, Always a pleasure to exchange information with you. I agree, and I never expected a refrigerator to be a signal sucker of much magnitude in the past (qualifying I still have not been able to measure it directly to say it is now). I did replace a very old unit in the past year with a new one with a lot of electronics. I would not be surprised if this one had an across the line cap for filtering. When I first installed the new refrig. unit I started having communications issues. At first I believed the issues to be (dual band) RF related since the new, large stainless steel unit now "blocked" a couple of RF paths. I re-arranged a couple dual band lamplincs and things got better. That was about the time that I decided to "get serious about communications issues" This possible resonance condition really peaked my interest. I will follow up someday in the future just because it is so interesting (even if I do not install any Insteon devices on that circuit in the future).

Hello IndyMike, I have also been guilty of speculating on theories and try my best not to until I have testing results to support the theory. I try to qualify statements with that in mind. I will eventually get around to testing to prove or disprove a possible resonant condition. This particular situation surprised me. It consists of an outlet in the middle of a small branch of 6 total outlets on a 20A kitchen circuit. The main load on the circuit is the refrigerator located at the first outlet off of the home run. While monitoring the "suck level" at this particular outlet it "maxes out" the measurement range. While still monitoring that outlet I have unplugged all devices on that circuit except the refrigerator. The high drain level remains. Measuring that same circuit but at the service cabinet (looking back they other direction at the refrigerator load) measures only 1/2 of what was measured at the problem outlet. Doing the calculations seemed to support a large capacitive load that the refrigerator along with the series inductance to that outlet might be just the right LRC combination to be resonant. I do qualify that I will not feel comfortable with assuming that is the case. I will remove the refrigerator one day and test further. Right now I am not adding Insteon devices to that circuit and this situation does not appear to "reflect" back at the service and so it is not a large priority yet. Who knows maybe I will end up finding a staple that was driven just far enough into the romex to be an issue for Insteon but not at 60Hz I really have to wait to test more.

Mark, They often use plumbing analogies for electrical issues. In this case you might think of it as a single hose that splits into, say three other hoses at one end. You have a certain amount of flow down the main hose that you want to maintain as even of a division of, and at a certain level of flow, in each at the end. Now if one of those end hoses is leaking it has the potential to "drain" flow away from the other hoses. May not be the best analogy but one that occurs to me.

Hi Mark, If you have time please read through the posts I pointed to earlier as I provided some of what you are asking there. Yes if there are a few large sucking devices together, such as I mentioned are in my master bedroom ( especially when located at the end of the home run from the service) those effects can be measured all the way to the service. I have measured the suck level both at the bedroom and at the service and when the problematic loads are unplugged the suck level is greatly reduced at the service as well. Your home AC network becomes a much more complicated network at the 131Khz Insteon frequencies and combination's of wire inductance and signal sucker capacitance's can result in localized resonances that can have a very large effect at points a fair way away from the signal sucker itself. The network impedance can vary greatly from one point to anther and it becomes difficult to generalize. While developing my tester I ran into a very interesting situation where one particular kitchen outlet registers the largest suck level in the entire house. There is nothing plugged into that outlet and nothing in any of the immediate outlets nearby (which all register a lower suck level). I believe that is due to my refrigerator causing the resonant condition I mentioned. I am yet to prove or disprove this until I am ready to move a rather large refrigerator just so that I can unplug it for further testing. I have a pretty large 20 amp wire-in filter that I will then put in place if the refrigerator appears to require it. When talking about going one step too far in filtering I would consider this one to take the cake. I really hope I am wrong and the refrigerator is not as large of a sucker as I suspect. ( or I may find some hidden device that I have yet to realize). My filterlinc etc. order did not arrive today, hopefully tomorrow. I will post my results in the other thread once I have had time to install the new devices and test the filtering that might be required.

I also got tired of playing with X-10 (lot of stuff in boxes) and upgraded to Insteon thinking it would have a lessor need for filtering. I have since come to the conclusion that filtering is a must (maybe not for every installation but probably for most). I just dropped $90 on three more filterlincs yet to be installed, but I want them on hand as I enlarge my network into an area that did not previously have any Insteon devices. I know I have three large signal suckers in that area. An LCD TV, a Satellite receiver (& power supply) and an Air Cleaner. They are all a large distance from each other and so I cannot use one filter for all I will be installing two ICon Relay switches and one Dual band Keypadlinc initially. I plan on investigating if the dual band unit will help me avoid having to install one or more filters. I agree with oberkc that you are best to filter the offender or it will probably surface again in the future, especially if you expand your system.

Glad to hear you found it Mark, I have been working on a device that I think is becoming a great diagnostic tool. Don't know if I will ever be able to offer it to others but I remain hopeful. http://forum.universal-devices.com/viewtopic.php?f=28&t=5923&start=60 This device can provide you with detailed information about how friendly any one outlet may be towards an Insteon device being located there. It identifies signal suckers immediately and quantifies them. Using this tool I am now discovering all sorts of interesting things (for an engineer geek that is

Slight correction I increased the numbers in my last post based on these recordings:

Hi Mark, I have been doing a lot of testing on Insteon communications recently. From this I can tell you that I allow for 2-3.5 seconds as a worst case (that I have observed thus far) scenario between attempts to send a new message. As Lee Mentioned the time can vary greatly based on the number of hops, whether standard or an extended message, and whether or not retries are at play. For a worst case of an extended message, 3 hops, and 4 possible retries allow for the ~3.5 seconds. It can be rather painstaking to log messages and to figure out what they are telling you. There are many here who are very good at doing this. If you record some communications logs you could learn what to look for over time with other peoples help and use that to help gauge improvements as you move things around.

Thanks for the info on that relay Brian. That does look to be fairly robust. My concern is for the Smarthome unit that only states "For resistive loads only". While it may be ok for motor loads it would be nice if they stated that. Here is a link to the relay you mention: http://catalogue.dblectro.com/products/687-RELAYS/26-Electromechanic/689-NT90-DBL___NT90.pdf The ratings vary depending upon how you want to use it. You usually see contactors used when switching heavy inductive loads and motors.

When switching something other than a resistive load be careful to check the relay contact ratings. Simplehomenet also advertises this: ZBMLC30-2 - Dual (30/15A) Relay with Energy Meter - Model #4031A As coming soon. It appears to address loads that are not resistive but is more spendy. The Smarthome: INSTEON 220V / 240V 30 AMP Load Controller Normally Open Relay (Dual-Band) States that it is for resistive loads only. Washers have inductive loads and may eat up the relays if they are not rated appropriately.

Hi Michel, I appreciate your interest in this issue. I am content for now that everything works (as far as I know). Notifications work as it is. There is a good chance that notifications were not working when I had the NTP error. I only just used an email notification and had only started using it a month or so before this NTP error started. So I am unsure if the email notification had stopped working but I think it may have. As I said it works fine now. Since it is working fine, and I grow tired of working on these types of issues, I am going to leave good enough alone for now. Thanks for all your interest and direction. Regards, Ela

Michel, Right after I responded last night I did just what you are asking me to do now. I wanted to be sure I was remembering correctly and I was. DHCP fails every time.

That is correct. It was set to DHCP when I first started having the issue. I reset the IP to 0.0.0.0 and rebooted (with DHCP on). It assigned a new IP address and still failed DNS. The only way I got it to work was with static addresses since the router seems to want to use a DNS address that is no where near the router IP address. It wants DNS = 205.171.3.25

Hi Michel, My original setting had the DNS server address the same as the router IP address. Just to be sure though I did set it back once again. It immediately fails with a red Asterisk on the NTP server. As I said it seems unusual to me also. I am not familiar with different routers but this one must be different in some way. It is a PK5000Z.

Just for possible reference should someone else encounter this issue: ISY support said to check that "DNS Relay" is enabled in the router. I had no such setting in my router. What I did find is that the router had two DNS Server addresses listed. They were located in a "status" screen as opposed to the advanced setup where you enter IP addresses. I changed my ISY to be static IP and DNS settings. I used one of the two DNS settings in the router and it now works fine. I realize that I may still have future issues using static addresses but this is what I needed to do to get it working. AS I mentioned I am not very knowledgeable about TCP/IP, DNS etc. I have studied a lot over the past week though. I was under the impression that when DHCP was enabled that everything was supposed to take care of itself? (i.e.) That the DNS address would resolve itself. I also was under the impression that the DNS server address should be the same as the gateway address? To resolve my issue the DNS address was nowhere close to the gateway address (=the IP address of my router). Main thing is that it works now.

I will try the call but direct help like this is also very good. Checked and no duplicate addresses Reset the IP address with DHCP enabled and it then reassigned the very same address again. I suspect that the ISY cannot reach the router for DNS but it reaches my computer just fine via the router. I pasted part of the log above in an earlier post. what does it tell you? no switch

I continue to have this issue. I am not real proficient at Internet protocol stuff like DNS. I have studied and read a couple of other similar posts with no help? This seems as though it is a router setting issue? I have DHCP checked in the router so shouldn't I expect a DNS server address to be set automatically? If I understand this it is the ISY trying to get to the outside world to get a time update? I do not remember having this issue prior to installing a new router, however I also upgraded my ISY a few months back and I read a thread that stated a older firmware version did not report these errors as often? Could this be firmware related? Anyone? Just found some other forums stuff about this NTP on the internent: They talked about using a fixed IP for the NTP server address of: 70.90.153.222 They stated there are several server IP addresses for pool.ntp.org. I will try a fixed address for this. They also mentioned other address names such as 0.pool.ntp.org, us.pool.ntp.org I will try all of these.

Thank you Sub-Routine, It was set to DHCP.

I am getting a red LED on the ISY99I about every 15 seconds. The error log reads like this: In the configuration screen it has a red asterisk in front of the NTP server "pool.ntp.org" With all this it seems it should be obvious what is wrong but it is not to me? I suspect that when we had to replace our wireless router a few weeks back is when this started. Please let me know how I can fix this? The ISY99I seems to be operating fine otherwise.

Thanks Michel, 1)The address had remained the same. 2) I was not running the old Console - the new one shows the correct version once open. (after satisfying the ISY finder) 3) I stopped using the .jnlp and instead used the http://isy/admin and that works fine. Thanks for your help

Hello Michel and thank you for your kind reply, During the upgrade it failed and I used the line below to make it pass - even though I am on a pc. So I am for sure using the original address that was used previous to the upgrade. Are you saying that the ISY might have automatically been assgined a new address at boot and that is now different then the original I had used before the upgrade? If so then why would it work when I select the old address? I will check the ISY to see what address it is now at vs. old address. I am very confused by the constant recommendations to clear the java cache? As far as I know- I have been doing that constantly without a positive result. Can you explain or point me to an explanation since I am not familiar at all with java? Why so many options to reconnect as posted in the first post? Are they all created equal?

I upgraded from 2.7.15 to this version. This is the first update I have done and felt a little lost as to what I was doing but followed the directions and it seemed to go ok. I did have an issue of having to point it to my http address. Now when I start up using the last option in this list: *********************** . IMPORTANT Once upgrade is completed and ISY reboots, use any of the following methods to access your ISY's Admin Console: a. http://isy/admin - applet (Windows only) b. http://isy/admin.jnlp - Java application (Windows only) c. http://your.isy.ip.address/admin - applet d. http://your.isy.ip.address/admin.jnlp - Java application e. http://www.universal-devices.com/99i/2.8.13 - applet f. http://www.universal-devices.com/99i/2.8.13/admin.jnlp - Java application ******************** if says not found and presents a table of available HTTP addresses with mine as the only available. If I double click on my address it loads and all is fine. I have to do this each time I start up so I feel something is a miss?

Lee, Would it be worthwhile to then run individual on/off commands direct from the ISY to only the devices in question and record using the Event Viewer (set at level 3)?

I am slowly getting familiar with the communication protocol (with a long way to go). When I looked at the log I saw a msg. fail each time that did not apprear to have anything to do with the lights that failed the scene test. I also thought that there was no response from the lights that the op. said did fail the scene. This much seemed to make sense to me. What I do not understand is why the scene test states that it passes [suceeded] on the two lights that are failing??