Setup VLAN and HA tutorial

Configuration
175

Thanks to @cr0muald0 's excellent tutorial I was able to create a second interface for my HA Yellow to connect to devices on my IoT VLAN on my Unifi-controlled network. I was able to configure my first device (a Sonoff Dual R3 relay) via the ESPhome dashboard, where it shows as ‘online’.

The problem is that HA doesn’t auto-discover the device. It does not show up in the Integrations dashboard. I am able to add it manually using the IP address of the device, after which all controls function as expected. While this will probably work fine for a relay which will be online 99.9% of the time, I would really like auto-discover to work properly for future devices that may not be present in my network all the time and may receive different IP addresses.

I’ve read a lot of similar issues, both on the HA forums and on other sources, but none give a definitive answer for my problem. Some suggest that mDNS network traversal should be allowed but that would be necessary only if my HA device was in a different broadcast domain. Since I added the VLAN interface to HA, that should not be necessary. Of course I tried that, but it did not work. This seems to describe my issue but it doesn’t describe exactly what he did to resolve the issue and it received no replies.

Can anyone give me some pointers on where to look next to be able to diagnose this issue?

176

Hey @gerritgleufhoed, so you are saying the device is in the same network segment, right? That excludes the mdns problem. What integration are you using? As far as I know, the auto-discovery only works with Tasmota flashed devices or ESPhome integrated devices, but you did not mention that clearly. Did you flash your relay with Tasmota (I’m guessing no)? Are you using the ESPhome control system? And you have the ESPhome integration installed? Only then it might auto discovery ESP flashed devices, in my understanding (my Sonoffs are all Tasmota flashed and mqtt’ed) :slight_smile:

177

Sorry for not stating that clearly. Yes, the relay is in the same network segment as the newly added IoT VLAN interface in HA.

I have installed the ESPhome integration into HA and flashed ESPhome to my Sonoff relay (using the web.esphome.io dashboard wizard because I’m not yet running HA on HTTPS). When looking at the ESPhome HA dashboard (not sure if I’m using the right terminology here), the relay shows as ‘online’ and I’m able to send OTA updates to it. But it does not show up as a device with sensors and switches in HA, unless I add it manually through an IP address. After doing this I can control the relay without any problems.

178

From what I read, ESPHome requires mdns to function properly, so you don’t have to specify an IP in Home Assistant. How did you configure your ESP?

mDNS Component

The mdns component makes the node announce itself on the local network using the multicast DNS (mDNS) protocol.

Both Home Assistant and the ESPHome dashboard use mDNS to identify the IP address of all ESPHome nodes on the network. If mDNS is disabled, they will no longer be able to automatically find your devices. It may be necessary to use a static IP for all nodes and to enable the ping option in the Home Assistant add-on.

It is recommended to leave mDNS enabled.

Example configuration entry

mdns:
disabled: false

Then Home Assistant should be able to get the node’s IP (from mDNS and create the sensors automatically). Remember, either you give the node a static IP, or if you are using DHCP server, a fixed lease.

Read the Notes on disabling mDNS here: https://esphome.io/guides/faq.html#notes-on-disabling-mdns
and you will understand better the trouble of having a misfunctioning mDNS :wink:

179

Thanks for the reply, but I did not specify anything regarding mDNS in my ESPhome device yaml. Because mDNS is enabled by default, it should announce itself to the ESPhome dashboard instance, which should make it available to HA. Sadly, the second part of that sentence is not happening.

From the FAQ:

Online status detection in ESPHome’s dashboard by default uses mDNS

Since the ESPHome dashboard shows the relay as online, I must conclude that mDNS is working properly. It must be something related to announcing the device’s presence to HA that is not functioning. I could use tips to start diagnosing this further.

180

I see. According to what you are describing, it looks like the node is added to the dashboard but not creating the sensors in HA, as it should. For that to happen, it needs to have the node’s IP properly configured, which should be configured automatically, but apparently not always. Check this thread here to see if it helps:

181

I had read that thread already. The quote solution unquote in that thread is to just add the ESPhome device integration manually via the IP, which works in my case as well but should not be the go-to route to add devices.

