Bumbershoot

Will do, thanks!

PM sent. I wanna support the developers, and I don't mind a few cuts and bruises.

Hi @Jimbo. Upon installing and starting the PG3 version of this nodeserver, there was nothing to prompt me to get an authorization token as there was in the PG2 version. Unfortunately, the token I got for the PG2 version doesn't appear to be valid for the PG3 version. Maybe I'm missing something, but it's not entirely apparent what that would be. Thanks!

I see that the Wireless Tag nodeserver has been released for PG3. I've been waiting for it... ?

Oh, boy, there's some excitement... You'd think that you could factory reset the ISY and restore a recent working backup, if nothing else.

sudo pkg uninstall pg3 then, after it finished sudo pkg install pg3

Nope, not running. Try this from the command prompt: sudo service pg3 onestart

In your screenshot above, you were successfully logged into your Polisy. Unless you exited that PuTTY session, you're still logged on. If you're still logged in, type this at the command line prompt: ps aux | grep pg3 If pg3 is running, you should get output similar to this: [admin@polisy ~]$ ps aux | grep pg3 polyglot 2202 8.9 6.8 709108 280776 - S Fri14 98:22.53 /usr/local/bin/node /var/polyglot/node_modules/@universaldevices/pg3/bin/pg3.js admin 8563 0.0 0.1 12824 2420 2 S+ 14:47 0:00.01 grep pg3

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.