matapan

With all the discussions related to quality and design-related issues revolving around Insteon and Z Wave on this forum, I personally have had enough trying to use things developed by startups or small outfits and go with something that’s better engineered and thought out from the onset. I’m sure you’ll pay more but the headaches of Insteon reliability and functional limitations like dimming limitations really have tempered my drive for a more reasonably priced solution. You get what you pay for with lighting control hardware it seems. From a support perspective, yes it’s hard to support everything and spreading onself out too thin for a small company so I was curious if Lutron support would be considered something worth of investment in time and resources. Good to know it’s being seriously considered. As some other poster kind of suggested the lighting control hardware industry needs to mature more still to be adopted by a population beyond well heeled people and hobbyists. (Last part is my add!)

When Polisy eventually matures, it will be interesting to see what nodeservers are developed for it and how they are supported. ZWave may be the current migration path from Insteon. Personally, I’m unimpressed with the industrial design of thr ZWave devices I’ve seen online. In particular, there seems to be no real alternative to Insteon Keypadlincs. All the Zwave functional equivalents are so clunky. To be frank, I’m curious to see what support, if any will evolve for Lutron products. Lutron has been around for a very long time. They make high quality, well engineered products. I haven’t seen any installations using Lutron product fail like Insteon products do, and their product industrial designs are tasteful. Having reliable hardware paired with a versatile home automation controller seems like a good combination. Lutron is not sold through retail channels though, except For their Caseta line. It’s hard to determine from a consumer perspective if Caseta devices are interoperable with any of their professional lines like Radio Ra3. Would Lutron support be offered by UDI if there was a lot of interest in it, or by a third party node server developer? Personally, I would feel more comfortable if UDI offered support for Lutron for the simple idea that it would be easier to deal with a single entity for something as significant as a lighting system over something minor like IR remote control device support rolled in the form of a node server, for example. The versatility of ISY with the Networking support provides users with some latitude to develop their own integration solutions if a nodeswrver solution wasn’t satisfactory.

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?

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.

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.

I picked up one of these thermostats at a good price recently. I did a search in the forums to see if there are any issues with this thermostat and ISY-99. Are there any major issues currently to be aware of as it relates to using this version thermostat in an ISY-99 setup?

Can someone provide some information as to what the Schedule button does? Can one modify the existing schedule programming built into the thermostat? Or, can one obtain the scheduled programming information from the thermostat to create ISY programs that don't get overridden by the thermostat's own programming if the thermostat is left in the Program mode? Which thermostats and/or interfaces are supported with this functionality? Thanks.

I have a 2441V thermostat adapter, v2. Before posting this question, I checked the Wiki and found no reference to this button. Can you point me to the page where I can read about this? If the button is not supported for my particular setup, would it make more sense to disable or hide the button, or throw up a context specific error message which indicates this functionality is not supported for the device selected?