Installed background service, but background commands still not available
-
In response to your question, yes, I got a UAC prompt and allowed it. I see the service in the Windows Services manager, too, but it seems to stop itself even if I manually tell it to start.
If it helps, I am not logged in to an admin-level account, just as a normal user.
-
I'm pretty sure I'm stuck with "trigger c m d" as the "Invocation Name" for the Alexa skill. Someone else suggested using "trigger command", so I tried modifying it and Amazon doesn't let me now that it's published.
I'm surprised you could even install the background service without an admin-level account, unless maybe when it gave you the UAC prompt, you also typed in a username and password for an admin account?
You could also try removing and re-installing the background service. Just an idea.
You'll want to remove it anyway before installing this new 1.0.3 version of the agent I just published:
https://s3.amazonaws.com/triggercmdagents/TRIGGERcmdAgentSetup.exev1.0.3 now updates the voice field in the cloud when you to change the voice field in commands.json without changing the trigger field.
-
Yes, that's how the UAC works when triggered from a non-admin account, and (most) installers cause the UAC to come up. If there's only one admin level account it defaults to that one, but I do have to enter the password. I treat it a bit like using "sudo" on a Linux/Unix machine--I don't like staying logged in as an admin account.
I get an Access Denied error on that link.
-
Man, I'm so glad you told me the link didn't work. I forgot to make it public.
I stay logged in as an admin account and I didn't even think to test using a non-admin account. This gives me an idea of what the problem is and I think I can fix it, so look forward to v1.0.4 soon.
Christian, you've already helped me a lot. I appreciate it.
-
Christian, I fixed it. Now when you install the background service while logged in as a non-admin, the service will use the home directory of your non-admin account. What was happening before (with 1.0.3) is it was using the home directory of the admin account who's credentials you typed in to install the service.
-
I can confirm that background commands now show up. I'm not sure what the difference is between foreground and background. My lock and sleep commands appear to be non-functional when defined as background, but work fine as foreground.
Is there documentation that I've overlooked?
-
Good question. Background commands run in the context of the windows service, so they run as the local system account by default. The background commands can't display things in the GUI, but because they run as the local system account they have full access to your PC, so they can do things like reboot or stop/start other services. Also, the windows service starts when you boot your PC, so you don't have to be logged in for the background commands to run.
About documentation, you didn't miss it, I just haven't written much documentation yet. I need to work that. You're giving me ideas for what to document.
-
I think I've uncovered another bug. For some reason I'm seeing multiple entries in my command list on the website, even though my commands.json file doesn't have duplicates, and triggering one of the duplicated commands is problematic.
-
Yea I noticed it too. I've been working on fixing that tonight. It seems to happen more when there are more commands in commands.json.
-
I fixed that bug. Sorry it took so long. I posted v1.0.5 just now.
To remove your existing duplicates, just change the trigger name and save commands.json.
Thanks again for telling me, and thanks for your patience.
