Перейти к публикации
iT4iT.CLUB
EndWar

Не здоровый интерес к домашней автоматизации...))

Рекомендованные сообщения

@Alex_DIY думаю, что мы говорим об одном и том же, но немного по-разному.

В программе мы может узнать причину пробуждения, если память не изменяет, то поведать об этом нам могут

ESP.getResetReason();
ESP.getResetInfo();

Но, к сожалению, в случае внешнего прерывания это не поможет. Счетчики придется заводить также на RST, но не напрямую, а через обвязку в виде конденсатора или иным способом. Это нужно, чтобы порт подтягивался к земле кратковременно, в противном случае контроллер не запустится. Но этого по-прежнему будет не достаточно т.к нам требуется отличать какой из счетчиков нас побеспокоил. Видимо придется подтягивать RST дважды, при замыкании и размыкании сигнальной цепи счетчика. Тогда получится выделить по дополнительному порту, продублировать каждый из сигналов на них и таким образом ориентироваться в том, что происходит. Ну и сразу минусы:

  • Много обвязки
  • Просыпаться нужно в два раза чаще
  • Велика вероятность допустить ошибку в расчетах
  • Не нужные сложности

Но из-за спортивного интереса продолжим. Требуется передача показаний между пробуждениями. Для этого у нас есть доступ к области памяти, в которой можно хранить данные между циклами перезапуска ESP.

ESP.rtcUserMemoryWrite(offset, &data, sizeof(data))
ESP.rtcUserMemoryRead(offset, &data, sizeof(data))

Так мы может держать текущие показания под контролем, а в случае, если память пуста, диагностировать потерю питания и поднять тревогу, требуя пользователя произвести сверку значений. Также переносить эти значения в EEPROM при передачи данных на сервер умного дома, это каждые 10-100 литров по расходу.

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

Батарею какой емкости Вы используете? Какова частота замены аккумулятора? Рассматривали ли Вы варианты зарядки аккумулятора от солнечной батареи или другого источника?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А кстати, неплохая мысль по поводу ресетить ESP импульсным выходом счетчика. Правда все равно остаются условности и плюс ПЗУ чипа ESP, насколько у меня отложилось в памяти расчитан на не очень большое количество циклов перезаписи.

То как сейчас организован выход из deepsleep ESP это всего лишь выход из положения, то что он сам себя ресетит пином 16, поэтому как мне кажется через 

ESP.getResetReason();
ESP.getResetInfo();

мы будем получать одни и те же значения постоянно. А учитывая, что deepsleep ограничен максимум в 71 минуту, то фактически ESP будет просыпаться чаще и не иметь способностью определить причину пробуждения.

Лишняя обвязка - лишние затраты энергии, а при автономном питании надо это учитывать. Кому охота менять батарейку раз в месяц?  Сродни тому, что без заморочек глазами снимать показания.

2 часа назад, Kitsum сказал:

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

Мне понравилась идея с ATtiny + ESP мне понравилась, бегло глянул на характеристики, что может пробуждаться внешними прерываниями, во сне потребляет не много и пробуждения корректные с возвратом в управляющую программу. Одно но - программировать придется минимум на Си, а я его не знаю. + настройка чипа первоначальная с этим всем надо разбираться, а времени как всегда не хватает.

 

2 часа назад, Kitsum сказал:

Батарею какой емкости Вы используете? Какова частота замены аккумулятора? Рассматривали ли Вы варианты зарядки аккумулятора от солнечной батареи или другого источника?

ESP у меня не со счетчиками, а с датчиками за бортом. Батареи на улице. В связи с этим выбор пал на NiMH Eneloop 1900-2000, в связи с тем, что у них очень низкий саморазряд - раз, заявлена работа до минус 20. В связи с тем, что литий фосфат надо было где-то покупать ждать... а озвученные уже были под рукой, то решил остановиться на них. Последовательное соединение трех аккумуляторов + DC-DC LDO.  Расчетное время работы от одного комплекта аккумуляторов - год. С 28 сентября пока работает, то есть уже почти 3 месяца, пока всё идет по плану. Про зарядку батареи - это нужно увеличивать корпус устройства, не хотелось всё раздувать, да и с периодичностью замены источников питания в 1 год, не вижу смысла доп. трат средств + времени и усилий на подзарядку.

В принципе в сантехшкафу емкость источника питания можно  и увеличить, думаю место найдется у каждого, но при нормальной логике и правильно подобранных компонентах - можно легко выжать год-два от одного комплекта.

Единственное, посмотрел, есть несколько типов импульсных выходов счетчиков, есть с релейной схемой (просто геркон замыкает. размыкает цепь), а есть  стандарта NAMUR, где геркон меняет сопротивление, то есть в постоянке 5,6 кОм, при срабатывании геркона в параллель подключается второе сопротивление 2,2 кОм и итоговое становится 1,58 кОм. с первым вариантом все понятно, а во втором, помимо того, что изменение сопротивления надо подогнать под цифровые уровни ( прерывания срабатывают по цифровым входам МК), так еще эти сопротивления в счетчике будут кушать постоянно батарейку. 3.3 В/5.6 кОм = 0.59 мА. Учитывая постоянное потребление это 14 мАч в сутки. То есть за три месяца без учета МК только счетчик съест источник питания.

Да и компараторы-тригеры будут кушать на постоянной основе. Надо бы проверить свои счетчики. 

Вроде бы на ардуино прерывания реализованы, буду пробовать на ней, но это ближе к лету скорее всего. Но опять несколько мучает вопрос, как бы так обесточивать ESP ан время, когда ему данные передавать не надо. Думал реле, но там катушка в момент включения будет кушать многовато наверное.

