[SOLVED] WeMo Reliability

I can‘t tell as I don‘t use tasmota firmware with WeMo emulation, just MQTT.

I’ve been experimenting with Belkin WEMO devices with openHAB for the last week or so. I, too, have a number of WEMO devices in the house and it would be great to have them work with opeHAB rather than relying on the WEMO software. Otherwise, I may have to look for another solution.

My issue: I have the WEMO switch defined in THINGS, ITEMS, and I’ve created a rule pair that alternately send ‘ON’ and ‘OFF’ commands to the switch 10 seconds apart (offset by 5 seconds). What I see in the Log Viewer is the commands being sent as I would expect. What I’m seeing from the physical switch is that it quite regularly and randomly does not respond to the commands.

That is, I see the commands being sent in the logs and sometimes the WEMO responds and sometimes it doesn’t - very unreliable, and not really usable. So the switch does go on and off but not always as the commands are sent.

I don’t see any errors in the Log Viewer, just the commands being sent.

The setup is using openHAB 2.4.0-1 on a RaspberryPi under openHABian. The WEMO is one of the v1 hardware Insight switches with firmware version ‘WeMo_WW_2.00.11054.PVT-OWRT-Insight’. The network is running WiFi in the same room based on a Netgear ORBI.

Any tips or tricks I’m missing here, or is the WEMO a mistake?

Cheers, S t u a r t .

Try sending the commands with a higher delay. During development I saw that the WeMo devices sometimes block communication for some time.

1 Like

Thanks for the quick reply. Much appreciated.

I’ll give it a go. And report the outcome.

Cheers, S t u a r t .

Yes, reducing the tempo (15 seconds apart rather than 5) on the changes appears to be much more reliable. Thanks for the great feedback.

Cheers, S t u a r t .

1 Like

I am new to OpenHAB so I hope I’ve included all the pertinent info. I’m happy to test or maybe I just did something the wrong way??

I have 3 wemo switches and I am having reliability issues too. It works for 24 hours then the switches stop responding to rules or state changes and I have to reboot OpenHAB.

One wemo switch and two wemo minis.
I am using the OpenHAB 2.4 docker image being run on a fedora 21 PC.

All three switches were discovered and I’m using simple rules to turn things on/off during the day. Not more than 2 times per switch.

I’ve turned trace on for the wemo binding and I get the following:

2019-01-11 11:26:08.581 [DEBUG] [l.discovery.WemoDiscoveryParticipant] - Discovered a WeMo Socket thing with UDN ‘Socket-1_0-221802K0109598’
2019-01-11 11:26:08.584 [DEBUG] [l.discovery.WemoDiscoveryParticipant] - Created a DiscoveryResult for device ‘SW2’ with UDN ‘Socket-1_0-221802K0109598’
2019-01-11 11:26:08.598 [DEBUG] [l.discovery.WemoDiscoveryParticipant] - Discovered a WeMo Socket thing with UDN ‘Socket-1_0-221802K0108B07’
2019-01-11 11:26:08.599 [DEBUG] [l.discovery.WemoDiscoveryParticipant] - Created a DiscoveryResult for device ‘SW1’ with UDN ‘Socket-1_0-221802K0108B07’
2019-01-11 11:26:08.640 [DEBUG] [l.discovery.WemoDiscoveryParticipant] - Discovered a WeMo Socket thing with UDN ‘Socket-1_0-221241K0100D89’
2019-01-11 11:26:08.644 [DEBUG] [l.discovery.WemoDiscoveryParticipant] - Created a DiscoveryResult for device ‘H’ with UDN ‘Socket-1_0-221241K0100D89’

Then almost exactly 24 hours later:

2019-01-12 11:26:10.627 [DEBUG] [l.discovery.WemoDiscoveryParticipant] - Discovered a WeMo Socket thing with UDN ‘Socket-1_0-221241K0100D89’
2019-01-12 11:26:10.626 [DEBUG] [l.discovery.WemoDiscoveryParticipant] - Discovered a WeMo Socket thing with UDN ‘Socket-1_0-221802K0109598’
2019-01-12 11:26:10.629 [DEBUG] [l.discovery.WemoDiscoveryParticipant] - Discovered a WeMo Socket thing with UDN ‘Socket-1_0-221802K0108B07’

