Bumbershoot

I think it could, but only if it's used as a route to the controller for other devices. I have one old Z-Wave 300 device, and it works well, but it isn't used as a repeater for any other devices. As a result, network wide inclusion (NWI) and other newer Z-Wave features still work on my network. The entire network isn't dumbed down to the lowest common denominator (300 series) in my installation. It might, however, if the only route to the controller was through the Z-Wave 300 device.

I don't believe this is a hardware change. I think it has more to do with how the hardware is utilized. My impression is that there's a disk image that gets flashed to the hardware/media (containing the OS, the various mount points, UDI specific software, etc.), and that original image was only 4GB in size (the hardware can support a much larger image). It's likely possible to partition and format the remaining unformatted/unpartitioned disk space, but you'd have another mount point and a non-standard setup. It's perfectly reasonable to make that work if you're good with UNIX, but tricky if you're not. And, you don't have the 'root' password, meaning you can't get the machine into single user mode, that would likely be essential to do something like this. 'sudo' likely won't do it, and I don't believe that the 'admin' login actually carries superuser privileges.

Well, it looks like UDI isn't maintaining the FreeBSD-base repository for FreeBSD 12 anymore. https://pkg.isy.io/FreeBSD-base/FreeBSD:12:amd64/latest/meta.txz I edited this like to point at FreeBSD-base repository for FreeBSD 13 and had success. https://pkg.isy.io/FreeBSD-base/FreeBSD:13:amd64/latest/meta.txz The fix will likely be a bit complicated, so please open a ticket with UDI. Their support is fantastic.

I sent mine back to UDI, and they flashed the disk. I don't know what you're going to do from Canada... Make sure you run this command occasionally: sudo pkg clean If you fill up the disk space, you're going to be unhappy. UNIX machines can get very cranky when they run out of disk space.

Okay, you might have a very early Polisy on your hands. Just curious, issue this command: df -h You should get a report of your disk capacity. It should look something like this: Filesystem Size Used Avail Capacity Mounted on zudi/ROOT/default 24G 2.2G 22G 9% / devfs 1.0K 1.0K 0B 100% /dev procfs 4.0K 4.0K 0B 100% /proc zudi 22G 24K 22G 0% /zudi zudi/var/db 22G 118M 22G 1% /var/db zudi/usr/home 22G 37K 22G 0% /usr/home zudi/tmp 22G 28K 22G 0% /tmp zudi/var/log 22G 426K 22G 0% /var/log zudi/var/empty 22G 24K 22G 0% /var/empty zudi/var/isy 10G 20M 10G 0% /var/isy zudi/var/crash 22G 24K 22G 0% /var/crash zudi/var/run 22G 42K 22G 0% /var/run zudi/var/tmp 22G 24K 22G 0% /var/tmp zudi/var/db/pkg 22G 11M 22G 0% /var/db/pkg zudi/var/polyglot 10G 284M 9.7G 3% /var/polyglot If you only get a size of 4G instead if 24G, then you'll likely have to send your Polisy back to UDI to have the disk re-imaged. On the bright side, you'll be up to date when you get it back... In any event, you're probably going to need to open a ticket: support@universal-devices.com

Have you simply tried to update your Polisy before you run the scripts that have been suggested? It appears from the line below that you may need to in order to get anywhere further with the process. Try this at the prompt: sudo pkg update && sudo pkg upgrade After this process is finished, you might need to reboot: sudo shutdown -r now Once the Polisy is back up and you can login, start over beginning with the 'curl' command and see if you get a better result.

You can consider me available to help test with the Venstar, if that's what you're looking for. Python programming isn't in my skill set, unfortunately.

The Venstar Colortouch T7900 is working very nicely for me. A couple of things to consider if you're interested in one: the API for the thermostat is local, and there's a PG2 Node server available for it Venstar have remote temperature sensors available -- indoor, outdoor, wired, wireless, etc. there is a cloud service available from Venstar at no charge, if you desire it, but it's not mandatory there's a Nodelink Node server available for it, but Nodelink doesn't run on a Polisy the PG2 Node server doesn't display humidity % or expose humidifier functionality, though it's available in Nodelink @Goose66 is the author of the PG2 Node server, and he's indicated that it's coming to PG3...