One thing I did notice is that I don’t have the captive_portal or fallback AP configured in my device setting as I don’t see the point: the device should be able to connect to the configured wifi or fail, in which case I have to fix the configuration. I cannot image that being the cause of the autodiscover failing in HA, but it’s worth a shot.

I’ll try to get some log output of the device to compare it to the log output in the thread you linked to see if I see similar output.

182

I read somewhere that ESPhome auto-discovery sometimes takes a long time to find (around 5 minutes), so you can always try re-adding the node and wait for a longer period (over a night, maybe) and check later the logs if the API is somehow active and interacting with HA, as it should.

Another thing to double-check is the wireless AP configuration: if it’s not filtering communication between clients (some APs have client isolation by default turned on, especially for non-standard/custom /guest wireless networks).

If you could share your node config (redacted, obviously), it might be easier to check some overlooked config problem, although that does not seem to be the cause…

183

The VERBOSE logs for my ESPhome relay node doesn’t give a clue:

INFO Trying to connect to mvrelay @ 10.0.30.44 in the background
INFO Successfully connected to mvrelay @ 10.0.30.44 in 0.017s
INFO Successful handshake with mvrelay @ 10.0.30.44 in 0.112s
[22:23:06][I][app:102]: ESPHome version 2023.12.5 compiled on Jan 13 2024, 22:21:36
[22:23:06][C][status_led:065]: Status Led Light:
[22:23:06][C][status_led:066]:   Pin: GPIO13
[22:23:06][C][wifi:573]: WiFi:
[22:23:06][C][wifi:405]:   Local MAC: [redacted]
[22:23:06][C][wifi:410]:   SSID: [redacted]
[22:23:06][C][wifi:411]:   IP Address: 10.0.30.44
[22:23:06][C][wifi:413]:   BSSID: [redacted]
[22:23:06][C][wifi:414]:   Hostname: 'mvrelay'
[22:23:06][C][wifi:416]:   Signal strength: -59 dB ▂▄▆█
[22:23:06][V][wifi:418]:   Priority: 0.0
[22:23:06][C][wifi:420]:   Channel: 1
[22:23:06][C][wifi:421]:   Subnet: 255.255.255.0
[22:23:06][C][wifi:422]:   Gateway: 10.0.30.1
[22:23:06][C][wifi:423]:   DNS1: 10.0.30.1
[22:23:06][C][wifi:424]:   DNS2: 0.0.0.0
[22:23:06][C][logger:443]: Logger:
[22:23:06][C][logger:444]:   Level: VERBOSE
[22:23:06][C][logger:445]:   Log Baud Rate: 115200
[22:23:06][C][logger:447]:   Hardware UART: UART0
[22:23:06][C][uart.arduino_esp32:137]: UART Bus 1:
[22:23:06][C][uart.arduino_esp32:138]:   TX Pin: GPIO25
[22:23:06][C][uart.arduino_esp32:139]:   RX Pin: GPIO26
[22:23:06][C][uart.arduino_esp32:141]:   RX Buffer Size: 256
[22:23:06][C][uart.arduino_esp32:143]:   Baud Rate: 4800 baud
[22:23:06][C][uart.arduino_esp32:144]:   Data Bits: 8
[22:23:06][C][uart.arduino_esp32:145]:   Parity: NONE
[22:23:06][C][uart.arduino_esp32:146]:   Stop bits: 2
[22:23:06][C][uptime.sensor:031]: Uptime Sensor 'Uptime'
[22:23:06][C][uptime.sensor:031]:   Device Class: 'duration'
[22:23:06][C][uptime.sensor:031]:   State Class: 'total_increasing'
[22:23:06][C][uptime.sensor:031]:   Unit of Measurement: 's'
[22:23:06][C][uptime.sensor:031]:   Accuracy Decimals: 0
[22:23:06][C][uptime.sensor:031]:   Icon: 'mdi:timer-outline'
[22:23:06][V][uptime.sensor:031]:   Unique ID: 'a842e350ed40-uptime'
[22:23:06][C][template.select:065]: Template Select 'MechanischeVentilatieSelect'
[22:23:06][C][template.select:066]:   Update Interval: 60.0s
[22:23:06][C][template.select:069]:   Optimistic: YES
[22:23:06][C][template.select:070]:   Initial Option: Low
[22:23:06][C][template.select:071]:   Restore Value: NO
[22:23:06][C][switch.gpio:068]: GPIO Switch 'mvrelay Relay Medium'
[22:23:06][C][switch.gpio:070]:   Icon: 'mdi:electric-switch'
[22:23:06][C][switch.gpio:091]:   Restore Mode: always OFF
[22:23:06][C][switch.gpio:031]:   Pin: GPIO27
[22:23:06][C][switch.gpio:033]:   Interlocks:
[22:23:06][C][switch.gpio:037]:     mvrelay Relay High
[22:23:06][C][switch.gpio:068]: GPIO Switch 'mvrelay Relay High'
[22:23:06][C][switch.gpio:070]:   Icon: 'mdi:electric-switch'
[22:23:06][C][switch.gpio:091]:   Restore Mode: always OFF
[22:23:06][C][switch.gpio:031]:   Pin: GPIO14
[22:23:06][C][switch.gpio:033]:   Interlocks:
[22:23:06][C][switch.gpio:037]:     mvrelay Relay Medium
[22:23:06][C][gpio.binary_sensor:015]: GPIO Binary Sensor 'mvrelay Switch Medium'
[22:23:06][C][gpio.binary_sensor:016]:   Pin: GPIO32
[22:23:06][C][gpio.binary_sensor:015]: GPIO Binary Sensor 'mvrelay Switch High'
[22:23:06][C][gpio.binary_sensor:016]:   Pin: GPIO33
[22:23:06][C][light:103]: Light 'LED'
[22:23:06][C][bl0939:130]: BL0939:
[22:23:06][C][bl0939:131]: Voltage 'mvrelay Voltage'
[22:23:06][C][bl0939:131]:   Device Class: 'voltage'
[22:23:06][C][bl0939:131]:   State Class: 'measurement'
[22:23:06][C][bl0939:131]:   Unit of Measurement: 'V'
[22:23:06][C][bl0939:131]:   Accuracy Decimals: 1
[22:23:06][C][bl0939:132]: Current 1 'mvrelay Current 1'
[22:23:06][C][bl0939:132]:   Device Class: 'current'
[22:23:06][C][bl0939:132]:   State Class: 'measurement'
[22:23:06][C][bl0939:132]:   Unit of Measurement: 'A'
[22:23:06][C][bl0939:132]:   Accuracy Decimals: 2
[22:23:06][C][bl0939:133]: Current 2 'mvrelay Current 2'
[22:23:06][C][bl0939:133]:   Device Class: 'current'
[22:23:06][C][bl0939:133]:   State Class: 'measurement'
[22:23:06][C][bl0939:133]:   Unit of Measurement: 'A'
[22:23:06][C][bl0939:133]:   Accuracy Decimals: 2
[22:23:06][C][bl0939:134]: Power 1 'mvrelay Power 1'
[22:23:06][C][bl0939:134]:   Device Class: 'power'
[22:23:06][C][bl0939:134]:   State Class: 'measurement'
[22:23:06][C][bl0939:134]:   Unit of Measurement: 'W'
[22:23:06][C][bl0939:134]:   Accuracy Decimals: 0
[22:23:06][C][bl0939:135]: Power 2 'mvrelay Power 2'
[22:23:06][C][bl0939:135]:   Device Class: 'power'
[22:23:06][C][bl0939:135]:   State Class: 'measurement'
[22:23:06][C][bl0939:135]:   Unit of Measurement: 'W'
[22:23:06][C][bl0939:135]:   Accuracy Decimals: 0
[22:23:06][C][bl0939:136]: Energy 1 'mvrelay Energy 1'
[22:23:06][C][bl0939:136]:   Device Class: 'energy'
[22:23:06][C][bl0939:136]:   State Class: 'total_increasing'
[22:23:06][C][bl0939:136]:   Unit of Measurement: 'kWh'
[22:23:06][C][bl0939:136]:   Accuracy Decimals: 3
[22:23:06][C][bl0939:137]: Energy 2 'mvrelay Energy 2'
[22:23:06][C][bl0939:137]:   Device Class: 'energy'
[22:23:06][C][bl0939:137]:   State Class: 'total_increasing'
[22:23:06][C][bl0939:137]:   Unit of Measurement: 'kWh'
[22:23:06][C][bl0939:137]:   Accuracy Decimals: 3
[22:23:06][C][bl0939:138]: Energy sum 'mvrelay Energy Total'
[22:23:06][C][bl0939:138]:   Device Class: 'energy'
[22:23:06][C][bl0939:138]:   State Class: 'total_increasing'
[22:23:06][C][bl0939:138]:   Unit of Measurement: 'kWh'
[22:23:06][C][bl0939:138]:   Accuracy Decimals: 3
[22:23:06][C][restart.button:017]: Restart Button 'Restart'
[22:23:06][C][mdns:115]: mDNS:
[22:23:06][C][mdns:116]:   Hostname: mvrelay
[22:23:06][V][mdns:117]:   Services:
[22:23:06][V][mdns:119]:   - _esphomelib, _tcp, 6053
[22:23:06][V][mdns:121]:     TXT: friendly_name = MVrelay
[22:23:06][V][mdns:121]:     TXT: version = 2023.12.5
[22:23:06][V][mdns:121]:     TXT: mac = a842e350ed40
[22:23:06][V][mdns:121]:     TXT: platform = ESP32
[22:23:06][V][mdns:121]:     TXT: board = esp32dev
[22:23:06][V][mdns:121]:     TXT: network = wifi
[22:23:06][V][mdns:121]:     TXT: api_encryption = Noise_NNpsk0_25519_ChaChaPoly_SHA256
[22:23:06][C][ota:097]: Over-The-Air Updates:
[22:23:06][C][ota:098]:   Address: mvrelay.local:3232
[22:23:06][C][ota:101]:   Using Password.
[22:23:06][C][api:139]: API Server:
[22:23:06][C][api:140]:   Address: mvrelay.local:6053
[22:23:06][C][api:142]:   Using noise encryption: YES
[22:23:06][C][wifi_signal.sensor:009]: WiFi Signal 'RSSI'
[22:23:06][C][wifi_signal.sensor:009]:   Device Class: 'signal_strength'
[22:23:06][C][wifi_signal.sensor:009]:   State Class: 'measurement'
[22:23:06][C][wifi_signal.sensor:009]:   Unit of Measurement: 'dBm'
[22:23:06][C][wifi_signal.sensor:009]:   Accuracy Decimals: 0
[22:23:06][V][wifi_signal.sensor:009]:   Unique ID: 'a842e350ed40-wifisignal'

