Since all the functionality of the doorDoor simulated simulation is non-blocking, it is possible to have what are essentially two programs making progress with their jobs at once.
So look at it as two programs.
One is, as far as I remember, the code that OP provided and asked for help with.
The other is a simulation of the phyisical circumstances the first program is meant to observe and control.
In order to allow focus on the part that matters (the OP's control program) I used the least possible intrusive means to connect that control program with the door simulator.
So in setup(), the only evidence of the door simulator is the function call so it can do its necessary setup. I could have placed the entirety of that directly in line, but that would be harder to just get over.
Then similarly in the loop() function, there is but one call to the door simulator, to give it an opportunity to push any of its tasks along. Here again I could have cluttered the loop code with all kinds of stuff.
This is a side benefit to using functions. Properly specified and written, they afford an opportunity to make the high level code much easier to read, maintain and enhance.
Above line 120 otherwise is the OP's code. After line 120 is my door simulator. It can be ignored and left to do its job. Or studied for what it is.
You can see some stylistic differences. I use # define. That will always be a part of C/C++, but is considered old fashioned and some feel safer in ways. I will let anyone who cares make the argument; it is unlikely that I will stop using # define. The net effect and main benefit of either is to make one place where manifest constants, or "magic numbers" can be specified.
Normally all those and several other elements would appear in some conventional order. To keep the two programs, or the two main functions of the one program separate, I placed everything I possibly could below line 120, again so there would be less one needed to ignore in studying the main point of the code, the OP's goal to control a door motion as informed by user command and limit switches.
There is also a hardware connection between the control program and the door simulator. Those four white loopy wires are the only hardware logical connection.
Two wires route the simulator's current values for the limit switches to the input pins of the control program. There they are digitalRead()ed by the control program just as if they were hardware switches.
And two wires are outputs from the control program and tell the door simulator program whether and how to run the motor. Again, in real life these (or a computed variation of them) would be hooked to a motor control unit, there to make the door move, or not, and if moving either to the goal of opening the door or closing it.
The neopixel strip merely reports visually the current door position. Note that the door simulator would happily "burn out" the motor, as it is dumb, and depends on the control program to stop driving the motor once the limit switch is arrived at.
The individual LEDs at the upper right hand are wired to, and therefore report exactly, what the control program is asking of the door simulation, even as the individual LEDs at the extremes of the neopixel strip are wired directly to the limit switch outputs.
BTW I used wokwi LEDs which do not need a series current-limiting resistor. 
if (0) {
}
else {
}
looks a bit odd, but it is used here to do either one thing (test) or another (operate). When the value is 0 (false) it is the only else part that runs. If I change that to 1 (true), the commands from the control program are not used. The door simulator becomes a bit smart enough to reverse the motor all by itself when the door gets to the limit switch.
A rewrite that is kinder and gentler would be of the form (pseudocode here)
if the door is going up
add 1 to the position variable.
if the door is going down
subtract 1 from the position variable.
if the door reaches the end of allowed travel
reverse the direction it goes at each step
It uses the C/C++ ternary operator. I think I would have been better advised to strip out the test clause, just in case someone really looked closely. Better to have the door simulator serve only one pupose. The if (0) {} else {} is, now you see, just a way to quickly do one thing or antoher. I tend to leave testing junk laying about - one never knows when it might come in handy. Sadly, many times such testing code becomes invalid. Here, it still works. The door simulator cheerfully ignores all advices and commands coming from the control program.
Just now I noticed making the least change to the code breaks it. This is an issue I will pursue with the boys over at wokwi, a rare defect I feel sure, as I certainly did not publish a broken sketch, nor one that (at the time) was the least fragile.
It seems that adding the Adafruit_NeoPixel and "retrying" a failure in parsing the diagram.json file sets it right.
added: the issue was with wokwi, see Odd failure in perfect old project · Issue #649 · wokwi/wokwi-features · GitHub for details and explanation. As usual Urish is very on top of things keeping wokwi best of them all.
Yes. But the intent was that it be quietly off to the side. I will only say doorBar is the name of the neopixel object upon which plays out the door position.
I see a new post from you, there will be time in my future to take a look. Not just now.
a7