From then on I just get

2019-01-12 11:26:21.280 [DEBUG] [ome.binding.wemo.handler.WemoHandler] - WeMo UPnP device Socket-1_0-221241K0100D89 not yet registered
2019-01-12 11:26:21.281 [DEBUG] [ome.binding.wemo.handler.WemoHandler] - Setting up WeMo GENA subscription for ‘org.eclipse.smarthome.binding.wemo.handler.WemoHandler@70dbcd1e’ FAILED - service.isRegistered(this) is FALSE
2019-01-12 11:26:23.339 [DEBUG] [ome.binding.wemo.handler.WemoHandler] - WeMo UPnP device Socket-1_0-221802K0108B07 not yet registered
2019-01-12 11:26:23.339 [DEBUG] [ome.binding.wemo.handler.WemoHandler] - Setting up WeMo GENA subscription for ‘org.eclipse.smarthome.binding.wemo.handler.WemoHandler@777c8213’ FAILED - service.isRegistered(this) is FALSE
2019-01-12 11:26:23.884 [DEBUG] [ome.binding.wemo.handler.WemoHandler] - WeMo UPnP device Socket-1_0-221802K0109598 not yet registered
2019-01-12 11:26:23.885 [DEBUG] [ome.binding.wemo.handler.WemoHandler] - Setting up WeMo GENA subscription for ‘org.eclipse.smarthome.binding.wemo.handler.WemoHandler@70cd3f6’ FAILED - service.isRegistered(this) is FALSE

Then the switches stop responding…

Thanks

As always, what Java version are you using?

Sorry forgot that bit.

The output from java -version in the docker iimage:

openjdk version “1.8.0_192”
OpenJDK Runtime Environment (Zulu 8.33.0.1-linux64) (build 1.8.0_192-b01)
OpenJDK 64-Bit Server VM (Zulu 8.33.0.1-linux64) (build 25.192-b01, mixed mode)

I’ve created a bounty to have the WeMo binding updated to dynamically follow port changes on it’s next version.

Best, Jay

1 Like

Sorry, will not be able to provide an update in short time. In the meantime, you could try the following:
When WeMo devices become unresponsive, trigger a scan for new WeMo devices in PaperUI.
This should update existing devices.
Please post here if this works, we then can create a workaround.
Best
Hans-Jörg

Rediscovery through Paper does not work.
As mentioned, the Wemo device occasionally decides to change its port. If you have a stable network it won’t change the port, but if your wifi drops out or is restarted, it may decide to change its port when it rejoins the nework. One way that I reliably reproduce the problem is to just restart the wifi network. The new (half-size) wemo switches, as opposed to the Insite seem to have the problem most. The binding (last time I looked at it) uses smarthome to do the discovery, and that’s what needs to trigger the rescan but I could never figure out to force that.

For the 1.x wemo binding, am I supposed to just download it from git? I don’t see it on the list in the paper ui to install, like the MQTT 1.x binding… Might be handy to just list the 1.x binding again in paper, since a lot of people have the problem.

The Wemo 1.x Binding will not solve the issue, but will create some more.
I have created a test version which should solve the problem, will publish it here later today.

As promised, please find a new testing version at github
https://github.com/hmerk/wemo/blob/master/org.openhab.binding.wemo-2.5.0-SNAPSHOT.jar

Please note that it has only been tested with openHAB-2.5.0-Snapshot#1620
You need to delete your things and have them rediscovered via the search function of openHABs inbox.
If you get a feature missing error for UPnP, please install it via Karaf console

feature:install openhab-transport-upnp

The device properties now include ip-address and port as shown below

First, I wanted to Thank you SO MUCH for addressing this issue!

