Плагин MegaD

[Erik]

Вопрос.

У меня к меге подключены обычные выключатели, а не кнопки.

Они и так работают, конечно, во взаимодействии с мегой проблем нет.

В поле Act стоит 9:3, например, и выход 9 повторяет состояние выключателя на входе.

А во взаимодействии с сервером слишком много вариантов.

вариант 1.

Создать расширения, и в поле ответ поставить те же самые 9:3.

Вариант 2.

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

Вариант 3.

Расширения не создавать, создать мультисценарий, запускающийся при изменении входа, и устанавливающий состояние выхода в соответствии с изменением.

Как правильно?

[intrapro]

@Erik:

Вопрос.

У меня к меге подключены обычные выключатели, а не кнопки.

Они и так работают, конечно, во взаимодействии с мегой проблем нет.

В поле Act стоит 9:3, например, и выход 9 повторяет состояние выключателя на входе.

А во взаимодействии с сервером слишком много вариантов.

вариант 1.

Создать расширения, и в поле ответ поставить те же самые 9:3.

Вариант 2.

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

Вариант 3.

Расширения не создавать, создать мультисценарий, запускающийся при изменении входа, и устанавливающий состояние выхода в соответствии с изменением.

Как правильно?

Не бывает слишком много вариантов в нашем многовариантном мире

И единственно правильного решения тоже нет. Все зависит от задачи

@Erik:

вариант 1.

Создать расширения, и в поле ответ поставить те же самые 9:3.

Этот вариант самый быстрый - и по скорости реакции, и по реализации

Ответ отправляется как response на request сервера.

Еще плюс - вход как устройство (и даже как канал) можно не создавать.

Этот вариант заточен на контроллер MegaD, который дает возможность передать команду в ответ на request о переключении состояния

@Erik:

Вариант 2.

Создать расширения, и мультисценарий, который в зависимости от состояния входа устанавливавет состояние выхода.

Здесь будет задержка на выполнение сценария (которая реально конечно не заметна)

Опять можно обойтись без создания устройства для входа. В сценарий передается тело запроса.

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

@Erik:

В этом случае поле "отправить в ответ" и "установить состояние каналов" в расширении оставить пустым?

Да. "отправить в ответ" - это отправить response на request сервера. Здесь команда на контроллер пойдет отдельным запросом,

И состояние выхода будет установлено как результат выполнения этой команды

@Erik:

Вариант 3.

Расширения не создавать, создать мультисценарий, запускающийся при изменении входа, и устанавливающий состояние выхода в соответствии с изменением.

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

[Erik]

В варианте 1. Сервер отобразит лампу включенной? Или что нужно настроить?

В варианте 2 и 3. В этом случае сервер не ответит на запрос меги, он отправит свою собственную команду. А что будет с полем Act у меги? Мега не дождется ответа, сделает то, что прописано в Act, а потом еще и команда от сервера прилетит?

[intrapro]

@Erik:

В варианте 1. Сервер отобразит лампу включенной? Или что нужно настроить?

Нужно "установить состояние каналов" для выхода:

Так как у вас команда 3, то номер выхода=%значение входа% , например, 7=%ext0% (зависит от входящего сообщения)

@Erik:

В варианте 2 и 3. В этом случае сервер не ответит на запрос меги, он отправит свою собственную команду. А что будет с полем Act у меги? Мега не дождется ответа, сделает то, что прописано в Act, а потом еще и команда от сервера прилетит?

Сервер на любой запрос меги отвечает кодом 200. Он просто не передаст команду в ответ.

Из священного мануала:
<quote>> Флажок (чекбокс) справа от поля Act определяет логику работы сценария. Если он не установлен (по умолчанию), то сценарий выполняется ТОЛЬКО если сервер не прописан, недоступен или HTTP-статус отличен от 200. Если флажок установлен, то сценарий выполняется всегда независимо от наличия сервера. Контроллер в этом случае будет сообщать на сервер о событиях, но его ответные команды в рамках одной TCP-сессии будут проигнорированы.

[Erik]

@intrapro:

@Erik:

В варианте 2 и 3. В этом случае сервер не ответит на запрос меги, он отправит свою собственную команду. А что будет с полем Act у меги? Мега не дождется ответа, сделает то, что прописано в Act, а потом еще и команда от сервера прилетит?

Сервер на любой запрос меги отвечает кодом 200. Он просто не передаст команду в ответ.

Из священного мануала:
<quote>> Флажок (чекбокс) справа от поля Act определяет логику работы сценария. Если он не установлен (по умолчанию), то сценарий выполняется ТОЛЬКО если сервер не прописан, недоступен или HTTP-статус отличен от 200. Если флажок установлен, то сценарий выполняется всегда независимо от наличия сервера. Контроллер в этом случае будет сообщать на сервер о событиях, но его ответные команды в рамках одной TCP-сессии будут проигнорированы.