Когда есть время подумать , я сейчас задумываюсь об энергоэффективности связки. attiny(или  atmega) и передатчик (ESP, а может даже NRF стоит рассмотреть с точки зрения энергоэффективности, да под него потребуется и приемную часть организовывать, но если это сделает более энергоэффективной автономную часть, то почему бы нет).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В файле ESP.cpp можно подсмотреть какие события перезапуска может различать ESP8266

Скрытый текст

String EspClass::getResetReason(void) {
    char buff[32];
    if (resetInfo.reason == REASON_DEFAULT_RST) { // normal startup by power on
      strcpy_P(buff, PSTR("Power on"));
    } else if (resetInfo.reason == REASON_WDT_RST) { // hardware watch dog reset
      strcpy_P(buff, PSTR("Hardware Watchdog"));
    } else if (resetInfo.reason == REASON_EXCEPTION_RST) { // exception reset, GPIO status won’t change
      strcpy_P(buff, PSTR("Exception"));
    } else if (resetInfo.reason == REASON_SOFT_WDT_RST) { // software watch dog reset, GPIO status won’t change
      strcpy_P(buff, PSTR("Software Watchdog"));
    } else if (resetInfo.reason == REASON_SOFT_RESTART) { // software restart ,system_restart , GPIO status won’t change
      strcpy_P(buff, PSTR("Software/System restart"));
    } else if (resetInfo.reason == REASON_DEEP_SLEEP_AWAKE) { // wake up from deep-sleep
      strcpy_P(buff, PSTR("Deep-Sleep Wake"));
    } else if (resetInfo.reason == REASON_EXT_SYS_RST) { // external system reset
      strcpy_P(buff, PSTR("External System"));
    } else {
      strcpy_P(buff, PSTR("Unknown"));
    }
    return String(buff);
}

В принципе, основные причины различать можно. Надо проверить, какой код вернется в случае использования глубокого сна при отключенном пробуждении по таймеру и использовании RST.

11 час назад, Alex_DIY сказал:

Но опять несколько мучает вопрос, как бы так обесточивать ESP ан время, когда ему данные передавать не надо.

Я смотрю в сторону транзисторного управление портом CH_PD или VDDA с помощью КТ315 или S8050. После пробуждения ESP берет на себя обязанность по контролю этого порта. В свою очередь, контроллер счетчика, убедившись, что транспорт проснулся, снимает с себя обязанности по поддержанию его питания и начинает передачу показаний, а заодно спрашивает о статусе последней передачи данных на сервер. Теперь ESP принадлежит самому себе и после завершения поставленной перед ней задачи снимает питание с транзистора. Также надо подумать о возможности конфигурации всех этих ребят через Web - отдельный режим, вызываемый внешним раздражителем, скорее всего кнопкой. А вот если у ESP8266 уже имеется доступ к домашней сети, то можно производить конфигурацию через MQTT. Держать отдельный топик с логическим значением 0/1 и если появилась 1, то не записать данные счетчиков в соответствующие топики, а наоборот, прочитать их и вернуть логическое значение в 0, тем самым подтвердить чтение данных. Получается своего рода калибровка показаний. Может быть глупо, но это первое, что пришло мне в голову помимо Web интерфейса.

12 часа назад, Alex_DIY сказал:

а может даже NRF стоит рассмотреть

На сколько это надежный вариант в плане безопасности передачи данных? У WiFi какое-никакое шифрование. Возможно этот вопрос не уместен, но все-же, вдруг соседские дети проявят интерес и попробуют подменить данные. В случае полной автоматизации, можно получить сюрприз в квитке об оплате. У меня есть несколько модулей с NRF, но до их применения я пока не добрался.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 10.12.2017 в 04:02, Alex_DIY сказал:

40мкА deepsleep ( вместе с датчиками bmp180, si7021)

ого... мало, это "голый модуль" esp8266-07 ( вместе с датчиками bmp180, si7021) от (3х АА) черед dc-dc LDO MCP1700...?!

Изменено пользователем EndWar

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, потребление по 3.3 В 40 мкА- модуль с датчиками в глубоком сне. От чего не важно,это на потребление не влияет. Да, измерял после DC-DC, то есть сюда не входит его ток утечки. Ток утечки DC-DC mcp1700 1.6 мкА, но не более 4мкА по даташиту. 

В 12.12.2017 в 08:57, Kitsum сказал:

После пробуждения ESP берет на себя

Мне кажется здесь какое-то усложнение , поочередно устройства меняют свои роли, просто ещё не очень хорошо представляю общение между двумя контроллерами. Так сказать на таком низком уровне.

Проверил свои счетчики, у меня в релейном  режиме импульсные  выходы, уже радость)) 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 11.12.2017 в 20:30, Alex_DIY сказал:

программировать придется минимум на Си

Arduino IDE прекрасно работает с любыми ATtiny...

Скрытый текст

5a3101664fbab_2017-12-1313-28-56.jpg.4a1ad4f663fb0f4c95118d4f59727b52.jpg

 

15 часов назад, Alex_DIY сказал:

от чего не важно

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

В 12.12.2017 в 08:57, Kitsum сказал:

дети проявят интерес и попробуют подменить данные

думаю реальность такой ситуации 0,001%... устроить помехи - да, попробуют - возможно, подменят данные - смотрим процент выше...  там (в NRF) если мне не изменяет память, более ста каналов + всякие префиксы, идентификаторы, проверки контрольных сумм, подтверждение приёма, всё достаточно серьёзно... ))

