Плагин MegaD



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

    Что такое "значение физического уровня" и "значение логического уровня" в свойствах канала плагина?
    У 16 порта у единственного они 255 и 100 соответственно.



  • Участник @Erik написал в Плагин MegaD:

    Ни на одном другом выключателе такого не приходит.
    Не включал я обработку длинных нажатий. У меня коротких нет. Это выключатели, а не кнопки.

    То есть выключателей несколько, но один работает по другому? Это хорошо. Вы можете в отладчике посмотреть, m=2 думаю приходит и там.
    А обработка длинных видимо не отключается, это встроенная фича MegaD, как повествует мануал:

    Если используется сервер, то в том случае, когда вход (в режиме P или P&R) удерживается замкнутым более 1,5 секунд, на сервер отправляется второй запрос, в котором передается параметр m=2.
    
    http://192.168.0.1/megad.php?pt=4
    // спустя 1,5 секунды удержания клавиши выключателя
    http://192.168.0.1/megad.php?pt=4&m=2
    

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

    Нашей экспертизы тут не хватает 🙂 Может проконсультироваться на ab-log? Что может приводить к переключению настройки? Еще раз повторю, плагин не отправляет никаких скрытых сообщений
    А здесь он вообще только отвечает ответом на запрос.
    Кстати, можно попробовать такую комбинацию: в ответ команду не отправлять (Передать в ответ оставить пустым), но заполнить Выполнить запрос (в т.ч. на другой MegaD), и там прописать команду включения как /sec/?pt=23&cmd=1
    Но это только как эксперимент, особого смысла здесь нет

    Что такое "значение физического уровня" и "значение логического уровня" в свойствах канала плагина? У 16 порта у единственного они 255 и 100 соответственно.

    Это должно быть только у аналоговых актуаторов (напр у диммеров 100% яркость соответствует значению 255) , для бинарных это никакой роли не играет. У вас же выбран бинарный вход? Если нет, попробуйте заменить. Но не думаю, что это поможет



  • Участник @intrapro написал в Плагин MegaD:

    Это должно быть только у аналоговых актуаторов (напр у диммеров 100% яркость соответствует значению 255) , для бинарных это никакой роли не играет. У вас же выбран бинарный вход? Если нет, попробуйте заменить. Но не думаю, что это поможет

    Объясните, как оно там появляется.
    Потому, как я - не ставил. И порт не аналоговый актуатор. А универсальный бинарный датчик.
    Порт 16
    Зеленым выделены другие аналогичные выключатели, у которых проблем нет.



  • Участник @Erik написал в Плагин MegaD:

    Объясните, как оно там появляется.
    Потому, как я - не ставил. И порт не аналоговый актуатор. А универсальный бинарный датчик.
    Зеленым выделены другие аналогичные выключатели, у которых проблем нет.

    Объяснить могу, но это тонкости реализации редактора каналов на сервере.
    Если вы войдете внутрь канала для редактирования, там этих полей нет. Вероятно, когда канал создавался, он был скопирован из AO. Или тип переключался, так как это разрешено. Потом тип был изменен на DI, но поля остались, хотя они для канала этого типа не используются.
    Исправить это очень легко - удалите канал и создайте его как DI.
    Я даже предлагаю Вам 16 канал не создавать, так как для функции выключателя он не нужен. Входящее сообщение pt=16 просто отправляет команду 23:1



  • Нет. Никогда он не создавался как АО.
    И, кроме того, я его удалял и создавал заново, сразу как DI. Чтобы исключить некорректный конфиг.
    Поэтому, кстати, он последний в списке.

    И по поводу этой части лога.

    15.12 07:29:19.050 megad1: 192.168.13.10 => localhost:8083 HTTP GET /?pt=16&m=2&cnt=1
    15.12 07:29:19.051 IH: get [ { id: '16', value: '1' }, { id: '23', value: '1' } ]
    set { SENSOR6: { dval: 1, err: 0 }, LAMP13: { dval: 1, err: 0 } }
    

    При всем моем уважении. Сервер даже на включение меге команду не послал, пока я в расширениях запись не создал.
    Так там созданы только для /?pt=16 и /?pt=16&m=1
    Для /?pt=16&m=2 нет. На каком основании он отрабатывается вообще?



  • Участник @Erik написал в Плагин MegaD:

    Нет. Никогда он не создавался как АО.
    И, кроме того, я его удалял и создавал заново, сразу как DI. Чтобы исключить некорректный конфиг.
    Поэтому, кстати, он последний в списке.

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

    При всем моем уважении. Сервер даже на включение меге команду не послал, пока я в расширениях запись не создал.
    Так там созданы только для /?pt=16 и /?pt=16&m=1
    Для /?pt=16&m=2 нет. На каком основании он отрабатывается вообще?

    Алгоритм обработки входящих сообщений такой: ищется максимально совпадающий запрос.

    • Для /pt=16&m=1&cnt=xx это /pt=16&m=1

    • Для /pt=16&cnt=xx это /pt=16

    • Для /pt=16&m=2&cnt=xx это тоже /pt=16, так как других нет

    Если Вы добавите /pt=16&m=2 с пустой командой, то он команду отсылать не будет, отправит пустой ответ.



  • @Erik, честно говоря, нет необходимости в плагине делать каналы для выключателей, СМК, датчиков движения, то есть для всех, которые имеют "сухой контакт". Все их сработки просто должны быть описаны в расширениях.
    В качестве примера привожу расширениях с 3-х разных своих MegaD:
    Switch_Click&M2.png

    Участник @intrapro написал в Плагин MegaD:

    Алгоритм обработки входящих сообщений такой: ищется максимально совпадающий запрос.

    Как я уже говорил, тут то ли какие-то чудеса, то ли @intrapro (без обид!) не понимает где есть проблема. Потому что алгоритм в iH Berry работал безупречно. То есть:

    1. Если было прописано условие pt=0, то оно срабатывало только при входящем pt=0&cnt=xx
    2. Если было прописано условие pt=0&m=1, то оно срабатывало только при входящем pt=0&m=1&cnt=xx
    3. Если было прописано условие pt=0&m=2, то оно срабатывало только при входящем pt=0&m=2&cnt=xx
      Поскольку при переходе на iH Cherry и воссоздании всех настроек из iH Berry у меня все стало работать по другому...
      В общем, надо допилить этот алгоритм - чтобы он работал как полагается:)

    Мои рассуждения:

    1. Имеем, например, нужное условие срабатывания pt=0&m=1
    2. Имеем входящее pt=0&m=1&cnt=xx
      Нам нужно из всех условий данного плагина сформировать массив и при входящем сообщении отбросить у него ключ cnt и полученное сообщение сравнить со всеми элементами массива:
    massiv[number_element].indexOf("pt=0&m=1") >= 0
    

    Как итог, на выходе мы получим, что по заданному входящему есть совпадения в массиве, соответствующие, только pt=0&m=1...
    Другой момент, если нам надо будет обращать внимание на значение ключа cnt.

    @intrapro, в вашем коде мне немного не хватает комментариев чтобы читать код с листа, но у Вас все так и делается - утилитой формируется массив из всех условий и ищется первый номер условия, которое совпадает со входящим сообщением:

    for (var i = 0; i < tableMReq[pathname][id].length; i++) {
      if (isSuitable(tableMReq[pathname][id][i].queryprops, query)) {
      return tableMReq[pathname][id][i];
    }
    

    А вот эта функция как раз отвечает за принцип поиска совпадений сообщения body в массиве условий, но она мне реально не понятна...

    function isSuitable(patobj, qobj) {
        if (!patobj || !qobj) return;
    
        for (var prop in patobj) {
          if (patobj[prop] == "*") {
            if (qobj[prop] == undefined) return;
          } else if (qobj[prop] != patobj[prop]) return;
        }
        return true;
      }
    


  • @Alex_Jet , у меня ситуация странная.
    Потому, что до обновления прошивки на мегах все работало отлично.
    После обносления прошивки вылез этот один косяк, но только после того, как мегу присоединил к серверу. Без связки с сервером работает корректно.

    Я сам не могу найти проблему. Вот и бегаю между двумя форумами - ab-log и IntraHouse.

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

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

    Мне вообще выключатели нравятся больше кнопок. И каналы для них нужны. Это вам не кнопки! 🙂



  • @Erik, классно, что Вы придумали и реализовали такой богатый функционал! Предлагалось удалить канал только для тестирования. Чтобы вы увидели, что плагин с каналом ничего не делает. Но, думаю, поможет примерно также как и стирание плагина 🙂

    @Alex_Jet , по алгоритму плагина

    Как я уже говорил, тут то ли какие-то чудеса, то ли @intrapro (без обид!) не понимает где есть проблема. Потому что алгоритм в iH Berry работал безупречно. То есть:
    1.Если было прописано условие pt=0, то оно срабатывало только при входящем pt=0&cnt=xx
    2. Если было прописано условие pt=0&m=1, то оно срабатывало только при входящем pt=0&m=1&cnt=xx
    3. Если было прописано условие pt=0&m=2, то оно срабатывало только при входящем pt=0&m=2&cnt=xx

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

    Поэтому алгоритм обработки входящих запросов такой:

    1. Из таблицы входящих запросов формируются объекты, чтобы не было зависимости от порядка параметров в строке:
    "pt=0&m=1" => {pt:0, m:1}, "pt=0" => {pt:0}, "pt=0&m=2&cnt=*" => {pt:0, m:2, cnt='*'},
    
    1. Существенным параметром считается номер порта pt. Все объекты группируются в массивы по портам плюс отдельная группа запросов, в которых порт не участвует. Массив упорядочивается по количеству параметров от большего к меньшему
    Для pt=0 -  [{pt:0, m:2, cnt='*'}, {pt:0, m:1}, {pt:0}]
    
    1. Когда приходит реальный запрос (который тоже преобразуется в объект), то ищется подходящая группа по номеру порта pt, и в ней подбирается соответствие перебором массива образцов.
      Функция isSuitable(patobj, qobj) получает каждый элемент массива образцов patobj и входящий объект qobj. Во входящем объекте должны быть все параметры, которые задал пользователь, в этом случае функция возвращает true. Обратное не требуется, т е во входящем запросе может быть сколько угодно не упомянутых в образце параметров
    if (patobj[prop] == "*") {//  в образце может быть звездочка - тогда требуется просто присутствие
           if (qobj[prop] == undefined) return;  // не подходит, так как во входящем нет совсем
    } else if (qobj[prop] != patobj[prop]) return; // не подходит, так как параметра нет или значение не совпадает
    
    

    Поскольку массив упорядочен по убыванию количества параметров, если совпадение не найдено, далее берется образец с меньшим числом параметров. Если вы не прописали pt=0&m=2, то последний образец будет pt=0, и он подходит. Для изменения ситуации достаточно прописать pt=0&m=2 с пустой командой.

    В общем, надо допилить этот алгоритм - чтобы он работал как полагается:)

    Это замечательная идея. Поскольку плагин расположен в публичном репозитарии на github https://github.com/intrahouseio/intraHouse.plugin-MegaD, есть масса вариантов:

    1. Можно сделать pull-request в действующий репозитарий. Для этого откорректируйте код прямо в репо, вам будет предложено создать pull-request. После ревью и одобрения ваши изменения будут включены в действующий плагин.

    2. Можно сделать fork текущего плагина и менять на свой вкус.

    3. Можно разработать новый плагин с использованием нового API плагинов https://github.com/intrahouseio/intraHouse-Cherry/wiki/Plugin-API-4.6

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



  • Участник @intrapro написал в Плагин MegaD:

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

    Вы просто плохо его знаете!!!!
    Если неисправность возникает только при взаимодействии с сервером - значит сервер как минимум соучастник. Тут даже к следователю не ходи.
    Вопрос только - по злому умыслу, или непреднамеренно? 🙂

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

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



  • Участник @Erik написал в Плагин MegaD:

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

    После этого не значит вследствие этого.
    Если следователь не профессионал, то да. Решит, как проще, и дело закрыто.

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

    Вводные:
    Контроллер - самостоятельное устройство. Он может изменить настройку портов

    a) при действиях пользователя через web-интерфейс контроллера

    б) через внутреннюю программу контроллера, которая может изменить настройку, например, в защитных целях. Ну только предположим, что при нажатии на включатель идет дребезг, с частотой, которая проходит входные фильтры, но не позволяет отправлять сообщения на сервер так часто. Контроллер смотрит - P&R и при этом есть настройка сервера и решает - P&R
    не получится, буду работать в режиме P с программной фильтрацией. И никакого взаимодействия с сервером, заметьте, пока не было.

    в) под внешним воздействием. Разработчик MegaD говорит: "Отправлять GET-запросы, меняющие конфигурацию, может не только пользователь из браузера, но и сервер" То есть существует конкретный запрос, который нужно передать на контроллер по 80 порту.
    ОК, тогда этот запрос можно увидеть. Не верите отладчику, не доверяете плагину - подключите любой сниффер, wireshark или tcpdump прямо на сервере IH. Если увидите этот запрос - вопросы к серверу. Если нет - значит контроллер подвержен какому-то магическому внешнему воздействию или надо рассматривать вариант б)

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

    Наверно, нужно изучить фазы луны. Можно еще сервер тряпочкой протирать 🙂



  • @intrapro
    Вы очень здорово рассуждаете, но никак не объясняете причину бага.

    Баг такой - при добавлении сервера происходит искажение настройки порта.
    Если сервер не добавлять - не происходит. Мало того. Если убрать настройку сервера - настройки порта сами возвращаются в корректное состояние.

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



  • Участник @Erik написал в Плагин MegaD:

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

    Замена файлов помочь не могла. Код плагина не менялся с марта 2019 года



  • Участник @Erik написал в Плагин MegaD:

    @intrapro
    Вы очень здорово рассуждаете, но никак не объясняете причину бага.

    Баг такой - при добавлении сервера происходит искажение настройки порта.
    Если сервер не добавлять - не происходит. Мало того. Если убрать настройку сервера - настройки порта сами возвращаются в корректное состояние.

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

    Не с кем не охота вступать в дискуссию, но если все же это не косяк IH ? Дабы не обвинять ни кого, нужно более плотно подойти к анализу диагностики этой проблемы. Давайте рассмотрим мистическую и очень маловероятную вещь: если прошивка megad была старая, а при переходе на новую, было куча изменений, то при включенном сервере IH в момент перепрошивки, произошло именно то, что мешает Вам в данный момент. Просто Ваша проблема у других пользователей не проявляется. Опять же повторюсь, что для детальной диагностики этого бага нужно проблему изучать. Я бы на 2й машине с нуля установил без всего лишнего чисто для теста IH и проверил эту теорию.



  • И еще. Можно откатиться на ту же прошивку, при которой не было глюка и глянуть что будет.



  • Участник @artem521 написал в Плагин MegaD:

    Давайте рассмотрим мистическую и очень маловероятную вещь: если прошивка megad была старая, а при переходе на новую, было куча изменений, то при включенном сервере IH в момент перепрошивки, произошло именно то, что мешает Вам в данный момент.

    Нет. При прошивке я отелючал Мегу от сети, подключал к нотбуку патчкордом и прошивал. Сервер на прошивку влиять не мог.



  • Участник @intrahouse написал в Плагин MegaD:

    Замена файлов помочь не могла. Код плагина не менялся с января 2019 года

    Посмотрим.
    Файлы меняются не только при изменениях версии. Но и при некорректных отключениях питания, например. Юникс битый файл какой либо ценностью не считает. И просто удаляет его из файловой системы.
    Чтобы хотя бы это исключить, я переустановил плагин. И изменения поведения уже видны.
    Точнее протестирую в выходные.



  • @Erik, замена файла плагина на точно такой же без всякого на то основания - это из области ритуалов. Кто верит, тому помогает 🙂

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

    Я причину объяснить не могу, у меня недостаточно информации. Могу предложить варианты поиска проблемы

    Баг такой - при добавлении сервера происходит искажение настройки порта.

    Баг возникает на контроллере при прописывании сервера. Если это так - сервер совсем не при чем.
    Или не при прописывании, а при отправке контроллером сообщения на сервер (то есть при замыкании входа)?

    Можно попробовать:
    Тест 1. На сервере убрать обработку этого канала. Посмотреть, будет ли сбрасываться настройка.

    Тест 2. Прописать в качестве сервера не IH, а очень простой http-сервер, который просто слушает порт и точно ничего не отсылает

    Тест 3. Попробовать замыкать вход не выключателем, а напрямую на контроллере

    И самое главное - если все же думаете о внешнем воздействии на контроллер - исследуйте трафик



  • Участник @artem521 написал в Плагин MegaD:

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

    Я это планирую. Выше написано.



  • @intrapro

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

    Баг возникает после прописывания сервера, при замыкании входа.

    Если просто поменять IP сервера в настройках меги, или даже порт, ошибка пропадает.

    А косяков полно, разной степени критичности. Я же выше даже скриншот прислал, как после изменения настроек плагина меняется отображение его версии.
    Вы на это не прореагировали даже.

    Или это тоже больше ни у кого не проявляется? Или вы считаете это корректной работой?


Log in to reply