matapan

When I started out with Insteon, I was looking for a good controller solution. Based on the feedback I received on some online forums, UDI made the ISY99 and this was the controller everyone except perhaps Smarthome recommended for a well supported Insteon controller. Over the years, UDI has provided great support for their controller and Insteon devices using their controller. In hindsight, it was probably not something the company necessarily wanted to do, but to provide a good support experience they helped where they could. Kudos to UDI for this. By creating a layer for specific device technologies to work with Polisy, UDI has decoupled support for any specific protocol, leaving this responsibility up to the nodeserver publisher. This is similar to writing printer drivers for an operating system. Whether or not all of the available services in the OS are supported is implementation-specific. The incentive for those publishing nodeservers probably vary. Someone might be interested in publishing a nodeserver because they wanted a specific capability as a user themselves and they know how to write it. Or, they may want to publish a nodeserver for profit. The individual who wrote a nodeserver for themselves may not want the burden to support it and might ask people to use it as is because they may not be interested in the support aspect of it. The difference between printer device drivers and a nodeserver is that the printer driver drives the sales of the hardware. For someone trying to evaluate where they're going to go beyond Insteon, it's really hard to tell without making some substantial hardware investment to do an in depth evaluation of a nodeserver. Having some certification of nodeservers published describing their capabilities by some definitive feature set support would be helpful for someone trying to evaluate the next step beyond Insteon. As devices start failing, as they will inevitably, users will have to stockpile on backup Insteon devices to keep their setup going or migrate to a new lighting platform. Prescriptive guidance on what works well is very helpful if one chooses the latter option.

Don't get me wrong. It's a wonderful thing to see an active community engaged in expanding the capabities of what's being developed here. As an installer though, I would think you would want to know what is rock solid, stable and fully fleshed out before deploying it to minimize callbacks from your customers. The various levels of development stages different nodeservers are in does require people to dive in and really see what does work and what doesn't. I get a pretty good sense of where Polisy is now from the comments received so far. Thanks!

All I am asking is if there is a way to discern at a glance how fully fleshed put any given nodeserver is, particularly the ones one would pay for. The unique model presented here is one where the Polisy is a platform on which support for specific devices is left to 3rd party developers or power users. With other controller applications on the market the publisher provides and maintainance for the platform and device support. The quality and degree of the device support is inherently more consistent in general when it’s centralized. How does a potential customer decide if a feature set is “good enough” before taking the plunge with Polisy? Also, is there a package deinstallation process for any given nodeserver?

Having recently upgraded my ISY 994i controller to version 5.3.4, i was curious to see what significant changes existed in this new release. Apart from subtle changes in the UI, it seems pretty similar to the 4.x releases. I’m presuming the major changes allow for users to move beyond Insteon and ZWave with Polyglot and the different nodeservers people are developing. This sounds great in theory. I have a question though about release management. How does one assess the state of development with any given nodeserver quickly? Are there official releases of nodeservers with a defined feature set? For example, a number of users on the forum have been discussing new lighting platforms to migrate to, like Lutron. In perusing the Lutron Caseta nodeserver forum, it seems like it’s still in development. Is there anything published on the site or forums that summarizes the release state of each nodeserver? Also, are there user instructions on how to acquire and install any given nodeserver package on a Polisy device?

Hello fellow users: I was curious about the longevity of a 2413S PLM after it has been recapped. Noting that the suggested replacement caps sometimes have slightly different specs, presumably to improve reliability, it would be great if people who have done the recapping can share their experiences on how long the PLMs last afterwards. This is helpful for users who plan on keeping their setups going for a while; one can do some forward planning and plan on performing preemptive swaps of PLM's before the failure dates and perform service on the ones that were swapped.

For those of you using Z-Wave in earnest with your ISY setup, are there any Z-Wave switches that support the N-Way switching feature that Insteon switches have? Are there any good alternatives to Insteon Keypadlincs? I really like the layout and arrangement of the Keypadlinc buttons. Better than Lutron.

I found the tutorial on replacing the tact switches on X10 generation Smarthome switches. They are relevant in repairing Switchlincs with bad switches. The 2477DH has only one electrolytic capacitor, fewer than the ones on the PLM. Opening up a 2477D shortly.....

I've got a number of Switchlinc Dimmers with various issues, from non-responding paddles to noisy (buzzing) switches, to being outright dead. I've seen various threads over time which I can't find any more on repairs. Has anyone got some pointers on repairing these switches, both 2476D and 2477D(H)? Specifically, is it a good idea to drill out the metal rivet holding the PCB to the aluminum frame? Should this be riveted back?

