Device Control to Alexa API mapping?

[Jon]

I get that what it does it under their control. I was just hoping to get a bit more understanding on what it's currently doing. I was reading some of the alexa dev docs and it looks like i can enable a debug console on the alexa side and be able to see the discovery transactions. My thought was that if i could come up with a map of which various "control use" options correspond to which Alexa APIs and what their options are, then I'd be able to write my own documentation to fill in the blanks where HS's docs are lacking.
I have both the Jon00 VoiceMonkey plugin, as well as the mcsMQTT plugins installed. I'm familiar with VoiceMonkey. I haven't played with VM from mcsMQTT yet.

There have been times where I've wanted to do some things that would leverage some of the other Alexa APIs, like channel, volume, or mode select. If you're using the the correct alexa API, then it enables more natural phrases to be used. For instance. I can't have a device named channel, because it appears that there's no HS control type that uses the channel API. whenever you speak "set the TV Channel to 20" you get "TV doesn't support that" So as a workaround i have to have a device called "TV-Channel volume with a dim range set" then i can say "set the TV-Channel to 20 percent" and it works. And you have to say TV-Channel as if it's one worrd otherwise you still get the "TV doesn't support that" If it used the channel API properly, i could have a TV root device, with a Channel feature device, and i could "set the tv channel to 20". I ran into a similar thing with fan speeds. This would be a good use for the mode select API. Then i could give commands like "Set the Fan to Medium" Instead of "dim the fan to 66%". I actually have several devices where mode select would be nice. Holiday mode, vacation mode, babysitter mode, etc...those would all be nice to be able to set them via alexa.

[Michael McSharry]

I'm assuming that the "control use" field in HS is what determines which Alexa API a given device uses. Am i on track with this?

Control Use came about as a result of user revolt where there was not easy way to control a device using CAPI in HS2. While Control Use property was added by HST it did not have any standards of use. It was expanded as HST plugins needed extended capability, but no standards of user were defined.

If you want to have a more generalized Alexa integration, then look into Voice Monkey. Jon00 has virtualized it as a HS Speaker Client. mcsMQTT has virtualized it as HS Device. You can build upon these integrations, or you can start from scratch. In essence you need a cloud server that complies with the Amazon Alexa API. You could make your own, but if your needs are basic then building upon Voice Monkey will not involve any programming with AWS.

As stated in post #2, HST has developed their own AWS implementation for Alexa integration. What it does is totally under their control.

[mnsandler]

hs manages the alexa skill. we dont have any access to it. you might get into the hs4 plugin sdk support and see what they can offer.

[Jon]

I've been trying to learn more about how the control use field interacts with the Alexa service so i can get a better grasp on what is supported and what isn't and what Alexa utterances are appropriate for various scenarios. From my cursory research, the supported commands, aka utterances, that Alexa supports depends on which Alexa API a device is tied to. I'm assuming that the "control use" field in HS is what determines which Alexa API a given device uses. Am i on track with this? Is it possible to view the actual Alexa discovery json that HS passes to Alexa during discovery? (perhaps in a debug or developer mode?) That would tell me what HS is telling the Alexa service about each device. From there, i can cross reference the Alexa API for what the appropriate utterances are.
Is there a cross reference chart as to which "control use" option relates to which Alexa API?