I’m running OH 2.4 but I’m running 2.5m1 bindings using a KAR file.

I deleted the WeMo THINGS and re-found them but I do NOT have the HIDE PROPERTIES option so I can see the IP and Port. This may be a difference between OH 2.4 and OH 2.5?

My WeMo THINGS are all defined in the .thing file vs. using upnp.

It took a bit for OH to remove the binding --> Active │ 80 │ 0.11.0.oh250M1 │ org.eclipse.smarthome.binding.wemo but it did after a bit even though it was removed from the services.cfg before I started OH up and the cache/tmp directories where cleaned up also.

All 19 of my WeMo devices are online right now. I’ll keep everyone posted . . .

2019-06-24 18:06:48.422 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:lightswitch:Lightswitch-1_0-221602K1301B7A' to inbox.
2019-06-24 18:06:48.448 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:insight:Insight-1_0-231707K1201DE8' to inbox.
2019-06-24 18:06:48.499 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-221749K0102A74' to inbox.
2019-06-24 18:06:48.529 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:insight:Insight-1_0-231837K120048E' to inbox.
2019-06-24 18:06:48.547 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-221739K0103039' to inbox.
2019-06-24 18:06:48.584 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-221710K010228E' to inbox.
2019-06-24 18:06:48.597 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:lightswitch:Lightswitch-1_0-221622K130115C' to inbox.
2019-06-24 18:06:48.617 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:lightswitch:Lightswitch-1_0-221736K1300F5B' to inbox.
2019-06-24 18:06:48.664 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-221749K01027A4' to inbox.
2019-06-24 18:06:48.678 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-221609K0100F65' to inbox.
2019-06-24 18:06:48.692 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-221612K0102B49' to inbox.
2019-06-24 18:06:48.706 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:lightswitch:Lightswitch-1_0-221838K1302422' to inbox.
2019-06-24 18:06:48.722 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-221749K0102FCD' to inbox.
2019-06-24 18:06:48.769 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:lightswitch:Lightswitch-1_0-221736K1300F26' to inbox.
2019-06-24 18:06:48.809 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-221620K01013B1' to inbox.
2019-06-24 18:06:48.849 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-221749K0102E6D' to inbox.
2019-06-24 18:06:48.863 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-22B8B1K01028F4' to inbox.
2019-06-24 18:06:48.879 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-22C8B1K0108E93' to inbox.
2019-06-24 18:06:48.895 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'wemo:socket:Socket-1_0-221742K0118E30' to inbox.

Best, Jay

Sorry, you are still running the old binding.
Please uninstall the WeMo binding, clear the cache and after a restart, put the new version into your addons folder. bundle:list should then show you a snapshot version of the binding.

Best
Hans-Jörg

I actually did all those tasks from my original post; here’s my output.

openhab> list -s | grep wemo
191 │ Active    │  80 │ 2.5.0.201905310944     │ org.openhab.binding.wemo
openhab>

Best, Jay

Your last post showed the old binding running

Active │ 80 │ 0.11.0.oh250M1 │ org.eclipse.smarthome.binding.wemo

but now you have the correct version. Only difference is that you run openHAB 2.4, as I wrote, the new version is tested with openHAB 2.5-SNAPSHOT only.
Perhaps you could set up a test environment with a SNAPSHOT version.

Best
Hans-Jörg

Hey Hans,

I had to clear cache/tmp again because WeMo devices where failing BUT now I have the correct Paper interface for the binding showing the IP and Port. What I had to do is delete the THINGS first then shut down OH and clear cache/tmp. If I didn’t delete the THINGS before shutting down OH; OH would pull in the OLD binding back in.

I think I’m good now for testing.

Capture

I’ll keep you posted.

Best, Jay

:+1:

So far it’s working with 2.4 (I use the channel in the item definition and not the things). All I did was:

  • uninstall binding from paper
  • copy new binding to /usr/share/openhab2/addons
  • feature:install openhab-transport-upnp ,from karaf (openhab components will restart)