ELA

Hi LeeG, I was aware of this from logs I recorded of both the 9C and the 9B versions. My curiosity is that NeilP is reporting his version as 9B. It is the 9C ( the latest) that reported as i2 in my testing. Maybe there are some hybrids out there?

Hello NeilP, I re-installed my EZIO8SA, ver 9B firmware and it works as it should. It reports as an I2CS device. Responds to the ISY with Link table address starting at 1FFF. The ISY properly loads links there. I can watch the ISY status consistently update as I change the state of input #1. I am happy for me but curious about your 9B version. What firmware version did it show when you had it installed in the ISY?

NeilP, I spent way too much time analyzing the 9C version a while back. When I received the 9B version I did a quick test and was seemingly happy with the change. Perhaps I missed something. I never did implement the final application for which I bought the EZIO8SA and therefore I have not worked with the 9B for quite some time so now. I am very unhappy to hear that you are having issues with the 9B version. I would be interested to hear what your supplier might be able to offer. I re-read the entire thread and see where LeeG reviewed your level 3 trace of the device. It sounds like it is behaving the same as my 9C did? very perplexing. If I can find time I will try to rerun some tests on my 9B to see if I can offer anything further that might be of value.

Hello Brian, My EZICOMM (model# 2233-233) hardware v1.7 does indeed bring out +20V at pin 2 with respect to pin 7. Not saying anyone recommends taping into it, just that it is there. The EZIOCOMM uses a different serial daughter board than the 2413S. It has a larger EEprom that has a memory size large enough to hold 4000 links ( in theory). That is why the peek and poke method to determine where to store links produces problems in the 9C firmware version.

Hello NeilP, I had this same issue. What version Firmware is your EZICOMM? Mine was 9C. The solution was to return it and have it Reflashed back to version 9B.

Hello cmidgley, I have often seen where it is stated that Insteon requires a "pure sine wave". I have no direct experience on this but I suspect that is not necessarily the best way to explain what the issue is? This is a bit of speculation so if someone has more direct knowledge please correct. I believe what might be more accurate is that Insteon requires a very tightly regulated 60 cycle/sec time base. The power companies line frequency is very tightly regulated. A generator is likely to allow its frequency to "wander" when compared to the very tight tolerance of the power companies lines. Since Insteon is very dependent upon an accurate zero cross reference it requires a very tightly regulated time ( or frequency base). So in theory a "poor quality" sine wave could still allow an Insteon system to function as long as it maintained a very accurate time base. I say this only as a possible aid in your discussions with your electrician/generator specialist.

Here is a link to the relay shown on the device referenced: Note the minimum permissible load: http://www.hascorelays.com/electro_klt_series.asp You would want the 3 amp version

Hello arw01, I am not currently doing what you ask but a couple of ideas might be one of these : http://www.smarthome.com/70422/Enforcer-Indoor-Outdoor-Wall-Mounted-Photoelectric-Beam-Sensor-with-35-Foot-Range-E-931-S35RRQ/p.aspx On sale so makes it attractive. It could be mounted just to detect the car inside of the garage in its final resting place. Might also detect people walking in the garage though. Or a non contact infra-red thermometer to detect the cars engine heat. A unit with a relay output might get costly.

Rather than ask a generic question about differences and then question the answers, why don't you address the concerns over what you have read about? What have you read about that concerns you? LeeG's comments on the advantages of the EZflora are significant and make the programming of the Ezflora easier.

I have not confirmed this directly but one other advantage of the EZFlora can be the triac switching outputs turning on at zero cross and off at zero current. The Relay module would most likely not do this.

I believe some others have filtered the PLM for a ( at least perceived) increase in communications reliability. I have not done this myself so I cannot attest to a measurable increase in reliability. With the intent being to eliminate the PLM's initial send via power line(PL), the initial send is only RF. It is true in that configuration that you will still have PL comms via the other dual band devices, including the access points, during subsequent hops. I can see where this configuration may help comms issues with certain devices within marginal PL range of the PLM. May clear up issues where a device "tries too hard" to dig a PL signal out of the background noise floor. Situations where it then either gets confused by an erroneous marginal PL receipt and/or it gives precedence to the PL over RF, for some reason, when both are present. Of course there could still be issues with other devices subsequent PL hop retransmissions being marginal to some other device. Everybody's network configuration is most likely different in some way and what helps in one may hinder in another. If you think about it the PLMs initial send is not aided by any other devices. If you filter it such that RF is the only initial send, and there are several dual band devices within RF range of the PLM, then the 1st hop retransmit with be a simulcast of several devices together. This could make for a much stronger PL signal than the PLMs initial send would have been, assuming simulcasting works ( which I do not believe it always does as advertized). I am still investigating the issue that just cropped up for me with an APL. It is a very intermittent issue. Spent several hours testing with no failures. I have discovered a very interesting condition involving the circuits involved. During testing with my test device I am seeing a very high reliability number when using only 1 hop. When I use 3 hops the reliability drops off!!! After several worry free months I Once again can feel the Insteon black hole drawing me in.

arw01, I agree with Xathros suggestion and would not use a filterlinc on a microwave. You could also consider an XPF ( needs a rather large box though Must likely the microwave is at least 1000watt and the Insteon filters are pretty shabby to be heavily loaded. We have had a few discussions in other threads about the reliability of Insteon the mesh network not being all that it is cracked up to be. There does seem to be some conflict with its ability preferentially use RF only if power line signals are weak. The two theories discussed were: 1) that Insteon actually had a preference to use Power line over RF when both are present. 2) Or what I lean towards from my testing experience is that very weak power line signals are acted on erroneously and that upsets the device momentarily such that it is unable to utilize the RF that may be a valid signal level. This all seems to be consistent with some peoples better luck by isolating the PLM with a filterlinc, such that is is using RF only. In some cased this may prevent the weak power line from getting to some devices ( thus forcing it to use RF). It is so interesting that some people just seem to get lucky and never seem to report having any issues while others struggle. For the most part my system has been quite reliable once I invested way too many hours testing and reconfiguring it. Yet I still have some weirdness every once and and a while. Just yesterday an Appliancelinc that had worked fine started acting up. Refusing to turn off ( would turn on fine). I removed it from the home network and tested it thoroughly on an isolated network. It tested fine. ( yes I tested and did exclude: a load that is a signal sucker/noise generator as the culprit). When I then put it back into the home network now all was fine again? Maybe it was just tired and needed a rest:)