Here is my node config:

substitutions:
  devicename: mvrelay
  max_temp: "85.0"

esphome:
  name: ${devicename}
  friendly_name: MVrelay

  # Ensures that, after a reboot, the ventilation will go to the state reflected by the physical knob. Since the relais go off first during the boot, the default value is already "Low" and does not need to be defined anymore.
  on_boot:
    if:
      condition:
        binary_sensor.is_on: switch_medium
      then:
        - select.set:
            id: mvselect
            option: "Medium"   
      else:
        if:
          condition:
            binary_sensor.is_on: switch_high
          then:
            - select.set:
                id: mvselect
                option: "High"   
# Enable logging
logger:
  level: INFO

# Enable Home Assistant API
api:
  encryption:
    key: !secret mvrelay_api_key

ota:
  password: !secret ota_secret

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

esp32:
  board: esp32dev

sensor:
  - platform: wifi_signal
    name: "RSSI"
    id: sensor_rssi
    update_interval: 90s
    entity_category: "diagnostic"

  - platform: uptime
    name: "Uptime"
    id: sensor_uptime
    update_interval: 300s
    entity_category: "diagnostic"

  - platform: bl0939
    update_interval: 60s
    voltage:
      name: ${devicename} Voltage
    current_1:
      name: ${devicename} Current 1
      disabled_by_default: True
    current_2:
      name: ${devicename} Current 2
      disabled_by_default: True
    active_power_1:
      name: ${devicename} Power 1
    active_power_2:
      name: ${devicename} Power 2
    energy_1:
      name: ${devicename} Energy 1
    energy_2:
      name: ${devicename} Energy 2
    energy_total:
      name: ${devicename} Energy Total

