lilyoyo1

I'm sure all of them will be ported over eventually. It just takes time. In the meantime, pg2 version still works

That hasn't been my experience with them. Unfortunately your experience is different than mine. You could give their forums a shot

The very first link at the top of the forums has a message from UDI stating that PGC has been temporarily shut down due to a security vulnerability. You should have also received an email saying the same thing

Unfortunately I can't help you. The few times I've had a door fail to add, it automatically went into monitoring mode with the sensor. Maybe there's a problem with your hub. I'd check on myq forums or give their support another call

Go through the process. It'll eventually fail and put you in monitor mode only

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?

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

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.