You might write a program (Program1) that only writes the HSBKD settings to integer variables every couple of minutes, then, when you tap a fast on, run another program (Program2) that disables the first program (Program1) and sets your lights how you want them. Then, when you tap the on button, you could have another program (Program3) read in the values from the variables into the HSBKD settings and re-enable the first program (Program1), continuing where you left off? That's the easiest way I can think of. There's probably a better way, but I think you could make this work and not have it become too complex. I doubt that writing values to integer variables every few minutes would add much processing overhead to your Polisy.

I found the Node server in a failed state this morning. Here's the error: 2022-05-18 02:06:53 error: NS: uncaughtException REPORT THIS!: TypeError: Cannot read properties of undefined (reading 'baseUrl') at NotificationListener.topologyChange (/var/polyglot/pg3/ns/00:0d:b9:53:3f:34_9/node_modules/sonos-discovery/lib/SonosSystem.js:109:30) at NotificationListener.emit (node:events:390:28) at /var/polyglot/pg3/ns/00:0d:b9:53:3f:34_9/node_modules/sonos-discovery/lib/NotificationListener.js:117:17 at runMicrotasks (<anonymous>) at processTicksAndRejections (node:internal/process/task_queues:96:5) 2022-05-18 02:06:53 error: POLY: uncaughtException: Cannot read properties of undefined (reading 'baseUrl') TypeError: Cannot read properties of undefined (reading 'baseUrl') at NotificationListener.topologyChange (/var/polyglot/pg3/ns/00:0d:b9:53:3f:34_9/node_modules/sonos-discovery/lib/SonosSystem.js:109:30) at NotificationListener.emit (node:events:390:28) at /var/polyglot/pg3/ns/00:0d:b9:53:3f:34_9/node_modules/sonos-discovery/lib/NotificationListener.js:117:17 at runMicrotasks (<anonymous>) at processTicksAndRejections (node:internal/process/task_queues:96:5) 2022-05-18 02:06:53 error: NS: uncaughtException: Cannot read properties of undefined (reading 'baseUrl') TypeError: Cannot read properties of undefined (reading 'baseUrl') at NotificationListener.topologyChange (/var/polyglot/pg3/ns/00:0d:b9:53:3f:34_9/node_modules/sonos-discovery/lib/SonosSystem.js:109:30) at NotificationListener.emit (node:events:390:28) at /var/polyglot/pg3/ns/00:0d:b9:53:3f:34_9/node_modules/sonos-discovery/lib/NotificationListener.js:117:17 at runMicrotasks (<anonymous>) at processTicksAndRejections (node:internal/process/task_queues:96:5) 2022-05-18 02:06:53 error: NS: undefined

I suspect that a "Normal" status is just a placeholder, needed because of the use of a "state" variable. In the example posted by @MrBill above, the variable $sLeakKitchenSink is set to a value of "1" if a heartbeat is received within a 25 hour period, meaning no program is triggered by the changing of the state variable. If a heartbeat is not received, then $sLeakKitchenSink value is set to "2" which triggers off the notification program. I'm not sure what's going on there. Is the value of your heartbeat variable actually "1"?

They clearly are network ports. I poked around in '/etc/rc.conf' on my Polisy, and it appears they aren't enabled. Since we don't have a 'root' login, I don't think we can fiddle around with the networking outside of using what functionality UDI chooses to provide. I think that's smart, given the support headaches that providing 'root' access to the box would cause.

I'll bet the the 'udx' service is used to modify the network settings. UDI has indicated that they want to get rid of PG2, and this stuff hasn't made an appearance in PG3, so I'm betting that this ability will wind up in the ISY configuration tab at some point.

