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

Disregard this comment, had to run both the $ sudo dhclient vm-public and $ sudo dhclient tap0 to reconnect to the network this morning.

Thanks @tazman seems like we are making progress, this is the first time I've been able to reconnect to the network without destroying the VM and recreating it. After a reboot, I can $ sudo dhclient vm-public on the eisy IP - SSH session and HA reconnects to the network and everything works as expected. HA dashboard is accessible. I don't have to restart HA from the VNC viewer, it can already be running when the above command is run and it will come back online immediately. The VM will also run as expected after a VM poweroff -f and then a VM start, once the DHCP request is issued on the vm-public switch, HA will boot normally. I also agree that the problem is with the VM virtual network bridge, it seem that doesn't reset during a reboot or VM restart.

@Michel Kohanim I am not able to get to any other CLI session other then the HA CLI through the VNC viewer.

@Michel Kohanim ssh : Operation timed out, I cannot ping even from the diagnostics in my router (pfSense). From VNC $ docker ps is not a valid command: Something during the the startup when it is rebooting is preventing it from connecting to the WAN, maybe DNS related? I do run a local DNS server on the pfSense router, not sure what could be preventing it on a reboot verses a clean install?

@Michel Kohanim I have tried to set a static IP and that doesn't fix the connection issue on a restart or reboot. I also set up the the VNC client and was able to see the boot sequence and connect to HA CLI interface. This was the output from $ network info after running the $ ./create_ha_vm.sh install script. Then $ shutdown -r now, again reconnected to the VNC viewer and watch the boot sequence, the following screen shot was taken right after start up but hasn't changes in the last 30 minutes. Says it is waiting the supervisor to startup.. Could it be that HA doesn't actually startup within the VM to make the DHCP connection to the router?

@Michel Kohanim Yes, I lose connection to HA after a reboot or if I shutdown the VM from the CLI. I can restart HA from the HA dashboard and it will work as expected. Any of the following, sudo shutdown -r now, from the reboot button in admin console of the eisy, or if I preform a sudo vm poweroff -f, the VM will not reconnect to the network after the restart. The only way I can get it to work again, so far, is deleting the network setting of the VM's network bridge, destroying it and then rebuilding from the script.

@Michel Kohanim & @tazman I am Ok with giving access to my eisy or sending it in to UDI, it is not my production device so it is just sitting waiting on this to get resolved. It sound like it is not happening on all eisy's, others are running HA in the VM without issue. Are these the only 2 that are having problems? If I need to open a ticket, let me know?

I too am still having issues with the VM connecting back to the network after a reboot of the eisy, from either the admin console or the command line. I was about to ask you after my last post if you have survived a reboot but was still trying different things to determine what is causing the issue on mine. At first I assumed it was not reconnecting due to setting a DHCP reservation in my router, but I have found taking certain steps within HA I can get it to change to the new reserved IP and it will continue to work until a cold restart of the eisy computer. The only way to get the network bridge that the VM creates to reset is to go through all the steps to remove the network settings and then destroy and rebuild the VM, which I have done multiply time over the last 2 weeks. I have also tried restarting my DHCP server and rebooting my router to try and reestablish a connection. The VM displays the same information with $ sudo vm info homeassistant when connected to the network verses not connected. I can find anything within the VM commands or $ ifconfig that is different. I have tried restarting the VM and at the same time watching a tailed ping, it will show a couple of reply's during the startup process but then drops the connection, I think that maybe HA is failing to start within the VM but as of today can't find anything in the debug logs of the VM, just started looking into those. I tried the recommendation from this post: but it does not fix my reboot issue. I might try it again when I get the chance since I've resolved the DHCP reservation issue just yesterday. You give it a try, maybe you can get it to work and share how.

Any resolution on this issue? My setup is producing the same issues.

I have used this in the past to do you same thing you are trying to do when I had cellular internet, modem would lock up and required a power cycle to reset. Haven't had to use it since Starlink.