Еще позволю себе порекомендовать вот такую плату STM32F103C8T6 (может не самая лучшая статья но общее представление даст, много ещё информации гуглиться), расширенный функционал по сравнению с обычными arduino платами, интегрированные часы реального времени, usb и пр. и пр. конечно есть и минусы, но энергоэффективность (самой платы со всей обвязкой, мк отдельно не пробовал) даже по сравнению с Arduino Pro Mini 328 весьма велика... как правило (много кто пишет, так было и у меня) на ali под названием stm32f103c8t6 (64 Kbytes of Flash memory) продают stm32f103cBt6 (128 Kbytes of Flash memory), брал тут сразу много всего, но можно найти и дешевле...

Изменено пользователем EndWar
картинка пруф

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
6 часов назад, EndWar сказал:

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

согласен, не учитывались утечки на конверторе. НО и потребляемый ток зависит от напряжения, а на автономном источнике питания по мере отдачи заряда - напряжение меняется - падает, а то ксоответственно будет возрастать ;-) В итоге дойдем до интегрирования) Я об этом указал в своем посте.

 

В 12.12.2017 в 08:57, Kitsum сказал:

В случае полной автоматизации, можно получить сюрприз в квитке об оплате

Вот примерно по этому я не рассматриваю для автоматическую отправку в данных поставщику ресурсов.

6 часов назад, EndWar сказал:

там (в NRF) если мне не изменяет память, более ста каналов + всякие префиксы, идентификаторы, проверки контрольных сумм, подтверждение приёма, всё достаточно серьёзно... ))

Насколько я понимаю, то контрольные суммы и протоколы передачи можно придумать и свои , а не пользоваться библиотечными, так что сложность защиты можно варьировать.

 

6 часов назад, EndWar сказал:

Еще позволю себе порекомендовать

Это уже межгалактический космический корабль ... для охоты за воробьями ))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 минуты назад, Alex_DIY сказал:

Это уже межгалактический космический корабль

для кого как... ))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
9 минут назад, EndWar сказал:

для кого как... ))

ждём мастер-класса B| Пойду готовить каверзные вопросы :D

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
16 минут назад, Alex_DIY сказал:

ждём мастер-класса

в смысле..?! )) @Alex_DIY , что сегодня покурил, поделись... :D

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
42 минуты назад, Alex_DIY сказал:

сложность защиты можно варьировать

несомненно... к тому же мы ведь не собираемся непрерывно "шипеть" в эфир своими данными, включились, "плюнули" пакет - доли секунды, выключились... сигнал нужно поймать (во времени и пространстве как "межгалактический космический корабль":D), записать, расшифровать, очень мало вероятно это всё... 

Изменено пользователем EndWar

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
18 часов назад, EndWar сказал:

мы ведь не собираемся непрерывно "шипеть" в эфир своими данными

Этого и не нужно.  Соседу достаточно научиться "шипеть" как мы (Делай как мы, делай с нами, делай лучше нас B| для тех кто помнит:D ). Понять протокол шипения и слать на приемник всякую ерунду вместо нас, приемник то работает все время,а не синхронно включается-выключается вместе с передатчиком.

Изменено пользователем Alex_DIY

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Alex_DIY сказал:

достаточно научиться "шипеть" как мы

так я именно про это и говорю... ни ужели ты и в правду считаешь, что взломщик авто сигнализаций с серьёзным оборудованием будет сутками сидеть у порога твоей квартиры, вылавливая передачу, всего лишь для того, чтобы побаловаться..?! ну бред ведь...))

Изменено пользователем EndWar

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Alex_DIY , к стати если уж мания преследования, то не вижу ни каких проблем организовать:

1 час назад, Alex_DIY сказал:

приёмник синхронно включается-выключается вместе с передатчиком

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
2 часа назад, EndWar сказал:

взломщик авто сигнализаций с серьёзным оборудованием будет сутками сидеть у порога твоей квартиры, вылавливая передачу, всего лишь для того, чтобы побаловаться..?!

Представляете, аппаратуру можно оставлять включенной для логирования, а самому в это время спать :D

Не совсем понятно на что делается акцент в данном предложении? На серьезную аппаратуру для взлома? Взлома NRF ? чтобы снифать NRF достаточно другой такой же NRF (только тссс, не хочу чтобы все об этом знали :D)

2 часа назад, EndWar сказал:

не вижу ни каких проблем организовать:

Всё зависит от навыков и знаний B|, а так то проблем в теории нет. Сеансы связи по времени, при каждом сеансе сверка часов RTC  и т.д. и т.п. в оба устройства ввести алгоритм генерации ключей, зависимый от времени, чтобы при каждом сеансе ключ шифрования не передовался по незащищенному каналу, но был известен на двух сторонах этого канала  и т.д. и т.п.

Но я бы ознакомился с Вашей реализацией, раз "ни каких проблем" B|

Просто когда знания не велики, то всё кажется таким простым, а когда начинаешь задумку воплощать, то сразу либо вылезают преграды и приходится долго ломать голову и изучать что-то , чтобы их преодолеть, либо воплощение получается "игрушечным" и далеким от того, что задумал. По крайней мере у меня как-то так.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Alex_DIY , да что ж такое то... я ведь сказал

4 часа назад, EndWar сказал:

если уж мания преследования

к счастью этим не страдаю... более 6 лет работает система 433 МГц, по открытому канал управляет светом, бытовыми приборами, передаёт данные и никто меня не взламывает, нафиг ни кому не надо, а 1й этаж... ))

