Wemo plugs keep reconnecting to the network

[onlyoneme]

I'm not sure if my issue is related to the library or to the home assistant integration. When home assistant is running with wemo integration enabled all my wemo smart plugs keep reconnecting to the network constantly every few minutes. This doesn't happen when my HA is off. Logs don't seem to be helpful for me:

2021-07-14 12:46:43 DEBUG (MainThread) [homeassistant.components.wemo] Adding statically configured WeMo devices
2021-07-14 12:46:45 WARNING (Wemo Events Thread) [pywemo.subscribe] Resubscribe error for <Subscription basicevent "Audio Plug"> (('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))), will retry in 60s
2021-07-14 12:46:45 WARNING (Wemo Events Thread) [pywemo.subscribe] Resubscribe error for <Subscription basicevent "Showcase Light Plug"> (('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))), will retry in 60s
2021-07-14 12:46:54 WARNING (SyncWorker_9) [urllib3.connectionpool] Retrying (Retry(total=5, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f2785b86070>: Failed to establish a new connection: [Errno 111] Connection refused')': /upnp/control/basicevent1
2021-07-14 12:46:57 WARNING (SyncWorker_9) [urllib3.connectionpool] Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f2785b862b0>: Failed to establish a new connection: [Errno 111] Connection refused')': /upnp/control/basicevent1
2021-07-14 12:47:45 WARNING (Wemo Events Thread) [pywemo.subscribe] Resubscribe error for <Subscription basicevent "Audio Plug"> (('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))), will retry in 60s
2021-07-14 12:47:45 ERROR (Wemo Events Thread) [pywemo.ouimeaux_device] Unable to re-probe wemo <WeMo Switch "Audio Plug"> at 192.168.205.62
2021-07-14 12:47:50 ERROR (Wemo Events Thread) [pywemo.ouimeaux_device] Unable to reconnect with Audio Plug
2021-07-14 12:47:50 WARNING (Wemo Events Thread) [pywemo.subscribe] Resubscribe error for <Subscription basicevent "Showcase Light Plug"> (('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))), will retry in 60s
2021-07-14 12:47:50 ERROR (Wemo Events Thread) [pywemo.ouimeaux_device] Unable to re-probe wemo <WeMo Switch "Showcase Light Plug"> at 192.168.205.63
2021-07-14 12:47:54 WARNING (SyncWorker_3) [urllib3.connectionpool] Retrying (Retry(total=5, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f27857b04c0>: Failed to establish a new connection: [Errno 111] Connection refused')': /upnp/control/basicevent1
2021-07-14 12:47:55 ERROR (Wemo Events Thread) [pywemo.ouimeaux_device] Unable to reconnect with Showcase Light Plug
2021-07-14 12:47:57 WARNING (SyncWorker_5) [urllib3.connectionpool] Retrying (Retry(total=5, connect=None, read=None, redirect=None, status=None)) after connection broken by 'ConnectTimeoutError(<urllib3.connection.HTTPConnection object at 0x7f27856a4250>, 'Connection to 192.168.205.63 timed out. (connect timeout=3)')': /upnp/control/basicevent1
2021-07-14 12:47:58 WARNING (SyncWorker_3) [urllib3.connectionpool] Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f2785614130>: Failed to establish a new connection: [Errno 111] Connection refused')': /upnp/control/basicevent1
2021-07-14 12:48:01 WARNING (SyncWorker_5) [urllib3.connectionpool] Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f27858ec460>: Failed to establish a new connection: [Errno 111] Connection refused')': /upnp/control/basicevent1

[onlyoneme]

I've seen similar issue described here:

https://github.com/home-assistant/core/issues/47965

HA connects to the WeMo and requests to subscribe to event notifications. In that request it passes a CALLBACK URL (http://<ha_ip_address>:8989/<subscription_type>) that the WeMo uses to deliver the event notifications. The callback URL points to the HTTP server on port 8989. It is this subscription request that is failing for you.

My wemo plugs don't try to connect to my dockerized HA on port 8989. I've made a connectivity test from other device in the same VLAN as wemos, and connection can be established. Maybe passed CALLBACK URL is incorrect?

[esev]

Thanks for troubleshooting this further!

I agree. Maybe the CALLBACK URL is incorrect for the subnet, or possibly the WeMo devices will not initiate those subscription requests when the CALLBACK URL is on a different subnet from the device.

[onlyoneme]

What can be done then? Is there any easy way for me to check the passed url?

I can live without subscriptions, simple local polling is enough. But those frequent disconnections disrupt my automations. It also makes voice controlling via Google Assistant very unpredictable.

[onlyoneme]

Another example of errors I get:

Logger: pywemo.ouimeaux_device.api.service
Source: /usr/local/lib/python3.9/site-packages/pywemo/ouimeaux_device/api/service.py:210
First occurred: 14:01:11 (8 occurrences)
Last logged: 17:17:48
Error communicating with Showcase Light Plug at 192.168.205.63:49153, HTTPNotOkException('Received status 500 for http://192.168.205.63:49153/upnp/control/basicevent1') retry 0
Error communicating with Showcase Light Plug at 192.168.205.63:49153, HTTPNotOkException('Received status 404 for http://192.168.205.63:49153/upnp/control/basicevent1') retry 0
Error communicating with Audio Plug at 192.168.205.62:49153, HTTPNotOkException('Received status 404 for http://192.168.205.62:49153/upnp/control/basicevent1') retry 0
Error communicating with Showcase Light Plug at 192.168.205.63:49153, HTTPNotOkException('Received status 500 for http://192.168.205.63:49153/upnp/control/basicevent1') retry 1

[esev]

In Home Assistant, the subscriptions impact the frequency of the local polling. As long as the subscription is active then local polling doesn't happen. This was a feature added in 2021.3.0 to help improve connectivity for devices that don't have a solid WiFI connection (home-assistant/core#45904).

I don't believe there is anything more we can do in pyWeMo to improve the WiFi connection. I did notice when debugging the above issues that home-assistant/core#13106 made the polling interval more aggressive (the default is 30 sec and that PR made it 10 sec). home-assistant/core#45904 (comment)

I haven't tried this personally, but it may be possible to configure the scan/poll interval. See https://www.home-assistant.io/docs/configuration/platform_options/ Assuming you don't have any automations that would need to see the state of the device when it was controlled locally (on the device itself), I'd try bumping the scan interval up above 2 minutes.

(Just saw your latest post. Those HTTPNotOkException messages are odd. Especially the 404 status.)

[esev]

When did these error messages begin (all of them, not just the HTTPNotOkException)? Was there a particular version of Home Assistant where they started happening and a version where they weren't happening?

[esev]

Just as a debugging measure, can you ping the devices for several minutes. Is there any packet loss?

[onlyoneme]

As I said at the beginning my HA makes all wemos plugs disconnecting frequently from the network. I ping them every minute using Zabbix and I can see plenty of packet loss. This doesn't happen when HA is off.

Those issues started around month ago. I do not upgrade my HA frequently, it's possible I've upgraded quite old version that time. Unfortunately I cannot be more precise because similar time I've also upgraded the fw on wemos.

[esev]

As I said at the beginning my HA makes all wemos plugs disconnecting frequently from the network. I ping them every minute using Zabbix and I can see plenty of packet loss. This doesn't happen when HA is off.

Ah! Thanks for clarifying. I think the increased network traffic from Home Assistant probably makes the connection worse.

I can look more after work tonight. For now, try to adjust the scan interval. And also configure the devices statically and disable discovery. Discovery causes a lot of network traffic and happens every 5 minutes (more frequently at startup).
https://www.home-assistant.io/integrations/wemo/#configuration

Let me know if either of those help.

[onlyoneme]

All those plugs are defined as static because of their separate vlan subnet. Discovery on wemo platform is already disabled.

Just started playing with scan interval, I'll let you know about results soon. Thx for your help.

[onlyoneme]

I've added

switch:

• platform: wemo
  scan_interval: 120

because scan_interval was not accepted directly in wemo section. It didn't help. Honestly I doubt it has changed anything because state of wemos when triggered from the official app are reflected in the HA in just 10 seconds.

[onlyoneme]

I've taken quite old 1.0.0b6 version of wemo and installed it for testing as a custom component. It didn't solve my issues. Errors in the log are not exactly the same but quite similar and my wemos still disconnect from the network when HA is running.

As a last resort I've enabled wemo integration on very old HA 0.96.5 installed on Pi in the same vlan as wemos. This time everything was working as a charm with immediate wemo status updates and without any disconnections.

I guess something has changed in the latest firmware which makes current way of communication from HA to wemos not possible, and forces those devices to reconnect a network. Maybe this is due to different subnets. Probably there is no way to downgrade the fw so I'm doomed now.

[onlyoneme]

I've made some other test and now I'm pretty sure that my wemos will not accept any subscription request with the address from another subnet, even if it's a valid private network. They always disconnect on such try. I guess it's related to CallStranger vulnerability.

I think the only way to make it working with different subnets is to avoid any subscriptions at all and use polling only.

[Spectre5]

@esev, don't you run your wemo's on a separate vlan too?

[esev]

@esev, don't you run your wemo's on a separate vlan too?

I do, but my Home Assistant (Docker) has interfaces on both my IoT and Home vlans. So from pyWeMo/HomeAssistant's perspective, it is on the same vlan as my WeMo devices.

[onlyoneme]

@esev, don't you run your wemo's on a separate vlan too?

I do, but my Home Assistant (Docker) has interfaces on both my IoT and Home vlans. So from pyWeMo/HomeAssistant's perspective, it is on the same vlan as my WeMo devices.

Maybe it would be worth considering to add a parameter which avoids any subscription requests across subnets and forces local pulls only. I can see it works such way with Tasmota's devices running with wemo emulation enabled, which don't subsrcibe properly and return 404 on subscription requests. Local pulls work fine though even between different subnets.

[esev]

I like this idea. We can probably expose something like a can_subscribe method in pyWeMo that checks if the device is on the same subnet. Home Assistant, and other clients, can use this method to check before adding a subscription for a device.

[onlyoneme]

I like this idea. We can probably expose something like a can_subscribe method in pyWeMo that checks if the device is on the same subnet. Home Assistant, and other clients, can use this method to check before adding a subscription for a device.

Yes. I think it would be still wise to add the per device parameter in HA in case of devices which do not follow current Belkin's behavior and allow subscriptions between subnets (I just realized we do not discuss on HA's github...).

[esev]

Adding per-device parameters in Home Assistant seems like the best route. We can set the parameter default values based on what works for most Belkin devices. And folks can override those settings when it makes sense for their specific device.

I tried to break out individual devices so they each have their own config entry before, but was told that wasn't recommended (home-assistant/core#44192 (comment)). At the time there weren't any per-device settings though. I can bring this up again and see if the situation would be different if we wanted per-device options/settings.

[joshuakohut77]

Just following up to see if there has been any updates or solutions to this? I am having the same problems that OP was describing.

[esev]

Hi @joshuakohut77,

Are you also using Home Assistant? Are you also seeing a lot of packet loss when you ping the device?

For @onlyoneme and anyone else who is interested in this bug: If I were to add per-device configuration options for wemo devices in Home Assistant, what options would you like to see added? What would help to resolve this issue for you?

Let's collect a list of options here, and I'll try to make the changes after the 2021.9.0 release.

[joshuakohut77]

Hi @esev,
I am using Home Assistant through docker which is on a separate VLAN than my Wemo devices. I only allow ports 8989, 49152, 49153, and 49153 for the wemos. I don't see any other ports being called.
I suspect I am seeing some packet loss. With current firewall rules I can't ping the device but frequently I will see a wemo device become unavailable in Home Assistant for couple seconds before coming back to life. If you want me to do a ping test, I can do that test later but I'm guessing I have packet loss due to the random drop outs of Home Assistant.

As far as suggestions about resolutions, I'm not qualified to give any of value. I'm just a normal user who found this bug thread trying to resolve my log messages. However I am more than happy to do any testing and provide feedback with my home experience if that will be of use to you.

[esev]

@joshuakohut77 There are a few other ports that could be used, but the ones you listed are indeed the most common.
Here's the list that pyWeMo uses:

pywemo/pywemo/ouimeaux_device/__init__.py

Line 28 in 2ef78e0

PROBE_PORTS = (49153, 49152, 49154, 49151, 49155, 49156, 49157, 49158, 49159)

I think one Home Assistant per-device config option that would help you is an option to disable the subscriptions, since we now know they won't work across subnets.

[joshuakohut77]

I truly appreciate all you do so I don't want to seem impatient, but has there been any updates to the progress on this issue?

[esev]

I haven't had a chance to work on per-device configuration options yet. If you'd like to disable the subscriptions, and see if that improves things; comment out, or remove, these three lines in the wemo component within Home Assistant.
https://github.com/home-assistant/core/blob/fabf5204be374dd80c86af92b6076df063ac9a12/homeassistant/components/wemo/wemo_device.py#L146-L148

Having feedback about whether this improves things would be very helpful!

[joshuakohut77]

Okay I have been running this since yesterday afternoon. I no longer get consistent error logs as before. The device appear more responsive and turn on/off quicker but that could just be me wanting to see success. I have not visibly seen any devices become unavailable in home-assistant however when it happened before it would only last for a few seconds so unless I was watching, I wouldn't notice.
With all that being said, I still am seeing some logs which I will share and let you decide if they're related or just normal operation. The first log errors happened before/during integration start up. That can be found here. I only saw this once during startup.
There also was some reoccurring logs which happened throughout the entire day. Those can be seen here. I only grabbed a handful as they were all the same for many of the devices.

These may or may not any significance as everything appears to be working as expected with only a sample size of 1 day to analyze. I'll keep an eye on devices becoming unresponsive in home-assistant throughout the week as I'll be at my desk working and it will be easier to monitor rather than the weekend where I am out and about. Let me know if you have any questions or anything more I can help with.

[esev]

Thanks for testing. This sounds very promising.

The first set of logs look related to the number of network interfaces. Looks like you have quite a few. pyWeMo is trying to listen on all of them in order to respond to WeMo devices on the network. It's probably okay to ignore those logs. However, assuming this is Linux, you can try increasing the max multicast group memberships to make those logs go away.

# List current value
sysctl net.ipv4.igmp_max_memberships

# Increase value (where X is something larger)
sysctl -w net.ipv4.igmp_max_memberships=X

The second set of logs is indicative of pyWeMo not being able to connect to a device, or having an unreliable connection. Seeing that total=5 is an okay sign though. There are a few retries and it looks like the connection is recovering after the first try. As long as you don't see it going down to total=0 often, then you shouldn't see the device go into the unavailable state in Home Assistant.

Maybe per-device configuration isn't needed here. It's a lot easier for me just to add a single setting to disable subscriptions. I'll try to put a change together by next week.

[joshuakohut77]

Day two and everything is still great. Have not noticed any drop outs and the switches still seem much quicker to toggle. I think a single setting to disable subscriptions would be sufficient for this problem.
Just wanted to quickly respond to the other comments you made. My max multicast group was set to 20 and I only have 14 devices. I increased it to 25 but still see the logs, but as you said it's no harm so I'll just ignore them.
The other "retry" connection logs occasionally occur but never drop below total = 5. So once again not worried about it. Thank you for all your hard work on this library. Without pyWeMo my home assistant would not be the same. Once the change is in, I'll be happy to try it and let you know how it works.

[tknz]

What about NAT the request back via the firewall interface on the same subnet? I was about to try this out now... would need the callback URL to reference the firewall interface of the subnet rather than the address of the HA docker container because looking at a quick pcap the wemo doesn't seem to try connect if it's on another subnet. With this approach then the firewall can NAT it to the real address of the container on the other subnet.

[joshuakohut77]

What about NAT the request back via the firewall interface on the same subnet? I was about to try this out now... would need the callback URL to reference the firewall interface of the subnet rather than the address of the HA docker container because looking at a quick pcap the wemo doesn't seem to try connect if it's on another subnet. With this approach then the firewall can NAT it to the real address of the container on the other subnet.

Did you have any luck with this? Sounds like a lot of effort when disabling the subscriptions seems to be fine for me at least. I’m not sure what benefit this would add in the end other than letting the pyWemo to work without any changes.

[esev]

@joshuakohut77 I've put together a PR for home assistant to add a configuration option to disable the subscriptions for all devices. home-assistant/core#56972

@tknz I think that would work. You'd need to:

1. Only use DNAT when configuring the firewall to direct the subscription notifications back to the container. This is required because pyWeMo differentiates between the devices by their IP address. If the firewall changed the source IP of the connections from the WeMo to the container, then the subscriptions would no longer work.
2. Make code changes to pyWemo to override the callback host; as you have already mentioned.

Personally I think it's simpler to add the container to the same subnet as the WeMo (assuming that's possible). That way all the HA discovery logic works (for Wemo and all other integrations too). My docker host has a bridge interface on my IoT VLAN. Then the HA docker container has an interface on that bridge too.

/etc/network/interfaces (Ubuntu host)

# IoT Network (vlan 100)
auto enp4s0.100
iface enp4s0.100 inet manual
    vlan-raw-device enp4s0

auto br100
iface br100 inet static
    address 192.168.100.1
    netmask 255.255.255.0
    bridge_ports enp4s0.100

docker-compose.yaml

services:
  hass:
    ...
    networks:
      2_dmz:
      4_iot:
        ipv4_address: 192.168.100.15
      1_internal:
        ipv4_address: 192.168.1.15
      
networks:
  4_iot:
    enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 192.168.100.0/24
          ip_range: 192.168.100.16/28
          gateway: 192.168.100.1
    driver_opts:
      com.docker.network.bridge.name: br100
      com.docker.network.bridge.host_binding_ipv4: 192.168.100.1

The key is to match the ipmaipam & driver_opts up with the same interface & settings as the bridge interface on the host.

[tknz]

What about NAT the request back via the firewall interface on the same subnet? I was about to try this out now... would need the callback URL to reference the firewall interface of the subnet rather than the address of the HA docker container because looking at a quick pcap the wemo doesn't seem to try connect if it's on another subnet. With this approach then the firewall can NAT it to the real address of the container on the other subnet.

Did you have any luck with this? Sounds like a lot of effort when disabling the subscriptions seems to be fine for me at least. I’m not sure what benefit this would add in the end other than letting the pyWemo to work without any changes.

Yes got it going. Only real benefit is instant update when the button is pressed on the device. HA is delayed with other devices that are similar like Shelly unless COIOT (I use this) update or MQTT is used e.t.c

[esev]

Only real benefit is instant update when the button is pressed on the device.

There are a few other side-effects too. The WeMo motion sensor, and sensor on the WeMo Maker don't work well with HA when the subscriptions are disabled. The only time these devices will work properly, when subscriptions are disabled, is when HA polls at the exact same time as the motion occurs. The WeMo Insight energy monitors also don't display the current energy values as quickly when subscriptions are not used.

The long-press feature on the wall Switches/Dimmers also will not be detected in HA. This isn't related to subscriptions, but rather relies on HA and the switches being able to see multicast messages on the local subnet.

[Spectre5]

This thread is worthy of another wiki page that describes options for WeMo's on a different subnet. Could document the option to disable subscriptions (when/if added to pywemo) and what the caveats are to that. Of if you want to keep everything working well with subscriotions, the other two options are the extra interface like @esev does with Docker or the idea @tknz has implemented with DNAT. We can add the details on setting that up that we can send future people with the similar issues.

[nikadaika]

I haven't had a chance to work on per-device configuration options yet. If you'd like to disable the subscriptions, and see if that improves things; comment out, or remove, these three lines in the wemo component within Home Assistant. https://github.com/home-assistant/core/blob/fabf5204be374dd80c86af92b6076df063ac9a12/homeassistant/components/wemo/wemo_device.py#L146-L148

Having feedback about whether this improves things would be very helpful!

Thanks, guys. It was driving me crazy.
Seems to work fine as a workaround while we wait for home-assistant/core#56972

[joshuakohut77]

Personally I think it's simpler to add the container to the same subnet as the WeMo (assuming that's possible). That way all the HA discovery logic works (for Wemo and all other integrations too). My docker host has a bridge interface on my IoT VLAN. Then the HA docker container has an interface on that bridge too.

Thanks for this, I didn't realize how easy/simple this would be and it works great too. Would have saved me a lot of time configuring dozens of firewall rules to allow comms across vlans.

[esev]

Thanks for the feedback @joshuakohut77. It's great to hear that was helpful for you too.

This thread is worthy of another wiki page that describes options for WeMo's on a different subnet.

Good call @Spectre5! I started https://github.com/pywemo/pywemo/wiki/Networking. I'll start a Home Assistant docs PR to have the wemo page link to this also.

Anyone with other tips/tricks for getting pyWeMo to work across subnets, please feel free to contribute your solutions also!

[kebel87]

Thanks everyone for sorting this out, it has been bugging me for a while.

I am kind of noob with networking, but if anyone is interested to guide me I could try to make it work with HAOS running as a VM on a proxmox node with 2 NICs. HAOS is on main LAN, wemos are on IoT LAN.

I'd help documenting the steps and everything.

[jherby2k]

Yes got it going. Only real benefit is instant update when the button is pressed on the device. HA is delayed with other devices that are similar like Shelly unless COIOT (I use this) update or MQTT is used e.t.c

Can you help me out with this? I've:

1. Set up a NAT rule from the wemo IP to HA on my router (UDMP) via iptables -t nat -A POSTROUTING -s 192.168.2.121/32 -d 192.168.1.2/32 -j MASQUERADE (where 192.168.2.121 is the Wemo, and 192.168.1.2 is HA)
2. Opened up port 8989 between VLANs
3. changed line 162 in subscribe.py to host='192.168.2.1', (the Wemo's vlan gateway)

but i'm still seeing resubscribe errors in the HA logs

If i can get this working, i'll update the guide at https://github.com/pywemo/pywemo/wiki/Networking. Would really like the button presses to update HA instantly, and also clear out these error messages in the logs. Commenting out the 3 lines doesn't fix either of these, even if the devices stop crashing.

[onlyoneme]

@jherby2k
Are you sure your iptable rule is correct? Personally I use DNAT not SNAT here.

[onlyoneme]

@jherby2k
Let me clarify what you need to achieve.
From 192.168.1.2 you instruct 192.168.2.121 to publish any state changes on address 192.168.2.1:8989. But 192.168.2.1 is your router port address so you need to tell your router how to translate your destination address. That's why you need a DNAT rule with source = 192.168.2.121, destination = 192.168.2.1:8989 and destination translation = 192.168.1.2:8989.

[jherby2k]

So, something like this?

iptables -t nat -A PREROUTING -s 192.168.2.121/32 -d 192.168.2.1/32 -j DNAT --to-destination 192.168.1.2 ?

also instead of editing subscribe.py, i set `pywemo_callback_address = '192.168.2.1' on line 75 in util.py.

[onlyoneme]

@jherby2k
When you use pywemo >= 0.9.0 you just need to define global variable PYWEMO_CALLBACK_ADDRESS using callback ip with the port, ie. 192.168.2.1:8989. No longer need to edit files directly.

--to-destination in iptables should point to 192.168.1.2

[jherby2k]

Right, sorry - that was a typo. So, Python neophyte here - where can i define PYWEMO_CALLBACK_ADDRESS? in const.py? or can i define it somewhere else and not have to hack the wemo integration at all via custom_components?

[onlyoneme]

@jherby2k
Python script uses os.getenv() to get PYWEMO_CALLBACK_ADDRESS, so I guess you need to set env variable on the host where you have Home Assistant (can be dockerized as well). Or you can overwrite

callback_address = get_callback_address(
host=self.device.host,
port=self.callback_port,
)

in subscribe.py with

callback_address = '192.168.2.1:8989'

[esev]

FYI The PYWEMO_CALLBACK_ADDRESS hasn't been released in Home Assistant yet. It'll likely be in the next 2022.6 bugfix release though. It was added just yesterday home-assistant/core#73186

[esev]

Oh! It was actually released yesterday too. That was fast. https://github.com/home-assistant/core/releases/tag/2022.6.4

[jherby2k]

OK, so this is where i'm at:

Running 2022.6.4 already. I hardcoded pywemo_callback_address = '192.168.2.1:8989' on line 75 of util.py, rather than setting PYWEMO_CALLBACK_ADDRESS somehow inside the HA container. Either way i need to make changes inside the container, right? This seems like a better spot than subscribe.py.

then set this on my router:

iptables -t nat -A PREROUTING -s 192.168.2.121/32 -d 192.168.2.1/32 -p tcp --dport 8989 -j DNAT --to-destination 192.168.1.2

(not specifying protocol/port means all the traffic intended for Wemo cloud gets redirected too)

HA logs are clear of errors, but i still don't get instant updates in the UI when pressing the switch. I also don't see any connections to port 8989 in the FW logs.

Thanks for your help - i really will document the heck out of this once i have it working.

[onlyoneme]

@jherby2k
No errors in HA log means that wemo device has accepted subscription instructions. Publishing can be still not working because of incorrect callback (although I believe you've edited util.py successfully) or because of still wrong netfilter setup - incorrect or missing iptable rules. You should definitely see a traffic on 8989 if everything is fine.

[jherby2k]

Had a typo in my iptables command (the above is fine)... working great now! I've added the following section: https://github.com/pywemo/pywemo/wiki/Networking#tips-for-running-on-a-different-lan

it would be great if we could set PYWEMO_CALLBACK_ADDRESS via the Home Assistant integration.

[onlyoneme]

@jherby2k
I believe you can do that in HA using automations and shell commands.

[sclem]

If anyone stumbles across this thread dealing with a separate iot vlan for wemos and is running HA in k8s, here is how I was able to configure PYWEMO_CALLBACK_ADDRESS. Pretty much the same solution as iptables, except k8s handles the iptables rules.

My iot vlan is 192.168.4.0/24. I am using k3s with metallb. My k3s host has an ip address in the iot vlan already.

First add an available ip in the 192.168.4.x subnet to metallb config. I chose 192.168.4.200.

Then set in HA container env:

env:
  - name: PYWEMO_CALLBACK_ADDRESS
    value: 192.168.4.200:8989

Then configure a load balancer to expose 8989 on the iot subnet:

---
kind: Service
apiVersion: v1
metadata:
  namespace: home
  name: hass-wemo
spec:
  type: LoadBalancer
  loadBalancerIP: 192.168.4.200
  externalTrafficPolicy: Local
  ports:
    - name: wemo-upnp
      port: 8989
      protocol: TCP
      targetPort: 8989
  selector:
    name: hass

[starsoccer]

Are there any plans to add better logging or debugging to the subscription errors? I attempted to follow this thread and the wiki guide but my HA instance continues to receive a 400 error, "400 Client Error: Bad Request for url".

Ive checked the env variable is set by using the HA terminal & ssh addon to verify its set with the IP and port yet it continues to error. I also disabled my vlan blocking connected another device and tested to confirm going to the callback address and port gives a 404 error which is the same thing I get on my main vlan