Out of curiosity did you recently update your firmware? I was notified that there was new firmware for practically all of my WeMo devices today, and I'm hesitant to pull the trigger on that in case it's related to your issue.
These are what I get when trying to activate my wemo plugs from the dashboard;
[app:99](http://hubitat.lan/logs#app99)2020-12-12 06:07:05.906 pm [info](http://hubitat.lan/installedapp/configure/99)Setting binary state for Night light
[dev:131](http://hubitat.lan/logs#dev131)2020-12-12 06:07:05.897 pm [info](http://hubitat.lan/device/edit/131)Turning on
[app:99](http://hubitat.lan/logs#app99)2020-12-12 06:07:04.063 pm [error](http://hubitat.lan/installedapp/configure/99)java.lang.NumberFormatException: For input string: "nu" on line 387 (childSetBinaryState)
[app:99](http://hubitat.lan/logs#app99)2020-12-12 06:07:04.056 pm [info](http://hubitat.lan/installedapp/configure/99)Setting binary state for Lamps
[dev:133](http://hubitat.lan/logs#dev133)2020-12-12 06:07:04.047 pm [info](http://hubitat.lan/device/edit/133)Turning off
[app:99](http://hubitat.lan/logs#app99)2020-12-12 06:07:03.223 pm [error](http://hubitat.lan/installedapp/configure/99)java.lang.NumberFormatException: For input string: "nu" on line 387 (childSetBinaryState)
[app:99](http://hubitat.lan/logs#app99)2020-12-12 06:07:03.216 pm [info](http://hubitat.lan/installedapp/configure/99)Setting binary state for Backyard
[dev:130](http://hubitat.lan/logs#dev130)2020-12-12 06:07:03.207 pm [info](http://hubitat.lan/device/edit/130)Turning off
[app:99](http://hubitat.lan/logs#app99)2020-12-12 06:07:02.942 pm [error](http://hubitat.lan/installedapp/configure/99)java.lang.NumberFormatException: For input string: "nu" on line 387 (childSetBinaryState)
[app:99](http://hubitat.lan/logs#app99)2020-12-12 06:07:02.934 pm [info](http://hubitat.lan/installedapp/configure/99)Setting binary state for air conditioner
[dev:129](http://hubitat.lan/logs#dev129)2020-12-12 06:07:02.921 pm [info](http://hubitat.lan/device/edit/129)Turning off
[app:99](http://hubitat.lan/logs#app99)2020-12-12 06:07:02.351 pm [error](http://hubitat.lan/installedapp/configure/99)java.lang.NumberFormatException: For input string: "nu" on line 387 (childSetBinaryState)
[app:99](http://hubitat.lan/logs#app99)2020-12-12 06:07:02.343 pm [info](http://hubitat.lan/installedapp/configure/99)Setting binary state for kitchen
[dev:132](http://hubitat.lan/logs#dev132)2020-12-12 06:07:02.331 pm [info](http://hubitat.lan/device/edit/132)Turning offYes I did actually, whatever the newest firmware was available.
I also updated my WeMos FW recently: WeMo_WW_2.00.11452.PVT-OWRT-SNSV2
but I just checked and there is yet another new FW: 11565.PVT
Since my WeMos are working right now with Hubitat, just filling my log with error messages, I'm hesitant to upgrade.
@jason0x43 - is there anything in particular from the logs I can help provide?
did anyone find a solution to this problem?
I'm also seeing the same thing as @abalingit; where the app is giving me an error:
Unexpected Error
An unexpected error has occurred trying to load the app. Check Logs for more information.
Error: Cannot invoke method getAt() on null object
One of my Wemo switches went offline last week. It would not connect but my other 9 worked fine. I tried accessing the Wemo Connect app and I was getting the same error as you. I tried deleting and reinstalling the app which then made all the other Wemo switches stop working. I restored a backup of my Hubitat and everything was back to square one with only the one Wemo switch not working. It seemed to be that the switch had lost its subscription ID. I removed that switch from my Hubitat and the Wemo Connect app started working again. I re-added the bad switch and everything began to work again. I'm not sure what the issue was but that seemed to work for me. I did also update all my switches to the latest firmware.
I decided to be adventurous and pull the trigger on the updated wemo firmware. It updated my old v1 swich, my v2 insight switch, my dimmer switches, and my 3-way switch. All appear to be working fine. Still can't get the app to detect my v4 mini's though.
@jason0x43 so I've been digging into your code, and with my limited knowledge of how Hubitat itself does things it would appear that when the app calls the lan discovery that my WeMo Minis aren't being found based on the debug logs. Lots of SSDP handler events for the existing devices, but no mention of the new ones. Unfortunately I haven't had the time to dig into how exactly lan discovery works so I'm not sure how to go about troubleshooting further. Is there a way for me to try to force lan discovery against the specific device and see what comes back? Trying to read through the documentation on this but I'm having a hard time getting specifics on how to call lan discovery. Are there any logs I can provide/look at to shed some light on this?
@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
I'm not sure. It may, but I don't have any WiFi Smart Plugs to test with.
Ok thanks. Finally gave up on using them and am trying another solution. Thanks for your response though.
@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.
1 Like
@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.
