matapan

I have a few ideas to put forward that I haven't fully qualified. That said, I can't think of any negatives at the moment: 1. Use a X10 motion sensor. They're wireless, battery operated and low cost. Install a tranceiver to convert the signal to powerline X10 near your PLM and I think this might be an easy way to achieve your objectives. Some of the motion sensors have seals to make them usable outdoors. Both the sensor and tranceivers are pretty readily available. 2. Use an older Insteon motion sensor. They have programmable countdown timers. I think the default is 30 seconds but you can adjust the ON time to be longer. 3. Use a ZWave motion sensor if you have the add on Zwave board in your ISY. If you go this route, I would make sure the countdown timer for the ON duration is adjustable to your requirements. I know that with the one ZWave motion sensor I've tried so far, the countdown duration is a fixed 4 minutes and it cannot be adjusted.

You could always check to see if the switch controlling the load was turned on and set a variable to indicate that the switch was manually turned on and set the variable to zero and enable the countdown program for turning off the light by motion sensor when it is manually turned off. When the motion sensor is activated, you can check the value of the variable to see if the switch was turned on manually. If it was, then you can disable the countdown program. I think that is what you're asking for.

I used to think that Insteon was just completely unreliable because the build quality was highly suspect. After completing my current install and using for a while, I've changed my opinion somewhat. Coupled with ISY and in particular the ability to set retries for commands that get lost on n-way switch circuits. I think it's much better than my old install for the fact that it's dual band and Smarthome seems to have improved product quality somewhat. The jury is still out for me as far as reliability is concerned. But armed with the ability to repair my PLM, I think I'm good for a while. Most of the devices in my current install are dual band devices where my previous installation had more single band devices and a few dual band ones. I tried Wifi plugs in the form of Wemo modules and Smartthings; if your Wifi coverage is good, they seem to work okay. I don't think you get the mesh networking aspect of signals being repeated between devices that you do with Insteon or ZWave. Someone here can correct me if I'm wrong. But I've had a couple of Wemo plugs have problems communicating back to the Smartthings hub, presumably because of range issues and interference where the plug was located. I'm thinking that if you have enough ZWave devices to provide adequate coverage, that may be a good alternative. The number of manufacturers making ZWave devices is comforting from an installation lifecycle perspective. My personal issue with ZWave devices is that they generally don't look good, industrial design speaking. The newest Nokia/Smartlabs offering look nicely designed, and so does Lutron's offerings. ZWave devices seem to fall into two categories: really generic and plain, or a device that has a very sophmoric, toylike design. There's no elegance to these devices. If I was looking to replace my Insteon installation, I would be looking at Lutron. I've never seen a Lutron installation with glitchy issues. Their dimmers work great and any questions about reliability have never come up. They look good and purposeful. I've seen a total of 6 Lutron installations. A small sample size for sure, but no one who has one of the installations has ever chatted with me about how to get around this problem or that problem. It costs more for sure. But you get the assurance of a well engineered, reliable product. There's a separate discussion on this site about questions some people have with the latest wireless offering from Lutron. I'm personally just waiting to see how well these wireless retrofit systems work in practice.

While the prevailing sentiment now seems to be a move towards Z-Wave, I would caution you on your approach with respect to migrating to Z-Wave: As many others have suggested here in various ways, it's imperative to build out your Z-Wave network starting with the devices closest to the ISY and work your way further away from the device. That is if you're considering a slow migration. Like dual band Insteon, the reliability of your install is highly dependent in the number of devices deployed across your space. My first Insteon installation was made up of mostly single band devices with access points and a few dual band devices installed. The integrity of the installation had a lot to be desired, with virtual multiway switches not syncing with each other and erratic behaviors. It was awful in hindsight, made worse by the reliability issues people talk about. My current Insteon installation is comprised of mostly dual band devices with a few single band devices sprinkled in. The reliability of this installation is significantly better than the first one. The takeaway for me is that dual band Insteon is essentially like Z-Wave, working predominantly across wireless signals rather than powerline. I'm sure this isn't completely true, but my current installation has so many dual band devices evenly distributed across the space and it works so much better. It's hard to imagine how one would get a super reliable Z-Wave install without going all out and replacing your Insteon devices with Z-Wave, or doing a gradual migration starting from the ISY out.

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.