light:
  - platform: status_led
    name: "LED"
    id: led_status
    pin:
      number: GPIO13
      inverted: True
    internal: True

button:
  - platform: restart
    name: "Restart"
    id: button_restart

uart:
  tx_pin: GPIO25
  rx_pin: GPIO26
  baud_rate: 4800
  parity: NONE
  stop_bits: 2

switch:
  - platform: gpio
    id: Relay_Medium
    name: ${devicename} Relay Medium
    pin: GPIO27
    icon: "mdi:electric-switch"
    restore_mode: always_off
    # Ensure only one switch at a time is on (https://esphome.io/components/switch/gpio.html#interlocking)
    interlock: &interlock_group [Relay_Medium, Relay_High]
    on_turn_on:
      then:
        - select.set:
            id: mvselect
            option: "Medium"      
    on_turn_off:
      then:
        - select.set:
            id: mvselect
            option: "Low" 
  - platform: gpio
    id: Relay_High
    name: ${devicename} Relay High
    pin: GPIO14
    icon: "mdi:electric-switch"
    restore_mode: always_off
    interlock: *interlock_group
    on_turn_on:
      then:
        - select.set:
            id: mvselect
            option: "High"      
    on_turn_off:
      then:
        - select.set:
            id: mvselect
            option: "Low" 

