Bumbershoot

This is PG3 with ISY on the Polisy, v 5.30. On polyglot v2 on the ISY994 the value is correct.

Hi @Jimbo, I'm seeing an issue with temperature with tag type 13. Reporting actual Celsius when it should be in Fahrenheit. See screenshots...

@Jimbo, a reboot of the Polisy has corrected the problem. I got the appropriate dialogue this time, and now have a token.

Okay, I restarted PG3 and reinstalled the nodeserver, but something's goofy here. The log says it's 3.0.31 2022-01-10 14:20:09,409 MainThread udi_interface INFO __init__:<module>: UDI Python Interface for Polyglot version 3 3.0.31 Starting... and the UI says it 3.0.36. I'm going to reboot my Polisy.

Hmmm.... Already on 3.0.36. [admin@polisy ~]$ sudo pkg info pg3 pg3-3.0.36 Name : pg3 Version : 3.0.36 Installed on : Fri Dec 31 18:26:57 2021 PST Origin : misc/pg3 Architecture : FreeBSD:13:* Prefix : /usr/local Categories : misc Licenses : MIT Maintainer : andrey@xkinghome.net WWW : https://github.com/UniversalDevicesInc/polyglot-v2 Comment : Polyglot v3 for UDI Polisy Annotations : repo_type : binary repository : udi Flat size : 59.6MiB Description : Polyglot v2 server for Universal Devices ISY994 version 5.x.x WWW: https://github.com/UniversalDevicesInc/polyglot-v2

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.