Getting the Wemo app to work with UI7

albac0re · December 2, 2014, 7:21am

Has anyone had any experience with this app? I’m very new to the world of Vera and was hoping to use my existing wemo devices (2 plugs and 2 switches) after I read that there is an app that allows them to work.

After I install the app, and get to the point that I input the serial number and static IP, I click “add static” and then I’m asked to “close dialog and click save to commit to changes” but there is no dialog or save button ???

Any and all help would be appreciated.

I apologize in advance if this is not the correct place for this post.

Thanks!!

futzle · December 2, 2014, 9:40am

The message is a holdover from UI5. See my post here: http://forum.micasaverde.com/index.php/topic,28192.msg201700.html#msg201700

albac0re · December 2, 2014, 4:34pm

I appreciate your response. I’ll try your solution when I get home tonight. Thanks!

albac0re · December 2, 2014, 6:12pm

This worked PERFECTLY to get them onto my Vera network. Thank you so much!!

They work 100% on the browser control dashboard, but I can’t directly interact with them from the Vera UI7 android app. I can see the device and its current state, but when I tap the toggle switch, it does nothing. I have to create a scene that interacts with them for me which I can then manually trigger. Any ideas to get direct interactivity with WeMo devices in the app?

Thanks again for the instructions to “reload luup”!

xycmu · February 24, 2015, 8:15pm

Thank you for the suggestion, although it didn’t work in my case.

WeMo version: 10.10
VERA3 UI7 v1.7.513

My steps:

Belkin WeMo settings
Belkin WeMo ‘Configure’
Verify unknown device to add
Choose ‘Add Static’ (also tried manually entering device info)
Received confirmation and ‘Close dialog and press SAVE to commit changes’

Choose ‘Apps’
Choose ‘Develop apps’
Choose ‘Serial Port configuration’
Choose ‘Reload Luup’

Choose ‘Back’
Choose ‘Advanced’
Choose ‘New service’
Choose ‘Reload Engine’

Neither method resulted in a new device. When repeating the steps, the WeMo app still shows the device as unknown.

The device works fine when using the native Belkin WeMo phone app. Does anyone have suggestions?

jaitley · April 6, 2015, 2:05pm

I am in same situation. I saw the plugin and bought the WeMo Switch yesterday. But I can’t add device. It does not discover device automatically or let me add it manually.

I am very new to this platform and will need some time to dig into coding myself. the Lua/Luup is new for me too, as I am c# programmer.

