Can we combine this state with prior state? Wait for DD response and mode change in same state?

Only need second condition I think.

This should be switch on requested selection and, in each case, we set next state to wait for disinfect state and set the appropriate command (if not skip) or set next state to wait for treatment (if skip).

I think this should be more general start disinfection function that takes a specific disinfection command enum as a parameter.

Shouldn't this be UI REQUEST message? Why would we need to receive/handle a message that we send?

Do we need to send UI a response? Accept/reject?

Is this a message handler? If so, parameter should be a message and option should be extracted from message payload.

Does this command cause DD to transition to standby? It looks like the command to give when we transition into post treatment mode to tell DD to transition to post-gen dialysate mode.

Switch not needed here. Just signal standby mode with the received selection.

Should be disinfection selection type, not command type.
Also, move this down into if statement scope.

Why are we signaling a command to standby mode? We should signal the selection that we received from UI. Standby mode (later when we get there) will then look at the selection and decide there which command to send to DD.

Remove blank line.

Won't this happen when we transition to auto-eject state? Why do it here?

Shouldn't auto-eject state handle this BP homing?

Why are we worried about "handled"? Once confirmed, should we just go to auto eject state?

Why is this if statement separated from the one above? Why not just do this stuff in that if statement?

There should be function(s) in DDInterface to tell DD what we want (bypass, Qd, etc...).

This publish code should be in a publish function and we just call that function here.

Add comment to right.

Why is this above the definitions banner?

This signal function looks like a message handler. If so, it should take a message (like handlers below) and get the option from the message payload.

Needs comment to right.

Is TD going to request active cooling or is it going to happen automatically after heat or heat+citric disinfection completes?
You have an enum of heat disinfection commands, so why do we need separate messages for each disinfection? Should just be 1 message to start a disinfection with a command enum as its payload.

Why are we commenting this out?

Magic number. Make a #define.
Should this command be sent here or in transition function of pre-tx mode?

Why are we ending air trap control here?

Why is this commented out?

Add one more blank line before test support banner.