Bumbershoot

The Rainmachine nodeserver has short enough polling values by default, but they are changeable when you configure it. Generally, whenever a watched node changes state, the values in the nodeserver and ISY are updated, regardless of polling, so there's no need for you to do anything other than write an ISY program that watches the irrigation zone. I don't have a Flume, so I can't comment on that. I wouldn't sweat the network traffic these devices create. I have a great many more nodeservers than these things, and my ISY handles the load just fine. When the entire installation moves to Polisy, then I suspect it will be difficult to overwhelm the network stack with nodeservers unless they are badly misconfigured. All of this traffic will happen on the ethernet port. Polyglot v3 (which only runs on the Polisy) already has the FlumeWater and Rainmachine nodeservers available for download at a cost of $10 for FlumeWater and $15 for Rainmachine. If you want to get the attention of the developers, than you'll have to tag them in your response, like this: @Jimbo and @glarsen

When my Insteon leak sensors go, I'll probably replace them with these little beauties. I'm already running the Wireless Tag nodeserver, so adding these would be simple.

You might be able to do something with the Flume and Rainmachine nodeservers as they are, but it will depend on a couple of things: The Flume nodeserver -- the value of "GV1 - Current Interval Flow", and how often it updates in the nodeserver Know what's the expected water flow for each zone If the Flume nodeserver (I don't have it, so I don't know what data is produced and how often it changes) pushes updated data to the ISY in any sort of a regular basis, and you know the flow rate of each of your zones, then it's relatively simple to write ISY programs to notify you or shut off the zone if the flow rate is too high. I know that Flume states that they can give you data "minute by minute", so if that's the case, and the nodeserver captures it, it should be simple to set this up. You might try this: Turn off all other running water, then start your irrigation zones (in good working repair) and capture the water flow for each one by looking at that water flow in your Flume app as each zone is running (hopefully this a value that is captured by the Flume nodeserver). Once you have that value, you could write a simple program like this: Sprinkler Test - [ID 0004][Parent 0001] If 'RainMachine Controller / Zone 11 - Drip Zones' Status is Running And 'FlumeWater / Current Interval Flow' > 10 // just guessing at a value here - maybe a bit higher that what your // Flume reports is the normal flow for this zone Then Send Notification to 'Default' content 'High Water Usage' Set 'RainMachine Controller / Zone 11 - Drip Zones' Stop Else - No Actions - (To add one, press 'Action') You'd probably want to let the water normalize for each zone before examining the data, but that's relatively easy to accomplish.

I suspect that the data stream from nodeservers will be handled much faster, which should help reduce a perceptible lag in performance I sometimes see with my ISY. My guess/hope is that the Polisy will be much more capable with data that does not come across on a PLM or a Z-Wave dongle.

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.

Similar experience here. Nice bit of scripting to get that to work! Well done!

I don't think that @simplextech is working on non-paying projects at the moment, but there's this:

For what it’s worth, mine did the same thing. I’m a bit entertained. Maybe it’s some sort of UDI secret code indicating the imminence of Polyglot v3.0.

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