ESP-8266/ESP32 NodeMCU Lua: азы программирования.

Не, Игорь уже разъяснил, что m или client - в данном случае не принципиально. Да и в первоисточнике (откуда копипастили) тоже так.

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

 

Принципиально, но вопрос этот непростой, требует пояснения.

Если два - проще. Если 10 - сложно. Ну и вопрос унификации кода.

Абсолютно верно.

Но все проблемы от логики этого по отдельности отличного кода. Доберусь до компа - сделаю разбор. Ибо человек работал и это уважаемо.

 

В ожидании...

 

По коду из поста #966. Все ниже - ИМХО!

1. Код разделен на два файла. Логика понятна и проистекает она из подходов компилируемых языков, однако в интерпретируемом языке это не совсем верно.

Рвать код на куски следует с двумя целями:
- уменьшить объем занимаемой памяти;
- применять отдельный файл через какое-то время как библиотеку.

Смотрите, вот я за какие-то 30 минут воткнул датчик в проект. При этом не требуется разбираться с даташитом, вспоминать как он работает, etc. Предлагаю вам сразу делать свои микро/макро библиотеки. У меня оно выглядит так:
В папке лежит файл библиотеки, рядом файл примера как ей пользоваться:


Иного смысла выделения кучи функций в отдельный файл нет.
У вас там три функции? Сделайте три файла, уж наверняка чтение htu21d когда-то потребуется, а будет ли оно сопряжено, например, с такой публикацией на брокер или дерганием wifi - не факт.
Да более того - со временем вы усовершенствуете и публикацию и коннект к сети, и делать это постоянно расковыривая прошлые файлы - сомнительное удовольстве.

2. В опросе датчика htu21d можно увидеть tmr.delay(50000) - 50 миллисекунд остановки процессора! Это плохо в любой системе программирования чего угодно, в случае с ESP-8266 это просто запрещено. В этот момент вы ломаете все процессы, которые идут в SDK. Оный разрешает единоличный "захват" процессора чем либо в коде не более чем на 15 мс.
То есть, вы должны писать код без применения функции задержки. Вообще без применения! И вы не имеете права запускать что-то типа while, for, etc, что будет молотить более 15 мс. Это напросто для начинающего, но такова реальность. В отличие от Си, где вы полностью контролируете процессор, здесь всегда идут неподвластные вам процессы, в первую очередь работа wifi и обеспечение работы асинхронного кода.

Чтобы понять, как писать код с задержкой (аж 750 мс) - поизучайте топик 9 про ds18b20. Опрос этого датчика следует организовать аналогичным образом, через callback. Понять что это, для чего, как применяется - первая необходимость для написания кода на Lua, JavaScript, ибо это практически всегда асинхронные операции, где линейное мышление не работает. Оно как раз подводит в случае с публикацией на брокер. Код там работает совсем не так как вы ожидаете.

3. В файле функций и основном файле программы вы заряжаете wifi и включаете его. После чего, все что касается wifi висит в памяти ненужной и никогда не применяемой функцией. Это зря. Более того, разберитесь получше - модуль запоминает настройки и, будучи определенными один раз, обязывают модуль входить в сеть просто при подключении питания без всяких указаний. Иное - для специальных случаев и уж точно не для этого устройства.
Значит - минус все что касается wifi при предварительной настройке.

 

Игорь, огромное спасибо за разбор! Я примерно так и понял, что мыслю пока не по еспишному. Буду работать над этим. Функций будет побольше чем три ибо жадность безгранична и хочется всегда большего Мысль была сделать отдельной функции отдельный файл. Наверно так и поступлю. Вобщем пошел курить матчасть.

 

Это не все, это только половина, чуть позже дальше

 

Допилил счетчик.
1. Имеется led-дисплей 128×64, на котором отображаются показания счетчиков и IP устройства. Дисплей включается кнопкой на 5 секунд (чтобы не выжигать пиксели).

2. Установка начальных показаний и их коррекция при необходимости - через web-страницу.

