The type of input expected is speci?¬?ed in a property of
the DTMF_Input object as either ???character??? or ???string??? (for simplicity, we will
concentrate here on single character input). For each possible input there is a
ConditionalFlow relationship to another VoiceOutput. Mostly, this will be a test for
equality with a given character speci?¬?ed in the ConditionalFlow, but slightly more
complex conditions like >= could also be speci?¬?ed.
If an invalid key is pressed there is an InvalidInput ?¬‚ow, normally back to the
previousVoiceOutput, that is, the instructions for this choice. For cases where no input
is received there is a Timeout ?¬‚ow, which speci?¬?es how long to wait before it is
followed, again normally back to the previous VoiceOutput. AVoiceOutput can also
be directly followed by another VoiceOutput, allowing reuse at this level.
In addition to the rules speci?¬?ed here about how objects can be connected with
various ?¬‚ows, there are also some more speci?¬?c constraints. As usual, a Start object
can be in just one From role, to prevent ambiguity in the initial control ?¬‚ow. In a
144 HOME AUTOMATION
similar way, a DTMF_Input object may only be in one InvalidInput and one Timeout
relationship: there would be no way to choose between several. There will however
normally be several ConditionalFlow relationships, as they each specify their own
Conditions: the various keys that can be pressed.
Pages:
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284