@war02orc Discovery is run periodically whenever the Connect app is open in the Hubitat UI. The types of devices targeted by the discovery requests are listed in the discoverAllWemoTypes function. That function actually sends out the request, and handleSsdpEvent processes any messages that are received.
If no SSDP events are ever received for the v4 plug, it's possible that it doesn't respond to any of the targets in discoverAllWemoTypes (entirely possible because I'm not sure what the target for a v4 plug would be, although I thought I saw someone mention it might be urn:Belkin:device:controllee:1).
Hi..., was wondering if your app works with the Wemo WiFI Smart Plug -- I have been trying for a few days to get the devices discovered to no avail. Thanks, Darlene
@jason0x43 urn:Belkin:device:controllee:1 is the type listed in the xml when I browse to the device up via browser, but it looks like thatās already in your code for discovery. Is there a way I can force discovery on the specific ip of the device and log the results? Or is there another troubleshooting mechanism I can use to provide more insight into what is going on? I can write some quick test code, but I am having a hard time finding documentation on how the habitatās discovery function can be used.
@war02orc Open the Wemo Connect app, ensure that debug logging is enabled, and open a log view in a new tab. While the Connect app is open, you should periodically see messages about discoverAllWemoTypes, followed by some parseDiscoveryMessage, and handleSsdpEvent messages. Finding the corresponding log statements in the Connect app code should give you a better idea of the discovery flow.
Basically, discoverAllWemoTypes registers listeners for SSDP messages for certain search targets, and then periodically sends out discovery messages. When the app receives an SSDP message matching one of the search targets, it handles it in the handleSsdpEvent function.
Ideally, you should see something in the log about an SSDP message being handled for the v4 plug. If that's never showing up, then the search target for the plug (something like ssdpTerm.url:Belkin:device:controllee:1 may be incorrect, or the switch may not have seen the discovery message (note that it needs to be on the same network as the Hubitat hub).
My daughter had one of the older Weno smart plugs. Tried this driver and it didnāt work. But she has Alexa and after a firmware update, the plug response was decent. We simply used a virtual motion with switch driver and made two Alexa routines. One for ON, and one for OFF.
Just comment out the line runIn (3, off) with // so that this driver doesnāt behave like a momentary switch.
No, I havenāt had time to sit down and try to work this out. Everything ālooksā like it should be working, but it seems like the plug itself either isnāt responding or discovery isnāt recognizing the response. I think my next step is to see what, if anything, is being received during the discovery process but since Iām new to Hubitat programming I need to better understand how discovery actually works.
@jason0x43 I downloaded the new code and I'm seeing some weird results. At first, I was getting back errors of no route to host when putting the IP and port in manually, but then it started finding it and even returning the friendly name in the debug logs. The device didn't appear in the list in the app though. Then I noticed that when I opened the list that the last one in the list had been "renamed" as the one I was attempting to discover manually (WeMo Hallway (installed as Attic)). The automated discovery then kicked in, and corrected it. Manual discovery ran and renamed it again, the cycle continued as long as I had the page open. The IP addresses, mac addresses (I have had devices with the same mac before due to manufacturing issues, so I double checked to be sure), and even ports are different between these 2 devices. Any thoughts?
Chalk it up to poor testing on my part. I'm down to one active Wemo device at the moment, so I tested automatic discovery, and I tested manual discovery, but not both at the same time. Hmmmm...also, it looks like automatic discovery had been disabled (I had commented it out), so that wasn't good.
When manual discovery is enabled, as long as there's an IP address in the manual address field, the app will look for that device every 30 seconds (along with sending out a standard discovery message now that I've re-enabled that). It sounds like maybe the app was getting back different data sometimes when it pinged the device, or there was some other issue with how it was stored.
I pushed out an update. Give that a try, and if you could, please post a debug log dump from a couple of discovery request cycles. Hopefully that will let me track down why the discovered devices list is changing during subsequent discovery requests.
@jason0x43 I just sent you the logs in a PM. So after updating the code, I now see that every wemo device is changing the name of the last one in the list (not just the manual one). I have no idea why it changed back before, but now that one takes a turn at being everything in my WeMo environment lol.
Interesting. It looks like Wemos have 2 MAC addresses (one used for SSDP messages and one reported by the setup.xml), and that was causing some confusion in the device registration logic in the connect app.
I pushed a new version that tries to be a bit more definitive about what data is used for device registration. Give that one a try.
@jason0x43 so with the updated app code the wemo minis are now being discovered when I manually input the IP address! I'll play around with the wemo minis a bit later and confirm they work as expected.
Weird side effect though is that now all the rest of my WeMo devices show up twice in the list since there's 2 mac addresses for each. Looking at the info being returned for the old wemo switches I don't see any "good" way to correlate them back so they don't create duplicates. The mac addresses appear to be sequential (ex: one ends with A and the other on the same device ends in B) but it's not consistent. It's looking like the only thing unique about these is the IP address unless you can somehow correlate on the serial number, but I'm not sure what's returned by the discovery call.
I would guess the duplicates in the list are from discoveries made before the latest code update. The current code only uses the mac address listed in each device's setup.xml. Hmmm...I could clear the list periodically, or maybe add a control to do that.
I ran a few tests and the minis are responding as I would expect. On/Off/refresh and the automatic polling seems to be working (if I turn the switch on via the wemo app the hubitat updates to show the updated state).
Correct me if I'm wrong, but the list in the WeMo connect app interface is used exclusively to add new devices correct? So if I "uncheck" an item from the list it doesn't remove it or cause any problems with devices already added?
That is correct. When you click 'Done', the app creates or updates child devices (things that show up in Hubitat's devices list) for any checked devices in the discovered devices list. Unchecked devices are simply ignored. The only time the app will remove child devices is when it's uninstalled.
