Add a way to get the currently enabled intents

[koenvervloesem]

The new functionality to enable and disable intents on the fly is awesome! I used it in my app Keep quiet to ask your assistant to stop replying to your voice commands until you ask it to talk to you again.

This works like this:

• koan:Quiet - I disable all intents except koan:Talk.
• koan:Talk - I re-enable all intents that are enabled by default and I disable the other ones.

However, at any time other apps could have enabled intents that are disabled by default and/or disabled intents that are enabled by default. So to play nice with other apps, I really should do the following:

• koan:Quiet - Store the currently enabled intents in a list, and disable all these intents except koan:Talk.
• koan:Talk - Re-enable all intents that were enabled before receiving koan:Quiet. The ones that were disabled before are not in our list, so they stay disabled.

Currently the only way I see I could do that is by letting the app constantly monitor which intents get enabled or disabled and update this in a list. However, I think it would be useful if we could ask the Hermes object which intents are currently enabled. Not only for this app, but I guess for other apps it could be useful too, so they don't have to monitor this status of the intents themselves.

Would it be possible to add this functionality? For instance, just a method to ask whether a specific intent is currently enabled would already be very useful.

[fredszaq]

Hi @koenvervloesem

This is indeed something that we need to add. We'll need 2 APIs : one for the client apps to request the configuration to the dialogue and one for the dialogue to post it. (We can't do synchronous things with MQTT)

MQTT Topic	Payload	Remarks
hermes/dialogueManager/requestConfiguration	{}	Used by client apps to request the dialogue to publish its current configuration
hermes/dialogueManager/configuration	{"intents": [{"name": "SomeIntent", "enabled": true},...], "siteSpecific": [ "siteId"; "SomeSiteId, "intents": []}]}	Full configuration sent by the dialogue each time it is changed or when a request for it is made

We can potentially imagine using the existing hermes/dialogueManager/configure api in place of hermes/dialogueManager/requestConfiguration as all fields are nullable here and this would mean only one behaviour (post on configure => configuration update => post on configuration)

[koenvervloesem]

Hi @fredszaq, this approach looks great. And indeed, reusing hermes/dialogueManager/configure makes sense, as it's a special 'null' case then of the current behavior.

[koenvervloesem]

Hi @fredszaq and @anthonyray I have been thinking about how to use this new API, and it would be helpful to know whether a hermes/dialogueManager/configuration topic is published because the dialogue configuration is changed or because it's requested. Some apps will want to distinguish between the two situations because they only want to react to a change. See for instance: https://github.com/koenvervloesem/snips-app-keep-quiet/issues/1

[fredszaq]

Hi @koenvervloesem

This is in fact tricky, as we're in a full async context and we don't have in fact any way from the dialogue to know who is listening to the updates. Sending a new configuration and labelling it as "unchanged" (because it is in fact what would be happening) makes no sense as you can't know that the listeners effectively received the previous changes...

More over, this is the full config we'll be sending, and it is pretty much sure a given app will not want to react to every single change in this (we plan to expose other configurable things in the future) hence an app will already need to have a routine to check whether a config change applies to it or not. Hence I see not need to further complicate the api

[koenvervloesem]

Right, I see, that's tricky indeed, I missed the bigger picture. I'll need some extra checks in my app indeed.