Setup VLAN and HA tutorial

cr0muald0 · January 12, 2024, 1:29pm

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…

gerritgleufhoed · January 13, 2024, 9:04pm

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

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.

cr0muald0 · January 14, 2024, 8:14pm

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

gerritgleufhoed · January 15, 2024, 10:16pm

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?

cr0muald0 · January 16, 2024, 11:20am

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
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 Thanks again!

autoX · January 16, 2024, 10:04pm

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

gerritgleufhoed · January 16, 2024, 10:08pm

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.

pjrml · April 19, 2024, 4:44pm

THANK YOU!
This was what finally worked for me.

arifroni · May 8, 2024, 7:39pm

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?

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 :-/

Entirelynutz · May 10, 2024, 5:01pm

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.

cr0muald0 · May 10, 2024, 11:06pm

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

cr0muald0 · May 10, 2024, 11:10pm

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

arifroni · May 11, 2024, 12:23pm

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

Then I tried to add my samsungtv, and it worked!
Then I saw in unifi controller that HA is moving between networks. Not sure if this is expected.
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.
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 .

cr0muald0 · May 11, 2024, 1:16pm

I understand your config better now, thanks, but still there are important things to be considered.

Same network segment and everything works because there is no intermediate firewall/routing involved (except whatever filtering you do in both client and HA)
I don’t know how unifi works (I don’t use it), but remember that HA should only have ONE default gateway set up (although you have 2 network interfaces in it - Main VLAN and NOT VLAN, right?) You have TWO default gateways set up “gw4 192.168.2.1 / gw4 192.168.4.1” , and that is wrong. If Unifi sees the same hostname in two networks it might be confused or suspicious, but it should not be a problem, disabling whatever it is triggering.
You need to reconfigure the tasmotas and re-add them to use the ip of HA that belongs to the same VLAN as the clients. It can’t be going across VLANs.
I have a Zigbee usb and there is no waiting involved. Your network is not properly configured as per number 2 and 3

Entirelynutz · May 11, 2024, 7:35pm

Thanks for your reply. I am using
HA 2024.5.3
Home Assistant OS 12.3
TP-Link ER605 router
Raspberry Pi 4

After reading through the posts you provided it appears I can use the “ha network vlan” to create an HA VLAN. What I’m not sure about is do I need to create a VLAN with a static ip address for each device in my IoT VLAN or can I set it up for any device that appears on the VLAN?

cr0muald0 · May 12, 2024, 9:59am

This is something you need to decide on your own (your network architecture), but I can give you my example. I have multiple VLANs, all divided into categories of IOT devices (sensors, media, lights, etc), that is, those you want to/should/can see each other and those you don’t want to/shouldn’t see each other. Example: do you want your TV to see your Tasmotas? Not really, so create different VLANs and attach them each to their own VLAN. Each VLAN member should definitely have its own IP (static is good, but you can also have a dhcp server there). If you happen to have some other media device that you want to be able to see your TV (stream to it, for example), attach it to the same VLAN, and so on and forth. You can have as many VLANs as you want, and then just make HA/RPI4 belong to all of them by creating different network interfaces/VLANs.
Also remember, you should have one main network (usually what you get by default by plugging the RJ45 to your switch, if you don’t want to VLAN it specifically, you don’t have to, and it will sit in your PVID for that port from the switches config) that serves as a gateway to access the internet or the LAN, where no IOT device that you feel unsafe should be connected/allowed to (call it the safe/unsafe VLAN if you will)

A more direct answer to your last question is: you create a VLAN not for each client but for each group of clients + HA/RPI4. Every client that joins that group/VLAN will/should be able to talk to HA/RPI4 via IP in the same network segment/VLAN, that is not going through a firewall or router.

I know the thread is long, but there are many interesting posts with suggestions for you to pick from. Here’s a picture:

Olivier974 · July 23, 2024, 5:54pm

Hello @cr0muald0

first thanks for your huge help to the community! never found it by myself.

One question i have (perhaps a silly one, sorry by advance…)

Your LAN network is the physicall one? means its the Vlan1? i m right ?

Thanks.

Because i see any example if you have HA in Vlan10 with yur TV, pc…and have Vlan20 with yur IOT.
Is it the same and your config will applied?