3. Все данные сохраняются в файлах в spiff. Файлы создаются автоматически при первом запуске устройства. Пишется расход за день, за месяц и общий расход. Весь подсчет и хранение данных ведет устройство (не OpenHAB).
4. Ежедневно и ежемесячно обнуляются данные по соответствующему расходу (cron).
5. Для корректной работы cron ежедневно синхронизируется время (sntp).
Что все это дает:
Не надо лезть в люк с фонариком, чтобы снять показания счетчиков.
В ОН отображается "гистограмма", показывающая ежедневный и ежемесячный расход, а также расход в режиме реального времени.
В дальнейшем можно реализовать отправку по e-mail показаний счетчиков в управляющую компанию в заданный день. Но это уже через ОН.
Даже если у устройства не будет связи с брокером - подсчет будет все равно вестись без потери данных. При появлении связи с брокером ему будут переданы актуальные данные. А в отсутствие связи посмотреть показания можно на дисплее.

Некоторые фрагменты кода созданы с использованием наработок @ИгорьК
Все файлы прошивкой, а также пояснения по работе кода выложу чуть позже.

 

как я понял на esp32 без танцев с бубнами не залить lua.

нужно компайлить прошивку на линухе.

user-frendly на высочайшем уровне

 

4. Вы подключаете свой файл с функциями через require('functionLib').
Это можно, но то что вы делаете смысла особого не имеет. Модули и их способ их подключения - это библиотеки но имеющие цель не только "библиотечить", но и работать с памятью. Подключение модуля таким способом необходимо, в том числе, и для будущего их отключения - высвобождения памяти. В сложных проектах вы должны будете постоянно их загружать и выгружать. Хотя и не возбраняется такой подход, но, повторюсь, это бессмысленно.

5. Про функцию, что публикует ваши топики.

Публикация работает следующим образом.

Код (Text):

