Hi again.<br><br>I understand what you are saying and I guess the real problem comes down to my (mis)understanding.  The fsm object, as written, isn&#39;t a state machine -- rather it&#39;s a composite state.  The fsm object itself represents the outer shell state, and the states inside the fsm represent the submachine.  This is very clear when using a fsm as a sub-state-machine, but not so clear from the top level.<br>


<br>Now that I better understand what&#39;s going on, I can see that you implmentation is indeed fully correct, it&#39;s just confusing to me because of nomenclature.<br><br>I guess if there were any change, it would be to rename fsm&#39;s to &quot;composite_states&quot;, and then write in the documentation that the top-level FSM is always composed of a single composite_state which you call directly, as the only difference between a composite state and an fsm is that an fsm would not normally have an entry and exit action.<br>


<br>This is even more clear when I note that having an entry action on both the FSM and the initial state &quot;seems redundant.&quot;  And it is, but only for the top-most level composite state.  For composite state embedded in other machines, history could cause the entry action on the composite state to be called, but the not the entry action on the (normally) initial state.<br>


<br>As it seems too late for a change of  that magnitude, I&#39;ll just have to content myself with a better understanding of what&#39;s going on...<br><br>Thanks for taking your time to help.<br><br>-Chiem<br>