I need a more complete log to debug your issue…
Everything went back to normal after a few hours. I keep running the Wemo bindings with traces enabled. Will report here if something happens again. thank you
Here are logs from two of my Wemo sockets (one is a standard socket, the other one is an Insight Switch) for which I saw erratic behaviour today (notably, not switching off when requested to switch off). Sadly, I’m not able to tell exactly the timeframe where I saw the issues, but at least 221617K11000C4 started somewhere during the day and persisted until I captured the logs). At some point I executed the rule again and the state of the socket did not change, then I launched the Wemo iOS app to switch off the socket and it switched off immediately.
logs_ 221623K1200AB3.txt (415.1 KB) logs_221617K11000C4.txt (86.4 KB)
You Insight Switch sometimes does not answer on the Pings, that indicates it is completely not reachable. Do you have issues with your wireless network ?
The other device behaves nearly the same.
So I can not find anything which gives a clue for an issue in the binding. Might be worth to completely upgrade your openHAB to 2.5 stable.
Thank you for looking. I’m not aware of specific issues with my wireless network ; but the two Wemo devices I saw troubles with are also the most distant to my wireless access point - however not a huge distance. They also happen to be the one with automation logic with the highest occurence of state changes, so I cannot for sure says if they happen to be at fault because of their distance to the AP or because faults are more visible to me for these two devices.
Out of curiosity, are the “device not yet registered” warnings in the logs the indication that they do not answer ping? Also is it possible that the binding is more sensitive to a flaky connectivity issue than the Wemo app itself?
Anyway I may soon try to change these two Wemo for Hue plugs and keep Wemos closer to my AP.
There are several indicators for unresponsive devices, mainly not answering to the Pings. Device not reistered message is part of the UPnP GENA event system, which is some kind of sensitiv. I might think of replacing it by an own implementation, but this is something on the long run.
We don’t really know how Belkin communicates with the devices, as they are changing their UPnP implementation sometimes, without any notice. They do not provide an open API or SDK, so we have to fiddle it out when they make changes.
All in all, I would never recommend these devices and personally hove stopped using those mostly, just keeping them for debugging and testing.
With the 2.5 release, I seem to be back to getting the occasional:
Failed to get actual state for device 'wemo:lightswitch:Lightswitch-xxxx0': Invalid URI host: null (authority: 192.168.1.252:null)
Failed to get actual state for device 'wemo:socket:Socket-xxxx': Invalid URI host: null (authority: 192.168.1.208:null)
Failed to get actual state for device 'wemo:socket:Socket-xxx': Invalid URI host: null (authority: 192.168.1.207:null)
Is there a snapshot build I should look at? I don’t see any recent changes.
No, the code has not changed. I will have a look why this nasty thing reappeared.
Could you please provide a TRACE log for the occuring error.
I should add that 192.168.1.252 responds to SSDP with:
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=86400
DATE: Fri, 15 May 2020 22:33:03 GMT
EXT:
LOCATION: http://192.168.1.252:49153/setup.xml
OPT: “http://schemas.upnp.org/upnp/1/0/”; ns=01
01-NLS: 877c6c08-1dd2-11b2-9648-ef5fe71f891e
SERVER: Unspecified, UPnP/1.0, Unspecified
X-User-Agent: redsonic
ST: upnp:rootdevice
USN: uuid:Lightswitch-1_0-221805K13015C0::upnp:rootdevice
And http://192.168.1.252:49153/setup.xml does return the normal stuff.
I wonder if it would useful to do SSDP as background discovery and just constantly populate the port as a property. Even though the ports do change the SSDP discovery always seems to show the correct one, at least in my case.
There were some recent firmware updates to ALL WeMo devices. I’ve setup my OH instance to watch certain THINGs go online/offline with alerts and I’ve noticed after the WeMo firmware update that “some” WeMo’s seem to be going offline/online more often than before.
I’ve also noticed - if you unplug the WeMo after this update that it seems to correct the issues with OH.
I’m still running the org.openhab.binding.wemo-2.5.0-SNAPSHOT.jar version which is the original version Hans fixed the stability issues last year.
Best, Jay
I never use that wemo app but I just checked and see that it wants to update FW. It doesn’t sound like that will fix the issue from what you’re saying. I probably haven’t updated anything in at least a year. If nobody else is working on the binding I can take a look at adding a background SSDP discovery to see if that would help.
I do see that behavior. I myself have a hard time with the dimer. Setting the dimmer to 0 turn it off, but when I use the slider on the dimmer to set, let’s say 60, it put 60, then jump to 100 (while keeping the light at 60). I’m unsure if it’s on the android side that the problem is or if it’s openhab cause in paper ui, work correctly.
Thanks for the log, very helpfull.
It shows that the device does not respond to the ping, which is used to find the correct port.
So we have to find out, why it does not respond. There might be several reasons:
- Timeout to low
- Portrange not wide enough.
- Don‘t know.
I will provide a testing version covering 1and 2 soon. Let‘s see if it solves the issue.
SSDP background search is no option, as port 1900 is in use by the UPnP libs.
The next ping (2 minutes later) failed also, but thereafter it succeeded (with the correct port )
15-May-2020 17:24:58.176 [TRACE] [.openhab.binding.wemo.internal.handler.WemoHandler] - Ping WeMo device at '/192.168.1.252:49151'
15-May-2020 17:24:58.185 [TRACE] [.openhab.binding.wemo.internal.handler.WemoHandler] - Ping WeMo device at '/192.168.1.252:49152'
15-May-2020 17:24:58.194 [TRACE] [.openhab.binding.wemo.internal.handler.WemoHandler] - Ping WeMo device at '/192.168.1.252:49153'
15-May-2020 17:24:58.202 [TRACE] [.openhab.binding.wemo.internal.handler.WemoHandler] - WeMo device Lightswitch-1_0-221805K13015C0 responded at Port 49153
I have two Wemo Power Points that are on a “Controlled Load” (off peak) circuit so they are offline for a significant part of the day. When they go offline, openhab.log gets these errors every 2 minutes.
[ERROR] [ng.wemo.internal.handler.WemoHandler] - Failed to get actual state for device 'wemo:insight:Insight-1_0-xxx': Invalid URI host: null (authority: xxx.xxx.xxx.xxx:null)
If I restart OH2 then they stop. Given I have a couple of Wemo’s and both log an error every 2 mins, my openhab.log gets heaps of these entries.
I also don’t see a wemo being un-contactable should be an openhab.log “ERROR”. Would it not make more sense to post once (in events maybe) that they have gone offline? and once more when they are online?
Thanks
Nathan
Something I found out, and currently it’s the dimmer again doing the problem, if there’s a network outage, I need to restart openhab for it to connect to the wemo again. I’ve waited 2 days to see if my dimmer would connect again and still nothing. 
Could you please provide a TRACE log for your issue. Probably, Your Dimmer is changing Ports as well. If so, I can implement the solution used for the plugs into the dimmer handler as well.
As nobody requested it before, I did not do this forehand.
I am also having a problem with disappearing Wemo devices on my installation (2.5.5 running on debian via docker). It will run for a day or so, and then will just stop working until I reboot. I am getting the following error in karaf:
10:31:25.907 [ERROR] [ing.wemo.internal.handler.WemoHandler] - Failed to get actual state for device 'wemo:insight:WashingMachine': Invalid URI host: null (authority: 192.168.1.145:null)
The odd thing is that I only see this for one out of my ~dozen Wemo devices. All of them seem to be showing the same issue.
This is a new issue, but I also just recently switched from OH running on Raspbian (with no issue) to OH running on Debian inside a Docker container. I don’t know whether that is causing the problem.
I’ve set my ome.binding.wemo logging leverl to TRACE, but I don’t have any entries yet. Will update when I see one.