Предыдущая часть.

Проверка работоспособности.

Все файлы залиты, и, нажав на пару кнопок, следует увидеть такую картину:

Все дальнейшие махинации будем осуществлять с помощью MqttSpy.

Если вы изменяли что-то в коде — коннектимся к своему брокеру, нет — iot.eclipse.org.

Подписываемся:

И еще раз:

Итого подписка на два топика:

• noo01/#
• fromnoo01/#

В ESPlorer нажимаем на кнопку «main.lua» и наблюдаем результат:

А теперь при помощи MqttSpy делаем «раз-два-три» — и окне ESPlorer наблюдаем перезагрузку устройства.

То есть, команда «OFF» устройству в топике «noo01/raw/00» вызывает его перезагрузку. Сделано это исключительно для удобства настройки, с учетом того, что в работе устройства блокируется UART и после старта до него не достучаться, кроме как отключив питание. Или выдавая указанную выше команду.

Таким образом, каждый раз, когда вы запускаете (вручную или через init.lua) устройство в работу, соединившись с брокером оно выдает в топике «fromnoo01/getmqtt» информацию «Got Broker now».

Итого:

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

Управление устройством.

Как вы знаете, управление в протоколе mqtt осуществляется парой: топик / дата. Выше мы уже дали первую команду — команду на перезагрузку устройства. Что же мы можем сделать еще? Сначала понять правила составления топиков.

Топик состоит из:

1. начала, которое всегда (если вы ничего не меняли): noo01/
2. команды;
3. номера ячейки привязки.

Например. «noo01/comm/22»:  «comm» — команда, 22 — ячейка привязки. Все команды ищутся в файлах «run.lua», «raw.lua» и «lght.lua».  Что за бред? Ну, не совсем.  Сделано это для… удобства, вашего и моего.

Сначала был единственный файл-обработчик команд run.lua. С увеличением желания парсить все больше и больше команд, он начал расти и «тяжелеть», что для маленького объема оперативной памяти ESP-8266 чревато перезагрузкой.  А вот памяти для записи скриптов у ESP-8266 — немеряно.

Тогда возникла идея, обработку новых команд поручать новому файлу. Таких файлов получилось еще два — raw.lua обрабатывает, как ясно из названия, «сырые» 15-байтные команды (16-й байт считает сам, добавляет 17-й и отправляет на MTRF-64).

Потом появился файл lght.lua — обработка команд с установкой яркости.

UPD 30.05.2017 — добавлен файл rise.lua — световой будильник.

Как же это работает? Принятая от брокера  пара топик/дата парсится на три глобальные переменные (см. файл main.lua): comm, itm, func.

• itm — числовая переменная, адрес ячейки привязки, третья часть топика.
• func — стринг, то что в топике под номером 2,
• comm — стринг, то что пришло в data.

После обновления этих глобальных переменных вызывается функция newdeal() из main.lua, которая просматривает список файлов в устройстве, и если находит файл с именем переменной func —  запускает его, иначе — run.lua.

Что вам это дает? Вы можете сами написать скрипт с именем, например igothome.lua, в котором ваша дача от радости что вы приехали помигает окошками и включит все уличное освещение, причем запустится в работу это всего через один топик брокера «noo01/igothome/00» с датой, например, «ON». Или с датой 7 — семь раз помигать! (И я планирую это сделать на самом деле — прикольно же!)

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

Перечислим все команды, которые возможны для обработки в настоящее время.

Пользуемся таблицей:

Топик: noo01/askf/17 Дата: ON — запрос состояния нового блока F привязанного к ячейке 17.

Топик: noo01/comm/22 Дата: OFF — выключить старый силовой блок, привязанный к ячейке 22.

И вот команда на устройство отправлена. Что же мы должны увидеть? Вот что:

4 — команда отправилась, дальше — ответы от устройства. 5 — размер кучи (свободной памяти) для технических нужд, 6 — raw-ответ MTRF-64 по UART, 7 — прасинг сделанного устройством — ячейка 22 переведена в состояние 0 (то есть выключена).

Заключение.

Полагаю, это все об устройстве. Я ничего не сказал о том, что приходит от устройства в ответ на команды и как выглядит информация от датчиков. MqttSpy в помощь. Привязали — и смотрим:

В любом случае, приходит информация в топике fromnoo01/raw, и одновременно в топике, типа  fromnoo01/00, где две цифры после слэша — номер ячейки MTRF-64.

Что делать со всем этим дальше зависит от вашего уровня подготовки и применяемой системы умного дома.

Я работаю с OpenHab и в теме о нем, а также в прошлых темах на этом сайте неоднократно раскрыто как делать items и писать правила.

=====================================

Хочется сказать, что наконец (сколько лет!) Ноотехника сделала толковое устройство. Хотя очень непросто понять, что мешало сделать приемо-передатчик сразу. Удивляет, также, зачем MTRF-64 при включении входит в режим загрузки микропрограммы — у него много ног, и вход в этот режим можно сделать по опросу какой-нибудь из них. Модуль если и поменяет прошивку, то раз за все время, а может и никогда.

Если у вас есть вопросы, лучше задавать на форуме Амперки. Спасибо за терпение — тема получилась некороткой 🙂

UPD 06.05.2017. pubmqtt.lua — уточнена очистка таблицы после передачи. В файле main9.lua (переименуйте) содержится другой способ отправки raw-информации с MTRF-64. Каждый байт нумеруется, а между парой номер:байт — пробел, байты в десятичном формате:

Ну и остальные файлы на gitHub иногда обновляются, заглядывайте.