search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
73.23k stars 30.58k forks source link

TPLink component fails to register devices outside of current subnet (discovery & declared) #23218

Closed bgulla closed 3 years ago

bgulla commented 5 years ago

Home Assistant release with the issue:

0.89.1

Last working Home Assistant release (if known): 0.88

Operating environment (Hass.io/Docker/Windows/etc.):

Docker, Hassio Tested Component/platform:

https://www.home-assistant.io/components/tplink/

Description of problem: I host all my TPLink IoT devices on a separate subnet/vlan for security purposes and up until 0.89 (the addition of the dedicated TPLink component vs switch/light components). The devices still work in the Kasa app but are unable to connect given the new component. Devices on the same subnet as hass work properly.

Note: The hass instance is running on the 10.0.1.x subnet and my IOT/TP-Link devices are on 10.0.8.x

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):

tplink:
  discovery: true
  light:
    - host: 10.0.8.252

Traceback (if applicable):

2019-03-10 21:55:27 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/usr/src/app/homeassistant/helpers/entity_platform.py", line 257, in _async_add_entity
    if entity.unique_id is not None:
  File "/usr/src/app/homeassistant/components/tplink/light.py", line 82, in unique_id
    return self._sysinfo["mac"]
TypeError: 'NoneType' object is not subscriptable

Additional information: I have also tested this with switches and neither are working as expected and throw the same error.

This is a refresh of this issue that started to get off-topic.

stale[bot] commented 5 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

GatCode commented 5 years ago

I also have the same problem although the network is configured the right way. Are there any solutions until now? I've also created a Unifi community post: https://community.ui.com/questions/IoT-VLAN-Device-Discovery-Problem-but-Kasa-is-working/3afb479b-0ffb-497e-bd5f-b8ab44f6200b

hmoffatt commented 5 years ago

I'm also having trouble. My HomeAssistant machine has two interfaces, one on the regular subnet and one on the IOT subnet. The TP-Link devices are never discovered. Other devices are discovered on that subnet ok eg ESPHome. If I manually specify the IP of the device then it is found and working correctly.

vangorra commented 5 years ago

I'm not sure there are any solutions for discovery. You can set the ips of the devices in the config, then you don't have to worry about discovery.

hmoffatt commented 5 years ago

As I said, I actually have an interface on the IOT subnet, as well as another, so I'm not trying to do cross-subnet discovery (which can't work).

