Device command handling and messaging integration

Learning objectives

Separate input, state, and response so that the same command handling rules can be reused across messengers, the web, and device buses.

Execution conditions

The basic activity uses Python only. Choose a real messenger or MQTT connection only after verifying the handling rules.

Commands and state transitions

Starting conditions

The inputs are /start, /led on, /led off, /led invalid, and /unknown. The initial LED state is off.

Procedure

1. Write handle(text,state) to return the new state and a response message.
2. Process the input list in order and record the state before and after each step.
3. For invalid arguments and unknown commands, preserve the state and return usage instructions.

Results to retain

• A 5-row state transition table and a function.

def handle(text,state):
    if text=='/start':return state,'Commands: /led on, /led off'
    if text=='/led on':return True,'LED on'
    if text=='/led off':return False,'LED off'
    return state,'Usage: /led on | /led off'
state=False
for text in ['/start','/led on','/led off','/led invalid','/unknown']:
    next_state,reply=handle(text,state);print(text,state,next_state,reply);state=next_state

Record results and self-check

Input:

Previous state:

Next state:

Response:

Points to check

• Can you check it through function calls without sending real messages?
• Does the LED state remain unchanged for invalid and unknown?

Repeated commands and whitespace

Starting conditions

Repeat /led on three times, and add ” /led off “ with leading and trailing spaces.

Procedure

1. Check whether repeated commands preserve the state.
2. Define rules for strip and case handling, then compare with the original function.
3. Also choose two inputs to reject, and check that the state is preserved.

Results to retain

• A table with at least 6 inputs and 3 asserts.

tests=['/led on','/led on','/led on',' /led off ','/LED ON','']
# TODO: Compare the handler with normalized input against the original.

Record results and self-check

Input:

Normalization result:

State:

Accepted:

Points to check

• Did you apply consistent command normalization rules across inputs?
• Does repeated on avoid behaving like a toggle that reverses the state?

Separate transport from device logic

Read Week14-2_Telegram_Bot_Command_Handler.py and handle and dispatch in this notebook, and map each role to its function or line in the table. Mark roles absent from the original as 'None' and distinguish them from the test implementation.

Use the provided outbox log instead of sending real messages.

Starting conditions

Organize inputs from the web, messengers, and MQTT as {request_id,device,command}. Do not execute the same request_id again.

Procedure

1. Validate the request ID, device, and command, then pass them to the common handler function.
2. Handle the same request sent twice so that the state changes only once.
3. Record the response and actual state, and draw the request–handling–response flow.

Results to retain

• A role mapping table and 3 rows of simulated transmission logs.

seen=set();outbox=[]
def dispatch(message):
    if message['request_id'] in seen:return 'duplicate'
    seen.add(message['request_id']);outbox.append(dict(message));return 'accepted'
message={'request_id':'r1','device':'fan','command':'on'}
print(dispatch(message),dispatch(message),outbox)
# TODO: Validate invalid device and command values before they enter seen.

Record results and self-check

Role:

Original function and location:

Test substitute:

Observed results:

Points to check

• Can you test the same handling logic without a token?
• Did you check state updates and external transmission independently?