This may explain what's going on. In the file '/etc/rc.conf' it looks like the 'wlan0' interface isn't started on my machine (see the bottom four lines): #Network Interfaces (default) ifconfig_igb0="DHCP" ifconfig_igb0_ipv6="inet6 accept_rtadv" #disable starting igb1/2 at startup ifconfig_igb1_ipv6="NOAUTO" ifconfig_igb1="NOAUTO" ifconfig_igb2="NOAUTO" ifconfig_igb2_ipv6="NOAUTO" #WiFi disabled by default ipv6_ipv4mapping="YES" ifconfig_wlan0="NOAUTO" ifconfig_wlan0_ipv6="NOAUTO" I suspect that when you change to the WiFi interface, this file would have an edit that starts the 'wlan0' interface and disables the 'igb0' interface. I'm certain that there's a reason for this... EDIT: on further snooping around on my Polisy, I see a backup file of '/etc/rc.conf' that has the WiFi interface enabled. My guess is that the 'udx' service is what modifies these files, suggesting that UDI has a business reason for setting up Polisy networking as they do: #Network Interfaces (default) ifconfig_igb0="DHCP" ifconfig_igb0_ipv6="inet6 accept_rtadv" #disable starting igb1/2 at startup ifconfig_igb1_ipv6="NOAUTO" ifconfig_igb1="NOAUTO" ifconfig_igb2="NOAUTO" ifconfig_igb2_ipv6="NOAUTO" #WiFi disabled by default ipv6_ipv4mapping="YES" wlans_ath0="wlan0" ifconfig_wlan0="WPA DHCP" create_args_wlan0="country US regdomain FCC" ifconfig_wlan0_ipv6="inet6 accept_rtadv"

I don't think both interfaces are active at the same time, by default. If I run the command 'ifconfig -a' on my Polisy while the ethernet connection is active, I don't see the WiFi device at all in the output, just the three ethernet devices and the loopback device.

Kinda like the confusion that people have run into thinking they could simply reuse the cable they've been using between the serial PLM and ISY994... Those ports must be for some future expansion?

No, I don't think so. The Polisy's network cards have different MAC addresses (not even of the same manufacturer, it appears), so they'll present themselves to your network as completely different devices. As I understand it, your DHCP server might have issues if you use the same IP address for two different MAC addresses, though there's no doubt some networking kung-fu that would allow this to happen. EDIT: I think the ISY software just uses the underlying operating system's network services, and it doesn't care (or maybe even know) which interface it is.

FWIW, my WiFi router handles DHCP reservations for both ethernet and WiFi. When I switched to using WiFi for the Polisy, I just looked up the Polisy in the DHCP table on my WiFi router (it advertised itself as POLISY in the table with a different MAC/IP address than what is used for ethernet). I manually added it to the finder at the new IP address, IIRC. I now have static DHCP reservations for the Polisy whether it's connected via ethernet cable or via WiFi. The PG2 interface is interesting/difficult, but I certainly got it to work reliably -- I switched network interfaces at least three times over a couple of days when migrating off the ISY994. In production, my Polisy stays on a wired network connection. It works.

I'm not currently using this technique, but it worked well in the past. https://wiki.universal-devices.com/index.php?title=ISY-994i_Series_INSTEON:Networking#Dynamic.2FCustom_Page_Creation I created a csv file and appended data to it as necessary, making it more useful than a simple log file. I haven't tried this on Polisy, however.

I believe HomeSeer HS-WX300 dimmers/switches have that capability when set in "Normal" mode. I have an older model that I use in "Status" mode, which makes the onboard LED's vastly more useful than the LED's in Insteon dimmers/switches.

I wonder if the PLM Pro is this, finally going to see the light of day?

Do you have your device (Tempest) added to the configuration? Key: your Station ID; Value: local Token: the token from "Data Authorizations" from the Stations on the web page of your station

You might need to restart the Admin Console to get the nodes to appear and populate.

I don't think so, but below is a screenshot of what's available. Here's a link to the Jishi Sonos API, so I suspect if what you want isn't there then Sonos might not support it.

All is working. It took a couple of bounces of the AC for the phrases to populate, but they're working and the performance seems to be good. Thanks again for this!