[SOLVED] WeMo Reliability

hmerk · June 8, 2020, 7:45am

Thanks for you PR, looks quite good. Please address the comments made by @cpmeister.

Nevertheless, this will just solve the issue with respongin a wrong port, but might not solve not responding at all. That’s basically the issue mentioned the last couple of weeks.

billfor · June 8, 2020, 4:32pm

For the other issue, to rule out the binding, run the following scripts like so:
python2 wemo_disc.py | grep [ip of wemo]
/wemotest.sh [ip] [port]

It should respond with something. If not, the problem is probably not the binding.
Sorry I don’t have time to figure out how to attach scripts…

I have only tested this with switches.

root@alarmpi:~/root# cat wemo_disc.py
import sys
import socket

SSDP_ADDR = “239.255.255.250”;
SSDP_PORT = 1900;
SSDP_MX = 10;
SSDP_ST = “upnp:rootdevice”;

ssdpRequest = “M-SEARCH * HTTP/1.1\r\n” +
“HOST: %s:%d\r\n” % (SSDP_ADDR, SSDP_PORT) +
“MAN: "ssdp:discover"\r\n” +
“MX: %d\r\n” % (SSDP_MX, ) +
“ST: %s\r\n” % (SSDP_ST, ) + “\r\n”;

sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
sock.sendto(ssdpRequest.encode(), (SSDP_ADDR, SSDP_PORT))
print (sock.getsockname())

sock.settimeout(5)# set 5 sec timeout
while (True):
try:
print (sock.recv(1000))
except socket.timeout:
print (‘caught timeout’)
sys.exit(0)

root@alarmpi:~/root# cat wemotest4.sh
#!/bin/sh
ip=$1
port=$2
echo try port $ip:$port
nc -zv $ip $port
curl -m 2 -X POST -H ‘Content-type: text/xml; charset=“utf-8”’ -H “SOAPACTION: "urn:Belkin:service:basicevent:1#GetBinaryState"” --data “<?xml version=\"1.0\" encoding=\"utf-8\"?><s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/\” s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/\“><s:Body><u:GetBinaryState xmlns:u="urn:Belkin:service:basicevent:1"></u:GetBinaryState></s:Body></s:Envelope>” -s http://$ip:$port/upnp/control/basicevent1

dathbe · June 8, 2020, 4:52pm

I am running OH through the official Docker image (Docker). I am on “latest.” That means I’m running OH 2.5.5. java -version inside the container yields:

openjdk version "1.8.0_232"
OpenJDK Runtime Environment (Zulu 8.42.0.23-CA-linux64) (build 1.8.0_232-b18)
OpenJDK 64-Bit Server VM (Zulu 8.42.0.23-CA-linux64) (build 25.232-b18, mixed mode)

The Docker instance is running on OpenMediaVault 5.5.2, which is just a GUI built over Debian 10.

I’m happy to test any snapshots or try any other tweaks. But I don’t have any experience editing binding JARs.

hmerk · June 8, 2020, 6:10pm

Did you use —net=host as an argument to start your docker instance ?

dathbe · June 8, 2020, 10:48pm

Yes. I created the container through docker-compose with the following YML:

version: '2.2'

services:
  openhab:
    image: openhab/openhab:latest
    container_name: openhab
    restart: unless-stopped
    network_mode: host
    tty: true
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /etc/timezone:/etc/timezone:ro
      - <REDACTED>:/openhab/addons
      - <REDACTED>:/openhab/conf
      - <REDACTED>:/etc/cont-init.d
      - <REDACTED>:/openhab/userdata
    environment:
      OPENHAB_HTTP_PORT: 8080
      OPENHAB_HTTPS_PORT: 8443
      USER_ID: 1000
      GROUP_ID: 100
      EXTRA_JAVA_OPTS: "-Duser.timezone=America/Los_Angeles"
volumes:
  openhab_addons:
    driver: local
  openhab_conf:
    driver: local
  openhab_userdata:
    driver: local

billfor · June 13, 2020, 1:40am

By the way I still get “bouncing” on some of the devices when I try to set state. So for example:

2020-06-12 07:00:00.032 [INFO ] [org.eclipse.smarthome.model.script.org.openhab ] - Check humidifier. Fcst 75.0 °F
2020-06-12 07:00:00.078 [INFO ] [org.eclipse.smarthome.model.script.org.openhab ] - Enabling humidifier
2020-06-12 07:00:00.167 [INFO ] [org.eclipse.smarthome.model.script.lambda ] - ON
2020-06-12 07:00:02.915 [INFO ] [org.eclipse.smarthome.model.script.lambda ] - OFF
2020-06-12 07:00:03.398 [INFO ] [org.eclipse.smarthome.model.script.lambda ] - ON

What is supposed to happen (and does happen sometimes) is:

2020-06-12 05:00:09.143 [INFO ] [org.eclipse.smarthome.model.script.org.openhab ] - Check humidifier. Fcst 75.0 °F
2020-06-12 05:00:09.193 [INFO ] [org.eclipse.smarthome.model.script.org.openhab ] - Disabling humidifier
2020-06-12 05:00:09.808 [INFO ] [org.eclipse.smarthome.model.script.lambda ] - OFF

I forgot where we left this. Maybe I’ll poke around and see if nobody has any other ides. It has been going on for a long time, mostly harmless but just annoying to see it toggle like that.

billfor · June 13, 2020, 1:48am

Oh I found my old post. Will try autoUpdate=false and see if that helps it. I had done that way back but it might have gotten erased.

Jamie_Diamond · June 15, 2020, 3:19pm

The reliability of my WeMo devices has gone way down. (I recently updated to WeMo Accounts) My openHAB frequently does not have/get correct status for WeMo Insight Smart Plugs and I will have to toggle the switch to get a WeMo Insight to respond. For instance to turn my dehumidifier on I will issue 3 of the .sendCommand() commands. First an ON, wait a few milliseconds, OFF, wait a few more milliseconds, and ON again. Boom, works every time now. The other thing is I’ve had to create “shadow” switches, switch items not associated with any things, which I switch on and off in parallel with the actual WeMo switch. I check the status of that item in rules which need to query the state of the WeMo item. I have had autoUpdate=false all through this from working correctly a few weeks ago to not working correctly now, although I have found that the above mentioned work-arounds get me by. I describe this also in my question on WeMo Accounts, openHAB 2.5 - Wemo Accounts compatability

ERROR:
2020-06-15 10:47:00.931 [ERROR] [ng.wemo.internal.handler.WemoHandler] - Failed to get actual state for device ‘wemo:insight:Insight-1_0-231707K1200D5C’: Invalid URI host: null (authority: 192.168.108.226:null)

hmerk · June 15, 2020, 6:03pm

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.

billfor · June 16, 2020, 3:00pm

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” }

Jamie_Diamond · June 16, 2020, 5:50pm

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.

rpwong · June 16, 2020, 7:22pm

After you signed up for Wemo Accounts, was there a firmware update?

Jamie_Diamond · June 18, 2020, 2:20am

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.

rpwong · June 18, 2020, 3:34am

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.

dathbe · June 18, 2020, 3:21pm

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.

dathbe · June 18, 2020, 4:09pm

Turns out there is some kind of permission problem with the snapshot Docker builds, so I can’t upgrade anyway…

rpwong · June 18, 2020, 6:28pm

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.

dathbe · June 18, 2020, 10:20pm

Is there a 2.5.6-snapshot.jar I can manually add to my install?

dathbe · June 19, 2020, 3:26am

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 cd to 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.

dathbe · June 20, 2020, 3:27pm

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.