matapan

I've been playing with Z-Wave devices recently. The observations others have had are worth repeating here: 1. The reliability of your Z-Wave installation is wholly dependent on the number of Z-Wave devices in your installation and how far each device is located from each other. For example, to have a one or two device installation that has one of the devices two floors up from the ISY is not going to work. But if you have devices that are close enough to talk to each other from the ISY, like lights on a string, it's possible to work your way up to the device two floors up with intermediary ZWave devices acting as repeaters and make it work. 2. When installing the new ZWave device, it's always a good practice to remove it from the network even if it was never asssociated with it before adding it. Also, it's a good practice to be within close proximity of the ISY when adding the device for the best experience adding the device, if at all possible. I had the idea that ZWave was going to be a good and solid alternative to Insteon when I started this investigation. Now, I'm appreciating the existing Insteon installation for its capabilities and performance. In addition to trying new ZWave devices, I've tried using a few Zigbee devices on a Smartthings hub. From the things I've tried so far, the Zigbee devices communicate farther than the ZWave 300 and 500 devices I've tried do. I haven't tried any 700 devices because the ISY module supports only 300 and 500 devices. I have not upgraded to Polisy yet.

Thanks for the information. Nice to know that a ZWave network reverts to the lowest common denominator. If it’s critical to ensure one is using only Zwave devices of a certain pedigree, how can you tell from the Admin console the relevant device information? With Insteon devices having the device name and version number is very helpful. Any similar information offered for ZWave devices? 300, 500, 700 type device?

Also, can ZWave 300 devices act as repeaters for ZWave 500 or 700 devices? I can see a scenario where I use the old ZWave On/Off modules as repeaters to connect a ZWave 500/700 lock to ISY, for exampe.

I've been adding a few ZWave devices to my installation recently. A few plugin on/off modules to start. I have a Utiltech moisture sensor and a AT&T Digital Life garage door controller I'm thinking about adding. After reading some of the posts here, and how there are different ZWave versions, I was wondering if it's okay to mix old and new devices in a setup. Some ZWave 300, some 500 and 700. Or, do the devices that are used all have to be using the same version controller?

For the commerical industry, I'm sure there are good, well-designed solutions. Same thing for high end residential installations. The mass market stuff isn't though, and the players in the space for the most part are pretty immature IMHO. While Philips is a well known company in lighting, I wouldn't necessarily call the Hue offering to be a very complete line. From a product offering perspective, Insteon is pretty comprehensive, less a good lock offering, and Lutron is reasonably comprehensive lighting control offering. You can cobble a bunch of Z Wave products from different vendors but industrial design maturity is in the eye of the beholder. Things tend to look like a collection of mismatched assemblies in the Z Wave installations I've seen so far.

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.