OK, that's the trouble with the tiny window. I saw
case JAMMED_OPENING:
openProximity = digitalRead( openProximityPin );
if ( openProximity == LOW ) {
and misunderstood. If you think about it (I see) the only way to get into JAMMED_OPENING is if the proximity switch caused it to in state OPENING. Therefore checking that again, no matter if you digitalRead() the pin or use a variable, is redundant. You immediately exit the state for CLOSING, so it's not like you need to refresh.
In fact what would mean finding the proximity switch no longer complaining? You'd be stuck in that state… until?
I believe a similar point could be raised for JAMMED_CLOSING.
It may not matter, but a good thing to do is to ferret out things like this, which can unnecessarily increase the amount of code. Code your readers must read, code you yourself might wonder one day. I was mislead, thinking you had some reason to check the switch and came to a bad conclusion. The more the code makes sense through the tiny window (!) the better you are doing.
You have made good work with this, I dare to say before I have taken a low level flight about the latest.
You may like to relax with another thread where the idea of a state diagram is brought out and explored:
Post #12 has a diagram and shows how the state bubbles work and how the transistions are labeled.
As for functions, nice! Please post your latest working version when you feel it is ready, that is what I will spend any time I have. Beach yes, and just now up to my elbows in paint doing some work on the crib. A different kind of fun.
a7