lilyoyo1

Did you even try to pair it? The app has a way for monitor only

If you have zwave, theres a tilt sensor which would work better for you

DA is ok but still falls short of insteon in that responding devices do not report status when turned on in this manner. I haven't quite figured out how the Isy handles this but with the way I program things, it's not really helpful to me due to that limitation

The way zwave communicates has always been a hangup with many people. This is why you get the popcorn effect when turning off groups of devices. Since they use routed messages in general for their mesh, I assume it would cause more issues to send a group trigger at once along different routes than 1 command at a time. The idea for direct association was to lessen the load on a controller and speed up communication. Using their own example of a motion sensor and a switch; do you really need a controller slowing down response for that. If you have dynamic lighting (lighting profiles for difference situations), then a controller managing things makes sense. But if you have a simple light that will turn on/off, does it matter? All hardwired devices can be repeaters along a route. What they are referring to is specifically being able to control another device and being aware of how/where to send information. To break it down, a standard device along the signal path only knows the device it's supposed to listen out for and repeat to. In essence, switch 2 knows switch 1 will send a command to it and that it needs to talk to switch 6. It has no idea that switch 3,4,and 5 are out there A scene capable controller on the other hand can talk to devices not on its route. This means it can learn and make paths so that it's signal can get to those other devices. Going off what I said about normal devices, switch 1 knows about switches 1-20 and uses 3, 7, and 11 to talk to switch 15. I don't know why they chose this path. My guess would be cost savings. While It does result in less congestion and clashes vs a broadcast message, it also saves on programming since an OEM doesn't have to do extra coding to make things work. A static controller is simply the main processor such as the Isy that provides an application to allow you to set up your devices.

All of my frustrations with zwave summed up in 1 post. It's a convoluted mess which is why I pretty much refuse to use the protocol outside of ancillary devices. Every controller handles things differently (if they support them at all). I know homeseer and fibaro's home center controller has specific sections to set up the associations that you choose using the proper group#. But, each device has to support what you're trying to do to make it work. Since they talk about alot of different things in the article, which parts are you having problems understanding?

You're better off posting on eBay. Since forum members here are already Isy users, i think you'll be hard pressed to get anyone to buy a product that doesn't even make for a good paperweight

I'd remove the device and connect it to a pigtail and factory reset it. If it stays on then it's a problem with that location

Do you have the 300 board (light on back of ISY) or 500 board (no light). If you have the 500 board, Id recommend upgrading to 5.3.4 to see how things work. Most likely, you'll need to set the parameters using the owners manual found on the mfg. website

It would be helpful if you post your Isy firmware and UI

There are 2 different worlds we're dealing with. The insteon world which is all device to device (whether a single device or group of devices) and the ISY. The ISY doesnt status scenes but Insteon devices does. Factory reset a responder switch and see what happens with the controlling switch led. You'll see it flash red due to not receiving an acknowledgment. The reason I separate the 2 is if you are having problems with devices not turning on/off via scenes, watching the controlling switch itself can help provide information about whats going on since linked devices are updating their statuses properly. My only issue with his statement is telling a newbie a less than ideal way of interacting with his devices due to him having an experience with a single bad device when there are countless thousands of others using scene capabilities without any issues like this. Scenes are a powerful tool in an installers arsenal (look at how many struggle with zwave). Trying to get someone to steer clear of them is a disservice to the user. This is made even worse when you can increase the retry count (if needed) between controller and responder

They run sales from time to time. I've seen them give people chances discounts post sale when asked but that's usually fine close to the sale end date

Did you clear your Java cache and use the launcher from the 5.3.4 upgrade page? Does your UI match your firmware

Let's get this right, you have an issue with 1 errant device and that makes the protocol bad and the people are morons. Yet tens of thousands use scenes every day without experiencing the same thing. Insteon devices actually does send confirmation status to each other. That's why you'll see the red light blink on a device when it doesn't get an acknowledgement. The isy assumes the device state when it processes scenes. Regardless, scenes are much much more efficient and faster than programs. But to each their own.

Do not take shortcuts when setting up Isy/polisy. There is not a single person that has, who has come out with a great experience. You will have issues at some point. When you bring in your devices, so you are bringing in is Id numbers. This can mean spending more time running around trying to figure out what they go to. I use the 2448a7 on 1 Polisy, and the 2413s on another. I feel like I get better performance from the actual PLM but there's no definitive numbers to say different.

There's best practices found through experience and what the manual says. It's like going to school or job training. What they teach you is one thing but real life is another. That's where exclude then include comes from. The device may not have been added to your system but do you know if it was tested at the factory? What about it being re-flashed. Was the proper procedures followed? That's why everyone says exclude then include.

What's the wait for

No. It's like anything that happens once and disappears. It could be anything.

If it only happened once it could be an errant signal. You could factory reset the switch and restore it to be safe

Under the label

I'd upgrade to 5.3.4 just in case there's been updates that 5.3 doesn't have. You may need to look at the device owners manual to see if any parameters for that device needs to be set. It may require programs in order to work. If so, you'll see the options in the if drop-down menu

Every program is independent of each other unless purposely written in such a way that connects them together. Is: if this happens then run program 2

Thats not unique. Many on here will tell you to factory reset brand new insteon devices as its not uncommon for devices to have stored test links. zwave devices do not stay awake long enough to send their signal and update parameters based off motion to conserve batteries which is why I said to wake up the device to set your parameters. If this is your only zwave device, depending on location it probably wont update since it would be out of range.

It's the same for the most part across the line. Cut power (pulling out the set button cuts power) then apply power while holding the set button in. The length of time varies based on age of device but has been consistent since 2013

Take your face plate off and use a butter knife or small flat head screwdriver. It's really not that hard. They purposely made it hard to prevent accidently resets. It's not something one should have to do on the regular basis where it's made easier

Judging by the steps you took to get things added, I'd say you're doing things incorrectly. Prior to adding any zwave device you should first remove the device. Then hit add. It can take a while for all zwave nodes to appear in the Isy. While staying close to the Isy (unless you have a strong mesh), that's when you want to configure the parameters. In order for them to take, you must wake the device up prior to submitting the parameter changes.