I am working on it right now. I just finished tweaking the dynamic input text to include the fan/pump status. Now I am going back through the ST documentation Groovy Basics to understand better what methods, def updated(), def installed(), etc
I so new to groovy that it isn’t real intuitive in getting my head around it quickly so it is taking me a little while. I gave up last night as it was getting late 
The Updated and Installed methods along with the mode functionality is specific to ST and unrelated to the Groovy language.
Most of the things I’ve helped you with aren’t in the documentation either, but considering that the documentation changes every couple of weeks, going through it again can’t hurt.
Let me know if you have any questions…
Got it all in and it is working!! Thank you sir!
I needed to modify your suggestion a little and add an ELSE so that when it wasn’t in a User selected run mode the Evap Cooler is shut down.
So here is the question… although it works it is it isn’t quite right. It is a very similar to the issue that you fixed with changing setpoints that didn’t do anything originally.
The scenario is the evap cooler has been off while I was out of the house. When I switch from Away mode and go to one of the user selected modes like Home which allows the smartapp to control again the Evap Fan motor isn’t turning ON immediately even though the setpoint is clearly calling for cooling to be turned on.
I am assuming this is because something needs to change even though the room may be super hot to execute the temperature handler?
Is there a way to have the temperature handler evaluate upon a mode change so that it can turn on cooling equipment without waiting for a polled room temperature change?
Subscribe to the mode change event and use the line below again in the mode changed handler.
handleTemperature(tempSensor.currentTemperature)
I think the subscription looks something like:
subscribe(location, "mode", modeChangedHandler)
OK. I am not exactly sure what you are asking me to do here? I made the other changes I think you were asking. Also just for my own learning as I understand the groovy basics do I need to add a line in the def updated() method? I was thinking def udpated() was used somehow when making a change like mode selection?
If it helps here is the link to the GitHub code with my latest changes based on your input.
line 258 is the if (currentModeAllowed(settings.selectedModes)) {
line 304 is the def currentModeAllowed(allowedModes) {
line 184 is the Subscribe to the mode change event
So where is the mode changed handler in the code to make the change you are asking?
Subscribing to a location event works the same way as subscribing to a device event so need to create the handler method the same way you would for any other device.
If you find that the mode change handler isn’t executing, check the documentation because I’m not sure that I gave you the correct syntax.
Installed and Updated Method Explanation
The only time the “installed” method executes is when the SmartApp is first installed. The “updated” method gets executed when the SmartApp is installed and every time you click the SmartApp’s “Done” button.
(I think it’s every time, but it might just be when you exit the SmartApp by tapping the “Done” button)
Recommended Solution for Mode Issue
I’m using “process” as a general term for the code that checks if changes like turning things on/off need to be made and makes them when needed.
Goal 1: Immediately start process when mode is in the selectedModes list and the settings are changed.
You already achieved this goal by adding “handleTemperature(tempSensor.currentTemperature)” to the “updated()” method.
Goal 2: Immediately start the process when mode becomes one of the modes in the selectedModes list.
You can achieve this goal by implementing the “modeChangeHandler(evt)” method and adding the line “handleTemperature(tempSensor.currentTemperature)” to it.
Goal 3: Prevent the process from starting when mode is not in the selectedModes list.
The Updated, modeChangedHandler, and temperatureHandler methods all execute the handleTemperature method so the easiest way to prevent them from starting the process is by wrapping the contents of the handleTemperature method with “if(currentModeAllowed(settings.selectedModes)){”.
If you also want to prevent the temperature change log entries, you can wrap the temperatureHandler method contents, but otherwise it’s not needed.
When motion is detected, it does more than just execute the handleTemperature method so the easiest way to prevent the process from being started is by wrapping the contents of the motionHandler method with “if(currentModeAllowed(settings.selectedModes)){”.
I’m pretty sure that adding the mode checks to the handleTemperature and motionHandler methods and adding calling handleTemperature method from the new motionChangedHandler, as described above, with solve all your problems.