binary_sensor:
  - platform: gpio
    name: ${devicename} Switch Medium
    id: switch_medium
    pin:
      number: GPIO32
      mode:
        input: True
        pullup: True
      inverted: True
    filters:
      - delayed_on_off: 50ms
    publish_initial_state: false
    on_press:
      then:
        - select.set:
            id: mvselect
            option: "Medium"
    on_release:
      then:
        - select.set:
            id: mvselect
            option: "Low"
  - platform: gpio
    name: ${devicename} Switch High
    id: switch_high
    pin:
      number: GPIO33
      mode:
        input: True
        pullup: True
      inverted: True
    filters:
      - delayed_on_off: 50ms
    publish_initial_state: false
    on_press:
      then:
        - select.set:
            id: mvselect
            option: "High"
    on_release:
      then:
        - select.set:
            id: mvselect
            option: "Low"

select:
  - platform: template
    name: MechanischeVentilatieSelect
    id: mvselect
    options:
     - "Low"
     - "Medium"
     - "High"
    restore_value:  false
    optimistic: true
    on_value:
      then:
        - lambda: |-
            if (id(mvselect).state == "Low") {
            id(Relay_Medium).turn_off();
            id(Relay_High).turn_off();
            } else if (id(mvselect).state == "Medium") {
              id(Relay_Medium).turn_on();
            } else if (id(mvselect).state == "High") {
              id(Relay_High).turn_on();
            }

If you find anything wrong with this config, please let me know :slight_smile:

I also checked the ESPhome add-on config and it actually has a setting called

Home Assistant Dashboard Integration

which is disabled by default (at least in my case). Enabling it does nothing different. Here are the logs since the most recent restart of the ESPhome add-on:

s6-rc: info: service fix-attrs: starting
s6-rc: info: service base-addon-timezone: starting
s6-rc: info: service base-addon-log-level: starting
s6-rc: info: service fix-attrs successfully started
[21:46:28] INFO: Configuring timezone (Europe/Amsterdam)...
s6-rc: info: service base-addon-log-level successfully started
s6-rc: info: service base-addon-timezone successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service init-nginx: starting
s6-rc: info: service esphome: starting
s6-rc: info: service esphome successfully started
s6-rc: info: service init-nginx successfully started
s6-rc: info: service nginx: starting
s6-rc: info: service nginx successfully started
s6-rc: info: service discovery: starting
[21:46:31] INFO: Waiting for ESPHome dashboard to come up...
[21:46:31] INFO: Starting ESPHome dashboard...
2024-01-13 21:46:32,469 INFO Starting dashboard web server on unix socket /var/run/esphome.sock and configuration dir /config/esphome...
[21:46:32] INFO: Starting NGINX...
2024-01-13 21:46:33,536 INFO 304 GET / (0.0.0.0) 15.29ms
2024-01-13 21:46:33,610 INFO 304 GET /devices (0.0.0.0) 4.07ms
[21:46:33] INFO: Successfully send discovery information to Home Assistant.
s6-rc: info: service discovery successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
2024-01-13 21:46:38,615 INFO 304 GET /devices (0.0.0.0) 4.03ms
[repeating]
2024-01-13 21:47:44,033 INFO 304 GET /devices (0.0.0.0) 2.96ms
2024-01-13 21:48:37,061 INFO 304 GET / (0.0.0.0) 2.80ms
2024-01-13 21:48:37,174 INFO 304 GET /devices (0.0.0.0) 4.14ms
2024-01-13 21:48:39,696 INFO 200 GET /static/js/esphome/c.VPeQYmPp.js (0.0.0.0) 33.61ms
2024-01-13 21:48:39,743 INFO 200 GET /static/js/esphome/c.nIEdC0BA.js (0.0.0.0) 3.97ms
2024-01-13 21:48:39,749 INFO 200 GET /static/js/esphome/c.bcXJSIrw.js (0.0.0.0) 3.13ms
2024-01-13 21:48:39,754 INFO 200 GET /static/js/esphome/c.KwoaAax2.js (0.0.0.0) 2.69ms
2024-01-13 21:48:39,836 INFO 200 GET /static/js/esphome/c.g39gNE03.js (0.0.0.0) 3.92ms
2024-01-13 21:48:39,867 INFO 101 GET /logs (0.0.0.0) 1.65ms
2024-01-13 21:48:39,871 INFO Running command 'esphome --dashboard logs /config/esphome/mvrelay.yaml --device 10.0.30.44'
2024-01-13 21:48:42,168 INFO 304 GET /devices (0.0.0.0) 3.13ms
[repeating]
2024-01-13 21:49:37,253 INFO 304 GET /devices (0.0.0.0) 2.99ms
2024-01-13 21:49:42,143 INFO 200 GET /static/js/esphome/c.JK_Zc7F3.js (0.0.0.0) 11.83ms
2024-01-13 21:49:42,259 INFO 304 GET /devices (0.0.0.0) 3.04ms
2024-01-13 21:49:43,226 INFO 101 GET /validate (0.0.0.0) 1.07ms
2024-01-13 21:49:43,229 INFO Running command 'esphome --dashboard config /config/esphome/mvrelay.yaml --show-secrets'
2024-01-13 21:49:44,611 INFO Process exited with return code 0
2024-01-13 21:49:47,259 INFO 304 GET /devices (0.0.0.0) 2.72ms
2024-01-13 21:49:52,214 INFO 101 GET /logs (0.0.0.0) 1.29ms
2024-01-13 21:49:52,217 INFO Running command 'esphome --dashboard logs /config/esphome/mvrelay.yaml --device 10.0.30.44'
2024-01-13 21:49:52,262 INFO 304 GET /devices (0.0.0.0) 2.06ms
2024-01-13 21:49:57,265 INFO 304 GET /devices (0.0.0.0) 2.65ms
2024-01-13 21:50:19,020 INFO 304 GET / (0.0.0.0) 1.65ms
2024-01-13 21:50:19,074 INFO 304 GET /devices (0.0.0.0) 2.70ms
2024-01-13 21:54:00,399 INFO 304 GET / (0.0.0.0) 1.71ms
2024-01-13 21:54:00,482 INFO 304 GET /devices (0.0.0.0) 3.68ms
2024-01-13 21:54:05,454 INFO 304 GET /devices (0.0.0.0) 2.57ms
2024-01-13 21:57:30,227 INFO 304 GET / (0.0.0.0) 2.72ms
2024-01-13 21:57:30,283 INFO 304 GET /devices (0.0.0.0) 4.40ms
2024-01-13 21:57:33,097 INFO 101 GET /logs (0.0.0.0) 1.11ms
2024-01-13 21:57:33,613 INFO Running command 'esphome --dashboard logs /config/esphome/mvrelay.yaml --device 10.0.30.44'
2024-01-13 21:57:35,296 INFO 304 GET /devices (0.0.0.0) 2.11ms
[repeating]
2024-01-13 21:58:51,340 INFO 304 GET /devices (0.0.0.0) 2.70ms
2024-01-13 21:58:56,299 INFO 200 GET /static/js/esphome/c.L2HzI1eb.js (0.0.0.0) 11.33ms
2024-01-13 21:58:56,306 INFO 200 GET /edit?configuration=mvrelay.yaml (0.0.0.0) 2.79ms
2024-01-13 21:58:56,326 INFO 200 GET /static/js/esphome/monaco-editor/esm/vs/editor/editor.worker.js (0.0.0.0) 3.97ms
2024-01-13 21:58:57,054 INFO 200 GET /static/fonts/codicon.ttf (0.0.0.0) 12.42ms
2024-01-13 21:58:57,387 INFO 101 GET /ace (0.0.0.0) 1.39ms
2024-01-13 21:58:57,390 INFO Running command 'esphome --dashboard -q vscode --ace /config/esphome'