It looks like the pyHS100 library expects the caller to handle discovery on each interface separately (as of https://github.com/GadgetReactor/pyHS100/pull/176), so HomeAssistant would need to do this to make this work again. Or at the very least the broadcast address could be specified in the configuration parameters for the tplink component.

rytilahti commented 4 years ago

So, to my understanding there are two issues at play here:

  1. Fail on static entries for sysinfo being none when using both discovery & static entries (as reported by @bgulla)
  2. Discovery targeting "wrong" network, which can be alleviated by the new pyhs100 API (mentioned by @hmoffatt). I will try to do a new release for pyhs100 soon enough to get this API accessible for homeassistant, so that some approach (configuring subnets to discover, either per interface or by broadcast address) can be added to homeassistant.
hmoffatt commented 4 years ago

Thanks @rytilahti . It would be great if the broadcast address could be specified in the tplink component configuration alongside the discovery setting, even better if the component could run discovery on all the interfaces automatically. My esphome devices got discovered on the "other" subnet ok, though maybe that was luck.

stale[bot] commented 4 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

hmoffatt commented 4 years ago

This is still useful but not implemented. Please re-open it.

rytilahti commented 4 years ago

https://github.com/home-assistant/home-assistant/pull/29505 is the PR for tracking the state for this.

stale[bot] commented 4 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

hmoffatt commented 4 years ago

This still needs fixing. There's a pull-request with the changes here: https://github.com/home-assistant/core/pull/29505 , but it's gone stale. @mbrancato?

hmoffatt commented 4 years ago

Does the new edict regarding YAML and integrations mean that no changes can be made to this integration without a major revamp?

stale[bot] commented 4 years ago

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

hmoffatt commented 4 years ago

This is still relevant.

gobigdave commented 4 years ago

I'm having this problem as well. My TPLink switches are on a separate IoT subnet. I verified that I can ping my HA server from the IoT subnet, and I can ping the switches from the HA server. Multicast DNS is enabled. Discovery doesn't work. I am able to add the switches to configuration.yaml, but they do not show up as available in the HA UI.

All switches work fine from the Kass app (my iPhone is in the main LAN).

estiens commented 4 years ago

Also seeking a fix for this

rytilahti commented 4 years ago

Let's reopen this then, the linked PR adding configurable subnets got stale, but statically defined devices should not be failing.

ryanfitton commented 3 years ago

Hello, I'm also hoping to see a fix for this. My setup is similar to those mentioned above. Home Assistant is in its own vlan, Tplink devices are in their own vlan. Firewall rules allow both vlans to communicate.

genebean commented 3 years ago

I am in need of this too. Like others, my Pi has a presence on both networks:

pi@homeassistant:~ $ cat /etc/network/interfaces
# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

allow-hotplug eth0
iface eth0 inet dhcp

auto eth0.16
iface eth0.16 inet dhcp

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
rafaelmathieu commented 3 years ago

I am in the same boat. Hoping for a fix at some point.

estiens commented 3 years ago

I can even ping the ip addresses of the switches (some are on a tp-link deco guest network, and some on my main network, but as far as I know that is a fake separation, they all get IPs from the same DHCP server in the same subnet) - however even if I manually set the IPs, only the ones connected to the main network wifi SSID that Hass is on can be found

snipes040 commented 3 years ago

This seems strange since I have the same setup with my TPLink switches on a separate VLAN so the integration doesn't work but specifying them manually with the IP's works completely fine for me. Here is my setup, hopefully this helps? The outside plug randomly flickers as well which only happens with that switch which is very weird but haven't been able to determine if it's a HA thing or a network thing.

tplink: discovery: false switch:

grilparto commented 3 years ago

I'm also having this same issue. TPLink Devices that are on the same network 192.168.1.0/24 as HA OS are being discovered and detected. TPLink Devices I've added to my IoT network 10.10.20.0/24 are NOT being detected. Hoping this can still be resolved.

Can confirm that things appear to work if manually configuring all IPs and setting discovery to false in the configuration.yaml per @snipes040 post above https://github.com/home-assistant/core/issues/23218#issuecomment-781433900

I also attempted to add a second NIC to my HA OS VM that was part of the IoT VLAN. I had to enable the second nic in HA OS using the command line. This created a few problems because HA OS would only pick one interface as default and ignore the other interface causing certain devices on the opposite network to become unavailable and never be found. Wasn't able to confirm if this method impacted only tplink devices but felt that it wasn't worth pursuing.

hmoffatt commented 3 years ago

The latest version of the tplink integration does support non-YAML configuration but devices outside the subnet are still not discovered. Could it get the networks from the new network integration to do the discovery?

It appears that specifying IP addresses in the YAML still works at least.

hmoffatt commented 3 years ago

If you hit "reload" on the TPLink integration now it ignores the YAML settings and attempts discovery, which fails if your devices are on another subnet.

bdraco commented 3 years ago

After #56701 you can now add an device by ip manually via the config flow.

bdraco commented 3 years ago

https://github.com/home-assistant/core/pull/56721

hmoffatt commented 3 years ago

This works great. I set up a brand new test 2021.10.0b2, change the network config to add my other VLAN as well, then added the TPLink integration and it found my two HS110 devices.

kushagharahi commented 3 months ago

Sorry to gravedig -- I'm having trouble with discovery cross subnet. Direct connection via IP works cross subnet, but not discovery. Any tips? mDNS is enabled as well. Let me know if I should open a separate issue or if this is my network config causing this.

rytilahti commented 3 months ago

Please create a new issue, this issue has been closed already for 3 years and the integration has changed a lot since then.

As long as the homeassistant is configured correctly (i.e., you have configured it to use multiple interfaces) this should work fine as it is what I also use for development. To do that, you have to enable the "advanced mode" in the user profile, which will make it possible to configure the network interfaces under the network settings.