For what it’s worth, I think I got it working by moving the swag container to an ipvlan (was previously on a custom bridge, though I tested it with default networking as well) along with all its associated containers. No idea why that would matter.
So here’s another update on this issue.
The Wemo binding seems to not play nice with web server containers generally. I’ve tested it with linuxserver/swag (nginx + letsencrypt), linuxserver/nginx, and nginx (Docker Hub’s nginx container). Each time I can start one of these containers and the binding will stop working – i.e., defined things will go offline. And then I can remove these containers and everything in OH returns to normal (after restart). This occurs when the OH container is running in “host” network mode, and the web server is running on a bridge network (either user-defined or default) or as host. It happens even when there is NO exposed port on the web server.
Some alternatives I’ve tried:
-
I can move OH off of host, but that presents problems with other bindings – in particular, I couldn’t figure out what port needed to be opened for the Nest binding to work properly.
-
I can move the web server to a level 2 ipvlan. This works fairly well, except that the documentation specifies that the ipvlan cannot communicate with the host. macvlan_ipvlan_driver_notes.md · GitHub. So I cannot have the webserver act as a reverse proxy for my OH container.
-
I can move the web server to a level 3 ipvlan. This also seems good in theory, and with some simple static routing on my router I was able to get my host communicating with my web server. But I was unable to get it so my web server was accessible from the WAN.
Surely there has to be SOMEONE else out there running (1) OH on Docker with a (2) reverse proxy who has managed to (3) keep the Wemo binding working? This was a fun project for an otherwise slow weekend, but I think I’m going to go back to just not connecting my Wemos to OH. Sad, but certainly not a dealbreaker. I’ve mostly converted over to TP-Link’s Kasa devices anyway.
A fair number of people use Docker, but very few use reverse proxies or Wemos. When we put those three variables together, you might actually be the only person who’s tried this and also reads/posts in this community (I guess that’s a fourth variable).
I got rid of all of my Wemos except for my Wemo Maker (which I use to control my fireplace) and Wemo Motion sensor. These two devices were discontinued long ago, so Belkin no longer breaks them with firmware updates (I’ve still denied them Internet access just to be safe). Like you, I’ve replaced all of the Wemos I had with TP-Link Kasa switches and plugs.
Isn’t this the recommended way to expose your OH instance to the web? I surely can’t be in the minority of wanting to access my OH from outside the house.
No, the recommended way is to use the myopenHAB cloud server, which also enables notifications to the Android and iOS apps.
You’ve been around here longer than I have, so I’m guessing you set up the reverse proxy long before myopenHAB was available. 
myopenHAB is available since the beginning, just with another name at start.
But yes, cause of notifications, it always was the recommended way….
1 Like
I don’t really have anything I can add here. I have run OH in Docker with a reverse proxy on the same machine in the past but no longer do so. I’ve never used Wemo. I’ve never seen a similar issue like this but it seems pretty clear that the Wemo binding is using some port or some other network resource that the other containers that cause problems want to use too.
Thank’s Rich. Wemo binding uses standard UPnP implementation (JUPnP) with standard ports.
Nothing special.
To track this further down, please set loglevel to DEBUG for org.jupnp.* and restart openHAB.
We should see some errors regarding the ports I assume.
I actually did know this now that you’ve reminded me. But I’ve always felt that it defeats 80% of the point of rolling your own automation system to avoid the cloud systems out of your control…only to send all your information to another cloud cloud system out of your own control. I also have other services that need a reverse proxy, so this won’t solve my issue.
When you say “standard ports” (plural), is it something beyond 1900?
I’ll try the jupnp debug suggestion when I have some time.
Thanks everyone.
Sorry for irritating, I meant standard port (singular)
You can run you own myopnHAB instance to have it under your control. You only loose notification feature, but this is already lost when using other remote access options.
Only if your primary goal is control. I want all of my devices to work locally if possible, but I’m not too concerned if remote access isn’t available for a brief period of time. My automations will continue to work just fine, and I don’t have to bother with the extra work required for a reverse proxy. It’s just a trade-off.
On the rare occasions when myopenHAB crashes, Dan usually jumps on it immediately (and gives us status updates as he goes). So I’m personally better off trusting his expertise than my own (complete lack of) expertise.
I might feel differently if I knew more about network security. I think that’s probably the dividing line, as I feel like I only know just enough to be very dangerous to myself.
1 Like