Это не понятно.

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

[intrapro]

@Erik:

@intrapro:

@Erik:

В варианте 2 и 3. В этом случае сервер не ответит на запрос меги, он отправит свою собственную команду. А что будет с полем Act у меги? Мега не дождется ответа, сделает то, что прописано в Act, а потом еще и команда от сервера прилетит?

Сервер на любой запрос меги отвечает кодом 200. Он просто не передаст команду в ответ.

Из священного мануала:
<quote>> Флажок (чекбокс) справа от поля Act определяет логику работы сценария. Если он не установлен (по умолчанию), то сценарий выполняется ТОЛЬКО если сервер не прописан, недоступен или HTTP-статус отличен от 200. Если флажок установлен, то сценарий выполняется всегда независимо от наличия сервера. Контроллер в этом случае будет сообщать на сервер о событиях, но его ответные команды в рамках одной TCP-сессии будут проигнорированы.

Это не понятно.

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

Нужно лог смотреть.

[Erik]

@intrapro:

Нужно лог смотреть.

где?

[intrapro]

@Erik:

@intrapro:

Нужно лог смотреть.

где?

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

Возможно, есть какие-то изменения прошивки контроллера

[Erik]

@intrapro:

@Erik:

@intrapro:

Нужно лог смотреть.

где?

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

Возможно, есть какие-то изменения прошивки контроллера

У меня прошивка старая, с какой купил. Ни разу не прошивал.

Мне от контроллера нужен базовый функционал, к которому и вопросов то никогда не было.

[intrapro]

@Erik:

@intrapro:

@Erik:

где?

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

Возможно, есть какие-то изменения прошивки контроллера

У меня прошивка старая, с какой купил. Ни разу не прошивал.

Мне от контроллера нужен базовый функционал, к которому и вопросов то никогда не было.

А в чем текущая проблема?

Какой вариант Вы хотите реализовать?

[Erik]

Проблема одна - я в возможностях заблудился.

Работало само, но только не отображались изменения в интерфейсе IH, если были сделаны выключателем.

А тут оказалось, что не должно было работать.

Тревожно.

Пока сделал мультисценарии с автозапуском по изменению.

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

Но кнопки нажимать поеду только послезавтра.

[intrapro]

@Erik:

Проблема одна - я в возможностях заблудился.

Работало само, но только не отображались изменения в интерфейсе IH, если были сделаны выключателем.

А тут оказалось, что не должно было работать.

Тревожно.

Пока сделал мультисценарии с автозапуском по изменению.

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

Но кнопки нажимать поеду только послезавтра.

Если расширения не создавать (события не слушать), то будет задержка <= период опроса входа. Так как про изменение входа сервер в таком случае узнает только при опросе

[Erik]

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

В третьем варианте - большая задержка.

Лучший вариант - второй? Расширение запускает скрипт, все быстро и один раз. Правильно?

[intrapro]

@Erik:

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

Почему? Если сценарий к входу не привязывать, то команда будет посылаться в ответ на событие изменения входа и все.

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

Если же там длинное - не длинное нажатие, то да, легче запустить скрипт.

[Erik]

Я не понимаю логику работы плагина.

Что значит "установить состояние каналов" в расширении?

И почему в примере "1=ON&7=TOGGLE"

Что это значит? Если от меги пришло сообщение, что канал 1 стал "ON", состояние канала на плагине не изменится, если не будет расширения, которое изменит состояние канала? Не достаточно сообщения от меги?

И изменение состояние канала 7 - это только меняется состояние канала? И IH его отобразит в подключенном устройстве после очередного сканирования? И он только отобразит? Или при изменении состояния устройства пойдет команда на мегу?

И какой синтаксис у поля "установить состояние каналов"?

Или для одного выключателя делать 2 расширения.

Один на включение с входящим от меги /megad?pt=1 и ответом 9:1, установкой состояния канала 9=ON

Второй на выключение с входящим от меги /megad?pt=1&m=1 и ответом 9:0, установкой состояния канала 9=OFF

???

[intrapro]

@Erik:

Я не понимаю логику работы плагина.

Что значит "установить состояние каналов" в расширении?

И почему в примере "1=ON&7=TOGGLE"

Что это значит? Если от меги пришло сообщение, что канал 1 стал "ON", состояние канала на плагине не изменится, если не будет расширения, которое изменит состояние канала? Не достаточно сообщения от меги?

И изменение состояние канала 7 - это только меняется состояние канала? И IH его отобразит в подключенном устройстве после очередного сканирования? И он только отобразит? Или при изменении состояния устройства пойдет команда на мегу?

