These are all subtly different problems I think, but in general most of these architectures currently assume there is a single intent.
> stop music and turn off all the lights
This is probably the easiest of the bunch because you are asking it to perform two distinct actions.
> turn off the bedroom light in 5 minutes
This is much more complex, because you are asking the application to setup some sort of workflow - after it understands what you want it to do, it then has to work out how to execute that, which will be utilising the device API's / services. This is a simple example, but there are lots of permutations of different actions here, for example you might want to say "turn off the sound system once this song finishes playing" which assumes that the assistant has the capability to then understand you want it to create a task specifically waiting for the trigger of a particular song finishing playing, and that it has the ability to setup that trigger.
> "keep the lights on” in a motion sensor system
Now this is where the orchestration gets tricky -
The assistant has to:
* Work out that the lights are being affected by a motion sensor system, which is likely outside it's own platform.
* Work out that your intent is that you want the assistant to override that.
* Understand how to connect to the platform in order to control it.
* Work out what parameter it is supposed to alter to achieve this task.
* Override the existing users settings, and presumably reinstate the settings after some portion of time.