Tried re-installing several times again and got the same results. Found that the commodo firewall was blocking javaw.exe. It was set as a web browser. I had to change it to a trusted application to allow it to run. Have not idea if that is a safe thing to do but that is what it took.

Hello Michel, I used in the instructions under 6b. I believe I also tried 6c. That got me the desktop icon but when first run it did not find the ISY and if I remember correctly I did have to use the add button to add the URL. In reading the instructions again I am wondering what is the Dashboard step?

I had trouble updating to 3.3.9 and the new java earlier last week. Next day updated to 3.3.10 with the same result of the ISY finder remaining and having to select what was in the window to start the ISY interface. After reinstalling the *.JNLP 3 times it started working magically. The ISY finder would run briefly and then progress to the password entry on its own. Now today I tried to start once again from the desktop icon and the ISY finder remains displayed and I have to click on the entry to get it to start. The ISY finder shows: My lighting:http://aaa.bbb.c.d/desc[uuid etc] The IP address is correct. Is the /desc expected? This is a minor nuisance. I will contact support if required when I have time. Just wanted to check if there is something obvious I missed?

When an Insteon message is repeated or simulcasted multiple times that is not really doing the same thing over and over. I am not going to go so far as to praise the Insteon hardware/protocol because I know it has issues. For sure if your network is pristine messages will get though and no need to repeat or ack anything. I can get 100% success with sending zero max hop messages in a good portion of my home network, but not all of it. However what you may be missing is the fact that the network impedance is always changing. When hops are repeated there may be different combinations of devices contributing(Simulcasting). If you look at a few of the Oscope pictures I have posted you can see that the hops almost never look identical to each other ( in a busy-non isolated network). In the thread below there are many pictures and descriptions of marginal communication situations. I point to this one particular post that speaks directly to your suspicion that retries may not be effective. http://forum.universal-devices.com/viewtopic.php?p=54985#p54985 The statistics there show several devices that are relying completely on retries to complete a message exchange. Some devices were 100% successful, but had to constantly rely on retries to do it. Others occasionally failed to receive even with retries and the success rate dropped off. This is common of marginal communications, where retries often make all the difference in getting the message through. When you are relying on retries however, you are extra susceptible to occasional complete misses when anything at all changes in the network. That particular post was speaking to the effect of moving the PLM and the drastic change in the reliability statistics as a result. ( some people do not believe the PLM placement matters I always strive to observe no retries to be occurring in my network. However they can be very helpful if or when it is a marginal network.

I tend to talk in terms of a PLM as the sender since I have done so much testing with them. I believe the device retries pertains to any Insteon Powerline sender. I have not reviewed the Insteon details doc in a while but it covers the concept of time slots. If the message is sent with 3 hops they will all be sent, even if the intended receiver hears the msg at hop#0. The time slots must be reserved for their intended purpose. When the recipient sends its acknowledge MSG it must wait for the appropriate time slot, after the senders 3 hops slots. (Again assuming 3 hops max send). Scene messaging and group sends attempt to improve on speed with another technique. I cannot speak to all the why's of this protocol. Too much to review and respew. I speak from a combination of reading the Insteon details in the past and lots of of Oscope reviews of message exchanges. Please do review the details doc and see if they provide justifications. I am typing on my wife's iPad and I find I try to avoid typing too much with this keypad

