Пользователь
0,0
рейтинг
12 августа 2014 в 00:02

Автоматизация снятия показаний со счетчиков воды из песочницы

Все знают, что лень двигатель прогресса. Так случилось и в моем случае.



В квартире присутствует 6 точек раздачи воды (3 холодные и 3 горячие). На каждой из точек стоит счетчик.
Каждые 2 счетчика спрятаны за люками скрытого монтажа, один из люков находится за зеркалом, которое нужно снять, чтобы до него добраться.

Раз в месяц с 20 по 25 число необходимо снимать показания со всех счетчиков и отправлять данные в Управляющую Компанию на бланке определенного образца.

В какой-то момент мне надоело открывать люки, снимать зеркало и было решено автоматизировать снятие показаний.

Вот, для примера, пара люков (открытый и закрытый):



Сначала перерыл интернет на предмет существующих устройств автоматизации. Нашел только один для меня подходящий — Счетчик импульсов-регистратор «Пульсар» 6-ти канальный. Надо сказать, что стоит он почти 6000 рублей! На самом деле в розницу нигде я его не видел, так как слишком специфический продукт и предполагается, что закупать их будут ТСЖ на все квартиры в доме. Попытался его заказать через интернет в разных местах, но каждый раз, как только доходило до доставки, продавец пропадал. Как я понял, они не любят работать с «физиками», либо был не слишком настойчив.
Ну, нет, так нет — сделаем сами, да еще и дешевле.

Тут то и пригодилась Arduino Mega 2580 с Ethernet модулем, которая была когда-то куплена для различных экспериментов.

Когда делали ремонт в квартире, от каждой точки, где имеются счетчики, до щитка на лестничной клетке, были проложены кабели типа UTP cat 5e. Это было одно из требований контролирующей организации, чтобы в будущем снимать все показания централизованно. Будущее все никак не наступает, а провода пригодились.

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

В итоге, что мы имеем:
  • Счетчики воды
  • Arduino Mega 2580
  • Arduino Ethernet 3.0
  • Бокс для Arduino
  • Блок питания
  • Шлейф для протягивания из слаботочного щитка в шкаф к Arduino.
  • Домашний сервер на Debian с Lighttpd и Mysql

Сами счетчики такие:



Экспериментальным путем было определено, что счетчики работают не просто, а очень просто. Когда последний разряд меняет свое значение с 9 на 0, замыкается геркон внутри счетчика и это значит, что утекло еще 10 литров воды. В таком состоянии он находится до того, пока значение последнего разряда не станет равным 3. Т.е. фактически нам надо фиксировать момент перехода из состояния «разомкнуто» в состояние «замкнуто». Заострю внимание, что мы фиксируем ТОЛЬКО факт перехода из одного состояния в другое, потому что система может обесточиться, да и вообще, мало ли какие могут быть коллизии.

В момент замыкания геркона, Arduino по HTTP вызывает простенький perl-скрипт на сервере, где крутится lighttpd. Скрипт записывает в базу данных этот момент. Другой скрипт позволяет смотреть текущее состояние счетчиков.

Скетч Arduino с комментариями:
#include <Ethernet.h>
#include <SPI.h>
#include <Bounce2.h> // Эту библиотеку необходимо скачать тут: https://github.com/thomasfredericks/Bounce-Arduino-Wiring

byte mac[] = {0x90,0xA2,0xDA,0x0E,0xF1,0x92}; // MAC-адрес нашего устройства (написан на наклейке платы Ethernet shield)
IPAddress ip(192,168,1,11); // IP адрес, если вдруг не получится получить его через DHCP
//IPAddress server(192,168,1,10); // ip-адрес удалённого сервера (использовался, пока не было имени)
char server[] = "smarthome.mydomain.ru"; // Имя удалённого сервера
char request[40]; // Переменная для формирования ссылок
int CounterPin[6] = {22,23,24,25,26,27}; // Объявляем массив пинов, на которых висят счетчики
char *CounterName[6] = {"0300181","0293594","0300125","0295451","0301008","0293848"}; // Объявляем массив имен счетчиков, которые мы будем передавать на сервер
Bounce CounterBouncer[6] = {}; // Формируем для счетчиков Bounce объекты
EthernetClient rclient; // Объект для соединения с сервером

void setup() {
  //Serial.begin(9600);
  for (int i=0; i<6; i++) {
    pinMode(CounterPin[i], INPUT); // Инициализируем пин
    digitalWrite(CounterPin[i], HIGH); // Включаем подтягивающий резистор
    CounterBouncer[i].attach(CounterPin[i]); // Настраиваем Bouncer
    CounterBouncer[i].interval(10); // и прописываем ему интервал дребезга
  }
  // Инициализируем сеть
  if (Ethernet.begin(mac) == 0) {
    Ethernet.begin(mac, ip); // Если не получилось подключиться по DHCP, пробуем еще раз с явно указанным IP адресом
  }
  delay(1000); // даем время для инициализации Ethernet shield
}

void loop() {
  delay(1000); // Задержка в 1 сек, пусть будет. Мы уверены, что два раза в секунду счетчик не может сработать ни при каких  обстоятельствах, потому что одно срабатывание - 10 литров.
  // Проверяем состояние всех счетчиков
  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 запрос
      }
    }
  }
}

// Функция отправки HTTP-запроса на сервер
void sendHTTPRequest() {
  if (rclient.connect(server,80)) {
    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();
  }
}


На сервере крутится: Debian, Lighttpd, Mysql. В свою очередь на нем имеется два perl-скрипта: один для записи состояний счетчиков в базу, второй для вывода текущих показаний.

input.pl
#!/usr/bin/perl -w

use strict;
use CGI::Fast;
use DBI;

while(my $q = CGI::Fast->new)
{
    main($q);
}

sub main
{
    my $q = shift;
    my $dbh = DBI->connect( "dbi:mysql:database=smart_home;mysql_client_found_rows=1;mysql_enable_utf8=1;mysql_socket=/var/run/mysqld/mysqld.sock", 'dbname', 'password',
    {
        RaiseError => 1,
        AutoCommit => 1,
        mysql_multi_statements => 1,
        mysql_init_command => q{SET NAMES 'utf8';SET CHARACTER SET 'utf8'}
    } ) or die "Cannot connect";
    $dbh->{mysql_auto_reconnect} = 1;
    print "Content-Type: text/html; charset=UTF-8\n\n";
    print "OK\n";
    my $object = $q->param("object");
    if ($object)
    {
        $dbh->do(q{INSERT INTO water_count (object) VALUES(?)},undef,$object) or die $dbh->errstr;
    }
}


