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:
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.
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…
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.
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 
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
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!
1 Like
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
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.
THANK YOU!
This was what finally worked for me.
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 :-/
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.
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
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
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 
.
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
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?
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:
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.
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.
1 Like