И какой синтаксис у поля "установить состояние каналов"?

Возможно, сразу и не понятно, хотя это работает с самой первой реализации на Berry.

Но если смотреть в контексте - то можно понять. И простить

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

1. Опрос канала. Сервер опрашивает контроллер с заданным периодом. Также можно циклически делать полный опрос cmd=all. Плагин парсит ответ и записывает значения в канал (несколько каналов)

Минусы: при частом опросе (коротких интервалах) нагружается контроллер, при длинных - страдает оперативность и визуализация

2. Мега сама может посылать сообщения об изменении ВХОДОВ. И это здорово! С дискретными датчиками обычно именно так и работают.

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

То есть плагин НИКАК не привязан к синтаксису входящих сообщений контроллера. Он их не разбирает, только группирует по pt=x (pt=1, pt=23,.., без pt) и для входящего находит самое подходящее в табличке.

Поэтому для сообщения нужно явно прописать, что оно значит с точки зрения переключения входного канала (-ов): 1=ON

По одному входному сообщению может теоретически меняться несколько каналов.

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

Дальше - можно отправить команду в ответ на сообщение. Например, включить лампу (7:1)

Но сервер сам знать не знает, что значит 7:1 (а тем более 7:2 или 7:3)

И контроллер при этом не пришлет состояние выхода при переключении. Вы знаете, это такая фишка MegaD - типа сервер переключил, сам и должен знать. Следовательно, мы должны еще установить состояние выхода для индикации заранее (в большой надежде, что команда дойдет) И если команда 7:2, нужно установить 7=TOGGLE

@Erik:

И изменение состояние канала 7 - это только меняется состояние канала? И IH его отобразит в подключенном устройстве после очередного сканирования? И он только отобразит? Или при изменении состояния устройства пойдет команда на мегу?

И какой синтаксис у поля "установить состояние каналов"?

Нет, команды - отдельно, состояния - отдельно. Отправили команду, в канале установили состояние: ON, OFF, TOGGLE, сразу отработала визуализация связанного устройства

Синтаксис действительно неудачный Можно писать и так: 1=1&7=0 Но 7=2 - так не прокатит

Можно также присвоить значение прямо из запроса. Если оно там есть

Например, сообщение: /..&ext0=* - принимается любое значение, и это значение записать в состояние: 7=%ext0%

@Erik:

Или для одного выключателя делать 2 расширения.

Один на включение с входящим от меги /megad?pt=1 и ответом 9:1, установкой состояния канала 9=ON

Второй на выключение с входящим от меги /megad?pt=1&m=1 и ответом 9:0, установкой состояния канала 9=OFF

???

Да, именно так. Если бы было сообщение в формате /megad?pt=1&val=1 (или 0), то обошлись бы одним

[Erik]

достаточно в "установить канал" указать 9=ON

Или нужно обязательно 1=ON&9=ON ?

Или правильно 1=1&9=1 ?

[intrapro]

@Erik:

достаточно в "установить канал" указать 9=ON

Для переключения светильника на индикации - достаточно

@Erik:

Или нужно обязательно 1=ON&9=ON ?

Для переключения светильника на индикации - не обязательно

Если у вас есть канал для выключателя и вам важно его состояние (участвует в других сценариях, выведен на индикацию), то 1=ON&9=ON

В общем, хуже не будет

@Erik:

Или правильно 1=1&9=1 ?

Стандартный синтаксис 1=ON&9=ON. Но так тоже можно

[Erik]

Спасибо.

[Erik]

Пощелкал выключателем.

На сервер от меги приетает это

26.06 11:40:36.196 megad1: 192.168.13.10 => localhost:8082 HTTP GET /?pt=5&cnt=778&mdid=
26.06 11:40:36.197 megad1: 192.168.13.10 <= localhost:8082 
26.06 11:40:36.802 megad1: 192.168.13.10 => localhost:8082 HTTP GET /?pt=5&m=1&cnt=779&mdid=
26.06 11:40:36.803 megad1: 192.168.13.10 <= localhost:8082 
26.06 11:40:37.299 megad1: 192.168.13.10 => localhost:8082 HTTP GET /?pt=5&cnt=780&mdid=
26.06 11:40:37.300 megad1: 192.168.13.10 <= localhost:8082 
26.06 11:40:37.789 megad1: 192.168.13.10 => localhost:8082 HTTP GET /?pt=5&m=1&cnt=781&mdid=
26.06 11:40:37.790 megad1: 192.168.13.10 <= localhost:8082 

Расширение ждут это

/megad?pt=5

ответов нет.

Вписал /?pt=5 вместо /megad?pt=5, заработало.