Чем отличаются настройки wb-mqtt-gpio.conf и wb-mqtt-adc.conf?
Во всяком случае я воткнул счетчик Политех в 5vout, GND и D1 (у меня WB7 где “A1/A2/A3/D1”). работает, конечно, хотя как-то плохо влияет на датчики W1, у которых тот же минус (и плюс, но об этом позже)
В настройках wb-mqtt-gpio.conf я установил, что это счетчик воды, и он ихдает 477000 импульсов на кубометр воды (в бумажке написано 477 импульсов на литр).
И он что-то показывает, причем цифры мельтешат так быстро, что я решил заглянуть в top, и заметил, что нагрузка на процессор удваивается, если в доме открыть кран с водой. Я уж боюсь писать правило на изменение этого регистра.
Может, как-то сделать, чтобы оно считало там где-нибудь внутре в своем демоне, а в mqtt уже шло посчитанное значение, считанное раз в секунду? Может быть, если я переключу на A1, то настройками в wb-mqtt-adc.conf я смогу его успокоить?
Здравствуйте! Я — автоматический помощник техподдержки Wiren Board.
Сейчас нерабочее время — я постараюсь помочь сразу, а в ближайший рабочий день
инженеры посмотрят тему и ответят.
Перенос на A1 с настройкой wb-mqtt-adc не решит задачу: этот сервис измеряет напряжение, а wb-mqtt-gpio обрабатывает дискретные состояния и считает импульсы. Это разные способы обработки входа, а не два варианта настройки одного счётчика.
В проверенном коде wb-mqtt-gpio после обработки событий входов обновляются значения MQTT-каналов. Подсчёт уже происходит внутри демона, но отдельного ограничения «публиковать накопленное раз в секунду» в проверенной конфигурации я не нашёл. Поэтому рост нагрузки при появлении потока импульсов объясним; какой процесс даёт основной вклад, нужно посмотреть отдельно.
Что можно сделать сейчас:
Проверить выбор фронта. На скриншоте выбраны оба фронта. Если указанные в паспорте 477 импульсов/л — полные импульсы сигнала, следует считать один фронт: передний либо задний. Иначе получается двойной счёт. Коэффициент 477000 импульсов/м³ при подсчёте одного фронта соответствует вашим паспортным данным.
Уменьшить число десятичных знаков, например до 3 для обоих показаний. В коде счётчика значения округляются перед передачей в MQTT: это может сократить число меняющихся сообщений, но не устраняет обработку самих импульсов и не задаёт период в секунду.
Для правила в wb-rules можно использовать периодический таймер вместо реакции на каждое изменение. Это ограничит частоту выполнения правила, но не нагрузку самого счётчика.
Пришлите, пожалуйста:
релиз и версию пакета:
cat /etc/wb-release
dpkg-query -W wb-mqtt-gpio
какие процессы растут в top и их проценты при закрытом и открытом кране;
что именно происходит с W1: ошибки чтения, исчезновение датчиков или неверные температуры? Приложите также модель/страницу паспорта Политех с питанием и характеристиками выхода — влияние общего питания пока не стоит смешивать с нагрузкой CPU.
Примечание: я — ИИ-ассистент, а не сотрудник-человек; в ответе возможны неточности. Если пришлёте уточняющие данные/логи, я смогу проверить гипотезы точнее.
в общем-то растет больше всех wb-rules c ~45 до 120 - 150%, хотя я лично пока ни одного правила не написал. а так-то растут и остальные:
main с 16 до 50, mosquitto с 6 до 20, ну и вылезает wb-mqtt-gpio, который ест 13%, а с закрытым краном - 0,6%
я пробовал разные фронта, мне показалось, что с двумя он точнее отмеряет литр (ведь бумажка для настройки политеховского контроллера, кто знает, как они там считают).
знаков столько много, потому что охота видеть литры, а не кубометры. в правиле хотел в литры переводить
ой не стоит смешивать темы - не получу ответа ни по одной там свои заморочки: датчики 1w у меня вообще не питаются с щита. видимо, там такие дикие наводки и паразитное питание, что подключение 5в делает только хуже. в итоге от них только минус заходит в клемму gnd. там явно что-то происходит и лучше пока об этом не думать
По вашим замерам основная добавочная нагрузка — не сам подсчёт импульсов, а, похоже, обработка потока обновлений потребителями MQTT. Поэтому правило с таймером само по себе проблему не решит. Зависимость нагрузки от частоты публикаций также отмечалась в похожем обсуждении. Но почему у вас wb-rules уже без расхода занимает около 45%, пока не установлено.
Предлагаю один показательный тест: временно выставить 3 десятичных знака у суммарного показания и 2 у текущего расхода, затем сравнить нагрузку при примерно том же потоке воды. Это не период публикации, но округление должно уменьшить число изменяющихся значений.
Здесь уточню предыдущий ответ: 0,001 м³ — это ровно 1 литр, то есть три знака сохраняют литровое разрешение суммарного показания. Шесть знаков дают уже миллилитровое разрешение. Перевести отображение в литры правилом можно, но потерянные при округлении доли литра такое правило не восстановит. В коде счётчика округляется выдаваемое значение, а внутренний счёт импульсов сохраняется.
Фронты на время этого теста оставьте как есть, чтобы не менять несколько условий одновременно. Без паспорта именно вашего датчика нельзя уверенно утверждать, как изготовитель определил свои «477 импульсов».
Напишите, насколько изменится нагрузка после округления. Если требуется сохранить мелкое разрешение и при этом выдавать данные строго раз в секунду, это уже задача ограничения публикаций в драйвере, а не перевода единиц в wb-rules; подтверждённой настройки для этого я пока не нашёл.
Примечание: я — ИИ-ассистент, а не сотрудник-человек; в ответе возможны неточности. Если пришлёте уточняющие данные/логи, я смогу проверить гипотезы точнее.
ну это потому что я много других правил понаписал, тут вопросов нет. работает уже долго, вроде норм.
да, стало полегче. кажется, у wb-mqtt-gpio такие же значения, а вот wb-rules с открытым краном уже стал меньше 100%
они такого документа не вложили
наверно было бы неплохо добавить.
с другой стороны, я даже не уверен, что эта штука не пропускает импульсы и честно считает их все. хотя current все время скачет, хотя вода течёт равномерно. открывал только один кран в доме.
миллилитров я хотел, чтобы регистрировать возможные мелкие протечки, когда все краны закрыты. неплохо было бы иметь миллилитры, но не отображать их, а считывать даже раз в полминуты. если набежал миллилитр за полминуты - уже все ясно
Понял, фоновую нагрузку wb-rules тогда не исследуем. Снижение нагрузки после округления подтверждает, что существенный вклад даёт обработка обновлений, а не только подсчёт импульсов.
Для вашей задачи действительно нужны редкие публикации точного накопленного значения, а не округление до литров. Но здесь есть два отдельных ограничения:
Скачки current сами по себе не доказывают пропуск импульсов. В коде wb-mqtt-gpio расход вычисляется по интервалу между событиями, а не как средний за полминуты. При подсчёте обоих фронтов интервалы высокого и низкого уровней могут различаться — тогда показания будут колебаться даже при постоянной частоте.
Шесть знаков на экране не означают чувствительность датчика в 1 мл. При 477 полных импульсах/л один импульс соответствует примерно 2,1 мл. Главное же — минимальный расход, при котором датчик вообще начинает выдавать импульсы. Без этой характеристики нельзя рассчитывать на обнаружение 1 мл за 30 секунд: при столь малом потоке датчик может ничего не зарегистрировать.
Предлагаю два следующих шага:
Для проверки колебаний временно выбрать один фронт и сравнить стабильность current. Точность суммарного учёта проверить проливом известного объёма при двух разных расходах. Это практическая проверка, но не доказательство отсутствия пропусков: для строгой проверки нужно сравнить число импульсов на входе с независимым счётчиком или логическим анализатором.
Как временный компромисс — вернуть 6 знаков только суммарному показанию, оставив 2 у текущего расхода, и сравнить нагрузку. Правило затем может проверять прирост суммы раз в 30 секунд, хотя публикации исходного канала от этого реже не станут.
Пожелание к драйверу получается конкретное: считать каждый импульс, но публиковать накопленную сумму с настраиваемым периодом, независимо от её точности. Это разумная доработка; наличия такой настройки или регистрации задачи я пока подтвердить не могу.
Примечание: я — ИИ-ассистент, а не сотрудник-человек; в ответе возможны неточности. Если пришлёте уточняющие данные/логи, я смогу проверить гипотезы точнее.
проверил; при “капающем” или “немного текущем” кране их турбина вообще, видимо, не вращается, либо я уже его грязью забил. так что ставлю 1 знак для текущего и 3 для суммарного, будет просто график пользования ванными, как датчик утечки штука не работает.
публиковать с периодом и накопленную сумму, и скорость (ее даже легче будет считать). может пригодиться, если и не для этого датчика, то для других
Да, периодическую публикацию стоит предусмотреть для обоих каналов, а не только суммы. Пожелание к wb-mqtt-gpio можно сформулировать так:
Считать входящие импульсы непрерывно, независимо от периода публикации.
Публиковать накопленный объём и расход с настраиваемым периодом, сохраняя отдельно настройку точности.
Расход рассчитывать как средний за интервал: прирост объёма / фактически прошедшее время, а не просто реже отправлять последнее мгновенное значение. При отсутствии импульсов за интервал средний расход будет нулевым.
Это уберёт зависимость частоты MQTT-обновлений от частоты импульсов, хотя затраты на обработку самих входных событий останутся. Это именно предложение доработки, не существующая подтверждённая настройка; задачу в трекере я не создавал.
Для графика пользования водой ваши 1 знак у расхода и 3 у суммы — разумный компромисс. А проведённый тест показывает, что в вашей установке полагаться на этот датчик для обнаружения капельной утечки не стоит; причину отсутствия импульсов он сам по себе не устанавливает.
Примечание: я — ИИ-ассистент, а не сотрудник-человек; в ответе возможны неточности. Если пришлёте уточняющие данные/логи, я смогу проверить гипотезы точнее.
Для подсчёта импульсов с такой частотой можно использовать модуль счётчиков импульсов WB-MCM8: Модуль дискретных и счётных входов WB-MCM8 - Wiren Board . Он считает импульсы сам, а контроллер опрашивает его по Modbus с заданным периодом, поэтому частота обновлений в MQTT не зависит от частоты импульсов. Максимальная измеряемая частота входа модуля — 3,1 кГц (при обнулении параметра антидребезга).
Ваше пожелание по периодической публикации суммы и расхода в wb-mqtt-gpio внесу в пожелания разработчикам.
Добрый день.Обратите внимание что количество импульсов в паспорте указаны при максимальном расходе.Зависимость количество импульсов от расхода не линейна.Адекватно считать потребленный расход по одной константе импульсов не получится.Обрабатывать этот расходомер как счетчик с импульным выходом не получится.
попробовал первым делом, та ведь там три провода, ему питание нужно, и он сам испускает импульсы, а не замыкает там что-то там. я ж читал форум, вы предлагали оптрон, но у меня уже глаза не видют такую мелочь соединять
Здравствуйте! Спасибо! А известна зависимость? Было бы интересно
я уж заметил, довольно неудобная штука.
мало того! вот пока считаю с константой. Даже если нелинейная, но я открыл два крана и скорость стала меньше! или WB перестал успевать, или зависимость там бывает и обратная
ДУ20 2-45Л 477имп_Л.xlsx (15,0 КБ)
В свое время измерял свой. У меня в паспорте был указа макс.расход 45 л/м, а сейчас 3/4 вроде как 65 л/м.
Бросьте это дело на WB считать. Если Вам нужно просто наличие расхода, то имеет место быть. Корректно на WB не сможете обработаь импульсы в расход. Надо использовать аппаратное прерывание и аппаратный таймер.Тогда после тарировки можно что то сноное получить.
спасибо, вот это Вы работу провели! а к чему подключали (MCM8, вход реле через транзистор, или как) и сравнивали с официальным счетчиком, да? очень интересно. в бумажке (которую я бы и паспортом не назвал) в графе “расход воды” написано “2 - 40 л/мин”, то есть они даже не обещают считать, если потоК меньше 2 л/мин
По нагрузке CPU. В обоих архивах wb-rules держит около 50% CPU постоянно, не только при открытом кране — это общий объём MQTT-трафика от всей вашей автоматизации, а не только от счётчика воды. Между архивами (10 минут, в том числе тест с двумя кранами) заметного всплеска нагрузки не произошло. Также обнаружили: в конфигурации есть канал A1_IN с типом «счётчик воды» и точностью 6 знаков, но импульсов на нём нет ни разу за всё время логов — похоже, физически ничего не подключено. Если это так, лучше удалить канал.
По падению скорости при двух кранах. Диагностический архив — это снимок состояния контроллера на момент сбора, а не история публикаций в MQTT, поэтому подтвердить или опровергнуть само падение current по нему нельзя. Чтобы это проверить, нужна история значений канала во времени. Проще всего через SSH:
(подставьте реальный топик устройства) — запустите перед тестом и откройте краны по очереди. Если значение резко проседает именно в момент открытия второго крана — это будет видно в выводе по меткам времени. Пришлите, пожалуйста, несколько строк вывода вокруг этого момента. Это если вам еще интересно, поскольку, как я понял, вы уже подтвердили нелинейность зависимости.
собрал установку вертикальную. кран, обычный счетчик воды и за ним расходомер. Импульсы считал контроллером Овен.
Я тоже сначало думал что все так просто. В итоге на ардуино запил и по RS485 читаю расход. То что указан мин.расход это норма, у всех есть минимальная планка, ниже которой не считается расход.
там свои заморочки: датчики 1w у меня вообще не питаются с щита. видимо, там такие дикие наводки и паразитное питание, что подключение 5в делает только хуже. в итоге от них только минус заходит в клемму gnd. там явно что-то происходит и лучше пока об этом не думать