Hello ellesshoo, In theory you could "run out of hops" with a long string of devices, on a long enough cable run, with limited RF communications capability. Message timing can vary greatly depending upon whether it is scene or group send or a standard\extended direct message to one device. Below all assumes a standard direct message sent with 3 hops: Initially with good signal strength the initial send ( or hop #0) will be received by other devices. If the message was sent with 3 hops , all 3 hops will still be sent, but the message may be received right away at hop # 0. As you add more devices to a cable run they each add to the attenuation of the signal strength. If you have good RF comms that can compensate for this. If you have limited RF capability then it is possible that the signal begins to degrade enough that some devices need to rely on simulcasted hops from other devices. They may receive at the 1st hop. If the line is long enough, with enough devices others down the line may receive on hops #2 or hop #3. Another item that plays into how fast a device appears to respond is retries. If all 3 hops are used and the sender does not receive a acknowledge response it will retry several times, at the PLM level. Then on top of that the upper level application such as the ISY may also retry several times. With really good communications the message exchange may only take ~100 milliseconds for the intended receiver to "hear" the command. As the comms begins to deteriorate the time to receive begins to increase. It can take near to 1.5 seconds if the PLM is retrying up to 3 times. Even more if the PLM is not "hearing" any responses at all and retries 5 times. Then on top of that if the PLM fails to get a response, the ISY may do retries on its own. I forget exactly but I think the ISY waits about 8-9 seconds if messages are failing to get any response?

hello djones1415, Do you think it is coincidence that it occurs after 3 days or is it possible there is an event that coincides with the problem showing up? In particular are all 3 switch locations exercised regularly, possible one location is rarely used ( maybe every 3 days or so?) Can you have another person help you do a test? One person watches the status LED at the problem switch location while the other person switches each of the other two switches on and off several times slowly. Does the status LED behave erratically when one of the other switches is operated? Any chance this problem switch might be losing power when one of the other switches is operated? You mentioned your electrician had problems getting it working. Can you have him, or can you, sketch a diagram of how it is wired and post it?

I was reluctant to upgrade my code but knew I had to address the java issue. After my update last night to 3.3.9 I was surprised to see there is yet another new release now. I am not very knowledgeable on java usage. Can someone please help me understand the new access method? As I think I understand that we required java to be active previously because we went into the program via a browser. Now we need an application on our computer so we can access it without a browser. This then allows us to disable java in the browser for better security? After I followed the procedure I am having a small error yet that I would like to correct. I now have the 99i icon on my desktop. When I click on it it states "error". I need to use the isy finder and type in the address. I used this: "http://your.isy.ip.address/admin.jnlp " but it would not work. If I left off the "/admin.jnlp" It recorded a find. However now every time I try to access the program I still get the error and need to click on the one entry that was found previously and was retained in the window. But of course that entry is missing the "admin.jnlp" on the end. Is this a problem with not knowing the path to find admin.jnlp? What might be my best bet at fixing this issue?

A hub is over simplifying the issue. I would expect to pay $20 or more for a decent rs232 to USB converter. Then the next thing you would be missing is one end to power the USB bus, as well as USB master to control the bus. Buy a 2413s.

Thank you LeeG, I had tried the group broadcast direct previously but it appears I was putting the group number in the incorrect position. After monitoring the ISY I got it to work just as you said it would. Very cool ... Using the Fast ON and Fast OFF commands I was able to get it to run with only 50msec between sends and it appears to keep up pretty well visually and and with no naks from the PLM!

Hi leeG, I did not understand your comment about issuing group broadcast commands directly? I thought that a group broadcast command was automatically followed by cleanup message? Can you please cite the command format you are referring to? I did look through some old public domain Insteon command listings that hinted that old legacyv2 devices might have supported group broadcast commands without follow up cleanup message? That made me wonder if device changes over the years might have caused this light show program to then become less desirable due to speed limitations?

Hello Brian, Do you know how that device was able to accomplish 20 commands per second? Even with 0 hops and good communications I am wondering how they did that? I have tried for a "fastest communications" rate a couple of times in the past without such speed success. If I remember correctly I was lucky to get about 3 commands/sec even when devices were right next to each other and 0 hops. Do you know what command structure was used in that device? If it were direct with 0 hops you would still have the ack command. If it were group broadcast there would be a cleanup message? Is there a command structure that can be used that would send only the 50msec standard message length hop 0 and cause no other response traffic?

Merry Christmas Someguy, The PLM stores its link records in what is called an EEprom. Depending upon how well they are designed into a device they have been known to get corrupted. Any chance you experience brief power outages from time to time? One way in which that type of memory can become corrupted is during a brief power outage. Not real common but possible depending upon the timing of the power outage. Another possibility is a loose connection between the serial daughterbrd and the main PCA. The EEprom is located on the daughterbrd and if the connections between brds becomes loose that could also corrupt the links memory. I tended to exclude this possibility based on the fact that you have experienced this on two different PLMS. Any chance you have the old PLM or a spare? I would like to ask LeeG to comment here if he thinks this would be worthwhile or not? With a spare PLM as the interface you could use Simplehomenet Suite to read the link records of your suspect PLM. If you then viewed the raw serial data you might be able to determine if the first link record location has been totally zeroed out ( as in a factory reset) or if just the first byte might be corrupted, for some other reason. Ideally you would read other locations beyond the first as well but I do not know if SHN utility will allow that. That can be done using a terminal program.