client:publish(topic, ...

- асинхронная функция. Это значит, что получив ее, система не кидается ее исполнять, а вносит в регистр асинхронных функций, доделывает свои дела и лишь тогда занимается ей. Система не гарантирует, что асинхронные функции будут выполняться в том порядке, в котором они "запихиваются" в нее.
Вы вызываете публикацию дважды двумя вызовами неасинхронной функции funcTab.publicMQTT.
Эта функция "накидывает" в регистр аж 6 штук асинхронных функций :
2 х "установить связь", 2 х "опубликовать", 2 х разорвать связь = 6.
Соответственно, система вызывает их в том порядке, как ей понравится. Шанс отработать все правильно равен математической вероятности выпадения правильного порядка.

Мы опять столкнулись с асинхроном. Надо знать, что (почти)все асинхронные функции, имеющиеся в вашем распоряжении имеют callback. Установление связи с брокером - асинхронная функция. Она имеет два калбэка, ну так и воткните в тот, что "стреляет" при успешном соединении задачу на отправку сообщения на брокер а закрытие соединения - в callback успешной передачи.

Код (Lua):

--функция публикации в MQTT брокер
function funcTab.publicMQTT (conf, topic, data)
    m = mqtt.Client(conf.mqttClientId, 120, conf.mqttClientUser, conf.mqttClientPwd)
    m:connect(conf.mqttServerIP, conf.mqttServerPort, 0,
        function(client)
            client:publish(topic, data, 0, 0, function(client)
                print("MQTT sent: " .. topic)
                client:close();
            end)
        end,
        function(client, reason)
            print("failed reason: " .. reason)
        end)
end

Но это очень плохой способ общения с брокером. Объект связи с брокером надо создавать один раз и пусть висит. А так у вас постоянно возникает и он и висит функция, которая его создает. То есть вся эта забава имеет немного смысла, а памяти берет достаточно.

 

6. О ссылках.

Здесь довольно сильная засада. Я уже говорил о регистре, куда помещаются ссылки на callback функции.
В данном случае, client тоже ссылка на callback функцию. Система подразумевает, что она должна быть отработана. Без каких-нибудь действий с этой ссылкой она не удаляется из таблицы.

Объяснить это не просто на пальцах, здесь лучше смотреть документацию (и это касается всех асинхронов).
Если в теле асинхронной функции есть ссылка на объект, ее содержащий, операции с этим объектом следует проводить через эту ссылку, в ином случае, каждая операция с объектом "изнутри него" вызывает появление еще одной ссылки.
Количество ссылок большое, но все таки ограниченно.
Когда происходят неправильные обработки этого явления - растет реестр ссылок, при этом куча меняется незначительно. Все это ведет к крашу. Но, как мы знаем, система при этом перезагружается и для случаев со всякими датчиками, мы этого даже не замечаем. А для иных случаев, мы обычно предусматриваем всякие защиты от перезагрузок по питанию, и тоже не замечаем

Собственно все изложено здесь: https://nodemcu.readthedocs.io/en/m...does-the-sdk-event-tasking-system-work-in-lua
Я постарался кратко пересказать, но лучше читать первоисточник.
Другой пересказ в пункте 38.

Ну и данные все таки лучше собирать в таблицу, ее проще запостить на брокер, если данных очень много.
Вроде все

 

client - аргумент callback функции?
Типа идентификатора дочернего процесса, привязывающего его в реестре к родительскому?

 

Лучше читать первоисточник или просто поступать как рекомендует документация, если лень читать

Кстати, в каждом таймере есть внутренняя ссылка не него, и при уничтожении таймера изнутри в callback функции следует ее прямо уничтожать.

Код (Lua):

counter = 0
counttmr = tmr.create()

-- Правильно:
counttmr:alarm(1000, 1, function(t)
    counter = counter +1
    if counter > 10 then
        t:stop()
        t:unregister()
        t, counttmr = nil, nil
        print("All Done!")
    end
end)

-- А так не правильно, хотя и работает до поры до времени:
counttmr:alarm(1000, 1, function()
    counter = counter +1
    if counter > 10 then
        counttmr:stop()
        counttmr:unregister()
        counttmr = nil
        print("All Done!")
    end
end)

Это справедливо для всех случаев наличия внутренних ссылок в асинхронных функциях, коей и таймер является.

 

Не лень. На https://nodemcu.readthedocs.io не нашел. По крайней мере в разделе mqtt. Или это в книге Иерусалимски?

 

Размер LFS на сайте https://nodemcu-build.com увеличен до 256 Кб.

версия прошивки - 3.0...

Здесь можно взять рабочий Luac.cross.exe для LFS 256 Кб.
Для LFS = 128 Кб в bat файле установить константу 0х20000. Но работает и без нее.

 

Игорь, спасибо за пост, очень помог выловить утечку памяти. (Через таймер).

 

Игорь, вопрос: как выгрузить пакет, загруженный по require? Заметил, что после полного удаления объектов программы и самой программы загруженный пакет остается. У меня по меню чередуются вызовы программ, которые в свою очередь, загружают пакеты. Как-то не нашел я как выгрузить (уничтожить) пакет. Может плохо искал, тогда ткните носом, пожалуйста.

 

Иерусалимски. Глава 15.

Грузим:

Код (Lua):

-- загрузка с присваиванием ссылки на модуль
local mod = require "module"

Удаляем:

Код (Lua):

-- выгружаем модуль
package.loaded["module"] = nil
-- удаляем ссылку на него
mod = nil

Все просто, я не встречал, чтобы это не работало.

note. У Иерусалимски можно немного другим синтаксисом:

Код (Lua):

package.loaded.module = nil

Но так в некоторых случаях может не выгружаться. Видимо, это баг NodeMCU.

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

Причин здесь может быть две.

Либо система кэширует модуль независимо от желания юзверя, такая недокументированная возможность.

Либо это связано с тем, что при загрузке в сам модуль, как известно, передается ссылка на него. При "внешней" выгрузке, указанным выше способом, это грузит реестр. Однако повторная загрузка (а так происходит всегда в работающей программе) четко затирает эти ссылки и второй раз происходит "чистая" выгрузка.

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

 

Все отлично. Спасибо.

 

Интересная ситуация: в ESPlorer написал код:

Код (Lua):

pin = 2
pwm.setup(pin, 1000, 512)
pwm.start(pin)
tmr.create():alarm(1000, tmr.ALARM_SINGLE, function() pwm.close(pin) end)
 

Вместо 1сек до закрытия PWM пин открыт ровно в 2 раза дольше, т.е. 2 сек. Это еще полбеды. При отправке и загрузке кода уже из платы ШИМ закрывается ооочень быстро, может 0,5сек. т.е. разницы в строках:

Код (Lua):

tmr.create():alarm(50, tmr.ALARM_SINGLE, function() pwm.close(pin) end)
tmr.create():alarm(1000, tmr.ALARM_SINGLE, function() pwm.close(pin) end)
 

нет совсем.