Not sure if that helps, though.

184

I don’t see anything wrong, maybe you can increase the verbosity of the log in the node for the desired components and check if there is more info. Something like this:

 logger:
   level: INFO
   logs:
     mdns: DEBUG
     api: DEBUG

Another option is to check the API component and set rules to log when the connection occurs (if it occurs at all) and see what happens:

Like here in the example:

The other possible way is to try and ping or resolve the mdns address from Home Assistant to see if it’s working, given the fact that ESPhome integration needs mdns connection for auto-discovery to work.

As I don’t have it installed myself, it’s difficult to be more helpful :frowning:

185

I got it working! And I think I know what the problem was:

When you add a new VLAN interface through nmcli, it allows the HA instance to communicate with the VLAN and its devices (hence the ESPhome dashboard finds the relay without issue), but it does nothing with the HA configuration itself. HA is configured to Auto Configure the network adapters the integrations will use by default and it seems that it does not detect an added VLAN adapter automatically.

I found another thread a few days ago which hinted at the solution but didn’t state it explicitly. I hope this will help others who run into the same issue. You simply need to go to Settings - System - Network, go to the Network Adapter settings, unselect Auto Configure and select the adapters that are detected (in my case: end0 and end0.30). You will need to reboot the HA device manually for this to take effect.

By reverting back to the Auto Configure setting, I replicated my problem and the ESP node is not detected anymore. This could actually be worth a bug report, what do you think?

2 Likes
186

Great work! This is a very important piece of information for those who follow the tutorial. I have not come across anything like that yet, but VLAN integration/configuration through the HA terminal tools should now be the standard, I guess. It’s time to revisit this tutorial and adapt it to the latest version :slight_smile:
As you can see here in this post by @Deckoz2302, states that starting from HA version 11 you can configure VLANs using internal commands and the ethernet VLAN devices will also be listed in the network settings of HA. I don’t think a bug report is important here, given the fact that this was always an “under the hood” approach and not really accepted by the official HA, but maybe it’s worth a shot.
It’s great that you found the solution and posted it here for every one to benefit from it :slight_smile: Thanks again!

1 Like
187

1.) In HA you must configure the IOT VLAN to be the “main” network for integrations.
This is helping to solve ESPHome issues.

2.) mdns should work in that VLAN from now on

Sidenote:
If you played around with an “own” domain and static DNS names you must use something different than .local and make sure the DNS works correctly.
Unfortunately, I am not using mdns anymore (but not disabled in ESPHome) and have all things configured by lease-script in my mikrotik router.

Sidenote 2:
In the configuration there is a “use ip adress” option of ESPHome. This can solve some issues as well.

Good luck

188

I tried to replicate the situation by first removing the VLAN interface created with nmcli, rebooting and confirming that its configuration was removed. Then I added a vlan interface through the ha cli and did an ha network reload. It did not resolve the situation, the ESPhome relay was not discovered even after waiting several minutes. The interface did show up in the list of interfaces in Settings - System - Network, but it did not show up in the list of network adapters.

I then did a reboot of the system, after which the relay still was not discovered. I then proceded to disable the auto configuration of HA adapters and now the VLAN interface was present. By selecting both interfaces and rebooting, HA discovered the relay.

My conclusion is that it does not matter how the VLAN interface is added: they both require a reboot and disabling of the auto-configure network adapters option to be able to discover devices through mDNS on the VLAN. Judging by the lack of posts about this issue I must have a pretty rare setup going on. But perhaps this justifies an addition to @cr0muald0 's tutorial.

Interestingly, the connection made with ha does not show up in the nmcli con show output. I’m not at all familiar with NetworkManager to be able to explain that.

189

THANK YOU!
This was what finally worked for me.

190

