Комментарии 136
Круто :) Всегда мечтал чтобы коммуналка оплачивалась сама собой !) Но мне кажется, что не стоит дублировать механизм счетчика в ардуино, тем более, как правльно было замечено, могут быть перебои в подаче электричества. Почему-бы не поставить инфракрасные диоды и камеру, подцепить все это добро, например, к тому же ардуино и делать фотографии раз в минуту (или реже), а на сервере натравить на фотки OCR и полученные значения писать в БД.
Уже был такой пост, только счетчик был газовый. Но там была камера и OCR.
Только хотел написать, что вебкамера и фонарик как-то проще =)
слабо маштабируемо… представь себе 6 камер и 6 фонариков… а еще камере нужно расстояние для фокуса, а если счетчик впритык к крышке?
Чтобы небыло фигни с пропущенными импульсами — счетчик должен быть аппаратный с резервным питанием от литиевой батареи — например, 561ИЕ10(или её аналоги) — а уже контроллером с питанием только от сети считывать состояние счетчика, вычислять приращение и скидывать данные на сервер. Причем контроллер можно включать раз в сутки, счетчик может обеспечить автономность счета до 255 импульсов, а это 255 кубов воды между считываниями без потери данных.
Чтобы небыло фигни с пропущенными импульсами — счетчик должен быть аппаратный с резервным питанием от литиевой батареи — например, 561ИЕ10(или её аналоги) — а уже контроллером с питанием только от сети считывать состояние счетчика, вычислять приращение и скидывать данные на сервер. Причем контроллер можно включать раз в сутки, счетчик может обеспечить автономность счета до 255 импульсов, а это 255 кубов воды между считываниями без потери данных.
А ещё в счётчике, помимо резервного питания, должен быть резервный канал связи либо EEPROM что бы накапливать не отправленные значения.
Не нужен, если не нужны моменты времени то счетчик себе будет считать… чего его сохранять-то? Как появится напряжение так и будет обработана разница между предыдущим отправленным и текущим, лишь бы эта разница не превышала 255 единиц(для 8 бит счетчика).
Лично мне было бы интересно видеть статистику расхода воды в течении дня.
Ах да, ещё и RTC нужен :)
Ах да, ещё и RTC нужен :)
Часто бывает потеря электричества на целый день? Ну, подумаешь местами на время отключения света статистика будет несколько сглажена, зато скольких проблем удастся избежать. Другое дело конечно если вы педант и даже такая мелочь вас беспокоит… тогда да, потраченные ресурсы скорей всего будут оправданы.
1 импульс счетчика = 10 литров.
255 импульсов = 2 550 литров, это не 255 л.к.
255 импульсов = 2 550 литров, это не 255 л.к.
Можно раз в год(!) глазами посмотреть и сверить показания.
Если за это время (из-за перебоев) накопились какие-то расхождения между показаниями и подсчитанными импульсами, ничего страшного не случится, можно разницу оплатить и потом.
Если за это время (из-за перебоев) накопились какие-то расхождения между показаниями и подсчитанными импульсами, ничего страшного не случится, можно разницу оплатить и потом.
Поддерживаю
В определенный момент выяснил, сколько в среднем мы потребляем, поэтому показания вношу ежемесячно по среднему, а раз в год — визуальное снятие показаний и коррекция.
В определенный момент выяснил, сколько в среднем мы потребляем, поэтому показания вношу ежемесячно по среднему, а раз в год — визуальное снятие показаний и коррекция.
Тоже так делал, но в последнее время слишком не равномерно стали мы жить в квартире.
Да и момент статистики в данном решении тоже интересен. Теперь я знаю сколько какой воды тратит тот или иной член семьи в душе или сколько «стоит» принять ванну. :)
Да и момент статистики в данном решении тоже интересен. Теперь я знаю сколько какой воды тратит тот или иной член семьи в душе или сколько «стоит» принять ванну. :)
К сожалению, тоже так думал, пока как-то раз пол года не сдавали показания на съемной квартире, а когда нужно было съезжать заплатили 22к (да, именно 22к за 6 месяцев на 4х людей) из-за того, что протекал бачок унитаза и никому до него не было дела…
Наученный опытом, я бы не отказался от такой автоматизации, т.к. теперь каждый месяц тщательно слежу за расходом :)
Наученный опытом, я бы не отказался от такой автоматизации, т.к. теперь каждый месяц тщательно слежу за расходом :)
Судя по моему опыту использования малины и вебкамеры в качестве видео наблюдения перед входной дверью, веб-камеры не очень хорошая затея. За полгода у меня вышло из строя 2 камеры (logitech c270), по всей видимости матрица выгорает. Тут конечно нагрузка будет меньше, но настораживает.
Мне кажется, лучше число срабатываний геркона хранить в самой ардуине и передавать каждый раз на сервер не сам факт увеличения показаний на единицу, а значение счетчика целиком. Это позволит избежать расхождения показаний, когда сервер по какой-то причине не может принять данные: завис, обслуживался, отключился свитч и т.д.
Для начала стоит задуматься над тем сколько нужно TCP пакетов для передачи единственного int32 значения.
А потом стоит посмотреть как работает пульт телевизора в плане экономии энергии, что такое powerdown контроллеров Atmel и что такое WakeUp через reset, вопросы «пропадания» питания отпадут сами-собой. В таком режиме контроллер будет работать от батарейки месяцами!
В качестве направления для размышлений:
Алгоритм программы крутится вокруг: проснуться, инкрементировать значение в EEPROM, отправить (если нужно), уснуть, долгий сон (вода ведь не постоянно льется?) проснуться…
А потом стоит посмотреть как работает пульт телевизора в плане экономии энергии, что такое powerdown контроллеров Atmel и что такое WakeUp через reset, вопросы «пропадания» питания отпадут сами-собой. В таком режиме контроллер будет работать от батарейки месяцами!
В качестве направления для размышлений:
Алгоритм программы крутится вокруг: проснуться, инкрементировать значение в EEPROM, отправить (если нужно), уснуть, долгий сон (вода ведь не постоянно льется?) проснуться…
Для начала стоит задуматься над тем сколько нужно TCP пакетов для передачи единственного int32 значения.
А ничего что автор по http текстовку в «sendHTTPRequest(); » гоняет, байтом больше\меньше…
что такое powerdown контроллеров Atmel и что такое WakeUp через reset, вопросы «пропадания» питания отпадут сами-собой. В таком режиме контроллер будет работать от батарейки месяцами!
1) Автор кормит мегу от блока питания.
2) Автор не заморачивается прерываниями и спящим режимом — delay и поскакали дальше.
Совет Iv38, применительно к этому проекту, очень логичный. Добавлю — для Ардуино надо back up питание прикрутить от батарейки, иначе при пропадании 220В будет расхождение со счетчиком. Дешевый вариант — внешний аккумулятор для мобилы.
Капец велосипедостроителей развелось… PCF858x — часы с календарем, резервное питание уже предусмотрено и многие из них имеют независимый счетчик событий. На худой конец — есть такая микросхема 561ИЕ10, она правда с параллельным выходом но у меги достаточно свободных входов для этого.
Аккумуляторы телефонные… да батарейки CR2025 хватит на десятки лет — она скорей помрет из-за саморазряда. А телефонный аккумулятор работая в «резервном режиме» постоянно под напряжением сдохнет гораздо быстрее. Неужели в этом есть необходимость? Еще и схему правильного заряда литиевого аккумулятора городить… из мухи слона делаете.
Аккумуляторы телефонные… да батарейки CR2025 хватит на десятки лет — она скорей помрет из-за саморазряда. А телефонный аккумулятор работая в «резервном режиме» постоянно под напряжением сдохнет гораздо быстрее. Неужели в этом есть необходимость? Еще и схему правильного заряда литиевого аккумулятора городить… из мухи слона делаете.
Да, с помощью Ардуино развелось, нас «велосипедистов» — как грязи.
Мы забиваем гвозди микроскопом, гоняя на ATmega1280 код достойный Attiny85. Видимо мы понимаем, что время потраченное на глубокое изучение контроллеров, их Dev среды для нас (при штучном производстве то) никогда не окупит сэкономленного кВт электроэнергии. Напомню — это 4 рубля максимум.
Автор привел альтернативу с Пульсаром, он получил экономию.
Мы забиваем гвозди микроскопом, гоняя на ATmega1280 код достойный Attiny85. Видимо мы понимаем, что время потраченное на глубокое изучение контроллеров, их Dev среды для нас (при штучном производстве то) никогда не окупит сэкономленного кВт электроэнергии. Напомню — это 4 рубля максимум.
Автор привел альтернативу с Пульсаром, он получил экономию.
Похоже я вчера погорячился, в час ночи-то. Сеи гневные комментарии не в адрес автора (хотя и в его адрес, в какой-то мере), а в адрес Ардуино, и ее способности заставать человека забивать гвозди Адронным Коллайдером. Скоро в место пары обычных TTL/CMOS вентилей будем лепить ноутбук с вебкой для фотографирования показаний счетчика и связью с кластером на пару гигафлопс для распознавания этих фоток (и пробегающего мимо котика :) )
И тут мы возвращаемся к режиму экономии энергии? Как говорится ниже, самое «геморойное» — это организация резервного питания, и тут на первое место выйдет экономия энергии резервного источника. В предложенном варианте, аккумулятор вполне может стать основным источником питания и заряжаться от сети ровно тогда когда нужно и есть питание (думаю это будет случаться раз в месяц или реже).
Да конечно, прерывания и спящий режим — это ужасно сложно. Аж целых 10 строк кода. А использовать таймер вместо delay это совершенно невозможно, ведь нужно написать целых 3 строки кода — какой ужас.
Тут все-таки не на байт больше, а если учесть заголовок HTTP то вообще абзац будет. Боюсь если все станут использовать такой подход («байтом больше, байтом меньше») то и грядущего 5G не будет хватать для «Интернет вещей» и «Умного дома».
Сея конструкция просто потрясающая. А если счетчик сработает 2 раза в секунду? Или есть причины, которых мы не знаем, по которым счетчик не может сработать более 2 раз в секунду (неплохо бы написать в статье в таком случае) или что-то не так с этим куском кода и доверять прибору нельзя вообще…
для Ардуино надо back up питание прикрутить от батарейки
И тут мы возвращаемся к режиму экономии энергии? Как говорится ниже, самое «геморойное» — это организация резервного питания, и тут на первое место выйдет экономия энергии резервного источника. В предложенном варианте, аккумулятор вполне может стать основным источником питания и заряжаться от сети ровно тогда когда нужно и есть питание (думаю это будет случаться раз в месяц или реже).
Автор не заморачивается прерываниями и спящим режимом — delay и поскакали дальше.
Да конечно, прерывания и спящий режим — это ужасно сложно. Аж целых 10 строк кода. А использовать таймер вместо delay это совершенно невозможно, ведь нужно написать целых 3 строки кода — какой ужас.
А ничего что автор по http текстовку в «sendHTTPRequest(); » гоняет, байтом больше\меньше…
rclient.println(request);
rclient.print(«Host: „);
rclient.println(server);
rclient.println(“Authorization: Basic UmI9dlPnaJI2S0f=»); // Base64 строка, полученная со значения «user:password»
rclient.println(«User-Agent: Arduino Sketch/1.0»);
rclient.println();
rclient.stop();
Тут все-таки не на байт больше, а если учесть заголовок HTTP то вообще абзац будет. Боюсь если все станут использовать такой подход («байтом больше, байтом меньше») то и грядущего 5G не будет хватать для «Интернет вещей» и «Умного дома».
void loop() {
delay(1000); // Задержка в 1 сек, пусть будет :)
// Проверяем состояние всех счетчиков
for (int i=0; i<6; i++) {
boolean changed = CounterBouncer[i].update();
…
}
Сея конструкция просто потрясающая. А если счетчик сработает 2 раза в секунду? Или есть причины, которых мы не знаем, по которым счетчик не может сработать более 2 раз в секунду (неплохо бы написать в статье в таком случае) или что-то не так с этим куском кода и доверять прибору нельзя вообще…
Или есть причины, которых мы не знаем, по которым счетчик не может сработать более 2 раз в секунду (неплохо бы написать в статье в таком случае)
Есть такие причины. Одно срабатывание = один оборот счетчика. Это 10 литров. Максимальный расход через бытовой счетчик 1,5 м3\ч = 0,42 литра в сек.
Последняя цифра на счетчике это сотни литров, а геркон срабатывает на каждый кубометр…
Верхняя фотография горячего счетчика автора — 56,995
995 — это литры текущего куба.
Под ним круглый циферблат с красной стрелочкой — это 1 литр разбитый на 10 частей.
Геркон срабатывает на один оборот этой стрелки. То есть на один литр.
П.С. У меня такой же счетчик стоит. Инфа 100%.
995 — это литры текущего куба.
Под ним круглый циферблат с красной стрелочкой — это 1 литр разбитый на 10 частей.
Геркон срабатывает на один оборот этой стрелки. То есть на один литр.
П.С. У меня такой же счетчик стоит. Инфа 100%.
А, если так то да… тогда 10 литров/сек. Одно ведро воды за 2 секунды, много…
Все-таки геркон срабатывает не на 1 литр, а на 10 литров и на полный оборот последнего сегмента в счетчике, а не стрелки.
Вчера на своем счетчике проверил, у меня тоже так — одно срабатывание на 10 литров, то есть на один оборот младшего разряда.
Точно, твоя правда! Извини что ввел в заблуждение. Вспомнил — учитываю и замыкание и размыкание по такой логике:
замыкание — 59,980
размыкание — 59,982
замыкание — 59,990
замыкание — 59,980
размыкание — 59,982
замыкание — 59,990
Зачем размыкания фиксировать?
Точность чуть выше. Смотри 59,982. По жизни это не нужно, просто заморочка.
Понятно. А на чем собрана система?
www.digitalsmarties.net/products/jeenode
это ATmega328 + радиомодуль RFM12B. У меня проводов не было, 220 нашел.
Одна нода считывает показания и хранит в памяти значение потребления, висит в ванной.
Вторая нода питается от батарейки, принимает и выводит на экран www.digitalsmarties.net/products/graphics-board
Есть еще третья нода — рулит подогревом пола на балконе, шлет на 2 ноду текущую температуру, энергопотребление (чисто фан).
Написано и собрано 2 года назад, код уже утерян — оно работает, я не лезу
это ATmega328 + радиомодуль RFM12B. У меня проводов не было, 220 нашел.
Одна нода считывает показания и хранит в памяти значение потребления, висит в ванной.
Вторая нода питается от батарейки, принимает и выводит на экран www.digitalsmarties.net/products/graphics-board
Есть еще третья нода — рулит подогревом пола на балконе, шлет на 2 ноду текущую температуру, энергопотребление (чисто фан).
Написано и собрано 2 года назад, код уже утерян — оно работает, я не лезу
Конечно причины есть. Представь себе через полдюймовые трубы расход воды более 1куб.м./сек… представил? да это во много раз выше сверхзвука… даже если трубу разорвет в пух и прах расход и то меньше будет.
Блок питания ставил сознательно.
Объясню, почему.
Была возможность питать через USB от сервера и через него же передавать значения. Отвергнуто из-за невозможности отправки данных на удаленный сервер.
Еще статистика — за 3 года в этой квартире, электричество не отключалось ни разу.
Плюс момент энергобезопасности решался, когда делали ремонт. В серверном шкафу стоит бесперебойник (там же сервер и Arduino) и от него дополнительно по всей квартире разбросаны отдельные розетки ( в частности в кабинет к компу, к аквариумному оборудованию, к стойке в зале). Заморочился, в общем.
А вот про прерывания и спящий режим можно подробнее?
Объясню, почему.
Была возможность питать через USB от сервера и через него же передавать значения. Отвергнуто из-за невозможности отправки данных на удаленный сервер.
Еще статистика — за 3 года в этой квартире, электричество не отключалось ни разу.
Плюс момент энергобезопасности решался, когда делали ремонт. В серверном шкафу стоит бесперебойник (там же сервер и Arduino) и от него дополнительно по всей квартире разбросаны отдельные розетки ( в частности в кабинет к компу, к аквариумному оборудованию, к стойке в зале). Заморочился, в общем.
А вот про прерывания и спящий режим можно подробнее?
Если в двух словах:
Прерывания — это аналог «события» в языках высокого уровня. То есть случается у вас смена уровня на ножке, переполнения таймера, или другое событие (см. документацию) вызывается участок кода, который отвечает за обработку этого события (вы сами пишите что делать). То есть работает основной цикл, что-то считает, отправляет, и тут вдруг изменилось значение на ноге (или выставилось заданное) под действием внешних источников (кнопка, геркон, другой МК, внешняя микросхема) — вызвался кусок кода который его посчитал. Дальше управление передается в основной цикл программы в то место где прервалось. Прерывания позволяют реагировать на внешние события не отвлекаясь на постоянное ожидание, а когда же оно случится, и позволяет (в большинстве случаев) не пропустить это событие.
Спящий режим — это режим сниженного энергопотребления. Мега может просыпаться по множеству условий («Собачий таймер», сброс, прием по USART, по прерыванию INT0/INT1, и т.д.), Режимов сна много, отличаются тем что работает, а что отключено. Соответственно разные способы выхода из сна. Рекомендую обратиться к даташиту на мегу, там все подробно и просто (с примерами).
Упомянутый пульт ДУ работает по алгоритму: если нажата кнопка — подается питание на контроллер он отрабатывает нажатие, кнопка отпускается — батарейка физически отключается от контроллера. Время нажатия вполне достаточно для обработки всего что нужно и отправление контроллера в сон (хотя там не контроллер а спец микросхема). Но данный алгоритм вполне можно приспособить с помощью прерываний и глубокого сна к меге (что-бы не снимать с нее питание полностью).
Если интересуетесь электроникой, и микроконтроллерами (от Atmela до ARM) рекомендую заглянуть на сайт DIHALT -а easyelectronics.ru, но предупрежу что DiHALT недолюбливает Ардуино (ввиду негуманной цены и еще много чего), даже разработал свою отладочную плату — очень занятная. Хотя я предпочитаю изготавливать платы сам исходя из задачи. На его сайте и на Хабре полно статей с описанием технологии. Хотя подход к задаче зависит от задачи, желания и фазы луны.
Прерывания — это аналог «события» в языках высокого уровня. То есть случается у вас смена уровня на ножке, переполнения таймера, или другое событие (см. документацию) вызывается участок кода, который отвечает за обработку этого события (вы сами пишите что делать). То есть работает основной цикл, что-то считает, отправляет, и тут вдруг изменилось значение на ноге (или выставилось заданное) под действием внешних источников (кнопка, геркон, другой МК, внешняя микросхема) — вызвался кусок кода который его посчитал. Дальше управление передается в основной цикл программы в то место где прервалось. Прерывания позволяют реагировать на внешние события не отвлекаясь на постоянное ожидание, а когда же оно случится, и позволяет (в большинстве случаев) не пропустить это событие.
Спящий режим — это режим сниженного энергопотребления. Мега может просыпаться по множеству условий («Собачий таймер», сброс, прием по USART, по прерыванию INT0/INT1, и т.д.), Режимов сна много, отличаются тем что работает, а что отключено. Соответственно разные способы выхода из сна. Рекомендую обратиться к даташиту на мегу, там все подробно и просто (с примерами).
Упомянутый пульт ДУ работает по алгоритму: если нажата кнопка — подается питание на контроллер он отрабатывает нажатие, кнопка отпускается — батарейка физически отключается от контроллера. Время нажатия вполне достаточно для обработки всего что нужно и отправление контроллера в сон (хотя там не контроллер а спец микросхема). Но данный алгоритм вполне можно приспособить с помощью прерываний и глубокого сна к меге (что-бы не снимать с нее питание полностью).
Если интересуетесь электроникой, и микроконтроллерами (от Atmela до ARM) рекомендую заглянуть на сайт DIHALT -а easyelectronics.ru, но предупрежу что DiHALT недолюбливает Ардуино (ввиду негуманной цены и еще много чего), даже разработал свою отладочную плату — очень занятная. Хотя я предпочитаю изготавливать платы сам исходя из задачи. На его сайте и на Хабре полно статей с описанием технологии. Хотя подход к задаче зависит от задачи, желания и фазы луны.
С прерываниями будет все же сложней. На первый взгляд кажется все просто, но прерывания очень чувствительны к дребезгу в отличие от существующего вашего кода. Так одно срабатывание геркона может дать десяток импульсов, в итоге чтобы это побороть нужно усложнять аппаратную часть либо программную чтобы подавить этот самый дребезг, в итоге сложность проекта повысится на ровном месте.
Более того, удобных выводов под прерывание в контроллере только два, которые можно настроить на один фронт, остальные источники прерывания по любому пину не различают фронт или спад — срабатывают по изменению уровня, и необходимо дополнительно проверять в прерывании текущий уровень чтобы отличить фронт от спада, но между этой проверкой и возникновением прерывания проходит время из-за дребезга или по другой причине уровень вызвавший прерывание и тут же считанный для проверки могут отличаться — появятся сбои в работе.
Единственное что вместо вашей задержки вставить элементарный SLEEP, а один из таймеров(16-битный скорей всего) настроить на счет около 200...500мс(все-таки периода в 1 сек это довольно много) и организовать ему прерывание по переполнению с пустым обработчиком — оно будет выводить контроллер из спячки, который считает состояние датчиков выполнит необходимое действие и дальше спать. В принципе, даже при питании от БП такой алгоритм пригодится. Можно еще аппаратный вач-дог настроить на период в 2 сек, если вдруг зависнет и сбрасывать его когда считываете состояние датчиков…
Более того, удобных выводов под прерывание в контроллере только два, которые можно настроить на один фронт, остальные источники прерывания по любому пину не различают фронт или спад — срабатывают по изменению уровня, и необходимо дополнительно проверять в прерывании текущий уровень чтобы отличить фронт от спада, но между этой проверкой и возникновением прерывания проходит время из-за дребезга или по другой причине уровень вызвавший прерывание и тут же считанный для проверки могут отличаться — появятся сбои в работе.
Единственное что вместо вашей задержки вставить элементарный SLEEP, а один из таймеров(16-битный скорей всего) настроить на счет около 200...500мс(все-таки периода в 1 сек это довольно много) и организовать ему прерывание по переполнению с пустым обработчиком — оно будет выводить контроллер из спячки, который считает состояние датчиков выполнит необходимое действие и дальше спать. В принципе, даже при питании от БП такой алгоритм пригодится. Можно еще аппаратный вач-дог настроить на период в 2 сек, если вдруг зависнет и сбрасывать его когда считываете состояние датчиков…
вот тут по прерываниям arduino.cc/en/Reference/Interrupts
тут по sleep states donalmorrissey.blogspot.ru/2010/04/putting-arduino-diecimila-to-sleep-part.html
Но вот на счет не нужности их использования, согласен с Alexeyslav:
надо усложнять схему, ставить фильтр (конденсатор, индукционную емкость), у вас нет проблем с питанием, экономить батарейку не надо.
тут по sleep states donalmorrissey.blogspot.ru/2010/04/putting-arduino-diecimila-to-sleep-part.html
Но вот на счет не нужности их использования, согласен с Alexeyslav:
прерывания очень чувствительны к дребезгу в отличие от существующего вашего кода. Так одно срабатывание геркона может дать десяток импульсов
надо усложнять схему, ставить фильтр (конденсатор, индукционную емкость), у вас нет проблем с питанием, экономить батарейку не надо.
да ладно? А кто мешает обработать дребезг программно, аналогично способу примененному в программе автора?
Кроме того, избавиться от дребезга (особенно дребезга раздолбанной кнопки) емкостями не получится. Все равно придется делать программную «защиту»
Кроме того, избавиться от дребезга (особенно дребезга раздолбанной кнопки) емкостями не получится. Все равно придется делать программную «защиту»
да… городить историю с прерываниями чтобы потом дополнительно бороться с дребезгом программно — замечательный способ нагрузить себя ненужной работой. Существующий подход и так хорошо справляется с работой. Только надо иметь в виду, что длина импульса с геркона — всего 2-3Л, т.е. при скорости потока 2Л/сек и больше существует шанс что программа не заметит импульс, впрочем при таких значениях эту особенность скорее надо иметь в виду чем что-то предусматривать. Вдруг устройство попытаются поставить на промышленный трубопровод, где поток воды больше… а тут такая засада.
На самом деле длина импульса может длиться много больше, в случае, когда закрыли кран на значении последнего разряда 1 или 2. Так и будет состояние замкнуто висеть, пока не сольем еще литр-два воды.
вот интересно, а можно остановить гиркон так, чтобы он находился в состоянии перманентного дребезга пока снова не откроют кран?
больше-то оно не вредно, речь идет о минимальной длительности — вдруг импульс проскочит мимо проверок, и не будет зарегистрирован… Это граничное условие — импульс длительностью ровно в период опроса. Больше — будет зарегистрирован всегда, меньше — как повезет. В данном случае, геркон замыкается на протяжении 2-3Л по счетчику, нетрудно догадаться при каком расходе счетчик даст импульс короче одной секунды и соответственно когда начнутся проблемы.
Все эти фильтры не избавляют от дребезга, только лишь уменьшают его влияние. Ну зафильтруешь, всеравно фаза луны сойдется и пропустит один из тысячи импульсов дребезга. Самый надежный способ избавления от дребезга — это одновибраторы(но повышается чувствительность к помехам — ведь любой самый короткий импульс будет рассмотрен как срабатывание) или синхронный триггер защелкивающий состояние линии каждые N милисекунд, где N заведомо больше периода дребезга контакта.
Собственно, второй вариант с синхроным триггером сейчас и реализован программно — данные защелкиваются для последующего анализа раз в секунду. Недостаток этого подхода — негарантированное время реакции на срабатывание.
Собственно, второй вариант с синхроным триггером сейчас и реализован программно — данные защелкиваются для последующего анализа раз в секунду. Недостаток этого подхода — негарантированное время реакции на срабатывание.
Вот что происходит если пытаться убрать дребезг с помощью конденсатора… Резистор 250 Ом имитирует входное сопротивление порта меги (5В; 20мА)
Что-бы не разводить холивар пример антидребезгового алгоритма с сайта DiHalt-a:
Что-бы не разводить холивар пример антидребезгового алгоритма с сайта DiHalt-a:
Алгоритм прерывания с антидребезгом будет выглядеть так:
Зашли в обработчик INT0
0 или +1
Запретили локально INT0
Поставили на таймер событие разрешающее INT0 через несколько миллисекунд
Вышли из обработчика
Это вызовет большие трудности если надо ловить таким образом больше одного прерывания.
Мега принципиально не умеет работать с несколькими прерываниями — у нее нет стека соотвественно невозможно вызывать прерывание из прерывания, а не основного цикла. Первое прерывание будет перебито вторым и произойдет потеря данных, но это крайне редкие случаи в системах (когда накладываются два прерывания) для которых предназначена Мега (за все мое время использования меги такое случалось 1 раз при тестировании вложенных прерываний — то есть было искусственно вызвано)
Для решения таких задач (иерархичность прерываний) лучше использовать ARM.
Для решения таких задач (иерархичность прерываний) лучше использовать ARM.
Для примера рассмотрите задачу обработки нажатия кнопок на клавиатуре. Я хочу видеть человека, который сможет клацать по кнопкам со скорость <100-150 мс на нажатие (это что-то около 600 символов в минуту). Помнится раньше были часы в виде пейджера, так вот мы пробовали нажать две рядом стоящие кнопки (стар таймера и сто) с максимальной скоростью. Быстрее чем 200 мс никто не смог, а если жать одну два раза — то все 500-700 мс.
Кстати по алгоритму выше легко реализуется опция постоянного инкремента при зажатой кнопкой. В одну строку.
Кстати по алгоритму выше легко реализуется опция постоянного инкремента при зажатой кнопкой. В одну строку.
200мс в тех часах это скорей всего период сканирования кнопок клавиатуры, раньше он просто видимо не успевает зарегистрировать факт нажатия. да и речь все же идет не о кнопках а датчиках, которые срабатывают хоть и медленно но полностью асинхронно и независимо друг от друга — могут ведь сработать и все 6 одновременно с точностью до десятков наносекунд!
Будет очень смешно и весело, если программа не справится с одновременным нажатием кнопок…
Будет очень смешно и весело, если программа не справится с одновременным нажатием кнопок…
а вы никогда не нажимали 4-5 кнопок на клавиатуре одновременно?
Мы уходим от темы, в обычных клавиатурах организация матричная и коллизии при нажатиях двух и более кнопок неизбежны, так получается by design.
У нас же 6 входов ОТДЕЛЬНЫХ, умудрится сделать так чтобы программа вела себя не адекватно при одновременном срабатывании датчиков в произвольных комбинациях — это высший пилотаж.
Есть 6 входов, никаких матриц — поэтому логично требовать от программы работы во всех комбинациях и любыми одновременностями.
У нас же 6 входов ОТДЕЛЬНЫХ, умудрится сделать так чтобы программа вела себя не адекватно при одновременном срабатывании датчиков в произвольных комбинациях — это высший пилотаж.
Есть 6 входов, никаких матриц — поэтому логично требовать от программы работы во всех комбинациях и любыми одновременностями.
По опыту, гараздо проще обрабатывать отдельные абсолютно независимые входы (пусть даже и 6), чем разруливать колизии матричного исполнения (да и любого другого способа расширения количества подключаемых элементов сдвиговые регистры аля 74НС595, мультиплексоры и т.п.).
И у вас есть одна неточность: комбинации в данном примере не любые. Как было выяснено ранее если датчик сработал, его повторное срабатывание произойдет через значительный промежуток времени (в бытовых условиях, обусловлено ограниченной скоростью истекания воды из труб) достаточный для обработки сигналов других датчиков.
Но да, я с вами согласен обработать массив асинхронных величин на приеме требует некоторого умения и внимания к этой проблеме. Любая подобная система будет иметь ограничение разрешающей способности на уровне нескольких периодов тактового сигнала. В данном случае это не критично, так как датчик находится в состоянии замкнуто довольно продолжительный промежуток времени (даже с учетом дребезга) и обработать его значение не составляет большого труда (ну захватится его значение не на первом периоде дребезга а на втором, третьем или когда он выйдет на стабильный уровень) ведь в данной системе не предъявляются требования к определению точного времени срабатывания, главное их не пропускать, а это проще.
Алгоритм приема этих сигналов не будет иметь особых отличий при исполнении в прерывании или основном цикле программы. Описанные проблемы будут возникать как в первом так и во втором случае и придется принимать меры к их устранению. Применение прерываний и таймеров в данной задаче позволяет высвободить время на обработку и более жесткий контроль за отсутствием пропусков. Я предпочитаю стиль программирования контроллеров такой, в котором при наличии Hardware реализации той или иной возможности я отдаю предпочтение Hardware а не программной реализации. Обычно это немного снижает гибкость но значительно повышает надежность, скорость обработки, снижает размер использованного ОЗУ и памяти программ, (Имею ввиду что использую таймеры вместо delay, блок SPI вместо его программной реализации, и т.п.) что в тематике контроллеров является более критичным.
И у вас есть одна неточность: комбинации в данном примере не любые. Как было выяснено ранее если датчик сработал, его повторное срабатывание произойдет через значительный промежуток времени (в бытовых условиях, обусловлено ограниченной скоростью истекания воды из труб) достаточный для обработки сигналов других датчиков.
Но да, я с вами согласен обработать массив асинхронных величин на приеме требует некоторого умения и внимания к этой проблеме. Любая подобная система будет иметь ограничение разрешающей способности на уровне нескольких периодов тактового сигнала. В данном случае это не критично, так как датчик находится в состоянии замкнуто довольно продолжительный промежуток времени (даже с учетом дребезга) и обработать его значение не составляет большого труда (ну захватится его значение не на первом периоде дребезга а на втором, третьем или когда он выйдет на стабильный уровень) ведь в данной системе не предъявляются требования к определению точного времени срабатывания, главное их не пропускать, а это проще.
Алгоритм приема этих сигналов не будет иметь особых отличий при исполнении в прерывании или основном цикле программы. Описанные проблемы будут возникать как в первом так и во втором случае и придется принимать меры к их устранению. Применение прерываний и таймеров в данной задаче позволяет высвободить время на обработку и более жесткий контроль за отсутствием пропусков. Я предпочитаю стиль программирования контроллеров такой, в котором при наличии Hardware реализации той или иной возможности я отдаю предпочтение Hardware а не программной реализации. Обычно это немного снижает гибкость но значительно повышает надежность, скорость обработки, снижает размер использованного ОЗУ и памяти программ, (Имею ввиду что использую таймеры вместо delay, блок SPI вместо его программной реализации, и т.п.) что в тематике контроллеров является более критичным.
таймер или delay — это не так важно, просто с прерываниями появляются дополнительные проблемы — прерывание реагирует на каждый импульс в том числе и на дребезг и с этим что-то надо делать. Если же просто опрашивать кнопки со строго заданным интервалом то все эти проблемы решаются сами собой — и дребезг устраняется для всех датчиков сразу и узких мест нет. Просто считываем состояние датчиков в ячейку памяти, делаем XOR с предыдущим значением и у нас есть вся необходимая информация для решения — какой датчик изменил своё состояние и в какую сторону.
Именно с точки зрения логики этот алгоритм прост и легко проверяем а значит более надежен, хотя может и вылиться в большее количество строк чем с прерываниями. Но количество строк кода это не показатель, главное это сложность и надежность алгоритма.
Именно с точки зрения логики этот алгоритм прост и легко проверяем а значит более надежен, хотя может и вылиться в большее количество строк чем с прерываниями. Но количество строк кода это не показатель, главное это сложность и надежность алгоритма.
Если же просто опрашивать кнопки со строго заданным интервалом
За время опроса первой кнопки, вторая перешла в состояние отжато из-за дребезга, вы прочитали отжато. А юзер пальцем ожесточенно тыкает и краснеть начинает. Что будете делать?
делаем XOR с предыдущим значением и у нас есть вся необходимая информация для решения — какой датчик изменил своё состояние и в какую сторону.
Предыдущее значение: 010010
Текущее значение:101101
Результат XOR:111111
Подскажите по результату что и в какую сторону поменялось?
Процессы протекающие в электрических цепях подчиняются не логике, а законам Киргофа и уравнениям Максвелла (хотя да они логичны)
не каждую в отдельности, а фиксировать их состояние в один момент времени. Да и в принципе какая разница с каким смещением будет зафиксирована вторая кнопка относительно первой. Они ведь не влияют друг на друга — независимые. Главное чтобы фиксация эта происходила только один раз в заданном интервале — это гарантирует защиту от дребезга при условии что интервал опроса заведомо длиннее времени дребезга.
единица в результате функции XOR укажет нам какой из датчиков изменил свое состояние, а запомненное предыдущее или зафиксированное текущее покажет нам в какую сторону.
единица в результате функции XOR укажет нам какой из датчиков изменил свое состояние, а запомненное предыдущее или зафиксированное текущее покажет нам в какую сторону.
Часы Montana: таймер легко останавливался на 0,06 с, а если одну и ту же кнопку, то 0,12 с. Ещё и от самих кнопок зависит.
О нет, она конечно умеет при необходимости, но тут проблемы другого плана. Аппаратных прерываний всего два а надо 6 датчиков подключить… приходится задействовать прерывание по изменению состояния порта, а оно будет ОДНО на все датчики — это значит что надо будет отслеживать какой именно датчик привел к прерыванию, — эта операция не атомарна, состояние датчика из-за дребезга до проверки может изменится и программа не обнаружит ничего. Надо усложнять код, бороться с дребезгом и последствиями неатомарности операций — зачем этим всем забивать голову когда есть простые понятные и эффективные решения?
да ладно, у меги одно прерывание? ОДНО? когда вы даташит смотрели последний раз?
Ой прерывание чуть не на каждой ножке. 6 штук уж точно найдется.И да PCINT можно отработать с точностью до 1 нс. Так как выставляться они будут асинхронно.
Ой прерывание чуть не на каждой ножке. 6 штук уж точно найдется.И да PCINT можно отработать с точностью до 1 нс. Так как выставляться они будут асинхронно.
Независимых прерываний тут только два — INT0 и INT1.
PCINTx имеют один общий обработчик на каждый порт и не умеют работать по отдельным фронтам — только на изменение уровня. замаешься определять какая ножка и куда перешла и потом обрабатывать эти события а потом еще и подавлять дребезг индивидуально по каждому входу, разруливать как-то ситуации когда прерывание по другому входу возникает во время обработки, а если оно возникнет в тот момент когда контроллер еще будет входить в прерывание еще до сравнения состояния входов?
Все это называется одним словом — из мухи раздувать слона. PCINT — хороши для матричных клавиатур, чтобы пробудить контроллер из спячки по нажатию любой кнопки.
PCINTx имеют один общий обработчик на каждый порт и не умеют работать по отдельным фронтам — только на изменение уровня. замаешься определять какая ножка и куда перешла и потом обрабатывать эти события а потом еще и подавлять дребезг индивидуально по каждому входу, разруливать как-то ситуации когда прерывание по другому входу возникает во время обработки, а если оно возникнет в тот момент когда контроллер еще будет входить в прерывание еще до сравнения состояния входов?
Все это называется одним словом — из мухи раздувать слона. PCINT — хороши для матричных клавиатур, чтобы пробудить контроллер из спячки по нажатию любой кнопки.
На данный момент это работает в серийном изделии, код который разруливает описанные вами проблемы не сложен. Проблем не испытываем в том числе с дребезгом.
Каждая нога обрабатывается отдельно, антидребезг на каждую ногу инициируется отдельно. Также обрабатываются комбинации ножек. Задействованы 8 ног, код писался «нативно» (без дурилок и РТОС) на С.
Уж не хотите ли вы сказать, что конструкция
работает лучше, с учетом отправки НТТР запроса между проверками состояния ножек, а это как вы говорили ранее должна быть «атомарная операция». Представляете что случится если счетчики сработают через один с интервалом в 5-10 мкс?
Каждая нога обрабатывается отдельно, антидребезг на каждую ногу инициируется отдельно. Также обрабатываются комбинации ножек. Задействованы 8 ног, код писался «нативно» (без дурилок и РТОС) на С.
Уж не хотите ли вы сказать, что конструкция
for (int i=0; i<6; i++) {
boolean changed = CounterBouncer[i].update();
if ( changed ) {
int value = CounterBouncer[i].read();
// Если значение датчика стало ЗАМКНУТО
if ( value == LOW) {
//Serial.println(CounterPin[i]);
sprintf(request, "GET /input.pl?object=%s HTTP/1.0", CounterName[i]); // Формируем ссылку запроса, куда вставляем имя счетчика
sendHTTPRequest(); // Отправляем HTTP запрос
}
}
}работает лучше, с учетом отправки НТТР запроса между проверками состояния ножек, а это как вы говорили ранее должна быть «атомарная операция». Представляете что случится если счетчики сработают через один с интервалом в 5-10 мкс?
Ну замечательно, чего. С дребезгом тут можно столкнуться, если вдруг состояние входа изменится между проверками — между UPDATE и READ. Отловить такое событие будет чрезвычайно трудно, но оно будет происходить.
И столько кода для считывания состояния входов? из мухи слона… нет, ну чем хуже просто считать все входы разом и потом их обрабатывать побитно, через сдвиг в цикле? Если вдруг состояние изменится после считывания — обработано будет в следующей итерации.
И столько кода для считывания состояния входов? из мухи слона… нет, ну чем хуже просто считать все входы разом и потом их обрабатывать побитно, через сдвиг в цикле? Если вдруг состояние изменится после считывания — обработано будет в следующей итерации.
5-10 строк включая объявление переменных и работу с таймером.
А я что говорил что оно не так работает? Это и есть основная идея работы, только при срабатывании PCINTx все собирается в нужном регистре с нужными флагами и в нужное время. Куда проще в обработке и в итоге в надежности и отсутствии пропусков…
нет, ну чем хуже просто считать все входы разом и потом их обрабатывать побитно, через сдвиг в цикле? Если вдруг состояние изменится после считывания — обработано будет в следующей итерации.
А я что говорил что оно не так работает? Это и есть основная идея работы, только при срабатывании PCINTx все собирается в нужном регистре с нужными флагами и в нужное время. Куда проще в обработке и в итоге в надежности и отсутствии пропусков…
Сижу и думаю: может быть поставить с каждого входа диоды на пин прерывания и отслеживать любой фронт сигнала?
Смотря с какой целью. Это решение будет даже хуже чем использовать индивидуальные входы по PCCINTxx. Так можно отловить только «срабатывание любого из датчиков» — определить какой именно из датчиков сработал будет проблематично, кроме того первый сработавший замаскирует все остальные пока не снимет свой сигнал. Если вас это устраивает — то можно использовать. Обычно такой подход используется для опроса клавиатуры в пультах — по нажатию любой кнопки происходит прерывание и пробуждение контроллера, который уже определяет какая точно нажата и не помеха ли это.
Резистор 250 Ом имитирует входное сопротивление порта меги (5В; 20мА)
Ну вы даёте, входное сопростивление порта меги — мегаомы, какие ещё 250 Ом? Там internall pull up-ы и то на десятки кОм.
Раз уж так доставляет неудобств ежемесячная процедура, оплати 1 раз на год перед воду и все… никаких приспособлений не нужно :)
Хрень в том, что показания надо сдавать минимум раз в 3 месяца: иначе надо вызывать из РЭУ (ДЭЗа или хз как называется, в общем — управляющей компании) сантехника, который ворча на весь мир должен снять эти показания, заверить бумагу и посеять в недрах бюрократии…
Также в данном случае Управляющую компанию сильно напряжет факт оплаты за год. Допустим, что Вы оплатили 100 куб. м. холодной воды в январе (примерно столько выходит за год у меня), а в июле 1 куб. м. холодной воды подорожал на 7% (это реально так у меня) и как Вы думаете, что решит управляющая компания?
У вас даже грязевики запломбировали, тяжелый случай.
Частично описывал это (серверную часть): habrahabr.ru/post/154185/
Намного надёжнее на ардуине хранить кол-во импульсов и передавать его на сервер (как уже написали выше).
Тогда недоступность сервера (довольно вероятная ситуация при отключении света в квартире света) не будет влиять на показания.
А ещё можно добавить резервное питание, к примеру на базе USB PowerBank'а с одним-двумя Li-Ion аккумулятрами (главное чтобы он умел работать в нужном режиме) и на выходе получить автономный девайс с запасом на пару недель :)
Тогда недоступность сервера (довольно вероятная ситуация при отключении света в квартире света) не будет влиять на показания.
А ещё можно добавить резервное питание, к примеру на базе USB PowerBank'а с одним-двумя Li-Ion аккумулятрами (главное чтобы он умел работать в нужном режиме) и на выходе получить автономный девайс с запасом на пару недель :)
Учитывая, что электричество пропадает довольно редко и ненадолго, то в качестве аварийного питания на долгое время хватит и обычных батареек, включенных через диод. А если озаботится сном контроллера и побудкой по прерыванию, то о них, наверное, можно забыть на годы.
литиевые аккумуляторы сюда не подходят, они скончаются через 2-3 года а необходимости в их огромной емкости нет. Просто чудовищный перерасход ресурсов!
Всего-то ведь надо хранить под резервным питанием не больше 8 бит счетчика… а все остальное может и подождать — не критично. Для этого сойдет батарейка CR2025.
Тем более, она работать будет только в отсутствие электричества — а оно врядли будет отсутствовать больше нескольких часов к ряду и не больше нескольких суток в год. Да даже если и больше…
Всего-то ведь надо хранить под резервным питанием не больше 8 бит счетчика… а все остальное может и подождать — не критично. Для этого сойдет батарейка CR2025.
Тем более, она работать будет только в отсутствие электричества — а оно врядли будет отсутствовать больше нескольких часов к ряду и не больше нескольких суток в год. Да даже если и больше…
Хм, сделал практический тоже самое но RaspberryPI. Самое проблематичное в этом всем это организация бесперебойного питания.
Экспериментальным путем было определено, что счетчики работают не просто, а очень просто. Когда последний разряд меняет свое значение с 9 на 0, замыкается геркон внутри счетчика. В таком состоянии он находится до того, пока значение последнего разряда не станет равным 3.
Автор- экономлю кучу твоих нервных клеток в будущем.
С 0 до 2 — это не постоянная величина. За время жизни этот промежуток дрейфует (чисто механический дрейф из-за износа счетчика видимо или погрешности деталей шестеренок).
Как выловил — у меня ардуино с бекапом питания, все пишется в eeprom, и тут за год работы при сверке набегает расхождение.
Уж чего только не думал, и на дребезг контактов грешил и на длительную работу без питания. А потом перепроверил — интервал сместился на 8 — 0. Еще через 3 месяца — опять новый(не помню уж и какой). Счетчику уже 5 лет, примерно 400 кубов пробега.
А чем это мешает? Ну небольшой дрейф, но на один оборот мнадшего разряда срабатывание все равно один раз. А вот дребезг контактов, мне кажется, может создавать проблему, особенно при медленном вращении счетчика, когда геркон относительно долгое время находится в состоянии на грани.
Проблема, что:
не один раз в итоге получается. Смотри на примере
было 0-2,
в след обороте 1-3,
2-4
3-5
4-6
5-7
6-8
7-9
8-0
9-1
0-2
Ардуиной ты насчитал 11 оборотов, а счетчик сделал 12.
на один оборот младшего разряда срабатывание все равно один раз.
не один раз в итоге получается. Смотри на примере
было 0-2,
в след обороте 1-3,
2-4
3-5
4-6
5-7
6-8
7-9
8-0
9-1
0-2
Ардуиной ты насчитал 11 оборотов, а счетчик сделал 12.
То есть он на каждом обороте немного смещается и получается, что срабатывание происходит, условно говоря, на 0,9 оборота? Просто не могу представить как оно так может чисто механически. Я себе представляю, что там на колесике закреплен магнит, а рядом с колесиком стоит геркон. Как в такой системе может быть дрейф — ума не приложу. Надо на своих счетчиках попробовать последить.
По приведенному примеру — одно срабатывание на 1,1 оборота. Мои мысли на счет геркона были такими же на 100% — поэтому даже представить не мог этот дрейф, отсюда «Автор- экономлю кучу твоих нервных клеток в будущем. „
Как сдохнет счетчик — разломаю, посмотрю. Мои мысли — возможно от основного вала приводятся во вращение два различные шестерни:
— одна вращает литровую стрелку
— вторая крутит магнит
Теоретически при 100% совпадении в диаметре шестерен все ок, но видимо есть погрешность…
Как сдохнет счетчик — разломаю, посмотрю. Мои мысли — возможно от основного вала приводятся во вращение два различные шестерни:
— одна вращает литровую стрелку
— вторая крутит магнит
Теоретически при 100% совпадении в диаметре шестерен все ок, но видимо есть погрешность…
Спасибо. Интересно, понаблюдаю.
Пока же за 5 месяцев работы, расхождений не замечено.
Пока же за 5 месяцев работы, расхождений не замечено.
Ёлки… Геркон?
Дык взять простейший китайский велокомпьютер, да подключить прямо к счётчику!
Можно даже попробовать выставить «длину колеса» так, чтобы показания одометра вместо километров дороги стали показывать кубометры воды.
Схема получится тупая, как палка. И вполне энергонезависимая (от алкалиновой «таблетки» велокомп может работать пару лет точно. Больше не проверял).
А ардуину можно уже прикрутить (или не прикручивать), чтобы снять показания с этих самых «датчиков с накоплением».
Дык взять простейший китайский велокомпьютер, да подключить прямо к счётчику!
Можно даже попробовать выставить «длину колеса» так, чтобы показания одометра вместо километров дороги стали показывать кубометры воды.
Схема получится тупая, как палка. И вполне энергонезависимая (от алкалиновой «таблетки» велокомп может работать пару лет точно. Больше не проверял).
А ардуину можно уже прикрутить (или не прикручивать), чтобы снять показания с этих самых «датчиков с накоплением».
(кстати, всё ж не всякий. При очень большом интервале между импульсами они уходят в спячку. Идёт ли после этого «пробуждающий» импульс в счёт, или же просто будит и всё — неясно).
Тогда есть еще более олдовый способ. Берем дешевый калькулятор, припаиваем провода счетчика параллельно кнопке «равно», набираем изначальное значение счетчика, затем «плюс» и 0,01, наслаждаемся цифровым индикатором. К сожалению, как и велокомп, калькулятор будет засыпать в перерывах. Но самый существенный недостаток не в этом, а в том, что это фактически просто второй индикатор, он не дает особых преимуществ, ну, разве что его можно вынести в более удобное место. Тогда как описанный в статье способ позволяет делать с данными что угодно. Можно смотреть их на мобилке, можно строить графики потребления по времени, можно даже попробовать отправлять данные водоканалу автоматически.
Кто -нибудь экспериментировал со счетчиками без торчащего кабеля? В них тоже используются магниты для разделения мокрой и сухой среды и счетного механизма.
Думал как-то то ли геркон прикрепить к корпусу, то ли дачит Холла и посмотреть осциллографом на сигнал с него… но не уверен, что чувствительности их хватит, все же счетчик в воде и металлическом корпусе.
Вообще, мне кажется, собирать четко показания в течение года — и можно набрать статистику по сезонам, сколько в месяц тратится воды, плюс минус кубеметр — ерунда же… И потом только тот же скрипт будет сам подставлять статистические данные и печатать квиток… и просить раз в полгода производить коррекцию статистики
Думал как-то то ли геркон прикрепить к корпусу, то ли дачит Холла и посмотреть осциллографом на сигнал с него… но не уверен, что чувствительности их хватит, все же счетчик в воде и металлическом корпусе.
Вообще, мне кажется, собирать четко показания в течение года — и можно набрать статистику по сезонам, сколько в месяц тратится воды, плюс минус кубеметр — ерунда же… И потом только тот же скрипт будет сам подставлять статистические данные и печатать квиток… и просить раз в полгода производить коррекцию статистики
А есть уже готовые подобные решения?
Да, я уже писал в статье про Пульсар. Он придуман специально для этого и предполагается, что он ставится в щиток на лестничной клетке.
Да, сейчас уже есть возможность установить счетчики, которые сами передают показания на общедомовой сервер, а далее в ДУК. Такие счетчики есть на воду, электричество, газ и отопление. Гуглить как «счетчики с цифровым выходом».
Доброго времени суток.
Прошу великодушно меня простить, но Зоркий глаз заметил у вас торчащую систему защиты от протечек «Нептун». =)
Как она? Не подводили клапаны? Давно стоит? Там 12v или 220v версия?
Пробовали ручное открытие?
Прошу великодушно меня простить, но Зоркий глаз заметил у вас торчащую систему защиты от протечек «Нептун». =)
Как она? Не подводили клапаны? Давно стоит? Там 12v или 220v версия?
Пробовали ручное открытие?
220v, используется 3,5 года. По-моему разница 220 от 12 в наличии БП, которые висят над Нептунами. Хотя могу ошибаться.
Пока ни разу не пригодилась, но вручную раз в полгода замыкаю датчики, чтобы электроклапаны не закисали.
Ручное открытие? Это как?
Пока ни разу не пригодилась, но вручную раз в полгода замыкаю датчики, чтобы электроклапаны не закисали.
Ручное открытие? Это как?
Понял Вас, спасибо.
Тут написано что можно руками, предварительно обесточив и нажав на кнопку снизу. Как конкретно — не знаю ибо не имею возможности пощупать…
Просто только заказываю, интересен опыт использования…
Тут написано что можно руками, предварительно обесточив и нажав на кнопку снизу. Как конкретно — не знаю ибо не имею возможности пощупать…
Просто только заказываю, интересен опыт использования…
В нашей прибалтийской стране, в столице, в добровольно-принудительном порядке всем поставили такие:
Пытаюсь придумать как бы прочитать с него данные, т.к. у него есть радиолинк 868MHz.
Пытаюсь придумать как бы прочитать с него данные, т.к. у него есть радиолинк 868MHz.
Ого. У него батарейка внутри? Какой ресурс? Он куда-то что-то передает сам или нужно сначала ему запрос кинуть?
Вообще интересная штука, но без технической документации с ним будет не просто разобраться.
Вообще интересная штука, но без технической документации с ним будет не просто разобраться.
Да, батарейка. Написано 12 лет + 6 мес. (хранение).
Вот как раз с документацией и беда, что удалось выяснить, так это скорей всего брендированная поделка Siemens, протокол обмена Q AMR.
Вот как раз с документацией и беда, что удалось выяснить, так это скорей всего брендированная поделка Siemens, протокол обмена Q AMR.
Между этажами висит вот такой приемник
Автору спасибо за отличную идею.
Мелкие предложения по доработке скетча:
— отслеживание геркона повесить на interrupt — так вернее (http://arduino.cc/en/Reference/attachInterrupt)
— вести промежуточный итог в eeprom и отправлять по ethernet его — так снимется проблема неполучения данных в случае downtime сервера
Мелкие предложения по доработке скетча:
— отслеживание геркона повесить на interrupt — так вернее (http://arduino.cc/en/Reference/attachInterrupt)
— вести промежуточный итог в eeprom и отправлять по ethernet его — так снимется проблема неполучения данных в случае downtime сервера
Да, по комментариям выше, уже понял, что это как раз именно то, что необходимо будет сделать.
Сказывается отсутствие опыта при работе с Arduino. Публикация статьи как раз и предполагала, что люди поделятся своим опытом и соображениями.
Сказывается отсутствие опыта при работе с Arduino. Публикация статьи как раз и предполагала, что люди поделятся своим опытом и соображениями.
Подходящих прерываний в контроллере только два, а датчиков 6. Если вешать датчики на обычный порт, в этом режиме прерывания не различают фронт/спад и будут давать два импульса на срабатывание. И это если не рассматривать проблему дребезга.
Все-таки текущее решение прекрасно решает проблему дребезга, а в случае использования прерываний надо предпринимать специальные меры.
Все-таки текущее решение прекрасно решает проблему дребезга, а в случае использования прерываний надо предпринимать специальные меры.
Согласен, в процессе создания проекта, дребезг без текущего программного решения действительно был очень заметный и доставлял много неприятностей.
Был даже вариант, когда вешал конденсаторы для его устранения.
Был даже вариант, когда вешал конденсаторы для его устранения.
Конденсаторы это не выход, они лишь уменьшают дребезг но не избавляют от него совсем, один из ста импульсов все же проскочит.
И еще интересное замечание. Герконы ведь обычные контакты, чтобы считать их состояние необходимо «подпереть» их резисторами, а в некоторых комбинациях(все счетчики остановились в состоянии «замкнуто») ток через эту подтяжку может свести на нет все старания по энергосбережению. Имеет смысл, включать подтяжку за 100-200мкс до считывания состояния датчиков и после отключать. И подтяжку сделать посильнее, 1...5кОм иначе могут запросто ловится наводки, 50кОм — уже ловит статику по входу как изменение уровня, встроенная подтяжка тоже никуда не годится — слишком мягкая.
Все сигналы с датчиков желательно зашунтировать супрессорами, иначе ардуинка вылетит вмиг от близкой грозы, все-таки провода слишком близки от труб в которых будет наводится напряжение от ЭМИ грозового разряда. Поверь, это будет не лишним — есть печальный опыт всего лишь торчащим проводком длиной 30см из обесточенного компьютера — при следующем включении сгорел RS-232 выходной драйвер(с дымком) и чипсет(через 4 секунды) на материнке. А в гараже вольтметр(электронный, питается от измеряемой цепи) подключенный к 2-м метрам свободно висящих проводов просто разлетелась физически микросхема на части, не говоря о сгоревших защитных стабилитронах в питании.
И еще интересное замечание. Герконы ведь обычные контакты, чтобы считать их состояние необходимо «подпереть» их резисторами, а в некоторых комбинациях(все счетчики остановились в состоянии «замкнуто») ток через эту подтяжку может свести на нет все старания по энергосбережению. Имеет смысл, включать подтяжку за 100-200мкс до считывания состояния датчиков и после отключать. И подтяжку сделать посильнее, 1...5кОм иначе могут запросто ловится наводки, 50кОм — уже ловит статику по входу как изменение уровня, встроенная подтяжка тоже никуда не годится — слишком мягкая.
Все сигналы с датчиков желательно зашунтировать супрессорами, иначе ардуинка вылетит вмиг от близкой грозы, все-таки провода слишком близки от труб в которых будет наводится напряжение от ЭМИ грозового разряда. Поверь, это будет не лишним — есть печальный опыт всего лишь торчащим проводком длиной 30см из обесточенного компьютера — при следующем включении сгорел RS-232 выходной драйвер(с дымком) и чипсет(через 4 секунды) на материнке. А в гараже вольтметр(электронный, питается от измеряемой цепи) подключенный к 2-м метрам свободно висящих проводов просто разлетелась физически микросхема на части, не говоря о сгоревших защитных стабилитронах в питании.
Добавлю что есть не дорогии готовые устройства кроме пульсара, которые могут считать импульсы:
1. Достаточно известный проект: MegaD-328 ab-log.ru/smart-house/ethernet/megad-328
2. Можно использовать контролер от НАГ ERD-COUNTER-1.0 shop.nag.ru/catalog/00007.Avtomatizatsiya-i-monitoring/05629.Mikrokontrollery/09999.SNR-ERD-COUNTER-10 в котором уже встроенна батарейка и сть место под Flash карту
Цены на оба устройства достаточно гуманные, подвязать к своим системам учета не составляет проблем, есть полная документация по API
1. Достаточно известный проект: MegaD-328 ab-log.ru/smart-house/ethernet/megad-328
2. Можно использовать контролер от НАГ ERD-COUNTER-1.0 shop.nag.ru/catalog/00007.Avtomatizatsiya-i-monitoring/05629.Mikrokontrollery/09999.SNR-ERD-COUNTER-10 в котором уже встроенна батарейка и сть место под Flash карту
Цены на оба устройства достаточно гуманные, подвязать к своим системам учета не составляет проблем, есть полная документация по API
А я вот настраиваюсь на такое решение для всех счётчиков:
habrahabr.ru/company/medgadgets/blog/231705/
В моём случае, оплата идёт через онлайн, заполнений бланков и распечаток не надо :)
habrahabr.ru/company/medgadgets/blog/231705/
В моём случае, оплата идёт через онлайн, заполнений бланков и распечаток не надо :)
Реализовал подобное в рамках своего «Умного дома»
Только еще договорился с ТСЖ, о том, что они будут принимать показания по электронной почте. Соответственно добавил скрипт который 25 числа отправляет письмо и теперь вообще об этом не думаю. Поговорите, может и у вас можно договориться.
Только еще договорился с ТСЖ, о том, что они будут принимать показания по электронной почте. Соответственно добавил скрипт который 25 числа отправляет письмо и теперь вообще об этом не думаю. Поговорите, может и у вас можно договориться.
Вот скрипт для автоматической отправки показаний счетчиков воды через pgu.mos.ru (для жителей Москвы)
github.com/basiliocat/scripts/blob/master/pgu/pgu.sh
Работает на FreeBSD/Linux/MacOS, требует curl и jq
github.com/basiliocat/scripts/blob/master/pgu/pgu.sh
Работает на FreeBSD/Linux/MacOS, требует curl и jq
А как ардуино узнает, что геркон замкнулся?
А, у счётчиков шнурок есть свой оказывается.
Мне просто сегодня ставили счетчики, я их только сейчас вживую увидел. Этот шнурок можно прямо в ардуину втыкать?
Мне просто сегодня ставили счетчики, я их только сейчас вживую увидел. Этот шнурок можно прямо в ардуину втыкать?
Прямо воткнуть ты всегда успеешь. Перед этим надо убедится что ты все делаешь правильно: 1) как работает выход счетчика, 2) что ардуина ожидает именно такое поведение от подключенного к ней счетчика при помощи этого шнурка, 3) защита от статики и сильных наводок(например от грозы) на длинный(более 10см) провод.
В данном коде есть цикл, которые опрашивает ее состояние. Еще предлагали вариант реагирования на события, но я не стал ничего менять.
Добрый день! Собрал аналог вашего девайса на батарейках. Вдруг будет полезен: habr.com/post/418573
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Автоматизация снятия показаний со счетчиков воды