Thanks BrianH. In an earlier post, OberKC suggested using film capacitors to replace the low voltage capacitors to increase reliability. Is this something that is possible? Also, is there any difference between a 2413U and a 2413S other than the daughterboard? Can a daughterboard from a 2413S replace a 2413U daughterboard to make a functional 2413S, providing the daughterboard is functional? Finally, for the 2443 Access Point, is there a way to tell if the access point has stopped functioning, other than to look for the presence of a lit LED indicator?

Given the length of this post, I was wondering about a couple things: For a v1.0 2413s, is the original post for component replacement still the best list to follow? How long have people found the repairs to last? Another couple of years, or longer? Is there a modification which would enable this module to last much much longer than what people were experiencing with the original unmodified module?

Based on some of the posts here, may I offer several suggestions? - In the Admin Console's About Page, provide the software and firmware version of the ISY, along with the hardware information about the board installed and memory size of ISY. - In the Wiki page, provide information about any collateral impact a board upgrade may have on existing devices ISY has collected information on. Is the upgrade seamless after a board swap?

Thank you all for your suggestions. I performed the capacitor replacement as it was low hanging fruit. This did the trick.

The components with heat marks include the rectangular component with the inscription “15 30” on its top and the resistor to the right of this component in the image. There or no legend markings on the board which would give some clue as to what these parts are.

I use a Controlinc for turning things on and off at my bedside. Recently the unit would stop working for no apparent reason. Power cycling the unit would make the device usable for a time, but the usable time has become shorter and shorter to the point where the device is unusable. i opened up the device and noticed heat marks on the PCB around two components pictured. Does anyone know what exactly what these components are and where i can find replacement parts to repair the Controlinc? Thanks.

I just ran across this post. There are many IP to serial converters on the market, from single board modules you attach a wall wart power supply to and connect your network via network cable. These are available from Fry's or Jameco and run about $35. FWIW, I used about 3 of these boards for a similar application with the Network module without any issues.

Thanks for all the replies. Good to know that the alarm sensor states can be used by the ISY programs directly.

I purchased an ELK M1 alarm system which I plan to install in the new year. The alarm system will be outfitted with its own complement of motion and door sensors. With Insteon and ZWave motion and door sensors available, what makes the best sense for installing in the house? Are the sensors attached to an ELK panel visible to the ISY in real time when you purchase and install the ELK module? Are those sensors available to be used in scenes or programs? Or, is it better to use the Insteon or ZWave sensors in parallel with the ones already used by the alarm system? I noticed that some security alarm systems use ZWave sensors now. Is it better to go that route and integrate that type of alarm with ISY?

I am in the same boat, having just installed the ZWave board. I would suggest that for every device you add, you explicitly disassociate the device from the any ZWave network before you add it. Sounds funny, but every device I tried adding did not register with the ISY controller until I did this.

Thanks, Teken.

Does anyone have the jumper setting information for this early version motion sensor? My understanding is that the jump setting definition changed going from v1.x to 2.x. I have a MS v 1.1. Thanks.

EZX10RF converts your wireless X10 signals to an Insteon command sent to an Insteon device you map the X10 command to. It's useful for applications like Homelink, where you want to either activate a scene, run a program or toggle an Insteon device triggered by the wireless X10 command. If you have a X10 motion sensors, it's a cheap way of checking occupancy in any area of your home.

I'm using an EZX10RF X10 to Insteon gateway. Sometimes, I add a node to the device tree for a specific house and device code that doesn't work right. Is there a way to get rid of these nodes without getting rid of all the nodes under the gateway device? This would be very useful. Right now, I just mark the wonky node 'unused'.

Thanks for all the feedback, especially your post, paulbates. This was very helpful. I should clarify my post. I have an ISY994i, not an ISY99i. Hopefully my error is useful to some who actually have an ISY99i.

I think a list of the Insteon devices added to the list of ones supported would be useful. Also, it would be most useful to provide a brief explanation of how the security enhancements are useful to the average user, with any instructions on how to use them, if they are not transparent to the user. I understand many of these enhancements are improvements to assist the developer/integrator community. But where relevant, some of this information is useful to general ISY users too.

Is there any sort of abbreviated summary of functional improvements and bug fixes between major ISY firmware releases? From what I can see, the list of changes is summarized by each incremental release, and it pretty granular.