lilyoyo1

When you're talking about different countries, many things can behave differently due to differing local restrictions

Would've been great for you to supply that type of information in the very beginning. Could've saved us a lot of time

What we've been saying all along. The fact is, when you upgrade, all of your links are there. Download both at the same time and you're ready to go. With your way, you have additional steps. Not hard steps but additional nonetheless. In addition, since you haven't been using the launcher, you're still having to clear java as well as missing easily accessing polisy.

It's not that we didn't know. Just more efficient ways of getting the console in addition to that being an outdated way of accessing the admin console

Sounds like steps someone else we know would take. ?

I'd submit a ticket

I think it's the 2448a7. I have 2 polisy's set up. 1 with the PLM and 1 with the USB stick (both have different zwave boards too). The one with the PLM doesn't have any issues with talking to the same devices that the 2448a7 has. Both are in the same location and trying to talk to the same devices. The 2448a7 will miss button presses resulting in me restoring the device whereas the PLM will work flawlessly. The power line signal works faster than the Rf signal so there may be a slight decrease in communication (possibly imperceptible). I suspect the board being smaller means its a slower processor in the USB stick as well vs the PLM. Scenes will always work faster than programs so i use scenes for everything (programs will trigger my scenes too). Insteon devices will receive a response from responders but the Isy does not status devices when controlled via scenes. This is why you may see a switch blink red due to not getting a response. I've moved some of my setup to the 2448a7 for longer term testing so hopefully future updates will make things better as I'd rather use that than the PLM which takes up space.

Not that I've seen. If they are zwave+ then your devices would be 500 series.

Leviton is the only one I'm aware of still using hail.

There are no updates for them to issue at this time. Once they have a better idea about things and get it back up, THEN and only then will they update us. As MrBill stated (I concur with his reasons), I highly doubt it will be a quick fix. This is mainly due to them wanting to ensure that something like this doesn't happen again. Yes, I'm aware it's hard for causal users to keep up but then again, if a user is so casual they don't receive the emails and miss the very first post on the forum, they'll probably miss subsequent updates and details as they come in the future as well

If you use the launcher you can do that

They already do that. One just has to read them. You'll usually find major announcements on the very top post on the forum homepage. News concerning individual nodeservers are generally found on the actually nodeserver page. Yes, PGC is for cloud based nodeservers. Pg2 is for RPI based nodeservers which most likely will not be supported going forward (unless the individual developer chooses to). PG3 is for Polisy based Nodeservers

You must read AND follow the instructions exactly as it says on the 5.3 download page. Clear your Java cache and use the launcher found on the 5.3 page

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