This error indicates the device is not responding to the „port scan“.
Thanks to @billfor openHAB 2.5.6 will do different checks which hopefully solves this.
If not, there is not much we can do.
Don’t forget to add autoupdate=false in your items to fix the state flapping, e.g.:
{ channel=“wemo:socket:Socket-1_0-221816K0103611:state”,autoupdate=“false” }
I have had autoupdate=“false” for a long time. It helped me get everything Wemo working pretty much 100% up until I got to Wemo Accounts. With no change besides the Wemo Accounts things have been becoming less reliable and requiring more workarounds.
After you signed up for Wemo Accounts, was there a firmware update?
There was a firmware upgrade slightly before I signed up for Accounts. I believe that firmware supported both old style and new Wemo Accounts control of Wemo devices.
That’s what I suspected. I’m sorry to say that Belkin has a history of firmware releases that improve some things in Wemo will breaking others. So, I’d be more inclined to think that’s why things have become unreliable.
It’s honestly amazing that they haven’t gotten their act together after all these years.
I suspect they do not care about OpenHAB interoperability, so perhaps this is a feature not a bug?
Is it worth upgrading to 2.5.6-snapshot? I don’t know where I would look to find out what other major changes have been implemented.
Turns out there is some kind of permission problem with the snapshot Docker builds, so I can’t upgrade anyway…
I just meant that Wemo firmware updates are hit and miss in general. I was frustrated by Belkin’s efforts long before I started using openHAB.
Is there a 2.5.6-snapshot.jar I can manually add to my install?
To answer my own question, I took the following steps to create a 2.5.6 jar for the wemo binding:
- Download the docker repository from https://github.com/openhab/openhab-docker.
- Copy the files from the folder 2.5.6/debian (3 files total, including a Dockerfile) to my server.
- ssh into the server and
cdto the location of the copied files. -
docker build --tag openhab:2.5.6 .to create a new image. - Create a new container using the new image (I did this with a stack within Portainer, but you can use whatever you would normally use). You’ll likely need to shut down any running OH container first to avoid a port conflict. As soon as the container is fully loaded you can stop it again.
- Navigate to the config folder for the new container and then to userdata\tmp\mvn\org\openhab\addons\bundles\org.openhab.binding.wemo\2.5.6-SNAPSHOT (this is Windows notation because I copied and pasted File Explorer via Samba).
- Grab the 2.5.6 jar file from there (there were two, I used the one with the specific date instead of the generic “SNAPSHOT” filename, but it looks like they might be identical.
- Start your real OH installation.
- Disable your 2.5.5 Wemo binding (I did this in my addons.cfg file, but do it wherever you added the Wemo binding in the first place, e.g., PaperUI).
- Place the 2.5.6 jar in the addons folder of your real OH installation.
It’s only been running for a couple minutes, so I’ll try to report back on whether the connection to my Wemo devices is more stable.
1 Like
Good news: 36 hours after installing the 2.5.6 binding and I have not had any connection issues. thanks @hmerk. And that’ll teach me not to update my Wemo firmware.
1 Like
It would be good to get to the bottom of why the upnp announcement when the port change is getting lost or file a bug for the wemo people to fix. I’m guessing when you fire up the wemo app it does discovery then, so its likely to be correct – SSDP always returns the correct port, but openhab is long running compared to the app, so if the port change message is lost then the only surefire way to change state immediately is to do the scan. Hopefully when it gets to the end of the port range it recycles.
I don’t know much about UPNP or SSDP, but if there’s anything I can do to test, review, or tweak, let me know.
It seems the dimmer is always the trouble maker though. I upgraded to 2.5.7 in hope of fixing the issue and it’s still there. My dimmer is currently not working, it’s not answering to either the switch function or the dimming function.
I don’t have any dimmers. I have to reboot my installation periodically (once every couple weeks), but it has been mostly stable since the upgrade.
The resent fixes have not been applied to the WemoDimmerHandler as nobody reported those issues for the Dimmer. I try to provide a new PR soon…
I finally tried the latest version of WeMo binding 2.5.8 based on the change from probing rolling ports using a PING vs. HTTP. I found that it was not as 99% reliable as the PING version is.
The PING version actually shows the WeMo going up and down with a THING status change. The HTTP version does NOT do this. The PING version actually comes back online after a few minutes. The reason I know this is because I monitor all my WeMo THING status’s.
I ran the 2.5.8 version for 48 hours against 32 WeMo’s (plugs, insights, 2 way switches and 3 way switches). I found that some of the plugs failed against rules that have been running for months now.
The negative side of the 2.5.0 version is it does NOT have all the new WeMo stuff programmed into (i.e. Dimmers, etc.) but it’s 99.9% reliable though.
Below is the link to the JAR that Hans and I debugged in late 2019 with the rolling port issues.
http://www.vtmc.org/download/org.openhab.binding.wemo-2.5.0-SNAPSHOT.zip
Best, Jay
1 Like
I will try to find out why there is such a difference between both solutions and also aplly a fix to the other device handlers. Just don’t know when to find time.