:-[

dornier · April 10, 2015, 3:47am

[quote=“jaitley, post:6, topic:184446”]I am in same situation. I saw the plugin and bought the WeMo Switch yesterday. But I can’t add device. It does not discover device automatically or let me add it manually.

I am very new to this platform and will need some time to dig into coding myself. the Lua/Luup is new for me too, as I am c# programmer.

:-[[/quote]

I also had no luck in making it work. Actually, the plugin found one Wemo once, but since I performed a full reset on my Veraedge, it never found it again. The folks at Vera have tried making the plugin work, but no success yet.

peteinau · June 1, 2015, 5:13am

I can get it to detect the Wemo devices on the network quite happily, but I can’t add any devices. Stuck on the same process of it wanting me to hit the save button that doesn’t exist. I tried the same process as xycmu but didn’t add them.

fyford · July 22, 2015, 1:58pm

Same here… anybody!?

kitts · September 18, 2015, 3:32am

Anybody found solution to this problem?

I had my Wemo devices working in UI7, the devices were added pre-UI7. I changed my router and network then I can’t get this to work. There is no way the devices show up, no matter what I do, tried all suggestions so far!.

UpnpDiscovery works and the list shows in the UI, clicking the button Add Static works too…

I reloaded Lupp many times, it always says creating up to 0 children.

50 09/18/15 1:56:07.731 luup_log:138: Starting WeMo plugin (device 138) <0x2be30680>
50 09/18/15 1:56:07.732 luup_log:138: Creating up to 0 children <0x2be30680>
50 09/18/15 1:56:07.733 luup_log:138: Roll call of child devices <0x2be30680>
50 09/18/15 1:56:07.734 luup_log:138: Searching for UPnP devices… <0x2be30680>
50 09/18/15 1:56:07.735 luup_log:138: M-SEARCH sent to 239.255.255.250:1900 <0x2be30680>

How do we make it create the discovered devices?

frustrating!

futzle · September 18, 2015, 10:57am

[quote=“kitts, post:10, topic:184446”]50 09/18/15 1:56:07.734 luup_log:138: Searching for UPnP devices… <0x2be30680>
50 09/18/15 1:56:07.735 luup_log:138: M-SEARCH sent to 239.255.255.250:1900 <0x2be30680>[/quote]

You truncated the log just as it was getting interesting. What happens after the last line you quoted?

Also: after you “Add Static”, you have to “Save” your changes. In UI5 this was obvious: click the big red SAVE button. In UI7 you still have to Save, but this involves backing out of the config page and running to Apps > Develop Apps > Serial Port Configuration > Reload Luup. There’s an element of timing and an element of luck in this. I’ve heard reports that doing it too fast, or too slow, will stop it working.

Another edit: Even though this is an unsupported plugin, it’s probably worth everyone writing to MCV with a support request. The sheer volume of people wanting their WeMo switches to work in their Veras might prompt them to take a look at the plugin, and make whatever small change it needs to work on UI7. They’ve got access to the source code just as anyone else does.

kitts · September 19, 2015, 2:13am

[quote=“futzle, post:11, topic:184446”][quote=“kitts, post:10, topic:184446”]50 09/18/15 1:56:07.734 luup_log:138: Searching for UPnP devices… <0x2be30680>
50 09/18/15 1:56:07.735 luup_log:138: M-SEARCH sent to 239.255.255.250:1900 <0x2be30680>[/quote]

You truncated the log just as it was getting interesting. What happens after the last line you quoted?

Also: after you “Add Static”, you have to “Save” your changes. In UI5 this was obvious: click the big red SAVE button. In UI7 you still have to Save, but this involves backing out of the config page and running to Apps > Develop Apps > Serial Port Configuration > Reload Luup. There’s an element of timing and an element of luck in this. I’ve heard reports that doing it too fast, or too slow, will stop it working.

Another edit: Even though this is an unsupported plugin, it’s probably worth everyone writing to MCV with a support request. The sheer volume of people wanting their WeMo switches to work in their Veras might prompt them to take a look at the plugin, and make whatever small change it needs to work on UI7. They’ve got access to the source code just as anyone else does.[/quote]

Thanks for responding to this issue, I understand you have stopped supporting the plugin. I agree, Vera should pick this up and fix whatever that it need to get this working.

I have a Support email thread going on with Vera.

The Save part is where I am stuck with. I Reload Lupp engine so many times after adding Static.

I looked at the lupp code (programmer myself, cant figure out when the number of child device variable gets updates or saved)

Okay here is the full log: (10.0.0.211 and 10.0.0.212 are Belkin Switches)

50 09/18/15 20:56:27.963 luup_log:138: Starting WeMo plugin (device 138) <0x2b2e6680>
50 09/18/15 20:56:27.964 luup_log:138: Creating up to 0 children <0x2b2e6680>
50 09/18/15 20:56:27.965 luup_log:138: Roll call of child devices <0x2b2e6680>
50 09/18/15 20:56:27.966 luup_log:138: Searching for UPnP devices… <0x2b2e6680>
50 09/18/15 20:56:27.967 luup_log:138: M-SEARCH sent to 239.255.255.250:1900 <0x2b2e6680>
50 09/18/15 20:56:27.976 luup_log:138: M-SEARCH response received from 10.0.0.1 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:27.977 luup_log:138: Missing header LOCATION <0x2b2e6680>
50 09/18/15 20:56:27.978 luup_log:138: M-SEARCH response received from 10.0.0.1 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:27.979 luup_log:138: Response identifies itself as 10.0.0.1:5000 from UUID uuid:dd6d2c0e-b953-a631-31b9-3993ce0902fc <0x2b2e6680>
50 09/18/15 20:56:27.979 luup_log:138: M-SEARCH response received from 10.0.0.1 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:27.981 luup_log:138: Response identifies itself as 10.0.0.1:8200 from UUID uuid:4d696e69-444c-164e-9d41-e4f4c60d1422 <0x2b2e6680>
50 09/18/15 20:56:27.985 luup_log:138: M-SEARCH response received from 10.0.0.210 UDP port 33280 <0x2b2e6680>
50 09/18/15 20:56:27.987 luup_log:138: Response identifies itself as 10.0.0.210:49451 from UUID uuid:4d494342-5342-5645-0000-000002164561 <0x2b2e6680>
50 09/18/15 20:56:28.303 luup_log:138: M-SEARCH response received from 10.0.0.5 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:28.304 luup_log:138: Response identifies itself as 10.0.0.5:80 from UUID uuid:2f402f80-da50-11e1-9b23-00178818e57f <0x2b2e6680>
50 09/18/15 20:56:28.354 luup_log:138: M-SEARCH response received from 10.0.0.5 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:28.355 luup_log:138: Bad USN format from http://10.0.0.5:80/description.xml: uuid:2f402f80-da50-11e1-9b23-00178818e57f <0x2b2e6680>
50 09/18/15 20:56:28.404 luup_log:138: M-SEARCH response received from 10.0.0.5 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:28.405 luup_log:138: Bad USN format from http://10.0.0.5:80/description.xml: uuid:2f402f80-da50-11e1-9b23-00178818e57f <0x2b2e6680>
50 09/18/15 20:56:28.520 luup_log:138: M-SEARCH response received from 10.0.0.17 UDP port 33361 <0x2b2e6680>
50 09/18/15 20:56:28.522 luup_log:138: Response identifies itself as 10.0.0.17:1400 from UUID uuid:RINCON_B8E9372AC46401400 <0x2b2e6680>
50 09/18/15 20:56:28.790 luup_log:138: M-SEARCH response received from 10.0.0.3 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:28.791 luup_log:138: Missing header LOCATION <0x2b2e6680>
50 09/18/15 20:56:29.354 luup_log:138: M-SEARCH response received from 10.0.0.5 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:29.355 luup_log:138: Response identifies itself as 10.0.0.5:80 from UUID uuid:2f402f80-da50-11e1-9b23-00178818e57f <0x2b2e6680>
50 09/18/15 20:56:29.404 luup_log:138: M-SEARCH response received from 10.0.0.5 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:29.405 luup_log:138: Bad USN format from http://10.0.0.5:80/description.xml: uuid:2f402f80-da50-11e1-9b23-00178818e57f <0x2b2e6680>
50 09/18/15 20:56:29.456 luup_log:138: M-SEARCH response received from 10.0.0.5 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:29.457 luup_log:138: Bad USN format from http://10.0.0.5:80/description.xml: uuid:2f402f80-da50-11e1-9b23-00178818e57f <0x2b2e6680>
50 09/18/15 20:56:29.474 luup_log:138: M-SEARCH response received from 10.0.0.220 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:29.475 luup_log:138: Missing header LOCATION <0x2b2e6680>
50 09/18/15 20:56:29.845 luup_log:138: M-SEARCH response received from 10.0.0.211 UDP port 3081 <0x2b2e6680>
50 09/18/15 20:56:29.846 luup_log:138: Response identifies itself as 10.0.0.211:49153 from UUID uuid:Lightswitch-1_0-221345K1300F9D <0x2b2e6680>
50 09/18/15 20:56:30.969 luup_log:138: M-SEARCH response received from 10.0.0.10 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:30.970 luup_log:138: Response identifies itself as 10.0.0.10:8060 from UUID uuid:01091048-6c00-1051-80f6-000d4bbf7e45 <0x2b2e6680>
50 09/18/15 20:56:31.155 luup_log:138: M-SEARCH response received from 10.0.0.212 UDP port 3079 <0x2b2e6680>
50 09/18/15 20:56:31.156 luup_log:138: Response identifies itself as 10.0.0.212:49153 from UUID uuid:Lightswitch-1_0-221345K1300996 <0x2b2e6680>
50 09/18/15 20:56:31.523 luup_log:138: M-SEARCH response received from 10.0.0.20 UDP port 1900 <0x2b2e6680>
50 09/18/15 20:56:31.524 luup_log:138: Response identifies itself as 10.0.0.20:8060 from UUID uuid:015de0c9-0001-1064-80d3-b83e59d55453 <0x2b2e6680>
50 09/18/15 20:56:36.526 luup_log:138: Searching complete <0x2b2e6680>
50 09/18/15 20:56:36.526 luup_log:138: UPnP location http://10.0.0.1:5000/Public_UPNP_gatedesc.xml <0x2b2e6680>
50 09/18/15 20:56:36.527 luup_log:138: UPnP udn uuid:dd6d2c0e-b953-a631-31b9-3993ce0902fc <0x2b2e6680>
50 09/18/15 20:56:36.528 luup_log:138: Unknown uuid uuid:dd6d2c0e-b953-a631-31b9-3993ce0902fc, identifying … <0x2b2e6680>
50 09/18/15 20:56:36.859 luup_log:138: UPnP location http://10.0.0.17:1400/xml/device_description.xml <0x2b2e6680>
50 09/18/15 20:56:36.860 luup_log:138: UPnP udn uuid:RINCON_B8E9372AC46401400 <0x2b2e6680>
50 09/18/15 20:56:36.860 luup_log:138: Unknown uuid uuid:RINCON_B8E9372AC46401400, identifying … <0x2b2e6680>
50 09/18/15 20:56:36.937 luup_log:138: UPnP location http://10.0.0.5:80/description.xml <0x2b2e6680>
50 09/18/15 20:56:36.938 luup_log:138: UPnP udn uuid:2f402f80-da50-11e1-9b23-00178818e57f <0x2b2e6680>
50 09/18/15 20:56:36.938 luup_log:138: Unknown uuid uuid:2f402f80-da50-11e1-9b23-00178818e57f, identifying … <0x2b2e6680>
50 09/18/15 20:56:36.952 luup_log:138: UPnP location http://10.0.0.212:49153/setup.xml <0x2b2e6680>
50 09/18/15 20:56:36.952 luup_log:138: UPnP udn uuid:Lightswitch-1_0-221345K1300996 <0x2b2e6680>
50 09/18/15 20:56:36.953 luup_log:138: Unknown uuid uuid:Lightswitch-1_0-221345K1300996, identifying … <0x2b2e6680>
50 09/18/15 20:56:37.005 luup_log:138: Device type is urn:Belkin:device:lightswitch:1 <0x2b2e6680>
50 09/18/15 20:56:37.006 luup_log:138: Device http://10.0.0.212:49153/setup.xml is a D_WeMo1_Controllee1.xml <0x2b2e6680>
50 09/18/15 20:56:37.006 luup_log:138: Device http://10.0.0.212:49153/setup.xml is called Front Porch Light and has serial Number 221345K1300996 <0x2b2e6680>
50 09/18/15 20:56:37.008 luup_log:138: Noting details of unknown device uuid:Lightswitch-1_0-221345K1300996 <0x2b2e6680>
50 09/18/15 20:56:37.008 luup_log:138: UPnP location http://10.0.0.10:8060/ <0x2b2e6680>
50 09/18/15 20:56:37.009 luup_log:138: UPnP udn uuid:01091048-6c00-1051-80f6-000d4bbf7e45 <0x2b2e6680>
50 09/18/15 20:56:37.009 luup_log:138: Unknown uuid uuid:01091048-6c00-1051-80f6-000d4bbf7e45, identifying … <0x2b2e6680>
50 09/18/15 20:56:37.030 luup_log:138: UPnP location http://10.0.0.210:49451/luaupnp.xml <0x2b2e6680>
50 09/18/15 20:56:37.031 luup_log:138: UPnP udn uuid:4d494342-5342-5645-0000-000002164561 <0x2b2e6680>
50 09/18/15 20:56:37.031 luup_log:138: Unknown uuid uuid:4d494342-5342-5645-0000-000002164561, identifying … <0x2b2e6680>
50 09/18/15 20:56:37.658 luup_log:138: UPnP location http://10.0.0.1:8200/rootDesc.xml <0x2b2e6680>
50 09/18/15 20:56:37.658 luup_log:138: UPnP udn uuid:4d696e69-444c-164e-9d41-e4f4c60d1422 <0x2b2e6680>
50 09/18/15 20:56:37.659 luup_log:138: Unknown uuid uuid:4d696e69-444c-164e-9d41-e4f4c60d1422, identifying … <0x2b2e6680>
50 09/18/15 20:56:37.680 luup_log:138: UPnP location http://10.0.0.20:8060/ <0x2b2e6680>
50 09/18/15 20:56:37.680 luup_log:138: UPnP udn uuid:015de0c9-0001-1064-80d3-b83e59d55453 <0x2b2e6680>
50 09/18/15 20:56:37.681 luup_log:138: Unknown uuid uuid:015de0c9-0001-1064-80d3-b83e59d55453, identifying … <0x2b2e6680>
50 09/18/15 20:56:37.694 luup_log:138: UPnP location http://10.0.0.211:49153/setup.xml <0x2b2e6680>
50 09/18/15 20:56:37.695 luup_log:138: UPnP udn uuid:Lightswitch-1_0-221345K1300F9D <0x2b2e6680>
50 09/18/15 20:56:37.695 luup_log:138: Unknown uuid uuid:Lightswitch-1_0-221345K1300F9D, identifying … <0x2b2e6680>
50 09/18/15 20:56:37.743 luup_log:138: Device type is urn:Belkin:device:lightswitch:1 <0x2b2e6680>
50 09/18/15 20:56:37.743 luup_log:138: Device http://10.0.0.211:49153/setup.xml is a D_WeMo1_Controllee1.xml <0x2b2e6680>
50 09/18/15 20:56:37.744 luup_log:138: Device http://10.0.0.211:49153/setup.xml is called Kitchen Island Light and has serial Number 221345K1300F9D <0x2b2e6680>
50 09/18/15 20:56:37.745 luup_log:138: Noting details of unknown device uuid:Lightswitch-1_0-221345K1300F9D <0x2b2e6680>
50 09/18/15 20:56:37.758 luup_log:138: Sleeping for 300 seconds <0x2b2e6680>

futzle · September 19, 2015, 6:54am

Thanks for the log, kitts. That demonstrates that there isn’t an issue with discovery (historically the trickiest part of the WeMo plugin to run properly). Instead it points the finger at the JavaScript code that drives the plugin’s configuration dialog. I do know that MCV made some changes to the JavaScript API in UI7 so perhaps the code in the plugin that registers a detected WeMo device isn’t correct any more.

(It’s not the Lua code that updates the Child Device count; it’s the JavaScript code. Take a look around line 190 of J_WeMo.js.)

I don’t recall if there is much logging in the Luup log when you interact with the JavaScript API. Watch the log while you press the “Add Static” button. Perhaps it’ll give you some ideas.

If absolutely nothing else works, you can skip the configuration page and go to the Advanced tab and set the variables yourself. That same function I linked above is responsible for setting the variables on the parent device; you can read the source to see what they need to be called. Once those variables have been set you can restart the Luup engine and it should create the child devices.

cybrmage · September 19, 2015, 11:37am

I’ve attached a fixed javascript file for the Wemo plugin for UI7…

It allows the plugin to be configured using the UI…

After modifying the configuration, you need to reload the LuaUPnP engine…

futzle · September 20, 2015, 4:23am

Thanks cybrmage. Are you OK with this being included into the plugin (the licence is GPL)?

cybrmage · September 20, 2015, 4:25am

Yes.

futzle · September 20, 2015, 4:38am

I’ve updated the code at the source repository. I can’t update the file at apps.mios.com; when I try to edit that file I am told “Unable to open the file” and “File cannot be found”. I suspect it’s a permission thing: that file was created by an MCV employee when they made the plugin UI7 compatible last October, so perhaps I haven’t been given write permission to it.

kitts · September 21, 2015, 5:07am

I have updated JS file to vera and couldn’t get any further, no devices created . I do see the message has been changed to reload engine, instead of save.

So I started to muck with the Lua file. I set the variables manually using the advanced tab. I had 2 unknown devices.

I manually set ChildCount=2 and UnknownDeviceCount = 2

There were 2 sets of UnKnownDevice variables, those looked like my devices.

Then, I added a debug("childType : " … childType … " ", 2) inside the for loop in createChildDevices()

and reload engine, it failed to load plugin.

So I thought the following variable is not set correctly. I changed the line
local childType = luup.variable_get(ServiceId, “Child” … child … “Type”, Device)
to
local childType = luup.variable_get(ServiceId, “UnknownDevice” … child … “Type”, Device)

then reloaded engine, voila two new devices got created!

Checked the LuaUPnP.log, and it looks like working.

I am still not sure what is Child devices and UnknownDevice.

zoot1612 · November 16, 2015, 12:43am

@futze
I know that you don’t support this plugin anymore but was hoping you would update repository with the following: -

Insert xmlParser:parse() at line 226

local sink = function(chunk, err)
if (chunk == nil) then
	debug("sink: end of file", 4)
	xmlParser:parse()
	xmlParser:close()
	return nil
end

From [url=https://matthewwild.co.uk/projects/luaexpat/manual.html#parser]LuaExpat: XML Expat parsing for the Lua programming language Parser objects: -
parser:close()
Closes the parser, freeing all memory used by it. A call to parser:close() without a previous call to parser:parse() could result in an error.

In Initialisation function ensure that previous not found devices when found communications failure is marked as false. Maybe you want to do this differently.

-- Any existing children not accounted for?
local unaccountedDevices = 0
for i, d in pairs(ChildDevices) do
	if (not d.found) then
		unaccountedDevices = unaccountedDevices + 1
		--luup.set_failure(true, i)
	end
	luup.set_failure(not d.found, i)
 end

These have fixed the issues I was having in UI5 but whether you accept the changes or not is up to you.

automation169 · December 1, 2015, 9:31pm

Does anyone have a way to get this working without having to change the scripts? my devices are discovered just fine, but i have not been able to get them to be configured as devices. i have tried the jumping out and doing a “Reload” many, many, many times and it just will not configure them as devices.