As I wrote, dumb issue initroduced by myself. Please give this new version a try
https://github.com/hmerk/wemo/blob/master/org.openhab.binding.wemo-2.5.0-SNAPSHOT.jar
Thank you!
I stopped and uninstalled the WeMo bundle via Karaf and dropped the new one in the addon’s directory and everything seems to be working so far w/o any errors and all the devices are online.
Do you think I should of cleared the cache/tmp directories or is the way I did it fine?
Best, Jay
No, that‘s just fine.
Best
Hans-Jörg
I worked with draythomp on this exact problem 5 years ago. I hope what I have to say will save you some time. I have 9 Wemo wall light switches and two mini switches. Since I have been using Dave’s code I have not had any issues with the switches in 5 years mainly because of the solution we came up with. I am not a fan of Wemo. Their app is a piece of junk and very unreliable on both Android and iPhone. The wall switches will go offline for no apparent reason and then will come back with a difference port number. The good thing is the port numbers they use are always consistent. It is a matter of pinging to find out which one answers. It’s an amateurish design. But the hardware is cheap. Another app that works far better than the Wemo app is a Windows program call AllWemo.exe. It finds and maintains the wemo devices very well (almost as good as Dave’s code). Once the devices are initialy configured they seem to hold their configuration but change port numbers. This is true for all the Wemo devices (wall light switches, mini plugs, etc) that I have tested.
I have just spun up OpenHab on a Raspberry Pi to see how it works. Still evaluating it.
Hans I hope this helps you with your fix. I know it sucks. Dave and I both agree on that.
Cheers.
Glenn.
Thanks @gtracy for your explanation and referring to someones working solution. Unfortunately, this is not really helpfull, as the WeMo Binding uses UPnP GENA event system to receive status updates immediately instead of polling. Polling is just used as a backup.
So what I am trying atm with the help of @jwiseman is to find a way to have the failing devices anounce their config changes.
On the other hand I try to understand the root cause for these config changes, as I cannot reproduce these issues with my WeMo Socket or Insight switches. They never fail with changing ports. But I have to admit that I only use them for development purpose, no longer in my produktive smarthome.
Best
Hans-Jörg
We looked at the issue from several points of view. The problem is the Wemo devices as uPnP devices off no keep alive or heart beat. What componds it further is that when they “go to sleep” so to speak the do a reset and come back with a different port number. They do not go through the usual start up and announce sequece as you would expect. That is what makes this issue so bad. Very unexpected and unaccounted behaviour. One can’t even check with mac addresses in a router mac table as it is the port number change that creates all the unexpected behaviour at layer 3. As I said previously we spent considerable time trying work arounds, even hard coding mac/ip addresses but to no avail. One really does need to do some kind of polling (pinging) periodically to check the device is still alive. Now one possible solution is if there is a Ubiquiti Unifi controller aspect to OpenHab. I use the Ubiquiti APs and the controller will sense when my WEMO switches drop off line. This is not a solution for everyone as it depends on having a Ubiquiti access point in your network. This problem definitely falls under the category of NMS requirement.
Good luck.
Glenn.
Thanks for further explanation. openHABs UPnP implementation checks periodically if there are active GENA event subscription, otherwise send a fail which can set the device offline. This is also done with the background polling.
So far, we notice when a device fails, but I have not found a proper way to update the UPnP device registry with the new Port.
I was able to remove the device completely from UPnP registry and triggered a rediscovery, but this broke further communication. Still have to look closer into it.
Basically, I could change the communication to SOAP messages, As I did in earlier version, or still doing for some devices, but we would loose the event system…
Hi Glen,
I do have Unifi setup on my network and within OH. I don’t have Unifi monitoring the WeMo’s though.
What solution can you offer with Unifi while Han’s perfects the polling of the changing WeMo ports?
Best, Jay
The biggest thing is to detect when these little suckers go offline and then come back with a new port number. The range of port numbers are always the same numbers. I think there are four of them, but don’t quote me as it has been 5 years and I have slept
a couple of times since then.
There are a couple of solutions:
One is to set up and alarm in Unifi controller to go off when one of the Wemo’s goes off line and then comes back. I use a windows based controller rather than the Linux one. I found the code for the Linux one to not be very reliable in finding my access
points status accurately. You will also need to keep the controller running all the time. Wemo actually displays the wemo lightswitch ips, mac address and hostname plus other items. So, you can setup an email alert when it goes off line. You could use this
as a trigger to ping the four different port numbers and use that to bring that wemo back up in OpenHab.
Another option is to write a cronjob or polling script that will periodically check the status and then you can check which port it is on now.
In my conversation with Hans he mentioned that the he uses uPnP GENA to connect to the Wemo lightswitches and that he gets a message when they go down. I don’t know much about uPnP and particularly GENA because I have enough network tools and scripts to
worry about in my day job. But if you can get the message from GENA then you can initiate the reconnection to the lightswitch based upon the above steps.
Finally, David Thompson and I did a lot of work on this. David has a blog which goes through a lot of this and has Python code there that you could use. It is on his GitHub. Take alook at his blog site:
for more on this.
The bottom line here is to find out which port the wemo moved to and reinitialize this on OpenHab. I’m new to OpenHab so I am not a resource on that part.
Personally I am not that impressed with OpenHab. I find it too complex to setup and it is at least five years behind on common things. I’m surprised this issue took so long to get pointed out for as you can see we experienced it over five years ago. Also,
it appears doing fixes in OpenHab is not very easy. I could be wrong but that is my initial impressions. I am not a Java fan. I much prefer Python, it’s more of a network engineers tool and language. In the end that is what Home Automation really is. Java
is just not the right tool for it.
I hope this helps you out in creating a work around, or at least gives you a few ideas on how to approach it.
Best of Luck. Feel free to reach out if I can help with it any further.
Glenn.
My WeMo’s from a Windows Unifi Controller stand point never go offline; this is really a port change issue vs. a device going offline issue.
Can you please explain how you monitor the ports on Unifi Controller vs. the WiFi 2g/5g connection?
Here’s my WeMo’s on my home network with 3 AP Pro’s.
Best, Jay
The issue was pointed out some time ago, but it is not reproducible in my installation. My WeMo devices seem not to change their ports.
Fixing this issue can be achieved on several ways.
Changing all WeMo related communication to plain SOAP, if a request fails ping the different ports and use the new one for further requests.
In this case we would loose the event system, which is needed for sensors or power measurement of Insight Switches.
Other option is to solve this within JUPnP, a fork of the Cling UPnP project.
This is the preferred way, as it keeps the event system.
I have build a new testing version with a complete new approach.
When the Binding sees a WeMo device failing, it pings the different ports and sends a „WifiSetup:StopPairing“ command using plain SOAP to the responding Port.
This command should reboot the WeMo network interface.
@jwiseman is already testing this version and keeps me updated with the logs.
I really didn’t want to get into the Network discussion but I think I have to make something clear.
TCP connections as in the case of Wemo are ephemeral. They are only in effect while the connection is open and established (hence ephemeral).
Now a socket consists of an IP address plus a port number. It is this socket concept that Wemo seems to have adopted in their design (which is characteristic of a developer not a network engineer).
So when I mean offline I am referring to the fact that the socket connection has dropped and re-established a new socket connection. Hence you have the same ip address appearing with a different port number. (The devil is in the details).
Most client/server systems rely on the server socket to non-ephemeral such as a web server. As I said earlier the Wemo designers chose to consider the lightswitch to be an ephemeral device which attributes to part of the issue here.
Why they loose their TCP socket is the main issue here. We did not dive deeply into trying to figure it out because we don’t have access to their code and hence couldn’t fix the problem even if we did ferret out the source of the issue.
Instead we chose to implement a “kludge” fix.
Of note is people with only one or two devices seem to not experience this issue to my knowledge. Those with say 5 or more seem to see it occur.
Hope this helps. Also, I hope Hans code fixes the issue as it relates to OpenHab.
I’m convinced he will come up with a useable work around.
The problem is really Wemo’s to create an ultimate fix.
Cheers.
1 Like
I have created a workaround and a according PR
For everyone who wants to give it a try before ist gets merged, the jar file can be found here
https://github.com/hmerk/wemo/blob/master/org.openhab.binding.wemo-2.5.0-SNAPSHOT.jar
Best
Hans-Jörg
1 Like
Finally it is merged into master and will be available with the next SNAPSHOT.
1 Like
Thanks again Hans! It’s been working solid for over a week now. I just added 2 more WeMo’s to the mix also (total of 21).
Best, Jay
1 Like
In case it helps, here is code that always gets the correct port number through resets. I used to try every port with timeouts. This code works every time for me, 100%.
I was thinking of writing a server that executes this and listens to MQTT to change the state. Oddly I never have any problems with my light switches, just the wemo smart plugs. I have exactly 5 devices.
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, (SSDP_ADDR, SSDP_PORT))
print sock.getsockname()
sock.settimeout(5)# set 5 sec timeout
while True:
print sock.recv(1000)Hi there,
I’m quite new to OpenHab and as I initially saw some problems with my Wemo Sockets I installed the fixes 5487 (I believe through the JAR file). My OpenHab console reports that I’m running the Wemo Binding ver2.5.0.201911211440.
Everything worked flawlessly for a few weeks, but today my Wemo sockets have stopped to change state, both as part of rules or direct control through the Paper UI.
I enabled traces for the Wemo binding, and I can see these lines each time Openhab is sending a state change command to one of my Wemo sockets:
22:29:45.589 [TRACE] [ing.wemo.internal.handler.WemoHandler] - Command ‘OFF’ received for channel ‘wemo:insight:Insight-1_0-221736K1200F20:state’
22:29:48.037 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - WeMo UPnP device Insight-1_0-221736K1200BA9 not yet registered
22:29:48.040 [DEBUG] [ing.wemo.internal.handler.WemoHandler] - Setting up WeMo GENA subscription for ‘org.openhab.binding.wemo.internal.handler.WemoHandler@2aa844fd’ FAILED - service.isRegistered(this) is FALSE
I haven’t tried yet restarting Openhab - thought maybe there would be something useful to investigate first.
Hmm, strange, there should be more log entries in trace.
The lines you posted are not belonging to the same device, you can see different UDN.
You wrote using binding version 2.5… but what openHAB version are you running. Even your used Java version is important to know.
Hello,
I’m using Openhab version 4.2.1, java version “1.8.0_231” (running Openhab on a Synology NAS).
I looked at the logs a bit longer. The registration errors pops up regularly for all Wemo devices. When I trigger a change of state through the PaperUI, nothing appears in logs except “Command ‘OFF’ received for channel” (or ON).
I do see what looks like a successful activity for a Wemo Insight socket that is not part of my Openhab things/ items, but that is online on my network :
Ping WeMo device at ‘/10.92.1.163:49151’
23:04:31.069 [TRACE] [ing.wemo.internal.handler.WemoHandler] - Ping WeMo device at ‘/10.92.1.163:49152’
23:04:31.075 [TRACE] [ing.wemo.internal.handler.WemoHandler] - Ping WeMo device at ‘/10.92.1.163:49153’
23:04:31.080 [TRACE] [ing.wemo.internal.handler.WemoHandler] - WeMo device Insight-1_0-221736K1200C96 responded at Port 49153
It is the only wemo device showing these kinds of logs.
Few hours later: I’m now seeing my sockets working again (ie processing state changes) but not reliably. There is nothing different in the logs. I filtered my log entries for one specific Wemo socket: I basically get the same logs when state changes work vs when they do not.