I don't see any change here. How does this function get called? I don't see the function being used anywhere - nobody is calling it. I think it should be called by Messaging.c when a UI confirmation msg is received.

I thought we'd removed the first 3 states. Isn't install state the first state? Maybe Praneeth did that and it will show up when you merge staging into your branch.

171

Is this too early to tell DD to start? Ask Vinay.

Initialize post treatment too.

Delete this. No treatment params mode in Leahi.

Add blank line between declarations and code.

I would keep this stuff commented out until disinfection is implemented.

Door already not required. Remove.

break into 2 lines.

Let's comment remaining states for now.

Remove this line. There is no syringe detection.

Door is probably not required to be closed in standby. Change to FALSE.

Let's remove this for now.

Service record not yet available. Comment out with TODO

INVALID_REQUEST_FORMAT

I think we can do this check now, right?

Change reject reason to DD_BUSY.

Change reason to FP_BUSY

Fix reject reason name (not filter temperature?)

Add a TODO

Use structure instead of U32.

Make a structure for initiate treatment request payload (with 1 U32 in it) and use structure instead of U32.

Who is calling this function? Should be coming from UI, right? So should be a message handler (returns BOOL, takes a message as param, function is in table at top of Messaging.c).

Need to set state to preload state I think. Otherwise you will go to interrupted state.

Why did you remote call to init function here? Is it initialized somewhere else?

Use ternary operation to assign TRUE or FALSE explicitly.

This is at end of enum list above. So it should be at end of table here.

What alarm is this? It doesn't look like you've added a new alarm. This is one of the reserved (unused) alarms that UI s/w might use.

Do we really need these setup functions for each state? They all look very simple - just 1 or 2 lines of code.