result.pl
#!/usr/bin/perl -w

use strict;
use CGI::Fast;
use DBI;

# массив стартовых показаний счетчиков
my $start = {
    "0300125" => 102.53,
    "0301008" => 75.31,
    "0300181" => 65.92,
    "0293594" => 54.51,
    "0293848" => 55.04,
    "0295451" => 87.43
};

while(my $q = CGI::Fast->new)
{
    main($q);
}

sub main
{
    my $dbh = DBI->connect( "dbi:mysql:database=smart_home;mysql_client_found_rows=1;mysql_enable_utf8=1;mysql_socket=/var/run/mysqld/mysqld.sock", 'dbname', 'password',
    {
        RaiseError => 1,
        AutoCommit => 1,
        mysql_multi_statements => 1,
        mysql_init_command => q{SET NAMES 'utf8';SET CHARACTER SET 'utf8'}
    } ) or die "Cannot connect";
    $dbh->{mysql_auto_reconnect} = 1;
    print "Content-Type: text/html; charset=UTF-8\n\n";
    print "Текущие показания счетчиков:<br>";
    my $sql = "SELECT count(*) as c,object FROM water_count group by object";
    my $sth = $dbh->prepare($sql);
    $sth->execute;
    while (my ($count, $object) = $sth->fetchrow_array())
    {
        $start->{$object} = sprintf("%.2f",$start->{$object}+$count/100);
    }
    $sth->finish;
    foreach my $object (keys $start) {
        my ($intcurrent,$fine) = split(/\./,$start->{$object});
        print "$object <b>$intcurrent</b>.$fine<br>\n";
    }
}


