Adding transitional states to Custom Semantic Catalog

[wawa79]

Hello,

I suggest to add "transitional" states to Custom Semantic Catalog in the next release of the skill. States of items which require "significant delay" to change their state could report their actual state to Alexa.

For example:

• my garage doors are coded with a Number item which values are mapped to the states : closed, opening, open and closing. On rollershutters, transitional states would allow stateMappings="Closed=0,OpeningClosing=1:99,Open=100"
• dimmers could have one RangeValue endpoint for the level and one Mode endpoint which could be set to "processing" state while the value is being changed
• my audio / vidéo devices are coded with a Number item which values are mapped to several "real" modes (TV, multichannel, hifi) and several "transitional modes" used while hardware devices are changing their inputs and turning on or off (or preheating, for some valve amps or video projector involved in the process)
• scenes could also have a "changing" / "processing" state set until the target state is reached

I hope my proposal makes sense. If not, feel free to explain what I am missing :-)

[jsetton]

Thanks for your proposal.

Related to delayed/deferred response, this is something which is already in the works. This will introduce a new binding that will asynchronously respond to the Alexa API once it receives the command from the skill. Doing so will allow state response to be delayed waiting for the updated state up to 8 seconds (Alexa API limitation) with the exception of the LockController capability that can go beyond that.

We attempted to add this feature to the skill in the past (#73) but realized that this would drastically increase the Lambda resource cost since the function would be unnecessarily idling waiting for a state change. This is the reason why the skill currently requires the item state to be updated right after a command is received.

As far as transitional states, I don't see much use since this is not natively supported by the Alexa API. These wouldn't come into play when the Alexa API is formulating a response to a voice command. Likewise at the Alexa app level, the integration would be very messy with no value added.

It is important to note that not all Alexa capabilities supports state responses. The last two examples you provided would be modeled as Activity and Scene which doesn't have a state on the Alexa side.
Only a few of the capabilities that support state response (e.g. lock state, garage door open state, thermostat temperature/mode) have a proper voice integration on the Alexa side that will trigger different responses based on the state returned. Others, such as switch power state or dimmer brightness level, will always trigger a successful voice response even though the state hasn't changed or isn't the one that was requested.

There is a fine line when it comes down to voice request acknowledgements. It is definitely reassuring to know that a successful response would indicate that the actual request was successful. However, it could also have a negative effect if you are trying to delay the response until you can guarantee that the command was processed as intended. This is even more the case with smart home devices since you would see the changes happening in your environment as the command is processed. In that case, it may not always be the best approach to delay the acknowledgement. In most cases, a voice request acknowledgement should be a confirmation that the skill was able to validate/process the request and send any relevant commands to the OH server.

[wawa79]

Understood. Thank you for the reply.