My HA is in ‘Main’ vlan. I have many it devices in IOT and NOT vlan. My Samsung tv is in NOT vlan and HA needs to be in the same vlan for setup (not sure if it needs to be in same vlan after setup).

So I followed the guide. and finally samsung tv can be added. But in unifi log I see that HA is constantly jumping around vlans. Is that normal? should I expect any issues?

image
image1318×802 138 KB

Update1:

I realized all my Tasmota devices are unavailable from Tasmota integration. And saw from unifi log that Tasmota devices are dropped because of “DROP invalid state” rule. Once I disabled the rule, they were back in HA. Should I leave them like this? Is this a good practice for the firewall rule?

I have a rule that prevents IOT and NOT devices from accessing their respective gateway ports (80, 443, 22). HA is also blocked constantly by this rule. Is it necessary for HA to access this? should I make an exception to the rule?

I also have the feeling that my motion trigger automation are not working properly. all the devices are involved in the automation are zigbee devices (zigbee2mqtt by USB). I don’t understand why :-/

191

I know I’m late to the game here but hoping you still monitor this thread.

I am running Home Assistant on a Raspberry Pi4. My network hardware consists of a TP-Link ER605 router and a TP-Link 24 port POE switch. I have created VLAN50 for my Raspberry Pi and VLAN20 for my IoT devices. I can access my IoT devices from HA and not vice versa. However HA will not auto discover new IoT devices which is why I’m attempting to follow your tutorial.

I have installed the SSH & Web Terminal add-on. When I login to terminal and issue the whoami command it confirms I am the root user. However when I issue the nmcli command all it does is give me a long list of parameters and values. It does not take me into the nmcli configuration tool with the #nmcli prompt and ability to issue commands and save files.

Am I missing something or is this capability no longer available in HA?

Any help is greatly appreciated.

192

Hi,
will try to help, but much information is missing to give a proper suggestion.
Yes, it needs to live in the same VLAN, because if you change network segments the IP will change, and you’ll have to re-discover/re-add the devices to HA.
Tasmota devices should live in the same VLAN as HA to avoid firewall issues (they should belong at least to one common VLAN)
What gateway are you talking about? Firewall? HA? I don’t know how you set up your network to understand this question. Your setup is quite different from what is suggested in the tutorials above, as it seems you have only one VLAN to which HA belongs, right? If you detail better what you have and want to achieve, I might be able to help more :slight_smile:

193

Hi, it all depends on what version of HA you are using. Check these posts and see if you can configure your VLANs using the UI

194

Ok. I will try to explain the situation in more detail.

My HA (192.168.1.109) was in the Main VLAN.

My Tasmota and Samsung TV are in NoT VLAN (192.168.4.XXX).

Without any VLAN configuration (before applying your guide), I can control the Tasmota devices. Because I set a firewall rule that allows the NoT to communicate with HA. But I can’t add my samsungTV, because Samsung integration doesn’t like vlan (here).

So to solve this problem, I used your guide. And here is what I did

#added 2 vlan interfaces
nmcli con add type vlan con-name end0@vlan2 dev end0 id 2 ip4 192.168.2.109/24 ipv4.dns 192.168.1.194 gw4 192.168.2.1
nmcli con add type vlan con-name end0@vlan4 dev end0 id 4 ip4 192.168.4.109/24 ipv4.dns 192.168.1.194 gw4 192.168.4.1

#set the priority
nmcli con modify end0@vlan2 ipv4.route-metric 400
nmcli con modify end0@vlan4 ipv4.route-metric 401

#reboot HA machine
#uncheck auto in "system>network>network adapter" and manually selected all 3 interfaces.
#reboot HA machine again
  1. Then I tried to add my samsungtv, and it worked!
  2. Then I saw in unifi controller that HA is moving between networks. Not sure if this is expected.
  3. All my Tasmota devices are unavailable. and didn’t try to re-add them, just tried to reload. I have a rule DROP Invalid state in unifi. after disabling the rule, tasmotas are back again.
  4. My wife and I noticed that motion sensor-based automations are not instant like before. Devices involved in the automation are Zigbee devices by the way. So only possible reason I could find is that HA sent the command to turn on the light late because it was switching the network?! My Zigbee network is also connected to HA by USB, not any network adapter.

After all that, I reverted back and living my life without samsungTV integration :stuck_out_tongue: .