Bumbershoot

Do you get anywhere when you direct your browser to https://xxx.xxx.xxx.xxx:3000 If you do, then pg3 is running.

PuTTY used secure shell to get into your Polisy, and that's over port 22. Port 3000 is where pg3 publishes the HTML that your browser uses. Different ports for different purposes.

That's because pg3 wasn't running. A *.pid file contains a process ID for the program, and since it isn't running, there isn't a '/var/polyglot/pg3/pg3.pid' file available.

It doesn't appear that pg3 was running when you tried to stop it, but it looks like it started without error. No, that's a URL for your browser, not for PuTTY.

Yes. You need to specify port 3000, or your browser will use the default port for a secure session, which isn't 3000. https://xxx.xxx.xxx.xxx:3000/dashboard

1) I'd imagine the OS is compiled for an AMD64 compatible CPU, so it would be 64 bit. [admin@polisy ~]$ uname -a FreeBSD polisy 13.0-RELEASE-p5 FreeBSD 13.0-RELEASE-p5 #14 releng/13.0-n244765-2646dd66590: Wed Dec 8 22:59:39 UTC 2021 ec2-user@bsdev.isy.io:/usr/obj/usr/src/amd64.amd64/sys/POLISY amd64 2) I've understood that an FPU is standard on any modern CPU (at least since the Intel Pentium CPUs). 3) You should have the use of NFS and Samba, along with the SSH suite of tools, such as scp and sftp. All a bit of a learning curve if you're not familiar with the *nix command line, but the tools are there.

In my case, losing every is just fine. I assume that Z-Wave backup/restore is in the works? Thanks again!

One question: will the restore overwrite any testing stuff we've been doing on our ISY Polisy, or should be delete everything first (or just delete the configuration file)? Awesome, and thanks!

I'm entirely with you there. It's just that the explorer frames needed to include devices from long range don't exist in the 300 series network. The 500 series controller (ISY) is indeed apparently is receiving the explorer frames, so the mesh is all 500 series from the device to the ISY. This single 300 series device in the mesh does not seem to be affecting mesh communications when it's not being used as a repeater.

These devices I've installed have all been either 500 or 700 series devices. The last one was a 700 series light switch that I stuck in the wall in the far reaches of my garage (at least 75 feet from the ISY, with lots of 500 series devices to act as repeaters), and it included almost instantly. My confusion is that if the mesh was forced to operate at the lowest common denominator (300 series level) by the one device, then this Z-Wave + feature shouldn't work at all. This 300 series device is not used in any other devices path.

The thing that I don't understand is that, even though I have a 300 series device in the mesh, I've been able to use Network Wide Inclusion with new devices that are quite a distance from the ISY, which isn't supported in 300 series devices. If the entire mesh can only operate as it's least capable member, this shouldn't work. ? EDIT: no Z-Wave + device has this 300 series device in it's route to the ISY.

I've got this situation, but I don't really know how it works (though to be honest, the speed of my Z-Wave mesh seems to be fine): I have a 300 series device (which is a repeater) in the crawl space of my house (Water Cop), and quite a few other 500 series devices in the area. None of the 500 series devices put the Water Cop in the route to the ISY, but the Water Cop has 500 series devices in it's route to the ISY. It makes no sense that the speed of the Z-Wave mesh is limited by the existence of one series 300 device, when it's not in the route of the faster devices. My sense is that Z-Wave devices will always choose the faster route, if one is available.

Not yet, but in an unrelated post a couple of days ago, @Michel Kohanim gave us this: Last night, my house became the guinea pig for our ISY994 to Polisy migration/backup/restore. First of all, migration went absolutely perfectly. All INSTEON <profanity> was migrated properly with all the databases, programs, configurations, network resources, etc. (not Z-Wave yet). <sniparoo> I'm waiting for Z-Wave and a couple more nodeservers to get ported to PG3 before I migrate (though I could always keep Polyglot 2 running). I'm not certain about the Alexa/Google Home routines, but apparently @bmercier has done some work on a migration utility for those as well. Indications are that it's close...

Not yet, but it's coming shortly. Maybe this week?

@stevehoyt, to get the attention of people in this forum, put an ampersand (@) prior to their user name. Otherwise, you're just hoping they'll pay attention to the forum you're posting in. I think a simple ISY program could do what you're considering. No need to combine the nodeservers. This is exactly what the ISY does and does very well. I do something similar (with the Rainmachine nodeserver and WeatherFlowPoly nodeserver) when the wind or temperature values go outside of norms (shut off irrigation in high wind, or provide extra irrigation to newly planted areas in hot weather). The ISY is the glue between the two nodeservers.

Read through this thread, and you may get an idea of why:

The default ssh port is 22, which is what the Polisy uses.

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.