gfvalvo:
Highly unlikely. If you use the noInterrupts() / Copy / interrupts() technique, interrupts will only be off for a handful of microseconds.
Less than two in this case I'd estimate. So you would need to get two interrupts on a particular interrupt vector in that time to cause you a problem.
MaxG:
Is it then possible that the non-blocking function coincide with the ISR?
Of course, but it shouldn't matter. Except that your ISR is the function called meter_pulse_counter_isr. I think you're using ISR to mean the function called meter_values_calculate.
... considering these are set to occur at round seconds, e.g. 5 10, 15.
I assume they could occur all at once, say at 30 seconds the 5 10 and 15 occur, plus the ISR every second, also occurring at 30 seconds.
They won't all occur at once - the Arduino is single threaded. Even if they are all due because of the time, they will be executed one at a time.
...pulse_count_isr, CHANGE); // would double the resolution
I wonder why you use potentially problematic interrupts for a slow water meter.
Polling (testing for pin change) could be good enough, assuming loop time is less than sensor change.
Reboots when the pump is running could be supply related, and supply caps can go bad over time.
What are you currently using.
Leo..
As for the questions: What was changed?
Nothing! The thing ran for almost three years without a problem; two weeks ago it started randomly resetting the counter to 0 mid valve open.
So… while you may improve this program and get it on a better footing for the future, you must first figure out what (not nothing) has changed w/ your hardware setup.
Try running just a UNO with the simplest possible additions, KEDs and switches only. On a battery power supply. No long wires. It will probably work.
Thrn start looking at what can happen to real electronics after years. You may even have something wild like mains glitches &c. Or a new microwave oven. Or… something, not nothing.
Take a dram of whatever you use, these problems are the hardest. At least it’s manifesting regukarly, add “once in a while” to the observation and you’re really in the soup.
a7
:o Thank you for all your input.
I have attached an image of the controller.
It sits in the paddock, connected via 50m of Ethernet to a building, with the cable buried in the ground.
There are two other controllers (gate and tank), which use this connection w/o problems.
While the controller has a toroidal transformer, it is solely used for the 24V solenoid valves... switched via relay board, with an RC combo over the contacts. There is a switched power supply under the relay board for the 5V the electronics need.
As I said, nothing has changed with the set-up.
My interest in posting here was to make sure that my program is at least correct.
I have since reduced the lengths of some variables that were longer than 31 chars (my self-imposed/standard limit is 28); corrected the 5 second flow_counter pull/copy back to 1 second... and have the option to use either detach/attach or noInterrupts/interrupts.
I will upload this code (attached); if it still has problems, then I change the Ethernet shield, then the power supply.
BTW: the issues do not coincide with valve changes (open/close).
I have chosen to use an interrupt as the pulses can come in at a frequency of up to 300 Hz.
main.cpp (42.7 KB)
config.h (2.74 KB)
To close off this topic...
I went through the code with a fine tooth comb and changed two things:
[litCorrected the itoa function parameters; the third parameter was a non-related variable, rather than a base, here 10][/li]
Not sure, which one fixed, but the controller is now running stable for the last four days.
Thank you for all your input... as one said: the problem is most likely where you're not looking. 
And so it was.
The program also got improvements, such as reduction of global variables and other code style cosmetics.
