Wow... how simple was that :o thank you very much sterretje it has me flying thru my coding... a lot of understanding for a construction guy xD so do I still use the millis for all my other function?
The only thing that needs timing on your list is #4 "When all parameters are within threshold, every hour start aux fan for 5 minutes, then stops". It is the only one that mentions time.
One of the most difficult things for people to learn to do when programming is to come up with a complete and unambiguous specification for the behavior they want. If you've even been frustrated by a hyper-literal person doing what you said but not what you wanted, computers are 100x worse than that. a person can be coerced into compliance with rewards and punishments, but a machine cannot be entreated in such a way.
For those that only see the end result of programmers' efforts, computer controlled systems seem "smart". Those of us behind the scenes (like you are now) come to know just how insanely dimwitted computers truly are.
If I haven't yet scared you off, please keep reading. 
The most important part of coding is often the planning stage. You need to lay everything out on paper. I don't mean type it up, literally write it on paper and draw diagrams and tables if you need to. Thought needs to go into this, and you will most likely be revising some of these things. This is a skill that needs to be developed with practice, so don't be too discouraged if it's difficult at first.
The first part is to explicitly list out the inputs that your logic will be considering, and the outputs they will be controlling. You don't need pin numbers or any specific hardware considerations at this point, just the concepts.
Inputs
Greenhouse air temp: TooHigh, TooLow, JustRight
Humidity: TooLow, JustRight
Time
Outputs
Humidifier On/Off
Heater On/Off
Two-speed fan Off/Low/High
Aux fan On/Off
Now with that listed out, defining your logic comes next. You have a decent start with the list in post #4, but it is not finished. You need to look it over to see if there are any conflicts. For example, what speed should the two-speed be set at if the temperature and humidity are both low at the same time? #1 says it should be low, #2 says it should be high. It's probably impossible for the fan to be both at the same time, so you have a conflict there.
Make a table with each of your outputs as column labels on top (Humidifier, Heater, two-speed fan, Aux fan), and every combination of temp/humidity as the row labels. There are 6 combinations (JR = just right):
- Temp Low / Hum Low
- Temp JR / Hum Low
- Temp High / Hum Low
- Temp Low / Hum JR
- Temp JR / Hum JR
- Temp High / Hum JR
You'll have a 6x4 table drawn out now. For every single one of those combinations, fill out explicitly what every output should be.
The next thing to look for is ambiguity. A human might be able to use their own reasoning and be able to run a fan properly by being told "When all parameters are within threshold, every hour start aux fan for 5 minutes, then stops", but computers are dumb. Suppose the following happens:
- All parameters normal, so the aux fan runs at 2:00 pm.
- At 2:55 pm, humidity drops below level, and takes 10 minutes to go back to acceptable range. Time is now 3:05pm, after the time the aux fan was scheduled to be on.
What do you want to happen here? Turn the aux fan on immediately, or wait another hour until the next scheduled time? If you're ok with waiting, it's possible that the right humidity cycle could keep the aux fan off indefinitely.
Since you only have ON/OFF control of your various devices, you will probably need significant hysteresis built into the thresholds. You don't want to turn the heater on when the temp goes below 28, then immediately off again when it goes above 28. You will want a gap in between those thresholds so that you aren't cycling your heater too much.
The most difficult part of this project has nothing to do with code, it is planning out exactly what is supposed to happen in exactly what circumstances. After that the code is pretty trivial.
relay1State = digitalRead(relay1Pin);
relay2State = digitalRead(relay2Pin);
if (t<=28) {
digitalWrite(relay1State, HIGH);
digitalWrite(relay2State, HIGH);
}
What's even going on here? Why are you reading the output state of the relay pins? Why are you using those states as the pin numbers for digitalRead?