Hi unsal,
I tried to compile your ocde but you are using a different LiquidCrystal_I2C.h-library with different methods.
Where does this library come from?
How about using the hd44780.h library?
Pretty long code. it would be very hard for me to analyse your code with variable names written in your native language.
Take a look if there exists a subforum with your native language. Or translate everything to english.
I estimate there are only a few persons who enjoy doing this translation for you.
If you use a terminal-software that can save the received messages into a file on your hardsisk this will enhance your possabilities to search for the bug. In this way you could add a lot of serial debug-output. It doesn't matter if this file grows to a size of 100 Mbyte. If the debug-output does clearly state where the output was sended from you can trace back to the exact point. Of course this needs some analysing how to create debug-output in such a way that finding extreme situations can be done by searching for specific words or expressions and not reading through 10000nds lines of log-output
How about a second arduino that runs a pretty small program that does nothing more than measuring temperature and humidity and can give an alarm and shutoff your heating or humifier if values go beyond allowed limits?
Any professional device that uses a heater has security add-ons to shut down the device in case of a major malfunction
where the main control-unit fails.
If this second arduino is connected to a free IO-pin of your first you could log the status of this IO-pin and in case of an alarm indictated through the IO-pin-status changed this will give hints what is happening.
As a general advice: any code should be developed in a certain manner: Add one thing and then test for all circumstances that can occur and even test for circumstances you don't believe that they can occur.
If some if-conditions do testing for a value-range even test if the values go below or above the expected value-range and add precautions if the values go out of the expected range.
I prefer using onewire-sensors type DS18B20 over NTCs. They are at medium costs (2 Euro per piece) and avoid all the difficulties than can occur with using analog temperature-sensors with EMV. They have an accuracy of 0.5°C.
Though they have their own limits.
You can't use them with very long wires (exceeding 5m) or if you want to you have to add electronic ´s to make the bus-communication reliable.
You have defined some function but there is still pretty much code inside the main loop()
I prefer dividing the code in pretty small functional units. I define a function for each functional thing and this function does only one thing. If there is a second, thrird, forth,... etc. thing it will be defined it its one function.
Then every single function will be tested throroughly even for the craziest sitautions until it is working reliable.
Then and only then I go on with the next small function. In the end this approach safes a lot of time.
Determing the temperature needs a lot of complex calculations but you do no range-checking of the result for plausability. This might hide a bug. But I don't know.
For the use of NTCs I would prefer a table with ADC-values and their corresponding temperature-values over a such a complex calculation. This table hasn't be too big. maybe in 5K-steps. Inbetween a linear approximation will be precise enough. If these NTCs are very inlinear throw them away and replace them with something like a PT1000 or KTY.
As I already wrote I prefer digital onewire-sensors DS18B20.
best regards Stefan
kulucka_v3_manuelzamanMEGA_sdcard_kosan.ino
