Bumbershoot

Thank-you for that. It was already worth the price, this makes it even more so.

For nodeservers that directly control devices, this pricing model won't discourage me from any of the nodeservers I'm currently using, as they are generally a fraction of the cost of the controlled devices themselves. If I have a single $50 device and have to spend $10 on a nodeserver to control it, then I might think about it. Nodeservers that provide data to the ISY buy don't directly interact with devices (Sun, Timedata, Backup) would seem to be good candidates for the annual subscription model. Nodeservers that directly control devices seem to be good candidates for a one-time payment model, similar to the devices themselves. After all, I don't rent my devices, and I don't want to rent my ability to control them.

I'm not expert, but that's my assumption as well. EDIT: It looks like if you right click on the Z-Wave device in the device tree, and navigate to the context menu item, "Z-Wave | Show Information in Event Viewer | Network Details" then look at the "Last working route...", you can make a very good guess as to which devices are being used as repeaters for the device you've navigated to. Those repeaters are the first ones to upgrade. Sun 10/24/2021 10:58:04 : [ZW-SHOW ] ---------------------------------------------- Sun 10/24/2021 10:58:04 : [ZW-SHOW ] Last working route from ISY to Node 32 - ZW 032 Bench Light Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Node 7 - ZW 007 Siren Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Node 4 - ZW 004 Dimmer Switch Sun 10/24/2021 10:58:04 : [ZW-SHOW ] Sun 10/24/2021 10:58:04 : [ZW-SHOW ] Node 32 - ZW 032 Bench Light has the following neighbors Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Repeater - Node 4 - ZW 004 Dimmer Switch Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Repeater - Node 7 - ZW 007 Siren Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Repeater - Node 8 - ZW 008 East Multilevel Sensor Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Repeater - Node 9 - ZW 009 West Multilevel Sensor Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Repeater - Node 10 - ZW 010 Water Cop Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Repeater - Node 13 - Master Fan Switch Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - - Node 24 - ZW 024 Schlage Door Lock Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Repeater - Node 25 - ZW 025 On-Off Power Switch Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Repeater - Node 26 - ZW 026 On-Off Power Switch Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Repeater - Node 29 - Auto Door West Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Repeater - Node 30 - Auto Door East Sun 10/24/2021 10:58:04 : [ZW-SHOW ] - Repeater - Node 31 - ZW 031 Dimmer Switch Sun 10/24/2021 10:58:04 : [ZW-SHOW ] Sun 10/24/2021 10:58:04 : [ZW-SHOW ] ----------------------------------------------

If I were just starting with Z-Wave, I'd probably wait until the ISY/Polisy was released with Z-Wave (700 series), and buy only 700 series devices which are now coming to market. This might be a very viable alternative to Insteon.

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"