Между +5 и А4 подключен счетчик воды с импульсным выходом (1 импульс на 10л).
Конфигурация сделана через веб интерфейс, в файле так:
{
“decimal_points_current” : 2,
“decimal_points_total” : 2,
“edge” : “rising”,
“multiplier” : 100,
“name” : “A4_IN”,
“type” : “water_meter”
}
],
“device_name” : “Discrete I/O”
Если вывести на один график напряжение входа и сумму, которая уходит в топик, то видно, что не все импульсы учтены и в целом не понятно как график с суммой зависит от импульсов. В результате посчитанное отстает от показаний счетчика.
Добрый день! Проверить удалось.
Теперь, как мне кажется, подсчет импульсов опережает показания счетчика. Возможно, в алгоритме дребезг контактов не учтен или что-то подобное.
Было бы здорово, если бы алгоритм подсчета учитывал производительность насоса (коль речь о счетчике воды).
К пример, если производительность насоса 3 м.куб в час, а счетчик даёт один импульс на 10л, то переход от нуля к единице и возврат к нулю на выходе не может происходить быстрее чем за 12 секунд. Поэтому, если переход 0 → 1 → 0 (при подсчете по фронту импульса) случился быстрее, то его не нужно учитывать.
Понаблюдаю еще пару дней для уверенности, потом отпишусь. Но точно стало лучше чем было. Пожалуйста не закрывайте пока.
UP0209: убедился, счетчик импульсов опережает показания прибора учета где-то на 25% для моих условий. Предположительно учитывает слишком короткие импульсы типа дребезга контактов или помехи. Понятно, что даже требующий учета импульс может быть не виден на графике напряжений в силу разрешения этого графика по горизонтали (в csv выгрузке тоже не видно), но вот глубокой ночью с 3 до 6 вряд-ли был разбор воды… Провод у меня чуть меньше 3х метров, не знаю можно ли выше 3х вольт помехами собрать на такой длине.
Переключил, расскажу что получилось.
UP: Рассказываю. Режим “both” приводит к тому, что учитывается оба фронта импулься. Т.е. результат теперь нужно делить на два (или указывать необходимое на кубометр количество импульсов в два раза больше, чем в паспорте прибора учета). Кажется погрешность тоже должна удвоиться Понаблюдаю.
Предположу, что ваш лабораторный эксперимент не слишком похож на реальную эксплуатацию (импульсы короткие, к примеру, коль у вас поток в 300+ кубов в час, или счетчик не останавливается в 1 на всю ночь). Также предположу, что закорачивание входов может влиять на шум (не знаю).
Зато ваш эксперимент подтвердил, что в режиме “both” считает X2 и надо делить пополам (можно в доку добавить).
В моих условиях режим “both” работает с приемлемой точностью при делении на два, а по фронту с приемлемой точностью не считает.
Как бы цели что-то доказывать у меня нет, тем более что проблему удалось решить. Даже дважды удалось (открыл для себя esp32 с счетчиком импульсов “из коробки” с аппаратным подавлением дребезга контактов и настройкой длины импульсов, которые не нужно учитывать). Надеюсь текущий алгоритм из testing всех устроит.
ЗЫ: Не очень понятно, почему у Вас на картике поток так отличается при закорочнных входах.
ЗЫ2: Я когда руками (вместо счетчика) контакты замыкал, у меня тоже всё отлично считало, причем любым из способов.
Да, “both” подсчитывает два фронта. “rising” - только передний, “falling” - только задний. Это указано в интерфейсе при настройке.
На поток можно не ориентироваться в этом эксперименте, так как импульсы были достаточно редкие - примерно 1 в 20-30 секунд. Важно, что их подсчет теперь работает. Пока оставлю этот счетчик и понаблюдаю.
Понаблюдаю.