Feat/message targetting

[JarbasAl]

I could swear i made this PR before, but could not find it so here it goes again.

This is needed for the hive mind

Description

The speech handling now checks the message context if it's the intended target for the message and will only speak in the following conditions:

• Explicitly targeted i.e. the destination is "audio"
• destination is set to None
• destination is missing completely

The idea is that for example when the android app is used to access Mycroft the device at home shouldn't start to speak.

Targeting Theory

The context target parameter in the original message can be set to list with any number of intended targets:

bus.emit(Message('recognizer_loop:utterance', data, 
				 context={'destination': ['audio', 'kde'],
						  'source': "remote_service"))

A missing destination or if the destination is set to None is interpreted as a multicast and should trigger all output capable processes (be it the mycroft-audio process, a web-interface, the KDE plasmoid or maybe the android app)

Messages

• new message.forward method, keeps previous context.
  • message continues going to same destination
• message.reply method now swaps "source" with "destination"
  • message goes back to source

Inside mycroft-core

• stt / cli will use "audio" or "debug_cli" as source
• intent service will .reply to utterance message
• all skill/intent service messages are .forward (from previous intent service .reply)
• cli is for debug, will print all utterances
• audio will check if "audio" or "debug_cli" is the destination

How to test

• STT utterances trigger TTS
• Cli utterances trigger TTS
• Remote Clients do not trigger TTS

[pep8speaks]

Hello @JarbasAl! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2020-02-15 15:34:49 UTC

[JarbasAl]

deprecates #2118

[JarbasAl]

Hello @JarbasAl! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! beers

Comment last updated at 2020-01-22 19:02:49 UTC

you are wrong pep8 bot

travis says

mycroft/skills/fallback_skill.py:65:36: E128 continuation line under-indented for visual indent
mycroft/skills/fallback_skill.py:89:44: E128 continuation line under-indented for visual indent

[forslund]

Yay this I can review and include :)

[forslund]

The pep-8 things need to be fixed. I do think the CLI by default should show all interactions since it's used for debugging. Maybe an option to disable that? CLI should also produce audio by default.

Will look into the details later this week/weekend but it looks like the old PR but a bit more advanced. 👍

[JarbasAl]

I do think the CLI by default should show all interactions since it's used for debugging. Maybe an option to disable that? CLI should also produce audio by default.

since this only makes sense (in my opinion) when debugging, why not simply check for the "debug" flag already present in the .conf ?

if i'm writing a query i'm also reading the response, if I'm speaking i'm not reading... unless we are debugging like you said

other option would be to identify the source in the cli interface itself, something like

[cli] some spoken message
[speech] some spoken message

[forslund]

Tested and seems to be working as intended. The code looks excellent from what I've seen (apart from the pep issues)

I want the cli to view the utterances from the speech client and utterance entered on the cli to be outputted as audio. The CLI is first and foremost intended as a debug tool and removing this makes it a lot less useful.

It looks to me like the changes to the Message.reply() method should be backwards compatible so we don't need to hold off waiting for the 20.02 release. (Although this thursdays release may be the last of 19.08.)

[JarbasAl]

very minor nitpick, and not used in practice, but should i set destination here as "enclosure"?

[JarbasAl]

when using self.speak inside a scheduled event the message.context was lost, added the option to pass the message context

this allows things like common_XXX to forward messages correctly MycroftAI/skill-query#8 MycroftAI/skill-playback-control#28

[forslund]

Ok I have some weirdness on my Desktop machine, seem to work on my laptop but I get no speech on my desktop. Will dig and see if I have some weird config set.

[forslund]

should this be

    if event.context.get('destination') and \
            ('debug_cli' not in event.context['destination'] or
             'audio' not in event.context['destination']):

That change seems to make the PR work for me.

[forslund]

This looks good now I think. Do you think you could rebase it and squash the pep-8 fixes and the logic fixes into the relevant main commits to clean up the commit history a bit?

[forslund]

Rebased, and ready to merge! Thanks @JarbasAI, awesome work!

[pcwii]

@JarbasAI @JarbasAl, Does this PR add the ability to know what skill originated the message? I think this would be handy also for filtering / directing intents to / from other devices. I am looking for this functionality in my Mesh-Skill. Thanks for all the hard work!