Skills loading but not responding to intents

Archive - Mycroft Project This category is being retired - Support
1

I went to use Mycroft this morning to find that certain utterances no longer properly triggered skills. Here are some examples of utterances that previously worked with what they now return:

how are you
>> I am doing well, thank you — (works as expected)

set a timer for one minute
>> I dont know what that means — (answered by QuestionAnswersSkill)

set a timer
>> How long of a timer? — (works as expected)
one minute
>> Timer started for one minute — (works as expected)

stop timer
>> Sorry, I don’t understand. — (answered by QuestionAnswersSkill)

play queen on spotify
>> Just a moment while I look for that — (works as expected)
>> I’m not sure how to play queen on spotify — (CLI Info indicates Playback Control Skill returned no matches)

spotify list devices
` no response — nothing in the CLI log output at first; however, whenever the next utterance is received, the log reads:

ERROR | 738 | mycroft.skills.intent_service:handle_converse_error:247 | skill id does not exist

It looks like many of these commands are wrongfully going to fallback skills, though I am not sure if that is the case for all of them (see spotify)

A look at the skill log seems to indicate that skills are loading properly, so my guess is that somehow the intent system is the culprit, but I do not know how to go about fixing it.

This is an unfortunate case where everything was working fine yesterday, and I woke up today to find it broken.

If you have any ideas, they would be much appreciated!

2

I strongly advise to look at the vocab directory from your skill(s). You must be pretty precise in what you say in order to get a proper response.

But dont’t begin with weather skill code… :rofl:

<<btw another Feature request. Read the intents (or at least one variation) out loud. This can be pretty confusing at times. Especially with the library growing.

3

As far as I can tell, these should be valid ways of executing the desired commands. They seem to match the required intents for their respective commands. I am giving confidence in this not only by how recently they worked for me, but also that in the case of set a timer for one minute , the command is one of the example commands in the skill’s README file.

swapping one with 1 yields the same results, as does swapping spotify list devices with list spotify devices which is another command stated as working in the documentation.

4

Lets take start timer:

(code)

@intent_handler(IntentBuilder("start.timer").require("Timer")
                    .require("Start").optionally("Connector"))

which means:
required 1 of {start, set, create, begin, need, give}
required 1 of {timer, timers}
optionally 1 of {a, an, another, one more, the}

another entry point is @intent_file_handler('start.timer.intent'), speaking one of:

(another one|more|second|third|fourth|fifth| ) timer ((for ){duration} )
ping me in {duration}
timer
timer for {duration}
timer (for|called|named) {name}
timer (for|called|named) {name} for {duration}
{duration} (second|minute|hour) timer
{duration} timer (for|called|named) {name}

The rest could (and will) throw the intent handler off and the first has nothing to do with the second.

5

That is my interpretation as well. should that not mean then that set a timer for one minute is a valid intent that should result in a timer being started?

6

Nope,

“set a timer” would be entry point 1

“timer for {duration}” would be entry point 2

start.timer.intent has to be edited a such
(set a|) timer for {duration}
to grant entry

7

In that case, should any of the following work?

timer for one minute
one minute timer
timer for one

8

i don’t know how extract_duration_en (parsing “one minute”) handling looks like (i’m german) but

check
not
not

9

I see. Thanks for cross checking. Unfortunately, none of those utterances were able to work.

I do potentially have an idea though: in this commit, the timer vocab was changed from including elements that would have handled set a timer for one minute to forgoing them, as they were redundant since the same utterances could be handled by adapt to the same effect. This leads me to believe that there is some failure in the adapt module, though I do not know if it could explain all the issues I am having.

@gez-mycroft, it looks like you made the commit. Do you have any insights?

10

What is the output from the first of the three?

Oh since gez added this :dizzy_face:. That commit keeps me puzzled

11

by the first three do you mean:

?

If so, the responses were, respectively:

Sorry, I didn't catch that.
Please rephrase your request.
I don't know what that means.

Though I believe those are all fundamentally the same response

12

I just wanted to know if the first entered the method (the second and third shouldn’t be viable to begin with), but somehow the intent handler doesn’t recognize {duration} as a part of the intent or is able to assign the utterance to it

13

But i have to add that i recently set a timer myself (sucessfuĺly; german client) - which brings me back to the extract_duration_en problem which is probably somehow involved in this process.

14

Making a list of other commands that result in a generic fallback misunderstanding:

restart
shutdown
install timer
uninstall timer
install tuya
uninstall tuya

15

Another update:
I was taking a break from trouble shooting for a few hours, during which time Mycroft was left on and booted up. I had previously set up a service to flash a light whenever a mycroft.ready message was intercepted. With neither warning nor my interaction, the light suddenly flashed! I SSHed in to discover that some of the commands that had been failing before were working! Commands I specifically tested successfully included set a timer for one minute and restart. I also tested Spotify/Common play commands, though to no avail. I do not believe common play was able to resolve a candidate for the commands, despite them explicitly containing the word spotify and spotify being the only audio skill installed.

This seems to suggest that the spotify issue may be separate from the others, though I still suspect it is related seeing as it began to fail at the same time. it also potentially points a finger at the padatious services, which is listed here as being the sole producer of the mycroft.ready message.

Tragically, the positive results did not persist through a system restart, and Mycroft is now as functional as it was prior to the indication of the mycroft.ready message. I am hopeful, and feel one step closer to a solution, but am unfortunately still without an actionable path forward.

Any ideas are appreciated!

16

The Spotify issue is most likely because of this

17

That’ll do it. I heard that was a risk, but I did not think it would happen so soon.

I guess we can wrap up the Spotify issue as a red herring; the remainder of the problem, however, still stands.

18

Spotify could be the cause of this. I noticed the way spotify disabled the credentials caused the skill to lock up during startup due to a wait in the spotipy module. I did some server trickery and the credentials should fail to fetch completely allowing everything to load.

1 Like
19

Mixed success! I restarted Mycroft, and it was able to respond to commands as expected. invoking Spotify resulted in an error about bad credentials—as expected.

I am worried that something may have gone wrong during the update. While I was testing what commands were working, Mycroft said something about potentially bad internet connection, and that I should try again in three minutes. I did, and got no results, with my SSH connection freezing shortly after. I rebooted the pi, and am able to see the action light flashing, but have not been able to establish an SSH connection since.

EDIT: the pi eventually did connect to my router (it was not initially appearing as an attached device), the connection is extremely slow. As an example, took multiple minutes for the Microft/Picroft ASCII art to show up completely on login, and it appeared in multiple bursts of a few lines rather than all at once