Installed background service, but background commands still not available
-
I'm on Windows 10, installed the software and told the tray icon to install the background service, but I still can't see or access background triggers.
-
What's more, none of the additional foreground commands I have added are triggerable by Alexa. It always says it can't find the trigger.
-
Christian, I looked at your voice words for your commands, and tried them. The 2nd one worked well for me, but I had to remove the "ing" from the 1st one before Alexa recognized it.
Your voice word for your computer worked well for me.
One thing I found too is that Alexa understands better if you pause for about 1 second between "run X" and "on Y". So think of it like a comma - run this, on that.
Also I just noticed a bug in the agent when I tested that. I found that if I only change the voice word for the command in commands.json, it doesn't update on the website. I had to change another field for it to update the command's voice word. Oops! I'll try to fix that and post a new version of the agent by tomorrow.
Thank you for testing!
-
I'm sorry installing the background service it didn't work. I hope I can figure out why. I have Windows 10 too. I just tried uninstalling and re-installing the background service and it works for me.
Do you see the TRIGGERcmdAgent service listed in you Windows services? If so, maybe you just need to start it, or stop/start it.
When you installed the background service, did you see a "User Account Control" prompt to allow Node.js to make changes to your device? I assume you click Yes to that?
I'd appreciate any clues you can give me to help me reproduce the problem.
-
I feel silly now, and I must apologize. I thought the "voice" field was to designate how Alexa responded, and not for how I invoke the command. That is certainly my fault! So, I apologize.
It also appears that, for the commands I am defining, it probably doesn't matter whether I define them as background or foreground, so I will just use foreground.
Any chance the skill name itself could be revised to something easier to say?
-
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.
