Wemo switch and insight smart plug


I thought that too but the only way the WEMOs don't work is through Hubitat. They work through the WEMO app, Homekit (as enabled by the WEMO app) and Alexa....don't have Google home so cant speak to that.

I'm not sure what is happening but it feels like Hubitat cant maintain a subscription to all the WEMOs all the time. I put in a rule to resubscribe every hour or so but it doesnt seem to be working.


There are some subscription issues with the drivers, in that they sometimes lose their subscriptions and have to be manually subscribed. I have some thoughts on that, but haven't had a chance to update them yet.

Losing a subscription, though, wouldn't explain why the WeMo device isn't accepting commands. A subscription lets Hubitat keep up-to-date with the current state of a device, but it's not involved in sending commands.

Are your devices sometimes changing IP addresses, by chance?


Hi @jason0x43, no, I set all the WEMO devices to have a reserved IP on my router's IP table. I'm not sure why the WEMO's dont respond to Hubitat commands via a rule execution (which is mostly how I use the WEMOs w/ Hubitat). When I look at the devices, the Hubitat page says "offline" almost always until I run the Connect App to rediscover them....and then they lose the connection to Hubitat shortly after.


I can also confirm this behaviour:

  • 3 WeMo Switches, OK
  • 1 Wemo Insight, OK
  • 1 Wemo Mini, OK
  • 1 Wemo Mini, NOT OK

The affected WeMo Mini shows as Offline, and has no SubscriptionID.
I have just started tinkering with it, but so far I have not managed to get it subscribed again.

A manual subscribe generates this:

FYI: Both the WeMo Mini 1 & 2 are plugged into the upper & lower sockets of the same outlet.



Check the Connect app logs when trying to do a subscription (they'll have more details about what's going on).


Doesnt look like there's any errors from the Connect app:


But the WEMO device is still refusing connections from Hubitat:

WEMO iOS app, Alexa and Apple's Home App still able to control device but not Hubitat.


Maybe it's a port issue instead of an IP issue?

When I tried http://[myIPADDRESS]:49154/setup.xml, I don't get a connection. When I tried 49155 I get a different type of error while trying to connect (via the setup.xml URL). But when I tried 49153, a nice little XML page popped up. I also found the following on GitHub:

Also see, Wemo Switches change their own port numbers · Issue #55 · iancmcc/ouimeaux · GitHub


Ah, that makes sense! It reminds me of an issue I noticed at some point in the past that seems to discuss the same problem. Apparently some WeMo devices will randomly change their port numbers, which my Connect app doesn't currently handle. I'll need to add something to figure out the new port.


And just maybe, some of the devices use one port and some others use a different port. So if I have a dozen devices, they could all be using the whole range of ports...or even get a new one via a firmware update.

Sheesh...herding cats is easier I guess!

Do you think that this module developer is onto the right way of keeping the connections correct: GitHub - pavoni/pywemo: Lightweight Python module to discover and control WeMo devices.


Hey @jason0x43, if I wanted to hard-code my port number in, how would I do that? Would I set it in the driver or the connect app code?

Also, the connect app code seems to have some hex translation so not sure if hardcoding a port gets affected by that?

Thanks for helping making Hubitat work perfectly w/ WEMOs...super excited for my rules to be working finally...


Ideally this should be handled automatically by the Connect app. Until then, though, probably the best place to do that would be in childGetHostAddress in the Connect app. You'd need to add some logic that would identify the device (probably by the ip part of the address), and then supply the proper value for the port, something like

def childGetHostAddress(device) {
    def ip = device.getDataValue('ip')
    def port = device.getDataValue('port')
    if (ip == "") {
        port = 49153


Thanks so much for that!

I can confirm that all my devices are now using Port 49153.

I will try the code you mentioned and will report back asap.


Hmm, I set the following but now I get a [warn] port out of range:299347 error

def childGetHostAddress(device) {
log.trace "childGetHostAddress(${device})"
def ip = device.getDataValue('ip')
// def port = device.getDataValue('port')
def port = 49153

And this is the resulting device log:

And resulting Connect APP log:


Ok, instead of using decimal (49153), I had to use the HEX (C001).

I added some traces to figure out what was being returned by the Connect App and it was C002 which the WEMO Devices did not respond to.

Here is my code that has all my WEMO's working!

def childGetHostAddress(device) {
    log.trace "childGetHostAddress(${device})"
    def ip = device.getDataValue('ip')
    // def port = device.getDataValue('port')
	def port = "C001"
	log.trace "port_hardcoded(${port})"
	log.trace "port_softcoded(${device.getDataValue('port')})"

Resulting logs from Connect App:


D'oh, apparently toHexAddress is really fromHexAddress. Glad to hear things are working, though! The question is, how long before they change again? :smile:


Yeah I know right! Well, I have a little Excel VBA script to open up the URLs to check the port numbers again so will have to re-hardcode when they change and may even add the if statements if the different devices use different port numbers.

Thanks for the help and let me know how I can return the favor when you get the new Connect app to handle wandering port numbers.


For what it's worth...I had the same issue on a light switch. I restarted it and it has worked ever since. Last week the same switch started blinking indicated it had lost wifi connectivity. It worked fine other wise. WiFi was connected and everything worked. Just the damned blinking.

I called WEMO and they said "must be a glitch....go ahead and restart it". I restarted it and it works without the blinking now.

Sounds like Windows. When in doubt, reboot.

Gotta love it.


Found some code on the PYWEMO repository (line 18-64) on how they go about probing for which port to use:

# Start with the most commonly used port
PROBE_PORTS = (49153, 49152, 49154, 49151, 49155, 49156, 49157, 49158, 49159)

def probe_wemo(host, ports=PROBE_PORTS, probe_timeout=10):
    Probe a host for the current port.
    This probes a host for known-to-be-possible ports and
    returns the one currently in use. If no port is discovered
    then it returns None.
    for port in ports:
            response = requests.get('http://%s:%i/setup.xml' % (host, port),
            if ('WeMo' in response.text) or ('Belkin' in response.text):
                return port
        except requests.ConnectTimeout:
            # If we timed out connecting, then the wemo is gone,
            # no point in trying further.
            LOG.debug('Timed out connecting to %s on port %i, '
                      'wemo is offline', host, port)
        except requests.Timeout:
            # Apparently sometimes wemos get into a wedged state where
            # they still accept connections on an old port, but do not
            # respond. If that happens, we should keep searching.
            LOG.debug('No response from %s on port %i, continuing',
                      host, port)
        except requests.ConnectionError:
    return None

def probe_device(device):
    """Probe a device for available port.
    This is an extension for probe_wemo, also probing current port.
    ports = list(PROBE_PORTS)
    if device.port in ports:
    ports.insert(0, device.port)

    return probe_wemo(device.host, ports)


Well, one of my devices decided to use another port number...here’s to figuring this messed up Belkin logic all over again.


@jason0x43, I forgot to mention that I have UPNP turned off on my router...

Also, i Traced through the code today and I think that when the device gets created the first time around, it doesnt have a way to update it's IP and Port numbers so when it gets called, it returns the IP (and if set to static, that's not an issue) and the port that it had when it was created.

When I run the discovery command in the Connect App, it does get the updated port (as well as IPs if that changed) but I don't have the coding skills to update the Child Device's info with the latest App info.