Но вы то видимо "другой" (избранный) вас ведь все преследуют, логируют, сниффят и пр. и пр. ну дичь ведь... 

 

Изменено пользователем EndWar

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что касается 

В 12.12.2017 в 08:57, Kitsum сказал:

в случае полной автоматизации, можно получить сюрприз в квитке об оплате

к примеру подумать о том , чтобы на стороне сервера умного дома, перед отправкой данных обслуживающей организации сравнивать их со средними +- либо установленными вручную значениями и если они адекватные то отправлять, если нет выдавать предупреждение с просьбой ручной проверки... 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Alex_DIY @EndWar друзья, позвольте и мне внесу 5 копеек.

В 13.12.2017 в 00:48, Alex_DIY сказал:

Мне кажется здесь какое-то усложнение , поочередно устройства меняют свои роли

Дело в том, что во время работы транспортного контроллера могут возникнуть сложности, приводящие к его позднему сну:

  • Ошибки подключения к беспроводной сети
  • Задержки при передачи данных на севрер
  • Изменение поведения из-за внешних факторов, например, калибровка счетчиков
  • Форс мажорные обстоятельства

Все это приводит к работе в холостую контроллера счетчиков и повышению потребления. Может быть я не прав, все выяснится при опытной эксплуатации.

3 часа назад, EndWar сказал:

более 6 лет работает система 433 МГц, по открытому канал управляет светом, бытовыми приборами, передаёт данные и никто меня не взламывает

Рад был бы согласиться, но к сожалению, не стандартный интерес к чему-либо растет прямо пропорционально с ростом популярности, а мы с Вами как раз попадаем в круг интересов систем умного дома. И тут даже не важно кто разрабатывает, мы или они, главное, что используются популярные компоненты с открытыми спецификациями. А с программной частью справятся - "Mach mit, Mach’s nach, Mach’s besser!".

Так что в споре между нападающим и обороняющимся победителя не будет никогда, максимум сменят роли.

И опять же сугубо мое мнение. Если мы имеем два транспортных устройства с одинаковым ценником, это NRF и ESP, но при этом для первого необходимо придумать свой проприетарный протокол с шифрованием, а второе из коробки поддерживает CCMP и поверх этого может общаться с использованием SSL, так почему бы не бросить те же силы, чтобы получить CCMP + SSL + проприетарный протокол? Мне кажется, что это вполне логично. А NRF будет хороша при работе с некритическими системами, на подобии метеостанции.

1 час назад, EndWar сказал:

к примеру подумать о том , чтобы на стороне сервера умного дома, перед отправкой данных обслуживающей организации сравнивать их со средними +- либо установленными вручную значениями и если они адекватные то отправлять, если нет выдавать предупреждение с просьбой ручной проверки... 

Отличная идея. Очень будет кстати если начать разработку своего сервера умного дома...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
24 минуты назад, Kitsum сказал:

NRF и ESP

абсолютно согласен, даже больше... после появления ESP не вижу смысла тратить усилия и время на, по моему мнению - капризные, сложные, одинаковые по цене, но менее функциональные, по сравнению с esp, модули nrf... 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@EndWar

Ваша беда в том, что вы пытаетесь перейти к частному ( а я, а мне ...) а я рассуждаю в общем, гипотетически.  Обговариваем слабые и сильные стороны, а дальше уже каждый сам решает,  готов ли он поступиться этими слабыми сторонами или нет. Всего-то. Не нервничайте.

2 часа назад, Kitsum сказал:

Дело в том, что во время работы транспортного контроллера могут возникнуть сложности, приводящие к его позднему сну:

или к преждевременному отключению. В общем и целом, я с этим согласен.  Но я б всё-таки отрубал его, чем усыплял (транспортный узел в виде ESP).

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

P.S. всё что связано с финансами, я принципиально не пользуюсь автоматизированным (никаких автооплат, привязок карты и т.п.). Только вручную. такой у меня бзик (прошу понять и простить 9_9 )

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Alex_DIY , моя "беда" в том, что я больше практик, чем теоретик... )) Какой смысл рассусоливать (засорять эфир) тут о чём то 

7 часов назад, Alex_DIY сказал:

общем, гипотетически

что не приведёт к практическому применению..?! (Вопрос риторический, ответ мне не нужен) Опять же повторюсь - спор ради спора мне не интересен... Все мои записи основаны на практическом применении того или иного подхода, что и привело вас к превратному истолкованию моей позиции 

 

7 часов назад, Alex_DIY сказал:

( а я, а мне ...)

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

Изменено пользователем EndWar

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
В 12.12.2017 в 08:57, Kitsum сказал:

В принципе, основные причины различать можно. Надо проверить, какой код вернется в случае использования глубокого сна при отключенном пробуждении по таймеру и использовании RST.

это одно и то же, так как deepsleep в том виде, как он работает на esp8266 именно потому, что сам себя ресетит при выходе из стадии глубокого сна.

ESP.getResetReason: Deep-Sleep Wake
ESP.getResetInfo: Fatal exception:0 flag:5 (DEEP_SLEEP_AWAKE) epc1:0x00000000 epc2:0x00000000 epc3:0x00000000 excvaddr:0x00000000 depc:0x00000000

вот это выдают данные функции, что при подаче питания, что при "просыпании" по таймеру deepsleep, что просто по замыканию RST на GND. Сегодня дошли руки поиграться и проверить это на живом модуле, лишний раз убедился, что я не ошибаюсь B|

P.S. учитывая, обнаруженные в 2.4-rc2 баги, не буду столь категоричен в выдаче функций ESP.getResetReason и ESP.getResetInfo, ибо то, о чем написал выше, проверял на версии 2.4-rc2.

