Hey, you piqued my interest and I had a little free time, so:
Currently only space for a single parameter, but this should be sufficient for Dominiks example above.
1 Like
Hey @gez-mycroft, thanks!
I’ve cloned the repo in to /skills, and edited the
/mycroft-core/skills/make-get-request-skill.krisgesling/settingsmeta.yml
it now looks like this:
skillMetadata:
sections:
- name: Trigger
fields:
- name: trigger_phrase
type: text
label: Trigger phrase
value: "lights on"
placeholder: this should not include the wake word
- name: response_on_success
type: text
label: Response on success
value: "as you command"
- name: response_on_failure
type: text
label: Response on failure
value: "I can't sir"
[...]
I have also restarted mycroft with:
./start-mycroft.sh restart all
giving the command :skills in the CLI correctly lists make-get-request-skill.krisgesling among the installed skills.
but when I say “Hey Mycroft! … lights on”, Mycroft responds with :
lights on DEBUG output
>> I don't know what that means.
Is there anything else I need to do?
Again, thanks for your support!
The relevant part for this to trigger is @intent_handler(‘make.request.intent’), thus saying “Test this thing for me”. This is just a framework to be fleshed out.
Bullshit, haven’t recognized update_intent_file
can you nano in make.request.intent and post the content?
(i expect a newline problem)
Thanks @SGee, here is the nano of make.request.intent
test this thing for me
I don’t think it’s very evident from the code above, but there is a newline after “test this thing for me”… (ie: the file is composed of the above, followed by a new,empty line)
I’ve tried removing the newline and restarting Mycroft tho, and still the command is not recognized
I also tried “test this thing for me” as the command, but it is not recognized either.
I deleted and re-created the file with just a simple word in it (“lights”) and it IS working!
Given (the intention of) the code “lights on” should be written to make.request.intent
with the new content
test this thing for me\n
lights on
Sorry, just updated my last post:
I deleted and re-created the file with just a simple word in it (“lights”) and it IS working!
yeah, but this doesn’t resolve the core problem. This should automatcally be written as you change the config. (given the home config fetching algorithm got juiced)
Yep.
and I tought to play the smart guy and duplicate the skill (since as of now, I need at least two parameters: On and Off) and so have a skill for the “On” command and the other for the “Off” command but alas, this isn’t working either 
You could make something with “lights {status}” intent
and processing like
status = message.data.get(‘status’)
if status == “on”:
if status == “off”:
Thanks @SGee, but I’m really new at Mycroft 
when you say:
make something with “lights {status}”
you mean writing in make.request.intent exactly: lights {status} ?
I tried doing this, and putting the logic in __init__.py but lights {status} isn’t recognized anymore as a command. (of course by speaking “Lights On”)
Again, pardon me but I’m a total noob at this
Update: I also tried with double curly braces ({{status}}) as explained here:
but still the command is not recognized
Lets stay with the intention of the code and iron out possible errors
i mean
fields:
- name: trigger_phrase
type: text
label: Trigger phrase
value: "lights {status}"
with
@intent_handler('make.request.intent')
def handle_request(self, message):
"""Make the actual GET request."""
status = message.data.get(‘status’)
key = self.settings.get('param_key')
if status == "on":
value = self.settings.get('param_value')
if status == "off":
value = self.settings.get('param_value2')
...I’ve found that Mycroft won’t react to the command specified in the settingsmeta.yaml, but just to the one in make.request.intent
maybe something else is broke… elsewhere?
Just to be sure, I rm -fr the skill and re cloned it with
mycroft-msm install https://github.com/krisgesling/make-get-request-skill
then edited the above files one at a time, same results 
maybe you are doing something wrong, you really should not edit settingsmeta.yaml, you should edit settings.yaml , the meta is for usage by the backend to display web settings
or maybe its the known selene bug, the backend is known to overwrite any changes you make locally to skill settings.
so installed the skill and added a trigger phrase
short time later (ckeck cli) make.request.intent looks like
turn lights {status}
you are running mycroft with lang=en-us?
since i had to copy the locales to de-de first to take effect (there are only en-us locales yet)
intent_file = /opt/mycroft/skills/make-get-request-skill.krisgesling/locale/de-de/make.request.intent` (in my case)
@SGee: yes, running with en-us
@JarbasAl: there’s no settings.yaml in this repo, I’ve tried updating settingsmeta from the device settings in the website, but it takes long for the settings to apply (if ever) so I was changing them direcly on disk
i guess you have to use mycroft-stop ; mycroft-start all if changed locally
Another thing: Like coded atm, the intent file is overwritten with the new intent
settings.yaml or settings.json are created on device, not from repo.
edting settingsmeta will only change the web ui, you are not changing any settings on disk, you are just telling the web ui to show different text
https://mycroft-ai.gitbook.io/docs/skill-development/skill-structure/skill-settings
just use the web ui and wait for changes to sync, might take a few minutes.
i havent looked into gez skill, but this seems an odd thing to set utterance in web ui. just make a regular skill using intents like everyone else? that is literally what intents are for
1 Like
@JarbasAl: I’m a total noob here, just trying to make gez skill work in a very simple scenario.
That said, I think I’m getting closer.
I’ve edited the .py file to speak the variable instead of speaking the error, and one of the problems seems to be that even it the command (in the web ui) is
turn lights {status}
when I say “turn lights on”
the command that is returned is turn lights (ie, the variable stays… null)
I’ve deleted and re-cloned the repo to be sure to have a clean start, and I’ve modified ONLY the data in the webui to these values:
yet, even when writing in the cli
turn lights on
the parameter stays null
@Sgee: I’ve given up on updating locally, and I’m just using the WebUI trying to make things as easy and replicable as possible. If you read my above post, I’m not really managing to have the variable you suggested get a value.
I’m banging my head at this since hours… I didn’t expect this to be so hard…
Thanks for the help