Here you go. To simplify things, I removed all things and items except for one light switch. I’ve also included some potentially relevant non-Wemo log entries, including some Hue emulation log entries that talk about UPnP.
I’m aware that the binding has not changed. But when you say it’s a “device” issue, which device or devices do you have in mind as the potential culprit? I genuinely do not even know where to begin.
11:42:43.653 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.26.0.1
11:42:43.672 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.25.0.1
11:42:43.673 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.19.0.1
11:42:43.674 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.24.0.1
11:42:43.675 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.20.0.1
11:42:43.675 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.27.0.1
11:42:43.676 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.23.0.1
11:42:43.676 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.x.x.x
11:42:44.491 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.26.0.1
11:42:44.492 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.25.0.1
11:42:44.492 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.19.0.1
11:42:44.493 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.24.0.1
11:42:44.493 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.20.0.1
11:42:44.493 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.27.0.1
11:42:44.494 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 172.23.0.1
11:42:44.494 [WARN ] [rg.eclipse.smarthome.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.x.x.x
11:42:53.589 [INFO ] [g.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.27.0.1/16, truncating to /24, some addresses might be lost
11:42:53.599 [INFO ] [g.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.26.0.1/16, truncating to /24, some addresses might be lost
11:42:53.601 [INFO ] [g.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.25.0.1/16, truncating to /24, some addresses might be lost
11:42:53.609 [INFO ] [g.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.24.0.1/16, truncating to /24, some addresses might be lost
11:42:53.611 [INFO ] [g.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.23.0.1/16, truncating to /24, some addresses might be lost
11:42:53.614 [INFO ] [g.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.20.0.1/16, truncating to /24, some addresses might be lost
11:42:53.619 [INFO ] [g.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.19.0.1/16, truncating to /24, some addresses might be lost
11:42:53.622 [INFO ] [g.network.internal.utils.NetworkUtils] - CIDR prefix is smaller than /24 on interface with address 172.17.0.1/16, truncating to /24, some addresses might be lost
11:42:53.908 [DEBUG] [ternal.discovery.WemoDiscoveryService] - Starting WeMo UPnP discovery...
11:42:53.909 [DEBUG] [ternal.discovery.WemoDiscoveryService] - Starting UPnP RootDevice search...
11:42:55.181 [INFO ] [home.event.GroupItemStateChangedEvent] - WeMo changed from NULL to 0 through PoolLight
11:42:56.553 [DEBUG] [ding.wemo.internal.WemoHandlerFactory] - Trying to create a handler for ThingType 'wemo:lightswitch
11:42:56.555 [DEBUG] [ding.wemo.internal.WemoHandlerFactory] - Creating a WemoHandler for thing 'wemo:lightswitch:Lamp' with UDN 'Lightswitch-1_0-XXXXX'
11:42:56.558 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - Creating a WemoHandler for thing 'wemo:lightswitch:Lamp'
11:42:56.585 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'wemo:lightswitch:Lamp' changed from UNINITIALIZED to INITIALIZING
11:42:56.587 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - Initializing WemoHandler for UDN 'Lightswitch-1_0-XXXXX'
11:42:56.589 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - Setting up WeMo GENA subscription for 'org.openhab.binding.wemo.internal.handler.WemoHandler@XXXXX' FAILED - service.isRegistered(this) is FALSE
11:42:56.590 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - WeMo UPnP device Lightswitch-1_0-XXXXX not yet registered
11:42:56.601 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - Setting up WeMo GENA subscription for 'org.openhab.binding.wemo.internal.handler.WemoHandler@XXXXX' FAILED - service.isRegistered(this) is FALSE
11:42:56.602 [INFO ] [ome.event.ThingStatusInfoChangedEvent] - 'wemo:lightswitch:Lamp' changed from INITIALIZING to ONLINE
11:42:56.603 [TRACE] [ing.wemo.internal.handler.WemoHandler] - Command 'REFRESH' received for channel 'wemo:lightswitch:Lamp:state'
11:42:56.659 [INFO ] [nternal.dhcp.DHCPPacketListenerServer] - DHCP request packet listener online
11:42:57.298 [WARN ] [mulation.internal.HueEmulationService] - The UPnP Server service has not been started!
11:42:57.305 [INFO ] [mulation.internal.HueEmulationService] - Hue Emulation service available under /api
11:42:57.588 [INFO ] [hueemulation.internal.upnp.UpnpServer] - Hue Emulation UPNP server started on 127.0.0.1:8080
11:42:57.600 [INFO ] [mulation.internal.HueEmulationService] - Hue Emulation service available under /api
11:42:58.259 [INFO ] [.openhab.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
11:44:56.602 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - WeMo UPnP device Lightswitch-1_0-XXXXX not yet registered
11:44:56.605 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - Setting up WeMo GENA subscription for 'org.openhab.binding.wemo.internal.handler.WemoHandler@XXXXX' FAILED - service.isRegistered(this) is FALSE
11:44:56.653 [INFO ] [.io.hueemulation.internal.ConfigStore] - Hue Emulation disable pairing...
11:44:56.658 [INFO ] [.io.hueemulation.internal.ConfigStore] - Using discovery ip 192.x.x.x
11:44:56.659 [INFO ] [.io.hueemulation.internal.ConfigStore] - Hue Emulation pairing disabled
11:46:56.607 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - WeMo UPnP device Lightswitch-1_0-XXXXX not yet registered
11:46:56.610 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - Setting up WeMo GENA subscription for 'org.openhab.binding.wemo.internal.handler.WemoHandler@XXXXX' FAILED - service.isRegistered(this) is FALSE
11:48:56.612 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - WeMo UPnP device Lightswitch-1_0-XXXXX not yet registered
11:48:56.614 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - Setting up WeMo GENA subscription for 'org.openhab.binding.wemo.internal.handler.WemoHandler@XXXXX' FAILED - service.isRegistered(this) is FALSE
11:50:56.615 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - WeMo UPnP device Lightswitch-1_0-XXXXX not yet registered
11:50:56.617 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - Setting up WeMo GENA subscription for 'org.openhab.binding.wemo.internal.handler.WemoHandler@XXXXX' FAILED - service.isRegistered(this) is FALSE
Your log just show that no event subscription is established.
Not good, but does in general not hatm, as polling is used for fallback.
I need to see logs when you try to send commands to the device.
I had similar problem with upnp, turns out my host was the problem. Once I reinstall my linux (was on gentoo, switched to lubuntu), problem was gone. Even outside docker it wasn’t working but it was working if I installed openhab on other device
I’m just guessing, but I think @hmerk is looking for a log entry when the device isn’t working. So you’ll have to wait for it to stop responding and then show the log for that time period.
I used to have issues with a Wemo Motion refusing to respond to OH (while continuing to work in the Wemo app), and the solution was to block its Internet access (done through my router). It hasn’t disconnected even once since I did that. However, it’s been a long time since I made that change (maybe a year?), so I’m not sure if the same solution will work for you.
That’s just it, though. No matter how long I wait, there are no more log entries for the button push. I just keep getting the “not yet registered” entries (6 posts above) every 2 minutes or so, and then the “received command” entries if I push the button (2 posts above). I’ll try to cut off internet access and see what happens. I’ll report back.
Have you rebooted openHAB? From the OP’s posts, sounds like that’s necessary to get it back to “normal”. But it also feels like something ugly has happened with a Wemo firmware update.
Host in term of docker operating system. Your docker is a guest on your host, which is the os running the docker.
For me, I had a Gentoo machine running docker and my upnp stopped working for no reason. Tried kernel upgrade, recompile, nothing worked. I installed a new distro, lubuntu and everything worked again. I still have some issue with the binding though, like if I reboot my router, the wemo switch stop working until I reboot my openhab installation.
While I understand the usage of upnp for event service, we still could use an ip mapped connection like I did on my node red installation. Difference is since its not event base, I parse the status each 10nsec.
Let’s try to go step by step.
You are using docker on a debian installation, right ?
If so, please check your Java version. We strongly recommend to use Azul Zulu, there are known issues with other OpenJDK versions.
Next, please check if your docker container is set to
network = host
This is very important for UPnP to work properly.
Your earlier log showed warnings about multiple IP-Addresses. Please set the primary address in openHAB.
Next thing, your WeMo firmware versions.
Latest updates try to force control via WeMo cloud. This might break the binding completely and there is no solution. That’s why @rpwong recommended to cut of internet acces for the WeMo devices…
This is what the very first Version of the Wemo binding did. But still, sthis was not relaiable, cause the devices blocked connection if polled to often.
Under the bottom line, I dropped usage of the WeMo devices complletely, just keeping them for debug purpose.
If I will be in need of a controllable power plug again, I would by a Shelly, having very good experience with their devices.
Done. I did this through PaperUI (Configuration → System–>Network Settings–>Primary Address), which I’m sure is the preferred method…but is there a way to set this through text cfg files? I try to do as little as possible through PaperUI so that I can do clean installs without any manual input.
I set it to my 192.168.x.x address of the host machine. The other options were all 172.something.0.1, which I think refers to localhost(?).
The other Network Settings config options, which I’ve frankly never explored before, are set to the following:
Broadcast Address: blank
Single IP Address per Interface: Off
Use IPv6: On
No luck with this change, though it did resolve the karaf warnings about multiple IP addresses, which gives my OCD brain some peace.
Sigh. I strongly suspect this is the issue. Though I don’t recall a firmware update in the last few weeks. I have a lot of devices, but they are all running one of the following (depending on the type of device):
I’ve been investing in these WeMo switches for a long time, but maybe I need to reinvest. I ran a quick Amazon search for Shelly devices and they look like relay switches instead of smart outlets and light switches?
Hm, I am no docker expert, but your docker container should have it‘s own address to be configured here.
There is a config param, which I need to look up. Definitely can be configured via text file.
According to Shelly devices, I have wired the Shelly1 and Shelly2 behind my original light switches. Was using WeMo socket plugs only, as Lightswitch and Dimmer are not available as 240V versions…
I only have a basic understanding of Docker networks myself. For most of my containers, it is showing 172.xx.0.0 addresses, so maybe the 172.xx.0.1 addresses available as options in PaperUI are Docker addresses. The problem is that I don’t find any 172 address for OH because it’s assigned to host–so it should be using my server network information, right? For what it’s worth, OH is set up to on the default (80) port of the server, so it really is accessed through 192.168.x.x on my network.
Slight correction, as you can see from the compose file above, OH is set to run on 8080. But I have an nginx site rule set up to redirect traffic on port 80 to 8080.
Googled a bit and saw thatI was wrong. Your container will use the host address, so this should be configured.
Is discovery working ? If not, please check if port 1900 is open in your firewall.
I removed all of my Wemo plugs and switches and replaced most of them with TP-Link Kasa devices. The Kasa hardware isn’t as aesthetically pleasing, but they’re cheap and reliable. The only Wemos I have left are a Wemo Motion and a Wemo Maker, and Belkin stopped updating them years ago.
I’ve also got Z-Wave devices, and I’ve bought a few Tuya devices and flashed them with Tasmota.
The great thing about OH is that you don’t have to stick with one type of device. So if you get your Wemos working again, you can cut them off from Belkin’s cloud and go forward with another type/brand.
When you say “your firewall”, can you give me a little more guidance? I obviously have a firewall on my main router, but that only blocks traffic from the internet I think. I’m not aware of any firewalls inside my network, and both my OH server and my Wemos are inside my network. Is there another firewall somewhere I need to punch a hole through?
I’m beginning to think it MIGHT be a port 1900/UPnP issue. My Hue emulation is also not working. I know I’m getting a little off topic here, but Hue emulation status page is giving me the following:
Self test
To access any links you need be in pairing mode!
Pairing mode: Off (V2) Enable | Enable with bridge V1 emulation
3 published lights (see http://192.168.x.x:80/api/testuser/lights)
80 published sensors (see http://192.168.x.x:80/api/testuser/sensors)
UPnP discovery test
upnp announcement thread not running
serial no name
Reachability test
URL Responds? Ours?
http://192.168.x.x:80/description.xml yes yes
http://192.168.x.x/description.xml yes yes
The Discovery Test section looks like something’s wrong.
As an update here, I am completely bewildered, but I built a new server with basically the same hardware, the same operating system, the same docker, and the same openhab, and that one will detect my wemos. Sigh. The second server is on a different router/network, so I guess the next step is to see if it is my network or my server that is the problem on the original one.