Изменено пользователем Alex_DIY

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Kitsum

https://mysku.ru/blog/aliexpress/61934.html

Безотносительно GSM модуля сам подход к контроллеру довольно интересен. Человеку удалось добиться среднего тока потребления в 8,5 мкА. 

Помнится, ранее мы обсуждали реализацию и Вами высказывалась идея реализации через прерывания, НО через утяжку будут уходить бОльший ток.

пожалуй , если добавить к такой реализации МК части NRF24, должно получиться довольное экономное устройство сбора и передачи показаний.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Пожалуйста, войдите для комментирования

Вы сможете оставить комментарий после входа



Войти сейчас

  • Похожие публикации

    • Автор: Kitsum
      Всем привет, в этой статье поговорим об уже надоевшей всем теме - "Метеостанция". Каждый пытается сделать что-то свое, вот и я не стал исключением и попытался материализовать свои эротические фантазии на контроллере ESP8266. Тема задумывалась уже давно как некое обновление для предыдущего проекта этой тематики, но из-за своей неспешности переросла в нечто самостоятельное.


      При всей привлекательности микроконтроллера ESP8266 с его большим объемом памяти, железной поддержкой Wi-Fi и массой разных плюшек, он не лишен недостатков. Самый основной - ограниченное количество поддерживаемых одновременных TCP соединений равное 5. Если превысить этот лимит, то контроллер потеряет связь с окружающим миром, при этом watchdog будет думать, что все в порядке, а следовательно, даже не попытается нам помочь. Будем стараться это помнить!
      Стоит начать с концепции
      Доступ к данным метеостанции нужно получать без установки внешних приложений и под любой операционной системой. Для этих целей подойдет практически любой современный браузер. Меня всем устраивает Chrome. Раз уж за основу взят HTTP протокол, стоит озаботиться экономией трафика и ограничением числа TCP соединений. Хорошим тоном будет передача всего необходимого для формирования страницы контента только при первом обращении, а все последующие операции, такие как отображение показаний с датчиков или настройку контроллера, производить через API. В этом нам поможет JQuery. А вот, чтобы ослабить болевые ощущения от передачи файлов с SPI Flash в браузер, стоит предусмотреть систему кэширования, например, Etag. Это позволит отдавать тяжелый контент единожды, а при последующих загрузках страницы просто подтверждать его актуальность на уровне Web сервера микроконтроллера и кэш браузера вступит в игру, неимоверно уменьшив время загрузки страницы! "Вы были правы в одном, Мастер: переговоры были недолгими." © Звездные войны. Эпизод 1 Из-за того, что метеостанция с датчиками и контроллером должна располагаться на улице, жизненно необходимо предусмотреть возможность обновлять прошивку ESP через Web интерфейс. Аналогичным образом должны обновляться файлы Web сервера расположенные на SPI Flash. Этот и предыдущий пункт вкупе позволят обновлять функционал микроконтроллера из домашней сети или из интернета, если конечно в этом возникнет острая необходимость. Чтобы никто посторонний не могу вмешаться в работу устройства или изменить файлы Web сервера, последний должен хотя бы как-то себя защищать. Пускать в панель управления только после авторизации, блокировать доступ при попытках брутфорса пароля. В конце концов, контроллер обязан самостоятельно генерировать ключи (salt) для авторизации, дабы сделать алгоритм непредсказуемым и исключить потенциальный взлом, в случае если злодей завладеет исходниками проекта. Понятно, что кому она там нужна, эта метеостанция, если её не завязывать с умным домом, если только из-за спортивного интереса, но как говориться “Береженого Бог бережет”. Датчики стоит расположить по уму - в метеобудке, а вот контроллер в сухом и закрытом боксе. Объединить их между собой, как мне кажется, удобнее по I2C шине - минимум проводов, максимум удобства. Практически на всех вариантах плат ESP-xx имеется штатный светодиод, можно воспользоваться им как для индикации режимов и состояния микроконтроллера, так и для вывода какой-либо промежуточной информации. Что касаемо режимов работы ESP8266, как ни странно, но он должен находить домашнюю Wi-Fi сеть и подключаться к ней. Если вдруг звезды не были к нам благосклонны, и домашняя беспроводная сеть приказала долго жить, контроллер обязан перейти в режим точки доступа (AP) дабы к нему можно было подключиться с какого-либо устройства и перенастроить его на другую сеть. А вот пока последнее не произошло, ESP должен периодически сканировать эфир в поисках долгожданной домашней точки доступа и, если боги были к нам милосердны, и домашняя сеть появилась в эфире, незамедлительно переключиться в режим клиента (STA) и в пылу страсти воссоединиться с ней. Ну и естественно, как же без отправки данных на внешние ресурсы, сейчас без этого не обходится ни одна уважающая себя кофеварка, не говоря уже о метеостанции. Думаю, что основным блюдом станет протокол MQTT, это уже облегчает возможность интеграции с умным домом, стулом или той же кофеваркой. Ну а на закуску добавим поддержку "ThingSpeak" и "Народного мониторинга". При желании можно нарастить функционал, благо памяти у микроконтроллера еще много. Как я себе это представляю
      Учтите, что на видео, данные с датчиков, эмитируются самим микроконтроллером, это нужно для наглядности. В жизни метеорологическая обстановка намного спокойнее слава Богу.
      Перейдем к физической сборки устройства
      Как по мне, так самый оптимальный вариант, это воспользоваться отладочной платой NodeMCU V3 и базой для неё. Таким образом, мы получим отличный комплект с разведенной на его борту всей необходимой обвязкой и возможностью питать устройство от 5 до 24 Вольт.

      Отладочная плата на базе, и смотрится хорошо, и удобства хоть отбавляй.

      Заливаем прошивку, образ SPI Flash и подключаем четырьмя проводами датчики. Справится даже ребенок.
      Ссылки:
      Базовая плата для NodeMCU V3 с преобразователем питания 5-24V в 5V Отладочная плата ESP8266 от NodeMCU Естественно никто не запрещает Вам развести свою плату. Если Вы это сделаете, скиньте нам свое творение, возможно мы перейдем на него. В идеале, все должно размещаться в метеобудке.
      Датчики взятые за основу
      Теперь настал момент озаботиться, где описанные выше ребята будут жить. В прошлый раз мы использовали для этих целей, найденную в подножном корме, электрическую распределительную коробку. Кроме дешевизны в этом решении нет ничего положительного.
      В этот раз мы воспользуемся более серьезным вариантом – "Метеорологическая будка Стивенсона". Она способна защитить датчики от прямых воздействий окружающей среды, но при этом имеет открытую структуру со стенками в виде жалюзи. Удобно, красиво и самое главное – правильно!
      Будка печатается на 3D принтере по эскизам опубликованным на Thingiverse неким kowomike, спасибо добрый человек! Архив с эскизами можно будет скачать в конце поста.

      Фото готовой будки

      Шпилька М8 крепится через зажимной хомут к мачте уличной антенны.
      Примерка. Шпилька практически не укорачивалась, чтобы не закрывать будку параболической Wi-Fi антенной.
      Хотя в моем случае все это сделано не правильно т.к это солнечная сторона дома. Доступа на теневую сторону дома у меня нет, поэтому приходиться довольствоваться тем, что имеем. По прошлой метеостанции мне говорили "на солнечной стороне все эти измерения - сферический конь в вакууме, слепи %описание-многА-букАв% и закрепи на теневой стороне дома".
      Я пока живу в панельном многоквартирном доме, как и не малая часть нашей страны. Доступ к теневой стороне дома (а для меня, по факту, это окна в подъезде) - прямой вызов всем гопникам района трущимся рядом, любопытным соседям с бегающими глазками и всей элите человечества скрашивающей фоном мою унылую и слишком простую, по их мнению, жизнь. Думаю, что мысль я донес.

      Датчики располагаются на разных уровнях. В основании находится датчик освещенности BH1750 и смотрит ровно вниз. Мне кажется, так он будет меньше пачкаться и покрываться пылью и при этом смотреть наружу сквозь минимальное количество препятствий для солнечного света. Вообще размещение этого датчика, это целая головная боль. Как не крути, все будет не то. Оставил так, ведь по сути важны не сами показания, а тенденция изменения. Хотя кого я пытаюсь обмануть, точность важна всегда! Предлагайте свои варианты.
      Намного проще обстоят дела с датчиком атмосферного давления BMP180 и влажности SI7021, кстати, с последнего мы также будем забирать данные о температуре. Их размещаем в оставшемся свободном пространстве будки, благо его там с избытком, но не в конусе т.к пространство в нем менее проветриваемое.

      Все хозяйство подключается между собой следующим образом
      NodeMCU | ESP 07/12 | Датчики ----------------------------- D2 | GPIO 4 | SDA D1 | GPIO 5 | SCL 3.3V | 3.3V | 3.3V GND | GND | GND ВАЖНО: при финальном монтаже устройства на его место службы, обязательно установите перемычку между пинами GPIO 0 (D3) и питанием 3.3 Вольта. Причины её установки описаны в закрепленном сообщении с описание обновления от 12.08.2017.
      Сам микроконтроллер будет спрятан в уже знаменитую распределительную коробку, закрепленную на шпильке, чуть ниже будки Стивенсона. У меня все находится на стадии неторопливой сборки с попутным поиском более удачных идей.
      Плата расширения, на которой будет установлена плата NodeMCU, закреплена через ножки для крепления компьютерных материнских плат в корпусах.

      Разъемы для подключения внешних датчиков и питающей линии установил на местах где была пара штатных заглушек. Закрепил все через переходную пластину, выпиленную из куска фольгированного текстолита. Естественно, предварительно пластина была протравлена, а вся медь искоренена, ибо в этом случае она нам не друг.
      Также была предусмотрена проставка из полиэтиленового поролона (используется в качестве упаковочного материала при транспортировке грузов) между текстолитом и корпусом, общей толщиной 5мм, а после затяжки крепежных винтов, его толщина не превышает 1мм. Это было сделано из-за опыта эксплуатации предыдущего (временного) бокса для этой метеостанции. Без проставки влага быстро найдет путь вовнутрь, и срок службы устройства снизится.
      Производим примерку.
      При окончательном монтаже обязательно необходимо удалить все не плотно прилегающие части полиэтиленового поролона, то есть те части, которые располагаются снаружи и не сдавлены крепежной текстолитовой пластиной. Это необходимо сделать для препятствования накоплению влаги в доступных для неё полостях. Также пришлось увеличить число крепежных болтов для более надежного прилегания текстолита, в противном случае он может выгибаться.
      Все самое сложное позади, остается только вывести на один разъем шину i2c с питание 3.3 Вольта, а на другой подвести пины питания платы расширения. Но т.к у меня валялся "хвост" отрезанный когда-то от не рабочего блока питания маршрутизатора, и я не побрезговал им воспользоваться по прямому назначению.

      Далее останется все подравнять, проверить качество монтажа, возможность замены платы NodeMCU, если это будет необходимо при эксплуатации и самое главное, дважды проверить, что и куда припаяно. Мои кривые руки и невнимательность уже наказывали меня, а т.к ждать новые запчасти долго, повторять не хочется.

      Общий вид получился таким
      А вот как все выглядит в боевых условиях. Кстати, могу предложить идею с помещением в бокс мешочка содержащий впитывающий влагу гель, они часто встречаются в коробках с обувью. Если все герметично, то он впитает остатки влаги, а если нет, то лишним уж точно не будет.


      Требования (!!!Читать обязательно!!!)
      Arduino IDE с поддержкой контроллера ESP8266, версия 2.6.2 (на версиях выше работоспособность не проверялась) Установленный модуль в Arduino IDE для загрузки файлов во Flash память микроконтроллера. Как установить описано тут. Для работы модуля загрузки файлов во Flash может понадобится последняя версия Python https://www.python.org/downloads/ Любой модуль на базе ESP8266 c Flash 4MB (3MB выделяем под SPIFFS) В параметрах выставляем lwIP версии 2 и максимальную производительность (lwIP v2 Higher Bandwidth) Сам архив с последней версией проекта. Скачать можно в конце статьи или по этой ссылке.   
      Обязательные библиотеки (!!!Читать обязательно!!!)
      ArduinoJson (v5.13.5) PubSubClient Ссылки на библиотеки сенсоров указаны в комментариях к коду. Сами библиотеки, как и обслуживаемые ими сенсоры, не являются обязательными. Вы вольны использовать любые датчики, как физические, так и программные.
      Порядок установки (!!!Читать обязательно!!!)
      Изучите файлы проекта с примерами использования тех или иных сенсоров. Все файлы с примерами начинаются с префикса users_, это users_auto.h, users_bme280_x2.h и т.д. Загрузите необходимые Вам библиотеки или используйте эти файлы как пример для добавления иных датчиков. Выставите необходимые настройки для контроллера в среде разработки Arduino IDE. Пример настроек указан на скриншоте выше. Обязательно убедитесь, что выбрано правильное распределение места для внутренней файловой системы, это значит, что 3MB должно быть выделено под файловую систему. Также проверяем, чтобы использовался lwIP v2 в режиме максимальной производительности (lwIP v2 Higher Bandwidth). Произведите загрузку программы с помощью среды разработки (Ctrl + U). Произведите загрузку содержимого каталога data в файловую систему. Меню/Инструменты/ESP8266 Sketch Data Upload Перед тем как устанавливать метеостанцию на постоянное место жительства, подтянуть GPIO-0 (пин D3 на плате NodeMCU) к питанию 3.3V. Во время данной процедуры, питание на контроллере должно отсутствовать. Первый запуск (!!!Читать обязательно!!!)
      Помните, что вся конфигурация микроконтроллера производится исключительно через web интерфейс. Никаких изменений значений тех или иных параметров в коде не требуется, а подобную практику будем считать плохим тоном.
      И так, после запуска микроконтроллера он сразу перейдет в аварийный режим и поднимет собственную точку доступа с именем WeatherStation. Это нормальное поведение т.к подразумевается использование метеостанции в домашней беспроводной сети, ну а раз о ней пока ничего не известно, то и подключаться не к чему.
      Подключитесь к данной сети с любого удобного устройства и перейдите в панель управления (для этого имеется соответствующая иконка, запутаться невозможно), контроллер будет доступен по адресу http://espws.local или http://192.168.4.1 При попытке входа в панель управления будет запрошено имя пользователя и пароль, по умолчанию admin/admin. После входа в панель управления перейдите в раздел "Основные настройки WiFi" и укажите имя и пароль Вашей домашней сети, а также, при необходимости, укажите пароль для подключения к точке доступа поднимаемой контроллером в аварийном режиме. Если все сделано правильно, то контроллер подключится к домашней сети в течении 5-и минут.
      Если Ваша домашняя сеть скрыта, то после первоначальной настройки необходимо перезагрузить контроллер. Это необходимо из-за частичной поддержки работы со скрытыми сетями. После перезагрузки контроллер увидит Вашу сеть и запомнит её MAC адрес. Помните об этом если захотите сменить домашний маршрутизатор.
      Хотите помочь проекту или спонсировать новый?
      Yandex.Money PayPal.me Файлы
       
    • Автор: Kitsum
      Хотите помочь проекту или спонсировать новый?
      Yandex.Money PayPal.me Тема проекта
      Arduino IDE + Project + Libraries + tools: https://yadi.sk/d/jseefFB50NMhAg
    • Автор: Kitsum
      Просмотреть файл [esp8266] Библиотека CMD, реализует настройку микроконтроллера и управление вашей программой через терминал.
      Основная задача библиотеки, это прием пользовательских команд через UART интерфейс, их обработка и выполнение пользовательского кода, связанного с той или иной командой.
      Данная библиотека позволяет реализовать:
      Управление микроконтроллером Любую настройку, будь то WiFi, другие библиотеки или часть Вашей программы Вызывать Ваши задачи (функции) из терминала по команде и передавать им требуемые параметры Использовать контроллер в качестве шлюза между датчиками и программами на PC Внимание: любая команда, передаваемая в терминал обязана заканчиваться символом перевода строки "\n".
      Подключение библиотеки
      #include <cmd.h> Инициализация объекта, к которому мы будем обращаться для добавления команд. В качестве параметра объекту необходимо передать указатель на объект Serial или любой другой схожий по типу интерфейс.
      cmd command(&Serial); В функции Setup описываем какие команды требуется обрабатывать. Например, по команде "test" вызывать пользовательскую функцию с именем "myFunctionName". Имя пользовательской функции может быть абсолютно любым.
      void Setup() { Serial.begin(115200); command.add("test", myFunctionName); } Пользовательская функция будет вызываться каждый раз, когда по интерфейсу Serial поступит команда "test". Если команда будет передана с параметрами, то эти параметры будут переданы в качестве аргументов пользовательской функции.
      В функции loop должна находится команда вызова обработчика.
      void loop() { command.handleEvents(); } Пользовательская функция обязана соответствовать ряду требований:
      Не возвращать никакого результата (быть объявленной с типом void) Принимать в качестве первого аргумента переменную с типом byte в которой будет храниться число равное количеству переданных параметров Принимать в качестве второго параметра переменную с типом char** в которой будет храниться указатель на массив со всеми указателями (char*) на переданные параметры void myFunctionName(byte argc, char** argv) { /* ... */ } Функция всегда должна иметь такой вид, даже если не подразумевается, что ей будут передаваться какие-либо параметры.
      Чтобы перебрать все переданные параметры и вывести их в консоль, можно воспользоваться следующим примером
      void myFunctionName(byte argc, char** argv) { if (0 < argc) { for (uint8_t i = 0; i < argc; i++) { Serial.printf("%i. %s\n", i, argv[i]); } } } Пример вызова пользовательской функции без параметров и с ними
      # test No parameter was passed # test p1 p2 p3 p4 p5 0. p1 1. p2 2. p3 3. p4 4. p5 Помните, что параметры представлены в виде указателей и работать с ними нужно как с обычными переменными не получится т.к указатель содержит не значение переменной (переданный параметр), а указатель на ту область памяти микроконтроллера в которой это значение находится.
      Чтобы сравнить два значения, например, параметр под индексом 0 (идет первым в списке) с каким-либо значением в программе, воспользуйтесь функцией strcmp, которая возвращает целочисленное значение, указывающее на лексическое расхождение строк. Если строки равны, то возвращаемое значение равно 0.
      if (!strcmp(argv[0], "wifi")) { Serial.println(F("Первый аргумент WiFi")); } else { Serial.println(F("Первый аргумент НЕ WiFi!!!")); } Для копирования значения указателя в другую переменную с типом char можно воспользоваться функцией strcpy
      char myVar[20]; strcpy(myVar, argv[0]); if (myVar == "123456") { Serial.prinln(F("ok")); } Также можно обернуть указатель объектом String и получить весь функционал этого объекта, который будет содержать значение параметра
      String param1(argv[0]); // String param1 = argv[0]; Serial.printf("argv[0] length: %i\n", param1.length()); Serial.printf("argv[0] is integer?: %s\n", param1.toInt() ? "YES" : "NO"); if (param1 == "qwerty") { Serial.println(F("Hello QWERTY!")); } С библиотекой идут несколько примеров, в том числе и пример конфигурации WiFi в режиме STA.
      Автор Kitsum Добавлен 05.12.2018 Категория Библиотеки  
    • Автор: Kitsum
      Просмотреть файл [esp8266] Библиотека smartBlink, реализует умное управление штатным светодиодом, что позволяет добавить индикацию состояния вашей программы или микроконтроллера.
      Основная задача библиотеки, это добавление индикации состояния Вашей программы или микроконтроллера. Отображение состояния производится посредством светодиода. Что самое важное, работа библиотеки через прерывание, это позволяет ей поддерживать индикацию даже в то время, когда выполняется длительный код основной программы. Например, Вы можете использовать её для отображения в каком режиме сейчас работает WiFi микроконтроллера, STA или AP и т.д. Или ход выполнения какой-либо операции, например, передача данных на внешний сервер.
      Подключение библиотеки
      #include <smartBlink.h> Чтобы инициализировать управление светодиодом необходимо создать объект, через который мы буем задавать режимы работы индикации.
      smartBlink::smartBlink(byte gpio, bool on = LOW); Объекту необходимо передать два параметра, первый это номер порта, на котором находится светодиод, а второй это уровень логического сигнала, который заставит светодиод работать. Сигнал может быть низким (LOW) или высоким (HIGH), это зависит от схемотехники подключения светодиода.
      Например, штатный светодиод модуля ESP12, использующий GPIO2 (порт 2) можно объявить следующим образом.
      #define led2_pin 2 #define led2_on_signal LOW smartBlink led2(led2_pin, led2_on_signal); Теперь можно в основной программе использовать метод устанавливающий какой режим индикации использовать.
      smartBlink::setMode(mode_t mode); Например, зададим режим светодиода led2 в котором светодиод будет давать одну короткую вспышку раз в секунду.
      led2.setMode(smartBlink::mode_flash1); Режимов работы может быть несколько.
      led2.setMode(smartBlink::mode_off); led2.setMode(smartBlink::mode_flash1); led2.setMode(smartBlink::mode_flash2); led2.setMode(smartBlink::mode_flash3); led2.setMode(smartBlink::mode_flash4); led2.setMode(smartBlink::mode_burn); led2.setMode(smartBlink::mode_inhalf); Чтобы вернуть предыдущий режим индикации для ранее объявленного светодиода led2 используйте следующий метод
      led2.previous(); Благодаря работе библиотеки через прерывания по таймеру, индикация будет работать даже в тех случаях, когда выполняется долгий код.
      С библиотекой идут несколько примеров.
      Автор Kitsum Добавлен 10.12.2018 Категория Библиотеки  
  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

×
×
  • Создать...