Bumbershoot

Not exactly the information you're looking for, but here goes: I don't use the Z-Wave scene feature, as my Z-Wave network isn't extensive enough to make use of them (yet), but I put a couple of Z-Wave switches into ISY scenes (along with Insteon switches), and they work just fine. Not quite as fast as native Insteon lighting scenes, but they're becoming acceptably fast. The fastest seem to be those that use the Z-Wave 700 series chip, specifically the Zoos Zen76 switches. I've put these switches into scenes with Insteon switches, and they're quick (the performance seems identical to using an ISY program, FWIW). I don't yet know how this will impact the "popcorn" effect produced by earlier Z-Wave lighting solutions, but I'm hopeful that this problem will be materially solved. I'm speculating (and hoping), that with the ISY/Polisy Z-Wave enabled with a 700 series stick and utilizing 700 series switches (and/or repeaters), the combination will produce much faster Z-Wave performance. My understanding is that a 700 series network is significantly improved for speed over earlier iterations.

Hi @Michel Kohanim, how's the big endian to little endian byte order swap proceeding? I'm starting to think about a migration strategy, but I shudder at the complexity of recreating my current environment. I'd be willing to test a backup/restore function from one platform to the other, if you're on the lookout for volunteers. I think... ? EDIT: I have both serial and USB PLM's and I just ordered the Zooz Z-Wave stick. 16 nodeservers running as well...

If you're trying to test Polyglot 3, you can start it with this command: 'sudo service pg3 onestart'

Press and hold the bottom button until the LED flashes once. If it flashes twice or three times, then you've set it to medium or low.

I guess YMMV. I have the motion set to "high sensitivity" and they work reliably and quickly, better than my Aeotec multi sensors. I don't see any use for the "medium" or "low" sensitivity settings.

I just saw this, but have a look here:

You'll probably need to open a support ticket.

I just noticed that this thread got a bump, so I thought I'd throw in my 2¢ about these. I've got two of these Z-Wave garage door openers installed, and while they work as advertised with my ISY, they haven't been without issues related to the quality of their components. Mine are repaired and working fine (I've had them since 2017, IIRC). I don't know if the current crop still exhibits failures, but here's a link on how to repair these, should anyone be interested: https://community.smartthings.com/t/linear-garage-door-opener-stopped-working/70083

If you're referring to PG3 and/or the ISY on Polisy, then no issues at all. Nothing in production on that platform here.

I did the opposite, changing the Ecowitt device and nodeserver to use port 8082. Either method should work. This port conflict between nodeservers and the ISY is something that UDI should be aware of as they prepare PG3 and the Polisy/ISY for release. Flagging @Michel Kohanim and @bpwwer as a courtesy, though dollars to doughnuts they know all about these port conflicts...

The Ecowitt nodeserver has the same issue (using port 8080). I changed the port and everything works as expected. The developer has been notified.

I happen to have a USB PLM laying around. This should be interesting...

I believe it is fixed in 5.3.3. I use "adjust scene" to change on levels based on time and/or ambient light levels and it just works now.

User @simplextech started this list here: https://github.com/UniversalDevicesInc/Z-Wave-Devices/issues

Yes, it's the BATLVL property. Something like this should fetch the value into a report: ${sys.node.ZW024_1.BATLVL}

@mango, I don't think there's an elegant way to do what you're trying to do. You have to work around ISY limitations with regards to STRINGS. The first thing I did is create a program that puts user # into an INTEGER variable, and the lock status into a STATE variable. When the status of the STATE variable changes, I have another program that will evaluate a couple of conditions, and if the conditions are met, it will use both variables in the body of an email. I put a small static table (for user lookup information) in the body of an email customization. Below is an example of what the email look like: The Garage Door lock status is ${var.2.27} 0 = Unlocked 1 = Locked Person making this change is ${var.1.5} 0 = Manual or programmatic unlock 1 = Lori 2 = Brad 3 = Zak 4 = Katherine 5 = Wally 6 = Norman 7 = Ann

Try the bottom of the Z-Wave menu: Z-Wave | Z-Wave Version Selecting this option should produce a pop-up window that looks something like this (screenshot).

Alfred Locks makes their DB2-B, which comes in gold and has an optional Z-Wave module, which gets you above your price point, but the locks seem very full featured. https://alfredinc.com/collections/products/products/db2b

I've fiddled with my older lock (non Z-Wave +) a few times, and network wide inclusion doesn't seem to work with it, no matter how close/many repeaters are present. I've just had to remove it from the door at take it to the ISY (within 10 feet or so, if memory serves me correctly) and include it. I believe you can exclude it in place, however, just not include it. This was explained to me as being part of the "S0" security that the lock/ISY employ (as a way to defeat packet sniffers, man-in-the-middle attacks, etc., during setup). My lock is probably 75' away from my ISY. I don't have a Z-Wave + lock, so I can't report on that. All of my Z-Wave device that have security use "S0", so they all had to be included close to the ISY.

An observation/perception with Z-Wave performance on 5.3.3: I'm perceiving that my ISY is handling Z-Wave device updates faster than it has in the past. I don't know if this is true, as I don't have data to back this assertion up. This is perceptible in a couple of device types in my installation: Z-Wave motion sensors, my single Z-Wave lock and the state changes in my garage doors. None of my Z-Wave motion sensors are battery powered, but with this firmware, it very much seems that the ISY turns on the lights upon motion being sensed quicker than previously, which is nice. Also, when I open/close my garage doors, I notice that the firmware shows the transition from closed/opening/open almost exactly when the tilt sensor changes state. This has never been this quick or reliable. Additionally, my single Schlage lock displays changes of state in the AC immediately instead of a few seconds later. This just makes me think that UDI is getting their Z-Wave code optimized in their firmware. Not a big deal (and maybe not even true), but I'm liking my Z-Wave devices a little more with this release.

The 2477D is in 5.3.3 (see screenshot). Also the MS II can be added from the menu tree: "Link Management | Link a Sensor | Motion Sensor II"

FWIW, they fixed this issue with Adjust Scene in 5.3.2, which has indeed worked with my battery powered scene controllers. From the notes: 0000774 - Green icon appears on Insteon Controller Node after using Adjust Scene

@fasttimes, these dialogue boxes are what the "Options" and "Users" buttons at the bottom of the pane produce.

Installed. No apparent issues. The first thing I did is exercise my Schlage Z-Wave lock from the AC, and it operated as designed. EDIT: Are these new icons in the context menu in program details pane? Maybe I didn't notice them before...

No metal doors here. Stick frame house, probably 4 walls and 30' between the siren and lock, and the siren is probably 25' from the ISY. EDIT: The door the lock is installed in is metal clad. I just checked.