Thank you so much for your advice on programming style. And your reasoning is dead-on. I picked up this style of grouping variables of same type from somebody on this forum who very kindly helped me with a previous project.
Not sure what you mean by saying, "Suggest you look at switch change in state instead of switch level". Am I not switching based on State?
The changes that were made to your last sketch looks for changes in state in your switches.
Try the new changes to see if things are working as you need.
You may want to consider adding a manual mode of operation.
You may want to add a disable switch too.
Interesting how one makes problems for oneself. I actually had the upper level switch wired as NC, (which I think would actually make it behave correctly ). I even have a set of notes to myself justifying both the wiring and coding. And when I tested the app on the bench I actually had the two switches correctly wired, (NC on the top one and NO on the bottom one). But when I took it back out to the greenhouse, and it didn't work, I stopped thinking and started to make stupid changes. Most recently, when I couldn't get it to work, I second-guessed myself and changed the wiring to the top level switch to NO. (I think I was getting tired and frustrated, and just started flailing around) (And, to make it even more stupid, changing the wiring to the upper switch was not a trivial task - I had to drag out soldering equipment, extension cords, and insulation to the greenhouse. )
My God! I did not expect you to go to these lengths to revise my code. (But I am profoundly grateful to you for taking such pains.) I am going to have to spend some time going through everything, and if I really feel that I cannot grasp it, I will ask for clarification. But, for now THANK YOU.
I am going to need to explore this business of state machines vs. simple States. (I got the concept of using States directly from Blackfin, on this forum, a few years ago. And it has worked very satisfactorily on my previous project(s). And I could understand the logic behind it, (which looks to my unsophisticated eye as essentially the same, albeit perhaps simpler.)
I am fascinated by your beautiful circuit diagram. How on earth did you create such a masterpiece? (The motor reversing wiring is actually slightly different from your diagram, and does not use a bridge circuit, but I don't think this matters. And exactly the same simple hard-wired arrangement of relays has been in use in my greenhouse for years, to open and close ventilation flaps. The only problems I have encountered have been when the cheap Chinese relays fail after a couple of years' use, which caused me confusion the first time it happened. But I haven't been able to find any more reliable relays with the opto-isolation to avoid back-currents. And the latest batch has performed flawlessly for 2 years, so now that I know the most likely cause if the sytem fails, it is probably easier (and cheaper) just to replace the relays when, and if, they fail, (after a number of years.))
The diode bridge should be include in your design to snub out the noise generated by the motor’s inductance.
Not having the bridge will result in this noise affecting other electronics near by.
The bridge will also help prevent relay contact pitting.
There are many free schematic capture (PCB) programs available that can produce the same schematics.
EasyEDA and Kicad are two, others can be found on the net.
As I worked through things, I found that I was, in fact, entirely correct in my logic, and both switches needed to be wired as NO., ( The lower level switch is closed by the curtain going down, but the upper level switch is opened as the curtain rolls up and clears it) . But what I did learn from this exchange is how to use a state machine, and modular coding style in writing sketches. And I am most grateful to all who so generously guided me.