Wemo switch and insight smart plug

Device IPs will eventually update if you leave the Connect app open for a while. Every 25-30 seconds the app sends out a discovery request. As devices reply to the request, the app updates the IP addresses (including the port) of any installed child devices in handleSsdpEvent via a call to devices' sync methods . The main issues are that updating all the devices can take a few minutes, and it only happens while the app is open, not all the time in the background.

I tried calling the discoverAllWemoTypes() from within the childGetHostAddress code...doesn't work as one of my WEMOs is still setup with another port number.

Yeah, would be good to figure out how to sync everything up again w/o having the Connect App open all the time. Even then, I should report, I had the Connect App open for an hour while I was studying the code and it never synced the WEMO devices w/ the outdated port.

Presumably that's not affecting all the UPnP calls between WeMo devices, or nothing would be working.

Hmmm... I'm not sure why that would be, unless devices weren't responding to discovery requests (which could be the case if UPnP was off, but then again, the WeMo app itself shouldn't be working in that case).

In any case...

I've pushed up an updated version of the Connect app and drivers. There are quite a few changes:

  • Logging is a bit more consistent and a bit more thorough, and you can now turn off the detailed logging in the Connect app (that works for all devices, too)
  • Drivers and the Connect app now share a major version (it's a very loose definition of "version"). If the Connect app sees that a device is using an older driver, it will tell you
  • Device resubscriptions work now
  • The Connect app now schedules a refresh task that runs every 5 minutes by default. The refresh task will tell every child device to refresh, which involves a time sync, a resubscription (or new subscription if necessary) to device events, and an offline check.

Hopefully this will make things a bit more robust. Let me know if you run into problems.

1 Like

Oh, and speaking of time syncing, that actually works properly now. At least, it uses the the local hub timezone for the sync request rather than always assuming Eastern time. :smile:

Hi @jason0x43, thanks for the latest effort. Sorry to be the bearer of bad news but all my WEMOs show offline w/o a subscription ID. The App seems to know that it needs to resubscribe. All I have are a bunch of connection refused messages when I check the logs for the WEMO devices....

Request: can you make the ports and IP show as decimal on the individual device pages in addition to hex?

Update: Further investigation showing that the App is getting the wrong port numbers for the WEMO devices again. I re-entered some of the my old bandaid code and this time, another WEMO device decided to use a diff port...ayayayayay!

def childGetHostAddress(device) {
	log.debug "childGetHostAddress(${device})"
    def hexIp = device.getDataValue('ip')
    def hexPort = device.getDataValue('port')
	
	//Self-made modification due to port issues
	hexPort="c001"
	if (hexIp == "0A00000F") {
        hexPort = "C002"
    }
	if (hexIp == "0A00002A") {
        hexPort = "C002"
    }	
	log.debug "${hexIp}:${hexPort}"
	toDecimalAddress("${hexIp}:${hexPort}")
}

Oh and I did keep the App open for another 20mins to make sure everything was refreshed, etc...

Just updated to the latest app code and I'm seeing these errors in the logs.
I can still turn the switch/insight on/off via the dashboard.

@walksonair Open the Connect app, ensure debug logging is enabled, then click 'Done'. Updating the app settings (which happens when you click Done) will start a timer that will refresh everything every 5 minutes. This should ensure that your port numbers are updated.

If you look at the Connect app logs, whether the app is open or not, you should see sequences of messages like the following every 5 minutes:

There should be a discoverAllWemoTypes, then one or more sets of parseDiscoveryMessage and handleSsdpEvent calls. That's where IPs for known devices will be updated. If you see something like Device XXX is up to date, that means that the device is currently installed and the address and port received from the device agrees with what Hubitat is currently using. If Hubitat receives a discovery message for an installed device with a different IP or port, you should see a message like handleSsdpEvent: Updating IP address for existing device XXX, followed by handleSsdpEvent: Updated IP for device <device name>.

If you're not seeing these messages, then something more significant may be wrong.

@bobbles Make sure you're using the latest versions of the drivers and the Connect app. The childRefresh method was removed to fix an internal scheduling issue.

Doh!!!
Thanks for that. :wink:

Sorry about this but now getting this error from my WeMo Insight.

@bobbles I pushed an update to the Insight driver that should take care of that.

1 Like

Great stuff @jason0x43.
Thanks for the prompt service.
:smile::smiley:

I just install the new everything and I still have one dimmer with a null mac. It appears to realize it is null but doesn't seem to think it's important. :slight_smile:

Hope this is what you need. Thanks.

Edit: Forgot to mention that it has found a new device that all it seems to know about it is the mac. Could this be a duplicate of the dimmer? Kinda afraid to add it but I'll try if you wish.

Edit 2:
After clicking Done, I got this:

I got impatient and added the new device. It was, in fact, the Bedroom Light wemo dimmer. I now have two. One offline and one working just fine.
All I have to do now is to modify all my rules using the offline Bedroom Light to use the new one.
Non-optimal, but not a big deal.
Hope this helps someone.

@jim1 That was going to be my guess (that the newly discovered device was the Bedroom Light). While the app can update IPs for devices, it can't really deal with a null MAC since the MAC address is a device's ID, and without a MAC there's no way to match up a discovered device with an existing one.

Hi @jason0x43, I pasted back in the app and device code straight from your GitHub repository and watched for the debug messages like you said. I kept the App open for about a couple of hours now and can shod the logs but basically, I have a couple of WEMOs that show as offline and unfortunately the resubscribing (either manually or via the discovery) doesn't work. The device logs show connection refused and the App shows trying to resubscribe (multiple times).

Please let me know what I can do to help fix this issue...I'm very passionate about getting this to work right.

Here's the WEMO Connect App log copied from the live log page: Dropbox - WEMO Connect.log - Simplify your life

@walksonair I'll have to look through this more tonight, but from a quick glance through the logs I do see some oddities. For example, Hubitat is using 10.0.0.42:49153 for "Kids Noise Machine" around line 602. However, a bit later Hubitat receives a discovery message from a device (id 58EF68FE3DBB) that says it's at 10.0.0.42:49154. From the address I'm guessing that's supposed to be "Kids Noise Machine", but the port is off by one. Hubitat thinks that device is already using the proper address, though (line 580, where it says debughandleSsdpEvent: Device 58EF68FE3DBB is up to date).

You don't happen to still have some code hanging around that's modifying device ports, do you?

Hi, I made sure that I was using only the code from Github - I deleted the entire code text from the editor page for the WEMO Connect App (as well as for the driver) before pasting in the raw code text from Github and saving.

Yes, I saw the same that the ports are off by one for a few of my devices. No clue as to how or when that happened. The port dance has been going on for some time...!!!

@walksonair Have you tried removing one of the problematic devices (like Kids Noise Machine) and then re-adding it since updating the drivers and app?