Mysql база с одной таблицей:
CREATE TABLE `water_count` (
  `object` varchar(20) NOT NULL DEFAULT '',
  `datetime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8


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

Вот, собственно, и все. Теперь в любой момент я могу узнать какое значение имеют все счетчики, просто зайдя браузером на домашний сервер.

Что дальше?
Дальше хочется ежемесячную автоматическую распечатку на заполненном бланке.
Так же хочется подключить счетчик электроэнергии с передачей данных в Мосэнергосбыт, а потом и с их оплатой.
Статистика, графики и прочие радости работы с данными.
Dmitry Lunin @BlackRaincoat
карма
14,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (133)

  • 0
    Круто :) Всегда мечтал чтобы коммуналка оплачивалась сама собой !) Но мне кажется, что не стоит дублировать механизм счетчика в ардуино, тем более, как правльно было замечено, могут быть перебои в подаче электричества. Почему-бы не поставить инфракрасные диоды и камеру, подцепить все это добро, например, к тому же ардуино и делать фотографии раз в минуту (или реже), а на сервере натравить на фотки OCR и полученные значения писать в БД.
    • +1
      Уже был такой пост, только счетчик был газовый. Но там была камера и OCR.
      • +2
        • 0
          Спасибо!
      • 0
        Только хотел написать, что вебкамера и фонарик как-то проще =)
        • +2
          слабо маштабируемо… представь себе 6 камер и 6 фонариков… а еще камере нужно расстояние для фокуса, а если счетчик впритык к крышке?
          Чтобы небыло фигни с пропущенными импульсами — счетчик должен быть аппаратный с резервным питанием от литиевой батареи — например, 561ИЕ10(или её аналоги) — а уже контроллером с питанием только от сети считывать состояние счетчика, вычислять приращение и скидывать данные на сервер. Причем контроллер можно включать раз в сутки, счетчик может обеспечить автономность счета до 255 импульсов, а это 255 кубов воды между считываниями без потери данных.
          • 0
            А ещё в счётчике, помимо резервного питания, должен быть резервный канал связи либо EEPROM что бы накапливать не отправленные значения.
            • 0
              Не нужен, если не нужны моменты времени то счетчик себе будет считать… чего его сохранять-то? Как появится напряжение так и будет обработана разница между предыдущим отправленным и текущим, лишь бы эта разница не превышала 255 единиц(для 8 бит счетчика).
              • 0
                Лично мне было бы интересно видеть статистику расхода воды в течении дня.
                Ах да, ещё и RTC нужен :)
                • 0
                  Часто бывает потеря электричества на целый день? Ну, подумаешь местами на время отключения света статистика будет несколько сглажена, зато скольких проблем удастся избежать. Другое дело конечно если вы педант и даже такая мелочь вас беспокоит… тогда да, потраченные ресурсы скорей всего будут оправданы.
          • 0
            1 импульс счетчика = 10 литров.
            255 импульсов = 2 550 литров, это не 255 л.к.
    • +6
      Можно раз в год(!) глазами посмотреть и сверить показания.
      Если за это время (из-за перебоев) накопились какие-то расхождения между показаниями и подсчитанными импульсами, ничего страшного не случится, можно разницу оплатить и потом.
      • 0
        Поддерживаю
        В определенный момент выяснил, сколько в среднем мы потребляем, поэтому показания вношу ежемесячно по среднему, а раз в год — визуальное снятие показаний и коррекция.
        • +1
          Тоже так делал, но в последнее время слишком не равномерно стали мы жить в квартире.
          Да и момент статистики в данном решении тоже интересен. Теперь я знаю сколько какой воды тратит тот или иной член семьи в душе или сколько «стоит» принять ванну. :)
          • 0
            Как хорошо быть сибаритом, не заморачиваешься такими мелкими проблемами.
        • 0
          К сожалению, тоже так думал, пока как-то раз пол года не сдавали показания на съемной квартире, а когда нужно было съезжать заплатили 22к (да, именно 22к за 6 месяцев на 4х людей) из-за того, что протекал бачок унитаза и никому до него не было дела…
          Наученный опытом, я бы не отказался от такой автоматизации, т.к. теперь каждый месяц тщательно слежу за расходом :)
    • 0
      Судя по моему опыту использования малины и вебкамеры в качестве видео наблюдения перед входной дверью, веб-камеры не очень хорошая затея. За полгода у меня вышло из строя 2 камеры (logitech c270), по всей видимости матрица выгорает. Тут конечно нагрузка будет меньше, но настораживает.
  • +7
    Мне кажется, лучше число срабатываний геркона хранить в самой ардуине и передавать каждый раз на сервер не сам факт увеличения показаний на единицу, а значение счетчика целиком. Это позволит избежать расхождения показаний, когда сервер по какой-то причине не может принять данные: завис, обслуживался, отключился свитч и т.д.
    • –2
      Для начала стоит задуматься над тем сколько нужно TCP пакетов для передачи единственного int32 значения.
      А потом стоит посмотреть как работает пульт телевизора в плане экономии энергии, что такое powerdown контроллеров Atmel и что такое WakeUp через reset, вопросы «пропадания» питания отпадут сами-собой. В таком режиме контроллер будет работать от батарейки месяцами!
      В качестве направления для размышлений:
      Алгоритм программы крутится вокруг: проснуться, инкрементировать значение в EEPROM, отправить (если нужно), уснуть, долгий сон (вода ведь не постоянно льется?) проснуться…
      • 0
        Для начала стоит задуматься над тем сколько нужно TCP пакетов для передачи единственного int32 значения.

        А ничего что автор по http текстовку в «sendHTTPRequest(); » гоняет, байтом больше\меньше…
        что такое powerdown контроллеров Atmel и что такое WakeUp через reset, вопросы «пропадания» питания отпадут сами-собой. В таком режиме контроллер будет работать от батарейки месяцами!

        1) Автор кормит мегу от блока питания.
        2) Автор не заморачивается прерываниями и спящим режимом — delay и поскакали дальше.

        Совет Iv38, применительно к этому проекту, очень логичный. Добавлю — для Ардуино надо back up питание прикрутить от батарейки, иначе при пропадании 220В будет расхождение со счетчиком. Дешевый вариант — внешний аккумулятор для мобилы.
        • –2
          Капец велосипедостроителей развелось… PCF858x — часы с календарем, резервное питание уже предусмотрено и многие из них имеют независимый счетчик событий. На худой конец — есть такая микросхема 561ИЕ10, она правда с параллельным выходом но у меги достаточно свободных входов для этого.

          Аккумуляторы телефонные… да батарейки CR2025 хватит на десятки лет — она скорей помрет из-за саморазряда. А телефонный аккумулятор работая в «резервном режиме» постоянно под напряжением сдохнет гораздо быстрее. Неужели в этом есть необходимость? Еще и схему правильного заряда литиевого аккумулятора городить… из мухи слона делаете.
          • +4
            Да, с помощью Ардуино развелось, нас «велосипедистов» — как грязи.
            Мы забиваем гвозди микроскопом, гоняя на ATmega1280 код достойный Attiny85. Видимо мы понимаем, что время потраченное на глубокое изучение контроллеров, их Dev среды для нас (при штучном производстве то) никогда не окупит сэкономленного кВт электроэнергии. Напомню — это 4 рубля максимум.
            Автор привел альтернативу с Пульсаром, он получил экономию.
        • +2
          Похоже я вчера погорячился, в час ночи-то. Сеи гневные комментарии не в адрес автора (хотя и в его адрес, в какой-то мере), а в адрес Ардуино, и ее способности заставать человека забивать гвозди Адронным Коллайдером. Скоро в место пары обычных TTL/CMOS вентилей будем лепить ноутбук с вебкой для фотографирования показаний счетчика и связью с кластером на пару гигафлопс для распознавания этих фоток (и пробегающего мимо котика :) )

          для Ардуино надо 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
            Или есть причины, которых мы не знаем, по которым счетчик не может сработать более 2 раз в секунду (неплохо бы написать в статье в таком случае)

            Есть такие причины. Одно срабатывание = один оборот счетчика. Это 10 литров. Максимальный расход через бытовой счетчик 1,5 м3\ч = 0,42 литра в сек.
            • 0
              Последняя цифра на счетчике это сотни литров, а геркон срабатывает на каждый кубометр…
              • 0
                Верхняя фотография горячего счетчика автора — 56,995
                995 — это литры текущего куба.
                Под ним круглый циферблат с красной стрелочкой — это 1 литр разбитый на 10 частей.
                Геркон срабатывает на один оборот этой стрелки. То есть на один литр.
                П.С. У меня такой же счетчик стоит. Инфа 100%.
                • 0
                  А, если так то да… тогда 10 литров/сек. Одно ведро воды за 2 секунды, много…
                • 0
                  Все-таки геркон срабатывает не на 1 литр, а на 10 литров и на полный оборот последнего сегмента в счетчике, а не стрелки.
                  • 0
                    Вчера на своем счетчике проверил, у меня тоже так — одно срабатывание на 10 литров, то есть на один оборот младшего разряда.
                  • 0
                    Точно, твоя правда! Извини что ввел в заблуждение. Вспомнил — учитываю и замыкание и размыкание по такой логике:
                    замыкание — 59,980
                    размыкание — 59,982
                    замыкание — 59,990
                    • 0
                      Зачем размыкания фиксировать?
                      • 0
                        Точность чуть выше. Смотри 59,982. По жизни это не нужно, просто заморочка.
                        • 0
                          Понятно. А на чем собрана система?
                          • 0
                            www.digitalsmarties.net/products/jeenode
                            это ATmega328 + радиомодуль RFM12B. У меня проводов не было, 220 нашел.
                            Одна нода считывает показания и хранит в памяти значение потребления, висит в ванной.
                            Вторая нода питается от батарейки, принимает и выводит на экран www.digitalsmarties.net/products/graphics-board
                            Есть еще третья нода — рулит подогревом пола на балконе, шлет на 2 ноду текущую температуру, энергопотребление (чисто фан).
                            Написано и собрано 2 года назад, код уже утерян — оно работает, я не лезу
                            • 0
                              Спасибо, надо будет как альтернативу посмотреть.
          • +1
            Конечно причины есть. Представь себе через полдюймовые трубы расход воды более 1куб.м./сек… представил? да это во много раз выше сверхзвука… даже если трубу разорвет в пух и прах расход и то меньше будет.
            • 0
              Спасибо — это действительно аргумент, претензия снимается
            • 0
              Только не один куб, а 1 литр в сек.
              Все равно это очень много и не реально конечно. Давление думаю нужно за 100 Атм
              • 0
                .
              • 0
                Последнее колечко в литрах, значит геркон будет срабатывать каждые 10 литров — более 10 литров в сек расход должен быть чтобы учет воды стал глючить.
        • +1
          Блок питания ставил сознательно.
          Объясню, почему.
          Была возможность питать через USB от сервера и через него же передавать значения. Отвергнуто из-за невозможности отправки данных на удаленный сервер.
          Еще статистика — за 3 года в этой квартире, электричество не отключалось ни разу.
          Плюс момент энергобезопасности решался, когда делали ремонт. В серверном шкафу стоит бесперебойник (там же сервер и Arduino) и от него дополнительно по всей квартире разбросаны отдельные розетки ( в частности в кабинет к компу, к аквариумному оборудованию, к стойке в зале). Заморочился, в общем.

          А вот про прерывания и спящий режим можно подробнее?
          • +5
            Если в двух словах:
            Прерывания — это аналог «события» в языках высокого уровня. То есть случается у вас смена уровня на ножке, переполнения таймера, или другое событие (см. документацию) вызывается участок кода, который отвечает за обработку этого события (вы сами пишите что делать). То есть работает основной цикл, что-то считает, отправляет, и тут вдруг изменилось значение на ноге (или выставилось заданное) под действием внешних источников (кнопка, геркон, другой МК, внешняя микросхема) — вызвался кусок кода который его посчитал. Дальше управление передается в основной цикл программы в то место где прервалось. Прерывания позволяют реагировать на внешние события не отвлекаясь на постоянное ожидание, а когда же оно случится, и позволяет (в большинстве случаев) не пропустить это событие.

            Спящий режим — это режим сниженного энергопотребления. Мега может просыпаться по множеству условий («Собачий таймер», сброс, прием по USART, по прерыванию INT0/INT1, и т.д.), Режимов сна много, отличаются тем что работает, а что отключено. Соответственно разные способы выхода из сна. Рекомендую обратиться к даташиту на мегу, там все подробно и просто (с примерами).

            Упомянутый пульт ДУ работает по алгоритму: если нажата кнопка — подается питание на контроллер он отрабатывает нажатие, кнопка отпускается — батарейка физически отключается от контроллера. Время нажатия вполне достаточно для обработки всего что нужно и отправление контроллера в сон (хотя там не контроллер а спец микросхема). Но данный алгоритм вполне можно приспособить с помощью прерываний и глубокого сна к меге (что-бы не снимать с нее питание полностью).

            Если интересуетесь электроникой, и микроконтроллерами (от Atmela до ARM) рекомендую заглянуть на сайт DIHALTeasyelectronics.ru, но предупрежу что DiHALT недолюбливает Ардуино (ввиду негуманной цены и еще много чего), даже разработал свою отладочную плату — очень занятная. Хотя я предпочитаю изготавливать платы сам исходя из задачи. На его сайте и на Хабре полно статей с описанием технологии. Хотя подход к задаче зависит от задачи, желания и фазы луны.
            • 0
              Спасибо большое за развернутый ответ.
          • +1
            С прерываниями будет все же сложней. На первый взгляд кажется все просто, но прерывания очень чувствительны к дребезгу в отличие от существующего вашего кода. Так одно срабатывание геркона может дать десяток импульсов, в итоге чтобы это побороть нужно усложнять аппаратную часть либо программную чтобы подавить этот самый дребезг, в итоге сложность проекта повысится на ровном месте.
            Более того, удобных выводов под прерывание в контроллере только два, которые можно настроить на один фронт, остальные источники прерывания по любому пину не различают фронт или спад — срабатывают по изменению уровня, и необходимо дополнительно проверять в прерывании текущий уровень чтобы отличить фронт от спада, но между этой проверкой и возникновением прерывания проходит время из-за дребезга или по другой причине уровень вызвавший прерывание и тут же считанный для проверки могут отличаться — появятся сбои в работе.

            Единственное что вместо вашей задержки вставить элементарный SLEEP, а один из таймеров(16-битный скорей всего) настроить на счет около 200...500мс(все-таки периода в 1 сек это довольно много) и организовать ему прерывание по переполнению с пустым обработчиком — оно будет выводить контроллер из спячки, который считает состояние датчиков выполнит необходимое действие и дальше спать. В принципе, даже при питании от БП такой алгоритм пригодится. Можно еще аппаратный вач-дог настроить на период в 2 сек, если вдруг зависнет и сбрасывать его когда считываете состояние датчиков…
          • 0
            вот тут по прерываниям arduino.cc/en/Reference/Interrupts
            тут по sleep states donalmorrissey.blogspot.ru/2010/04/putting-arduino-diecimila-to-sleep-part.html
            Но вот на счет не нужности их использования, согласен с Alexeyslav:
            прерывания очень чувствительны к дребезгу в отличие от существующего вашего кода. Так одно срабатывание геркона может дать десяток импульсов

            надо усложнять схему, ставить фильтр (конденсатор, индукционную емкость), у вас нет проблем с питанием, экономить батарейку не надо.
            • 0
              да ладно? А кто мешает обработать дребезг программно, аналогично способу примененному в программе автора?
              Кроме того, избавиться от дребезга (особенно дребезга раздолбанной кнопки) емкостями не получится. Все равно придется делать программную «защиту»
              • 0
                да… городить историю с прерываниями чтобы потом дополнительно бороться с дребезгом программно — замечательный способ нагрузить себя ненужной работой. Существующий подход и так хорошо справляется с работой. Только надо иметь в виду, что длина импульса с геркона — всего 2-3Л, т.е. при скорости потока 2Л/сек и больше существует шанс что программа не заметит импульс, впрочем при таких значениях эту особенность скорее надо иметь в виду чем что-то предусматривать. Вдруг устройство попытаются поставить на промышленный трубопровод, где поток воды больше… а тут такая засада.
                • +1
                  На самом деле длина импульса может длиться много больше, в случае, когда закрыли кран на значении последнего разряда 1 или 2. Так и будет состояние замкнуто висеть, пока не сольем еще литр-два воды.
                  • 0
                    вот интересно, а можно остановить гиркон так, чтобы он находился в состоянии перманентного дребезга пока снова не откроют кран?
                    • 0
                      Интересная ситуация, но это надо у знатоков спрашивать.
                    • 0
                      Мне кажется, у геркона должен быть гистерезис, так что зависнуть в совсем нестабильном состоянии не выйдет.
                      • 0
                        Зависнуть он не может, но от вибрации не застрахован, правда у мелких герконов вибрация нужна такая что его просто разорвет в клочья. В целом, конечно герконы срабатывают четче чем механические кнопки.
                  • 0
                    больше-то оно не вредно, речь идет о минимальной длительности — вдруг импульс проскочит мимо проверок, и не будет зарегистрирован… Это граничное условие — импульс длительностью ровно в период опроса. Больше — будет зарегистрирован всегда, меньше — как повезет. В данном случае, геркон замыкается на протяжении 2-3Л по счетчику, нетрудно догадаться при каком расходе счетчик даст импульс короче одной секунды и соответственно когда начнутся проблемы.
            • +2
              Все эти фильтры не избавляют от дребезга, только лишь уменьшают его влияние. Ну зафильтруешь, всеравно фаза луны сойдется и пропустит один из тысячи импульсов дребезга. Самый надежный способ избавления от дребезга — это одновибраторы(но повышается чувствительность к помехам — ведь любой самый короткий импульс будет рассмотрен как срабатывание) или синхронный триггер защелкивающий состояние линии каждые N милисекунд, где N заведомо больше периода дребезга контакта.
              Собственно, второй вариант с синхроным триггером сейчас и реализован программно — данные защелкиваются для последующего анализа раз в секунду. Недостаток этого подхода — негарантированное время реакции на срабатывание.
              • 0
                Вот что происходит если пытаться убрать дребезг с помощью конденсатора… Резистор 250 Ом имитирует входное сопротивление порта меги (5В; 20мА)


                Что-бы не разводить холивар пример антидребезгового алгоритма с сайта DiHalt-a:
                Алгоритм прерывания с антидребезгом будет выглядеть так:
                Зашли в обработчик INT0
                0 или +1
                Запретили локально INT0
                Поставили на таймер событие разрешающее INT0 через несколько миллисекунд
                Вышли из обработчика
                • 0
                  Это вызовет большие трудности если надо ловить таким образом больше одного прерывания.
                  • 0
                    Мега принципиально не умеет работать с несколькими прерываниями — у нее нет стека соотвественно невозможно вызывать прерывание из прерывания, а не основного цикла. Первое прерывание будет перебито вторым и произойдет потеря данных, но это крайне редкие случаи в системах (когда накладываются два прерывания) для которых предназначена Мега (за все мое время использования меги такое случалось 1 раз при тестировании вложенных прерываний — то есть было искусственно вызвано)

                    Для решения таких задач (иерархичность прерываний) лучше использовать ARM.
                    • 0
                      Для примера рассмотрите задачу обработки нажатия кнопок на клавиатуре. Я хочу видеть человека, который сможет клацать по кнопкам со скорость <100-150 мс на нажатие (это что-то около 600 символов в минуту). Помнится раньше были часы в виде пейджера, так вот мы пробовали нажать две рядом стоящие кнопки (стар таймера и сто) с максимальной скоростью. Быстрее чем 200 мс никто не смог, а если жать одну два раза — то все 500-700 мс.
                      Кстати по алгоритму выше легко реализуется опция постоянного инкремента при зажатой кнопкой. В одну строку.
                      • +1
                        200мс в тех часах это скорей всего период сканирования кнопок клавиатуры, раньше он просто видимо не успевает зарегистрировать факт нажатия. да и речь все же идет не о кнопках а датчиках, которые срабатывают хоть и медленно но полностью асинхронно и независимо друг от друга — могут ведь сработать и все 6 одновременно с точностью до десятков наносекунд!
                        Будет очень смешно и весело, если программа не справится с одновременным нажатием кнопок…
                        • 0
                          а вы никогда не нажимали 4-5 кнопок на клавиатуре одновременно?
                          • 0
                            Мы уходим от темы, в обычных клавиатурах организация матричная и коллизии при нажатиях двух и более кнопок неизбежны, так получается by design.
                            У нас же 6 входов ОТДЕЛЬНЫХ, умудрится сделать так чтобы программа вела себя не адекватно при одновременном срабатывании датчиков в произвольных комбинациях — это высший пилотаж.
                            Есть 6 входов, никаких матриц — поэтому логично требовать от программы работы во всех комбинациях и любыми одновременностями.
                            • 0
                              По опыту, гараздо проще обрабатывать отдельные абсолютно независимые входы (пусть даже и 6), чем разруливать колизии матричного исполнения (да и любого другого способа расширения количества подключаемых элементов сдвиговые регистры аля 74НС595, мультиплексоры и т.п.).
                              И у вас есть одна неточность: комбинации в данном примере не любые. Как было выяснено ранее если датчик сработал, его повторное срабатывание произойдет через значительный промежуток времени (в бытовых условиях, обусловлено ограниченной скоростью истекания воды из труб) достаточный для обработки сигналов других датчиков.
                              Но да, я с вами согласен обработать массив асинхронных величин на приеме требует некоторого умения и внимания к этой проблеме. Любая подобная система будет иметь ограничение разрешающей способности на уровне нескольких периодов тактового сигнала. В данном случае это не критично, так как датчик находится в состоянии замкнуто довольно продолжительный промежуток времени (даже с учетом дребезга) и обработать его значение не составляет большого труда (ну захватится его значение не на первом периоде дребезга а на втором, третьем или когда он выйдет на стабильный уровень) ведь в данной системе не предъявляются требования к определению точного времени срабатывания, главное их не пропускать, а это проще.
                              Алгоритм приема этих сигналов не будет иметь особых отличий при исполнении в прерывании или основном цикле программы. Описанные проблемы будут возникать как в первом так и во втором случае и придется принимать меры к их устранению. Применение прерываний и таймеров в данной задаче позволяет высвободить время на обработку и более жесткий контроль за отсутствием пропусков. Я предпочитаю стиль программирования контроллеров такой, в котором при наличии Hardware реализации той или иной возможности я отдаю предпочтение Hardware а не программной реализации. Обычно это немного снижает гибкость но значительно повышает надежность, скорость обработки, снижает размер использованного ОЗУ и памяти программ, (Имею ввиду что использую таймеры вместо delay, блок SPI вместо его программной реализации, и т.п.) что в тематике контроллеров является более критичным.
                              • 0
                                таймер или delay — это не так важно, просто с прерываниями появляются дополнительные проблемы — прерывание реагирует на каждый импульс в том числе и на дребезг и с этим что-то надо делать. Если же просто опрашивать кнопки со строго заданным интервалом то все эти проблемы решаются сами собой — и дребезг устраняется для всех датчиков сразу и узких мест нет. Просто считываем состояние датчиков в ячейку памяти, делаем XOR с предыдущим значением и у нас есть вся необходимая информация для решения — какой датчик изменил своё состояние и в какую сторону.
                                Именно с точки зрения логики этот алгоритм прост и легко проверяем а значит более надежен, хотя может и вылиться в большее количество строк чем с прерываниями. Но количество строк кода это не показатель, главное это сложность и надежность алгоритма.
                                • 0
                                  Если же просто опрашивать кнопки со строго заданным интервалом

                                  За время опроса первой кнопки, вторая перешла в состояние отжато из-за дребезга, вы прочитали отжато. А юзер пальцем ожесточенно тыкает и краснеть начинает. Что будете делать?
                                  делаем XOR с предыдущим значением и у нас есть вся необходимая информация для решения — какой датчик изменил своё состояние и в какую сторону.

                                  Предыдущее значение: 010010
                                  Текущее значение:101101
                                  Результат XOR:111111
                                  Подскажите по результату что и в какую сторону поменялось?

                                  Процессы протекающие в электрических цепях подчиняются не логике, а законам Киргофа и уравнениям Максвелла (хотя да они логичны)
                                  • 0
                                    не каждую в отдельности, а фиксировать их состояние в один момент времени. Да и в принципе какая разница с каким смещением будет зафиксирована вторая кнопка относительно первой. Они ведь не влияют друг на друга — независимые. Главное чтобы фиксация эта происходила только один раз в заданном интервале — это гарантирует защиту от дребезга при условии что интервал опроса заведомо длиннее времени дребезга.

                                    единица в результате функции XOR укажет нам какой из датчиков изменил свое состояние, а запомненное предыдущее или зафиксированное текущее покажет нам в какую сторону.
                      • 0
                        Часы Montana: таймер легко останавливался на 0,06 с, а если одну и ту же кнопку, то 0,12 с. Ещё и от самих кнопок зависит.
                    • 0
                      О нет, она конечно умеет при необходимости, но тут проблемы другого плана. Аппаратных прерываний всего два а надо 6 датчиков подключить… приходится задействовать прерывание по изменению состояния порта, а оно будет ОДНО на все датчики — это значит что надо будет отслеживать какой именно датчик привел к прерыванию, — эта операция не атомарна, состояние датчика из-за дребезга до проверки может изменится и программа не обнаружит ничего. Надо усложнять код, бороться с дребезгом и последствиями неатомарности операций — зачем этим всем забивать голову когда есть простые понятные и эффективные решения?
                      • 0
                        да ладно, у меги одно прерывание? ОДНО? когда вы даташит смотрели последний раз?

                        Ой прерывание чуть не на каждой ножке. 6 штук уж точно найдется.И да PCINT можно отработать с точностью до 1 нс. Так как выставляться они будут асинхронно.
                        • 0
                          Независимых прерываний тут только два — INT0 и INT1.
                          PCINTx имеют один общий обработчик на каждый порт и не умеют работать по отдельным фронтам — только на изменение уровня. замаешься определять какая ножка и куда перешла и потом обрабатывать эти события а потом еще и подавлять дребезг индивидуально по каждому входу, разруливать как-то ситуации когда прерывание по другому входу возникает во время обработки, а если оно возникнет в тот момент когда контроллер еще будет входить в прерывание еще до сравнения состояния входов?

                          Все это называется одним словом — из мухи раздувать слона. PCINT — хороши для матричных клавиатур, чтобы пробудить контроллер из спячки по нажатию любой кнопки.
                          • 0
                            На данный момент это работает в серийном изделии, код который разруливает описанные вами проблемы не сложен. Проблем не испытываем в том числе с дребезгом.
                            Каждая нога обрабатывается отдельно, антидребезг на каждую ногу инициируется отдельно. Также обрабатываются комбинации ножек. Задействованы 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 мкс?
                            • 0
                              Ну замечательно, чего. С дребезгом тут можно столкнуться, если вдруг состояние входа изменится между проверками — между UPDATE и READ. Отловить такое событие будет чрезвычайно трудно, но оно будет происходить.
                              И столько кода для считывания состояния входов? из мухи слона… нет, ну чем хуже просто считать все входы разом и потом их обрабатывать побитно, через сдвиг в цикле? Если вдруг состояние изменится после считывания — обработано будет в следующей итерации.
                              • 0
                                5-10 строк включая объявление переменных и работу с таймером.
                                нет, ну чем хуже просто считать все входы разом и потом их обрабатывать побитно, через сдвиг в цикле? Если вдруг состояние изменится после считывания — обработано будет в следующей итерации.

                                А я что говорил что оно не так работает? Это и есть основная идея работы, только при срабатывании PCINTx все собирается в нужном регистре с нужными флагами и в нужное время. Куда проще в обработке и в итоге в надежности и отсутствии пропусков…
                • 0
                  Резистор 250 Ом имитирует входное сопротивление порта меги (5В; 20мА)

                  Ну вы даёте, входное сопростивление порта меги — мегаомы, какие ещё 250 Ом? Там internall pull up-ы и то на десятки кОм.
  • 0
    Раз уж так доставляет неудобств ежемесячная процедура, оплати 1 раз на год перед воду и все… никаких приспособлений не нужно :)
    • +2
      Хрень в том, что показания надо сдавать минимум раз в 3 месяца: иначе надо вызывать из РЭУ (ДЭЗа или хз как называется, в общем — управляющей компании) сантехника, который ворча на весь мир должен снять эти показания, заверить бумагу и посеять в недрах бюрократии…
      • 0
        Причем, увидев значение на счетчике меньшее, чем Вы уже оплатили он ещё и начнет подозревать Вас в нечестных действиях и внешнего изменения показаний счетчика.
    • 0
      Также в данном случае Управляющую компанию сильно напряжет факт оплаты за год. Допустим, что Вы оплатили 100 куб. м. холодной воды в январе (примерно столько выходит за год у меня), а в июле 1 куб. м. холодной воды подорожал на 7% (это реально так у меня) и как Вы думаете, что решит управляющая компания?
  • 0
    У вас даже грязевики запломбировали, тяжелый случай.
    • 0
      Увы, у меня так же — и страна другая.
    • 0
      У меня тоже пломбировали. Логично же — оттуда неучтенную воду сливать можно.
  • 0
    Частично описывал это (серверную часть): habrahabr.ru/post/154185/
    • 0
      Надо, наверное, добавить, что МК считал импульсы и отсылал их на роутер по XBee. Проблема была с питанием — если питание пропадает, то данные «уходят».
  • 0
    Намного надёжнее на ардуине хранить кол-во импульсов и передавать его на сервер (как уже написали выше).
    Тогда недоступность сервера (довольно вероятная ситуация при отключении света в квартире света) не будет влиять на показания.

    А ещё можно добавить резервное питание, к примеру на базе USB PowerBank'а с одним-двумя Li-Ion аккумулятрами (главное чтобы он умел работать в нужном режиме) и на выходе получить автономный девайс с запасом на пару недель :)
    • 0
      Учитывая, что электричество пропадает довольно редко и ненадолго, то в качестве аварийного питания на долгое время хватит и обычных батареек, включенных через диод. А если озаботится сном контроллера и побудкой по прерыванию, то о них, наверное, можно забыть на годы.
    • 0
      литиевые аккумуляторы сюда не подходят, они скончаются через 2-3 года а необходимости в их огромной емкости нет. Просто чудовищный перерасход ресурсов!
      Всего-то ведь надо хранить под резервным питанием не больше 8 бит счетчика… а все остальное может и подождать — не критично. Для этого сойдет батарейка CR2025.
      Тем более, она работать будет только в отсутствие электричества — а оно врядли будет отсутствовать больше нескольких часов к ряду и не больше нескольких суток в год. Да даже если и больше…
  • 0
    Хм, сделал практический тоже самое но RaspberryPI. Самое проблематичное в этом всем это организация бесперебойного питания.
    • +1
      А можешь исходниками поделиться?
  • –1
    Экспериментальным путем было определено, что счетчики работают не просто, а очень просто. Когда последний разряд меняет свое значение с 9 на 0, замыкается геркон внутри счетчика. В таком состоянии он находится до того, пока значение последнего разряда не станет равным 3.

    Автор- экономлю кучу твоих нервных клеток в будущем.
    С 0 до 2 — это не постоянная величина. За время жизни этот промежуток дрейфует (чисто механический дрейф из-за износа счетчика видимо или погрешности деталей шестеренок).
    Как выловил — у меня ардуино с бекапом питания, все пишется в eeprom, и тут за год работы при сверке набегает расхождение.
    Уж чего только не думал, и на дребезг контактов грешил и на длительную работу без питания. А потом перепроверил — интервал сместился на 8 — 0. Еще через 3 месяца — опять новый(не помню уж и какой). Счетчику уже 5 лет, примерно 400 кубов пробега.
    • +1
      А чем это мешает? Ну небольшой дрейф, но на один оборот мнадшего разряда срабатывание все равно один раз. А вот дребезг контактов, мне кажется, может создавать проблему, особенно при медленном вращении счетчика, когда геркон относительно долгое время находится в состоянии на грани.
      • –1
        Проблема, что:
        на один оборот младшего разряда срабатывание все равно один раз.

        не один раз в итоге получается. Смотри на примере
        было 0-2,
        в след обороте 1-3,
        2-4
        3-5
        4-6
        5-7
        6-8
        7-9
        8-0
        9-1
        0-2
        Ардуиной ты насчитал 11 оборотов, а счетчик сделал 12.
        • +1
          То есть он на каждом обороте немного смещается и получается, что срабатывание происходит, условно говоря, на 0,9 оборота? Просто не могу представить как оно так может чисто механически. Я себе представляю, что там на колесике закреплен магнит, а рядом с колесиком стоит геркон. Как в такой системе может быть дрейф — ума не приложу. Надо на своих счетчиках попробовать последить.
          • 0
            По приведенному примеру — одно срабатывание на 1,1 оборота. Мои мысли на счет геркона были такими же на 100% — поэтому даже представить не мог этот дрейф, отсюда «Автор- экономлю кучу твоих нервных клеток в будущем. „
            Как сдохнет счетчик — разломаю, посмотрю. Мои мысли — возможно от основного вала приводятся во вращение два различные шестерни:
            — одна вращает литровую стрелку
            — вторая крутит магнит
            Теоретически при 100% совпадении в диаметре шестерен все ок, но видимо есть погрешность…
            • 0
              Это если бы диаметр колес был… а шестерни передаточное число определяется количеством зубьев и ничем больше.
            • 0
              И как решили эту проблему?
              • 0
                В скетч добавил обработку команд от COM порта — считать переменную\записать переменную
                Подрубаюсь по COM порту раз в год, сверяю показания и вношу правильное значение.
                Тебе можно проще — есть lib WebServer под этот wiznet 5100 — подними север и прям get запросами пиши\читай переменные.
    • 0
      Спасибо. Интересно, понаблюдаю.
      Пока же за 5 месяцев работы, расхождений не замечено.
  • 0
    Ёлки… Геркон?
    Дык взять простейший китайский велокомпьютер, да подключить прямо к счётчику!
    Можно даже попробовать выставить «длину колеса» так, чтобы показания одометра вместо километров дороги стали показывать кубометры воды.

    Схема получится тупая, как палка. И вполне энергонезависимая (от алкалиновой «таблетки» велокомп может работать пару лет точно. Больше не проверял).
    А ардуину можно уже прикрутить (или не прикручивать), чтобы снять показания с этих самых «датчиков с накоплением».
    • 0
      (кстати, всё ж не всякий. При очень большом интервале между импульсами они уходят в спячку. Идёт ли после этого «пробуждающий» импульс в счёт, или же просто будит и всё — неясно).
    • 0
      Тогда есть еще более олдовый способ. Берем дешевый калькулятор, припаиваем провода счетчика параллельно кнопке «равно», набираем изначальное значение счетчика, затем «плюс» и 0,01, наслаждаемся цифровым индикатором. К сожалению, как и велокомп, калькулятор будет засыпать в перерывах. Но самый существенный недостаток не в этом, а в том, что это фактически просто второй индикатор, он не дает особых преимуществ, ну, разве что его можно вынести в более удобное место. Тогда как описанный в статье способ позволяет делать с данными что угодно. Можно смотреть их на мобилке, можно строить графики потребления по времени, можно даже попробовать отправлять данные водоканалу автоматически.
  • 0
    Кто -нибудь экспериментировал со счетчиками без торчащего кабеля? В них тоже используются магниты для разделения мокрой и сухой среды и счетного механизма.
    Думал как-то то ли геркон прикрепить к корпусу, то ли дачит Холла и посмотреть осциллографом на сигнал с него… но не уверен, что чувствительности их хватит, все же счетчик в воде и металлическом корпусе.

    Вообще, мне кажется, собирать четко показания в течение года — и можно набрать статистику по сезонам, сколько в месяц тратится воды, плюс минус кубеметр — ерунда же… И потом только тот же скрипт будет сам подставлять статистические данные и печатать квиток… и просить раз в полгода производить коррекцию статистики
    • 0
      А если, например, ее делать в случайные периоды, то можно даже уточнять распределение по месяцам, ошибку распределять, как в геодезии…
  • 0
    А есть уже готовые подобные решения?
    • 0
      Да, я уже писал в статье про Пульсар. Он придуман специально для этого и предполагается, что он ставится в щиток на лестничной клетке.
    • 0
      Да, сейчас уже есть возможность установить счетчики, которые сами передают показания на общедомовой сервер, а далее в ДУК. Такие счетчики есть на воду, электричество, газ и отопление. Гуглить как «счетчики с цифровым выходом».
  • 0
    Доброго времени суток.
    Прошу великодушно меня простить, но Зоркий глаз заметил у вас торчащую систему защиты от протечек «Нептун». =)
    Как она? Не подводили клапаны? Давно стоит? Там 12v или 220v версия?
    Пробовали ручное открытие?
    • 0
      220v, используется 3,5 года. По-моему разница 220 от 12 в наличии БП, которые висят над Нептунами. Хотя могу ошибаться.
      Пока ни разу не пригодилась, но вручную раз в полгода замыкаю датчики, чтобы электроклапаны не закисали.
      Ручное открытие? Это как?
      • 0
        Понял Вас, спасибо.
        Тут написано что можно руками, предварительно обесточив и нажав на кнопку снизу. Как конкретно — не знаю ибо не имею возможности пощупать…
        Просто только заказываю, интересен опыт использования…
        • 0
          На самом клапане к меня нет кнопок.
          В случае срабатывания датчика Нептуна, чтобы открыть клапан, надо сначала обесточить систему и, после включения, Нептун открывает его.
          Вероятно, сейчас Нептуны идут уже более продвинутые. Мы в 2010 нашли только такие.
          • 0
            Да все верно. Вчера созванивался с ними уточнить, с ручным открытием это новая серия Bugatti Pro. Видимо их и буду брать…
  • 0
    В нашей прибалтийской стране, в столице, в добровольно-принудительном порядке всем поставили такие:

    image
    Пытаюсь придумать как бы прочитать с него данные, т.к. у него есть радиолинк 868MHz.
    • 0
      Ого. У него батарейка внутри? Какой ресурс? Он куда-то что-то передает сам или нужно сначала ему запрос кинуть?
      Вообще интересная штука, но без технической документации с ним будет не просто разобраться.
      • 0
        Да, батарейка. Написано 12 лет + 6 мес. (хранение).
        Вот как раз с документацией и беда, что удалось выяснить, так это скорей всего брендированная поделка Siemens, протокол обмена Q AMR.
        • 0
          Ну, тогда остается только перехватить эфир при помощи SDR-приемника и анализировать протокол.
          • 0
            Этим и займусь, куплю приемник на 868, послушаю эфир, статья меня вдохновила.
            • 0
              Лучше взять SDR на основе ТВ-тюнера, на EBAY уже наборы продаются для крупноблочной сборки. Всяко полезней будет чем приемник на ограниченный диапазон, а стоить примерно одинаково.
        • 0
          Это скорее всего KNX протокол
      • 0
        Между этажами висит вот такой приемник
        image
  • 0
    Автору спасибо за отличную идею.

    Мелкие предложения по доработке скетча:

    — отслеживание геркона повесить на interrupt — так вернее (http://arduino.cc/en/Reference/attachInterrupt)
    — вести промежуточный итог в eeprom и отправлять по ethernet его — так снимется проблема неполучения данных в случае downtime сервера
    • 0
      Да, по комментариям выше, уже понял, что это как раз именно то, что необходимо будет сделать.
      Сказывается отсутствие опыта при работе с Arduino. Публикация статьи как раз и предполагала, что люди поделятся своим опытом и соображениями.
    • 0
      Подходящих прерываний в контроллере только два, а датчиков 6. Если вешать датчики на обычный порт, в этом режиме прерывания не различают фронт/спад и будут давать два импульса на срабатывание. И это если не рассматривать проблему дребезга.
      Все-таки текущее решение прекрасно решает проблему дребезга, а в случае использования прерываний надо предпринимать специальные меры.
      • 0
        Согласен, в процессе создания проекта, дребезг без текущего программного решения действительно был очень заметный и доставлял много неприятностей.
        Был даже вариант, когда вешал конденсаторы для его устранения.
        • 0
          Конденсаторы это не выход, они лишь уменьшают дребезг но не избавляют от него совсем, один из ста импульсов все же проскочит.
          И еще интересное замечание. Герконы ведь обычные контакты, чтобы считать их состояние необходимо «подпереть» их резисторами, а в некоторых комбинациях(все счетчики остановились в состоянии «замкнуто») ток через эту подтяжку может свести на нет все старания по энергосбережению. Имеет смысл, включать подтяжку за 100-200мкс до считывания состояния датчиков и после отключать. И подтяжку сделать посильнее, 1...5кОм иначе могут запросто ловится наводки, 50кОм — уже ловит статику по входу как изменение уровня, встроенная подтяжка тоже никуда не годится — слишком мягкая.
          Все сигналы с датчиков желательно зашунтировать супрессорами, иначе ардуинка вылетит вмиг от близкой грозы, все-таки провода слишком близки от труб в которых будет наводится напряжение от ЭМИ грозового разряда. Поверь, это будет не лишним — есть печальный опыт всего лишь торчащим проводком длиной 30см из обесточенного компьютера — при следующем включении сгорел RS-232 выходной драйвер(с дымком) и чипсет(через 4 секунды) на материнке. А в гараже вольтметр(электронный, питается от измеряемой цепи) подключенный к 2-м метрам свободно висящих проводов просто разлетелась физически микросхема на части, не говоря о сгоревших защитных стабилитронах в питании.
          • 0
            Спасибо за ценные замечания.
  • 0
    Добавлю что есть не дорогии готовые устройства кроме пульсара, которые могут считать импульсы:
    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
  • 0
    А я вот настраиваюсь на такое решение для всех счётчиков:
    habrahabr.ru/company/medgadgets/blog/231705/
    В моём случае, оплата идёт через онлайн, заполнений бланков и распечаток не надо :)
    • +1
      Т.е. на каждый счетчик ставить по одному устройству за $69?
      И еще, наверное, придется делать освещение, ведь за люками темно. :)
  • 0
    Реализовал подобное в рамках своего «Умного дома»
    Только еще договорился с ТСЖ, о том, что они будут принимать показания по электронной почте. Соответственно добавил скрипт который 25 числа отправляет письмо и теперь вообще об этом не думаю. Поговорите, может и у вас можно договориться.
    • 0
      Да, про e-mail мысль.
      Кстати, ваша статья помогла вообще на это решиться. В загородном доме после уборочно-заготовительной страды начну городить электронный огород. :)
  • 0
    Вот скрипт для автоматической отправки показаний счетчиков воды через pgu.mos.ru (для жителей Москвы)
    github.com/basiliocat/scripts/blob/master/pgu/pgu.sh
    Работает на FreeBSD/Linux/MacOS, требует curl и jq
  • 0
    А как ардуино узнает, что геркон замкнулся?
    • 0
      А, у счётчиков шнурок есть свой оказывается.
      Мне просто сегодня ставили счетчики, я их только сейчас вживую увидел. Этот шнурок можно прямо в ардуину втыкать?
      • 0
        Прямо воткнуть ты всегда успеешь. Перед этим надо убедится что ты все делаешь правильно: 1) как работает выход счетчика, 2) что ардуина ожидает именно такое поведение от подключенного к ней счетчика при помощи этого шнурка, 3) защита от статики и сильных наводок(например от грозы) на длинный(более 10см) провод.
    • 0
      В данном коде есть цикл, которые опрашивает ее состояние. Еще предлагали вариант реагирования на события, но я не стал ничего менять.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.