управление 2 датчиками и 3 насосами с помощью millis

Это подразумевается как дополнение к ответу Мишеля Кейзерса. Я полностью согласен с его оценкой: дублирования кода следует избегать, так как это сильно вредит ремонтопригодности. И я сочувствую ему, чувствуя желание реализовать это как правильный класс. ;-)

Однако я бы сказал, что между упрощенной версией кода OP и полностью объектно-ориентированной версией этого ответа есть промежуточный шаг, на который стоит ориентироваться как на следующую вещь, которую нужно изучить. Я имею в виду массивы и циклы.

Многие случаи дублирования кода следуют примерно такой схеме:

// В верхней части скетча:
some_type data0 = some_value;
some_type data1 = some_other_value;
// и так далее.

// Внутри функции:
do_lots_of_stuff(data0);
do_lots_of_stuff(data1);
// и так далее.

где do_lots_of_stuff() может быть большим количеством кода, а не одним вызовом функции (и это действительно было бы не так уж плохо, если бы это был просто вызов функции).

Простое решение такого рода дублирования кода состоит в том, чтобы поместить переменные в массив и обработать их, прокручивая массив:

// В верхней части скетча:
const int data_count = ...;
some_type[data_count] = {some_value, some_other_value, ...};

// Внутри функции:
for (int i = 0; i < data_count; i++)
    do_lots_of_stuff(data[i]);

Вот моя попытка применить эту технику к коду OP. Обратите внимание, что, поскольку для каждого насоса существует несколько переменных, нам нужно несколько массивов:

const int pump_count = 3;
const uint8_t pump_pins[pump_count] = {5, 6, 7};
const uint32_t pump_half_periods[pump_count] = {1000, 2500, 3200};

uint8_t pump_states[pump_count];  // НИЗКИЙ или ВЫСОКИЙ
uint32_t pump_last_actuations[pump_count];  // время в мс

void setup() {
    for (int i = 0; i < pump_count; i++) {
        pinMode(pump_pins[i], OUTPUT);
    }
}

void loop() {
    unsigned long now = millis();
    for (int i = 0; i < pump_count; i++) {
        if (now - pump_last_actuations[i] >= pump_half_periods[i]) {
            pump_states[i] = (pump_states[i] == HIGH) ? LOW : HIGH;
            digitalWrite(pump_pins[i], pump_states[i]);
            pump_last_actuations[i] = now;
        }
    }
}

Это устраняет все дублирование и должно быть проще в обслуживании и отладке.

Как только вы освоитесь с этой концепцией, я бы сказал, что следующим шагом с точки зрения построения абстракций будет объединение всех данных относительно одного насоса в структуру. Тогда у нас был бы один массив (элементами которого являются структуры) вместо набора массивов:

// Структура данных, описывающая насос.
struct Pump {
    const uint8_t pin;
    const uint32_t half_period;  // полупериод в мс
    uint8_t state;               // НИЗКОЕ или ВЫСОКОЕ
    uint32_t last_actuation;     // время в мс
};

const int pump_count = 3;

Pump pumps[pump_count] = {
// pin, half-T, state, last_actuation
    {5, 1000, LOW, 0},
    {6, 2500, LOW, 0},
    {7, 3200, LOW, 0}
};

Тело setup() и loop() будет очень похоже на предыдущую версию, но с pump_pins[i] заменено pumps[i].pin и так далее.

Третьим шагом на лестнице абстракции было бы встраивание кода, который обрабатывает структуру данных, с самими данными в классе, как показано в ответе Мишеля Кейзерса. При правильном определении методов основной скетч можно свести примерно к следующему:

#include "Pump.h"

Pump pumps[] = {
    Pump(5, 1000),
    Pump(6, 2500),
    Pump(7, 3200)
};

void setup() {
    for (Pump &pump : pumps)
        pump.begin();
}

void loop() {
    for (Pump &pump : pumps)
        pump.process();
}

Я перепробовал все эти методы, и оказалось, что первый (с коллекцией массивов) использует наименьшее количество строк кода, а последний (с классом) - наибольшее. Тогда можно было бы задаться вопросом, зачем использовать более продвинутые абстракции, если они увеличивают объем кода, который нужно ввести. Причина в том, что эти абстракции становятся полезными, когда программа усложняется. Вы можете собрать весь код, который имеет дело с насосами, в одном месте (возможно, в отдельном файле), весь код , который имеет дело с датчиками, в другом месте... и главный скетч, который объединяет все части вместе, остается простым.