Bumbershoot

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 didn't know about this. I set up a routine that's using this function, and so far, it works beautifully! Thanks for sharing the idea!

That's doable with Z-Wave. I have a couple of these: https://www.amazon.com/GoControl-GD00Z-8-GC-Z-Wave-Security-Black/dp/B085LKPHK6/ref=sr_1_3?keywords=GoControl&qid=1652372776&sr=8-3 Combine that with a geofence, and you're good to go: https://wiki.universal-devices.com/index.php?title=ISY_Portal_Node_Server_Occupancy_and_Locative_app_Instructions

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!

UDI did produce a PLM at one point, and a few prototypes are in use (I think Michel wrote somewhere that he still uses one in his home). Apparently, Smarthome decided against selling the necessary chips to UDI at the last minute, so it was never produced at quantity.

FYI - for anyone running reports using the soil moisture sensors, the reporting node (substitution variable) has changed in the PG3 version. In the PG2 version, the variable MOIST would produce data in an emailed report (this example assumes that the EcoWitt Node server is installed in slot 5): ${sys.node.n005_wh51_1.MOIST} In the PG3 version, the substitution variable has changed to ST: ${sys.node.n005_wh51_1.ST} You'll need to edit your reports. BTW, thanks @simplextech for the updated Node server!

Likewise for me. There are many other paths I could have taken besides Ring, but I got exactly the functionality I needed along with easy integration. I've recently helped other users migrate from the Insteon Hub to a Polisy, and would like to recommend Ring to them as the grow their installations, but only if it integrates with the UDI environment. @Michel Kohanim, any way we could help with this?

I just bought a Windows 10 PC simply to run Elk RP2 on for $145. Nice little unit, too.

It does/did have support for the cameras as motion sensors. I have a bunch of programs that use them. I'm eager to have the Ring Node server put back in action...

Bravo, kind sir! I just ran a test and it does indeed work!

No. You'll need one of these if you don't have the original that shipped in the box with the serial PLM https://smartenit.com/shop/plm-serial-cable/

1 - No need with Insteon, just restore a recent backup. 2 - Polyglot 3, if the required node servers are available. I'm running both at the moment, and will migrate to PG3 as additional node servers become available. 3 - Yes, just import a backup. 4 - The serial PLM cable you're using from your ISY won't work with Polisy. You need the original cable that shipped with your PLM. A USB PLM will work with Polisy if you have one. There are some small differences in the way the ISY software handles things on Polisy, and the ISY software is still under development. It generally works just fine, however.

Seems odd. All I can imagine is that the Z stick isn't properly seated in the USB slot or possibly Z-Wave support has been unchecked in the configuration tab.