xKing

@tazman start with looking at the logs - do this on the HA VM (SSH or VNC or what have you) docker logs homeassistant and see what is it it's not happy about

Thanks! A lot more UP/DOWN stuff, even lo0 gets UP/DOWN

Thanks! Time to ask @Michel Kohanim what kind of shady business is he up to in those scripts. There is a fun thing to do - reboot with UDX and ISY disabled and do dmesg look at last lines where interfaces go UP/DOWN now re-enable UDX and ISY - reboot again and just do dmesg command again - see more UP/DOWN stuff?

Allright, remove that line from loader.conf and add these (just for the TEST) to /etc/rc.conf Reboot and see if homeassistant still has an issue? udx_enable="NO" isy_enable="NO"

@rob7419 thank you sir, can you try adding net.link.tap.up_on_open=1 at the bottom of /boot/loader.conf This should set it as early as possible during the boot sequence.

Sorry if I was not specific but please watch the `tap0` status. Just 2-3 reboots is ok net.link.tap.up_on_open - is the system variable that says - bring the tap interface UP as soon as there is an opener (VM starts).

Interface `tap0` should come UP if this thing is set to 1. net.link.tap.up_on_open: 1 It’s done by the `vm init` which is called if you have `vm_enable=YES` in /etc/rc.conf Or you can do that manually by running `sudo vm init` before you do `sudo vm start` See if you can do a couple reboots and just check `sysctl -a | grep up_on_open` after reboot - you always see 1 ?

Just to clarify - when you say you restarted and interfaces were not up - do you mean that you have vm_list=“homeassistant” uncommented? Or you booted and did `vm start homeassistant` manually?

That looks fine, so what happens if you do `sudo vm start homeassistant` now - would tap0 still come up with no “UP” flag and require `sudo ifconfig tap0 up` ? Delete this: ifconfig_re0_ipv6="inet6 accept_rtadv"

Ok, try commenting out just `vm_list` from `/etc/rc.conf` and comment out the line you put in `/etc/sysctl.conf` reboot and see what does the `sysctl -a | grep up_on_open` say? you also have a duplicate ifconfig_re0_ipv6 in /etc/rc.conf - please delete the second one

No you don’t need any cron Can you post your complete /etc/rc.conf please

Stop home assistant, reboot eisy, do check this sysctl -a | grep net.link.tap.up_on_open

Do you have vm_enable="YES" In your `/etc/rc.conf` ?

So what happens if after you bring the home assistant you do this sudo ifconfig vm-public up; sudo ifconfig tap0 up Also try adding this into `/etc/sysctl.conf` and reboot net.link.tap.up_on_open=1

LOL @Michel Kohanim I'm not a guru it just always works for me @tazman and @rob7419 You don't really need to `dhclient` the `vm-public` nor `tap` devices, those don't need an IP address. Check your rc.conf, there should be no `ifconfig` entries besides these 2: ifconfig_re0="DHCP" ifconfig_re0_ipv6="accept_rtadv" after reboot your `ifconfig -a` should look similar to this (no tap, but vm-bridge is UP): re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=8209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> ether 00:21:b9:02:5d:7a inet6 fe80::221:b9ff:fe02:5d7a%re0 prefixlen 64 scopeid 0x1 inet6 fd18:31e5:33f2:844e:221:b9ff:fe02:5d7a prefixlen 64 detached autoconf inet 10.0.1.152 netmask 0xffffff00 broadcast 10.0.1.255 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> vm-public: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 52:14:e6:86:b4:2f id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: re0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 1 priority 128 path cost 20000 groups: bridge vm-switch viid-4c918@ nd6 options=9<PERFORMNUD,IFDISABLED> Start the VM (`sudo vm start homeassistant`) your `ifconfig -a` output should become like this: re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=82099<RXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC,LINKSTATE> ether 00:21:b9:02:5d:7a inet6 fe80::221:b9ff:fe02:5d7a%re0 prefixlen 64 scopeid 0x1 inet6 fd18:31e5:33f2:844e:221:b9ff:fe02:5d7a prefixlen 64 detached autoconf inet 10.0.1.152 netmask 0xffffff00 broadcast 10.0.1.255 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> vm-public: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 52:14:e6:86:b4:2f id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: tap0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 4 priority 128 path cost 2000000 member: re0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 1 priority 128 path cost 20000 groups: bridge vm-switch viid-4c918@ nd6 options=9<PERFORMNUD,IFDISABLED> tap0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 description: vmnet/homeassistant/0/public options=80000<LINKSTATE> ether 58:9c:fc:10:f8:32 groups: tap vm-port media: Ethernet autoselect status: active nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> Opened by PID 5537 `vm-public` has 2 ports `re0` and `tap0` and all interfaces are `UP` You should be able to see traffic on `tap0` interface, for example something like this: # just dump on the screen sudo tcpdump -i tap0 -s0 -vvv # save a .pcap file sudo tcpdump -i tap0 -s0 -w trace1.pcap see if you can capture a minute or two of traffic and attach what you have (or PM me). For the reference - I'm using pfSense 23.09.1-RELEASE as a router with KEA as DHCP server selected.

Analog was a community contribution so I have no idea what that does. MQTT is mostly for people who are willing to mess with the code

try maybe sudo -u polyglot bash pip3 uninstall bitstring pip3 uninstall --prefix /var/polyglot/pg3/ns/0021b9026038_7/.local bitstring pip3 install --prefix /var/polyglot/pg3/ns/0021b9026038_7/.local bitstring==3.1.9

Ah I see, polyglot 3 uses separate package repo for each node server - in this case /var/polyglot/pg3/ns/0021b9026038_7/.local/lib/python3.9/site-packages/bitstring.py is unique for LiFX install. I'll need to look around to see how to make it downgrade I'm still on PG2 myself

so what exactly do you get in the lifx log? bitstring version is ok (3.1.9). Version 4.0 is what caused trouble

what do you see in pip3 list output? Problem is not related to hardware platform (eisy, polisy, rpi, etc), it's just a new library compatibility.

so original LiFX integration is based on LifxLAN python project that was abandoned for a few years, one of the libraries it depends on updated and broke it you can work around that by doing something like this: sudo -u polyglot bash pip3 uninstall bitstring pip3 install bitstring==3.1.9 I don't know if LifxLAN author is going to update their library...

Can't you just send `DON` with appropriate speed?..

I don't have any of those mini ones so can't really test, sorry. Also @einstein.42 is the author, I just ported it to PG3

Gosh, if I remember correctly - something like this: - id: fanlight1 name: "Master Fan Light" type: switch status_topic: stat/MasterFan/POWER1 cmd_topic: cmnd/MasterFan/POWER1 - id: fanmotor1 name: "Master Fan Motor" type: ifan status_topic: stat/MasterFan/RESULT cmd_topic: cmnd/MasterFan/FanSpeed

so for motion - Hue hub is a "pull" thing, in other words - node server asks Hue hub for a status every short poll (I think it's 15 seconds by default). Even if you happen to catch motion reported - 15 seconds delay would be kinda weird. Same goes for other hue input devices - buttons, switches.