Умный счетчик расхода воды: бюджетный подарок к Новому Году.

Я сейчас в отпуске, компьютера нет. Через две недели смогу что-то предметнее ответить.

 

Понял, спасибо. Я надеюсь я справлюсь раньше
в /report кстати все таки призывает waiting data

 

Ипать счастливчик)

 

Завидуй конкретнее:

 

Больше впечатляет верхняя фотка. Снега нет... Деревья с листьями...
Белая зависть

 

Добрый день, Игорь. Пытаюсь адаптировать Ваш проект для электросчетчика с передаточным числом 1 кВтч = 3200 импульсов. Подправил исходник так, чтобы на каждый импульс прибавлялось 0,3125 Вт. Все прекрасно прибавляется, отправляется и в MQTT dash отображается в Втч.
Собственно вопросы:
- Как отправлять данные, чтобы в MQTT видеть кВтч в формате ХХХХХ,ХХ(Х)?
- Как организовать обнуление показаний при переполнении?
- Что надо поменять в коде, чтобы отправка на сервер была только при условии, что насчитано 5 Втч или 10 Втч (соответственно, 16 или 32 импульса)?

P.S. Прошу сильно не пинать, знаю только asm для PIC

 

Код выше не проверял!

Данные уходят одновременно. Они всегда разные. Не вижу возможности.

 

Спасибо, буду пробовать.
Попутно еще вопрос: при отключении питания данные в таблице должны сохраняться? Думаю, что нет. Ситуация следующая: интернет вырубился, счетчик продалжал считать импульсы, пропало питание, при восстановлении питания счет начинается с 0, при восстановлении интернета на сервер отправляется новые данные. Можете проверить алгоритм, заложенный в проекте?
В Ваших примерах в другой теме предлагалось сохранять промежуточные данные в файл с последующим считыванием при рестарте, это можно реализовать?

P.S.С мелкими проблемами разобрался сам (как и чем шить/заливать, как изменить пины, как переключить ADC на измерение VDD33)

 

Питания чего? Модуля, брокера, все вместе?

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

Промежуточные данные можно сохранять на ферромагнитную i2c память, но это усложнение проекта.

 

Спасибо за оперативный ответ!

Модуля.

Строка с форматирование вывода дает ошибки:
>> function pub(topic, info)
>> if topic == 'cool' or topic == 'hot' then info = ('%.3f', info/1000) end
stdin:13: ')' expected near ','
> print(topic..": "..info)
stdin:1: attempt to concatenate global 'info' (a nil value)
stack traceback:
stdin:1: in main chunk
> m:рublish(myClient.."/"..topic,info,1,1, function()
>> coroutine.resume(send)
>> end)
stdin:1: attempt to concatenate global 'topic' (a nil value)
stack traceback:
stdin:1: in main chunk
> end
stdin:1: '<eof>' expected near 'end'

 

Зашёл в тему, написано "бюджетный подарок"… и где тут на фото это?

 

Не только есть, но и пить! Сорри за флуд

 

Ой!!! Потеряно

Код (Lua):

string.format

Код (Lua):

 if topic == 'cool' or topic == 'hot' then info = string.format ('%.3f', info/1000) end

 

Спасибо, Игорь! Все работает.

 

Приветствую коллеги, просьба тапками не пинать, но я ноль во всей этой теме, но интересно повторить данный прибор учета воды.
купил себе россыпь esp-01, и программатор/прошивальщик pl2303, но к моему сожалению не могу найти информацию/инструкцию, как прошить с помощью этого девайса ЕСПешку. Поэтому ткните пальцем, пожалуйста, в подобную инструкцию.
Спасибо

 

http://forum.amperka.ru/threads/esp-8266-esp32-lua-азы-программирования-nodemcu.12558/page-29#post-203319

Не исключаю, что с ним может (?????) ничего не получиться. Производитель что-то забросил его драйвера и иногда на винде модуль ведет себя непредсказуемо.
В Линуксе все нормально.

 

Игорь, спасибо вам за ваши труды.
Повторил данный проект в исполнении и печатной платы, получилось примерно так.


Всё работает, за исключением того "бага", описанного вами ранее. Причём наткнулся на него при первом же включении, один из герконов был замкнут. У меня счетчики висят на коннекторе (4pin) и если коннектор подключить уже после подачи питания, то всё ок (и воду проливать не надо), кнопка то замкнулась. Вроде как и проблема не большая, но избавиться от неё хочется. Гипотетически, если моргнёт свет в момент замкнутого геркона, то контроллер повиснет и всё пропало =) и любая перезагрузка приведёт к тому же результату.
Прочитал всю ветку, проблема больше не обсуждалась.
Подскажите варианты решения плз.

 

Дело в том, что для ESP-1 ОБЯЗАТЕЛЬНОЕ требование в момент старта иметь ноги неподтянутые к земле. Если нога 3 притянута - модуль входит в режим заливки прошивки, если нога 4 - в режим загрузки с внешней памяти. С этим ничего поделать нельзя. Абсолютно.
Я где-то должен был писать, что единственный выход - применять модули с бОльшим количеством ног и вешать счётчики на другие, нетребовательные к положению при старте ноги.

Другой вариант - пробовать применять ноги UART, но я этого не делал.

 

И всё-таки мой внутренний перфекционист не дал мне спать спокойно и я решил зайти со схемотехнической стороны =) Есть два варианта.

Вариант А: Классическая схема RC-цепочки и транзистора. В момент подачи питания через резистор R1 начинает заряжаться C1 и по мере заряда открывает затвор полевика Q1 и держит его вечно открытым, через который, в свою очередь, коммутируются ноги МК на землю. Важно чтобы R3 был не меньше R1, иначе конденсатор будет слишком быстро разряжаться и на затворе будет слишком малое напряжение и полевик не откроется.



Вариант Б: Не менее классическая схема на таймере NE555. Тут всё просто. Номиналы R1C1 цепочки формируют время задержки запуска таймера и с ноги 3, через токоограничивающий R2, полевик открывается и так же держится вечно открытым.

Лампочки просто в качестве индикации нагрузки (коннекта).

При софтовой перезагрузке ( типа node.restart() ), на ноге Reset обвала фронта нет и МК с подтянутой gpio 3 или 4 так перезагружается спокойно. Единственная разница между схемами в том, что в варианте А, транзистор будет открываться (и закрываться) плавно по мере заряда C1, а в варианте Б фронт будет импульсного характера.


Оба варианта проверял в "железе", обе схемы дают задержку примерно в 1.5 секунды, чего вполне достаточно, чтобы проскочить момент загрузки контроллера. Может быть кому-нибудь пригодится. Если адепты схемотехники меня в чем-то поправят, буду рад.