rob7419

This link should provide the information you are looking for: https://products.z-wavealliance.org/products/2176?selectedFrequencyId=2

@tazman Thanks, I've tested and it is working for me as well.

@Whitehambone The "host_internet: false" and "supervisor_internet: false" suggest that the tap0 interface in still down. Try and see if that will allow HA to be resolved in a browser.

I have been playing around with the eisy some more and didn't have an issue with the ISY/IoX integration connecting until I plugged in the ZMatter USB device. If the ZMatter USB is plugged in the integration show an unknown connection and needs to be reloaded. If it's unplugged it will boot normally. @tazman are you utilizing the ZMatter? If so, can you confirm it will boot normally with it unplugged?

@tazman I haven't been testing the ISY/IoX to HA integration yet. But to help test I add the Universal Devices ISY/IoX integration to HA and preformed a couple of reboots from the CLI and the eisy to HA socket connected both time I then restarted HA from the dashboard and HA showed connected after, so at this point I would say I'm not seeing this issue on my device.

As always great support from UDI, 4 consecutive reboots and HA VM connects to network without issue. Thanks!!

This will be an issue for me also, if the USB ports can only be map to one of the controllers, ISY or HA VM. I didn't purchase the eisy for the purpose of running HA on it, being able to run both would be convenient. To have a single device running both to maybe get a little performance boost in their communication with each other, but I still need the ISY to control my Insteon devices. In my option and experience ISY is still the best controller for an Insteon network and for the foreseeable future I'm not interested in changing.

Thank you for the info, I had done a quick search and couldn't find anything, wish it would have been listed under the "help" information on the HA CLI.

@tazman Just to keep you updated also, Michel responded to my email "Looking through the code … I’ll keep you posted."

Sent them to support@universal-devices.com

This is the dmesg -a output with both UDX & ISY enabled and #vm_list="homeassistant" disabled in /etc/rc.conf, once eisy boots, start the HA VM. The interfaces do not produce the same behavior when started separately. Reset the Wifi, I've never set up the WIFI, but just to make sure this wasn't the issue. HA VM went offline when $ sudo udxops.sh wifi.reset was entered. Updated back to: ifconfig_inet6="inet6 accept_rtadv" in /etc/rc.conf and enabled the vm_list="homeassistant" to enabled VM to start on boot. Rebooted eisy, dmesg -a output with same results that HA VM starts but does not connect to the network. No change in boot with WiFi reset.

Just to verify that I'm getting the simular results as @tazman UDX & ISY Disabled, HA VM connects to network UDX & ISY Enabled, HA VM will not connect to network, last couple of lines on mine are different I am on a wired connection.

Me too, 3 successfully reboots with HA VM connecting to the network.

Added to /boot/loader.conf - net.link.tap.up_on_open=1 no change and just in case still no change. In both cases Brought the Home Assistant VM network back online.

@xKing and @tazman xKing, I would like to also express my appreciation on your "Guru" assistance. And here is what I have so far: I also am on pfSense 23.09.1 RELEASE, but still using ISC DHCP server, haven't switched to KEA due to it not being fully implemented. Was going to switch when it became the default. I might attempt to switch to KEA and see if it make a difference but will have to wait till later this afternoon to try. -------------------------------------------------------------------------------------------------------- After reading through all the post, the only thing that I changed to start with is in the /etc/rc.conf file: Didn't make a difference in how the Home Assistant VM started, VM was running but not connect to the network. -------------------------------------------------------------------------------------------------------- I then commented out in /etc/rc.conf Performed 4 consecutive reboots with the following steps. $ ifconfig -a - to check if vm-public was "UP" and in all 4 reboots it was true. $ sysctl -a | grep net.link.tap.up_on_open - check if net.link.tap.up_on_open: was = "1", all 4 reboots it was true. $ sudo vm start homeassistant - in all 4 cases the VM started successfully, the tap0 interface was created with a status of "UP" and connected to the network. Then I uncomment the "vm_list" line above to set /etc/rc.conf back the the original for the VM to start during boot. Again performed 4 consecutive reboots, VM was running but none of the reboots was it able to connect to the network on the initial boot sequence. Check the following on each: $ ifconfig -a - to check if vm-public and tap0 was "UP" and in all 4 reboots it was false. Neither interface showed "UP" status, on reboots 2 & 4 waited about 3 minute and then and the VM immediately started replying to ping request. $ sysctl -a | grep net.link.tap.up_on_open - check if net.link.tap.up_on_open: was = "1", all 4 reboots it was true. -------------------------------------------------------------------------------------------------------- In all the reboots, this variable was always set to "1". When does this variable get set during the boot sequence? Is it possible that the VM is starting before it does and prevents the network from being established? -------------------------------------------------------------------------------------------------------- Still working on tcpdump packet captures. Will DM them when I get something worth sending, will try to capture from pfSense first and then from the eisy. And finally my /etc/rc.conf and VM configure files for you to review: rc_conf 03-11-2024.txt HA_VM_Configure 03-11-2024.txt