I mean my goal is put my LAN in Vlan10 and my IOT in Vlan20. But when i look at your exemple, seems i better let my LAN by default in Vlan1 (which is not really a Vlan, just the default route) and put my IOT in Vlan20 and use your config.

EDIT : find your reply already : https://community.home-assistant.io/t/setup-vlan-and-ha-tutorial/87705/56?u=olivier974

so it’s more clear: Your LAN is VLAN1, defaut one. Do you declare it as VLAN1 in Pfsense? seems yes on your schematic, but i thought Vlan1 is a reserved one. I m possible wrong…

I read in Pfsense Docs that’s its not recommanded to use the physical interface (eg: re0) for LAN if you have Vlan on it. But in YouTube i see several videos don’t take this into account and use physical LAN as Local LAN, then add 2 or more Vlan “on top” of it.

I have only see one time a guy that delete the physical interface after had created 2 VLAN on it.

Sorry if its not clear, English is not my native language.

So i am really disappointed about use physical NIC for LAN or create a VLAN1 for LAN.

Thanks if you can take some time to reply.

cr0muald0 · July 23, 2024, 11:06pm

Hi @Olivier974 ,

You’re welcome I already had it both physically separated VLANs, with different cables coming from the server hosting the firewall software (although it is not required) and virtual/logical VLANs in OPNSense, which I use now (I use OPNSense, but the same procedure can be applied to PFSense).

VLAN1 is historically the default VLAN for all ports, so all belongs to VLAN1 by just plugging a cable to any port on an out-of-the-box managed switch. Because of this, VLAN1 should be left for admin purposes only, isolated from other devices, but it really depends on your setup. If you have virtualized PFSense, you should configure it from the beginning to use the main LAN network in some VLAN other than VLAN1, created in your switch to isolate your main LAN (could be any other number, VLAN10 or VLAN11, for example, does not matter, as long as it is available and is according to your switch’s capabilities).

If you already use the default/VLAN1 for your main LAN in PFSense and your switch, that means access and configuration/admin will also be connected and available to all LAN connected devices, and you might want to avoid that, as it is considered bad security practice. Again, your LAN should be attached to a different VLAN for security reasons, if you want to isolate any devices (not only IOT) from the administration network.

One other option, if your switch allows, would be to configure it to be adminned in some other VLAN (admin specific and some switches have such options), but that depends on what kind of switch you have.

cr0muald0 · July 23, 2024, 11:57pm

You need to understand how VLANs, tagging and PVIDs work in a switch: when you use re0 in PFSense (read “physical untagged default LAN”) it only means that it will use the PVID (default untagged VLAN in your switch).

Like I was explaining before, when you plug any network cable from any device that does not support VLAN tagging, how can you put it in a specific VLAN? Answer: You configure the PVID of that port to be of the VLAN you want the device to belong to.

Quick example: imagine you have a laptop that you don’t trust, and you want to connect it with a network cable to your switch and to a specific VLAN (ex., VLAN44 where all devices are dangerous) and you can’t configure that laptop’s network card, how will you attach it to a VLAN44? Answer: You configure that specific port on that switch to have a PVID of VLAN44 (that is, by changing the default VLAN of that port from VLAN1 to VLAN44) and any device attached by cable to that port is now by default on VLAN44.

That’s why your re0 in PFSense is by default, without any configuration on the switch, a member of VLAN1, unless you change the configuration of your switch and PFSense. Proper configuration should be like this:

Configure/create all the VLANs you want in your switch (VLAN10 and VLAN20 or more/other, if you will)
Choose the port in the switch where PFSense will connect to (port 1 for ex.).
Add VLAN10 and VLAN20 as accepted tagged VLANs in port 1 of your switch’s configuration.
Install/configure PFSense/OPNSense and choose/configure the network card that is attached to port 1 of the switch as LAN network (re0 for example, could be other), using/configuring VLAN10 tagged as the main LAN and VLAN20 as IOT network, for example)
Choose other network card/cable for internet WAN and configure firewall rules according

That’s it!

Olivier974 · July 24, 2024, 3:19am

thanks a lot for your explanations and time!

its really more clear now.

have a nice day