MegaD



  • @Alex_Jet:

    Для удобства использования redirect необходим столбец с признаком наличия хотя бы одного правила для redirect у соответствующего request.

    Сделаем в следующем релизе в конце недели.

    @Alex_Jet:

    Иначе при большом количестве request сложно соориентироваться у каких есть redirect.

    Действительно, сейчас настройка не прозрачна. В версии Cherry планируется при выборе записи сразу отображать связанные таблицы. Это относится также к каналам - можно будет показать сразу запросы канала.

    По поводу передачи времени от сервера при получении st=1.

    Думаю, это работает,если это отдельный запрос от сервера (в нашей терминологии Redirect), а не ответ (response) на st=1.

    Сеанс в HTTP 1.0 - это только 1 запрос и 1 ответ.

    Именно поэтому контроллер уже не может ответить Done, если мы передаем команду как ответ на сообщение от MegaD.

    И по термину Redirect. Надо бы придумать другое название, т.к. это просто передача запроса по инициативе сервера при получении сообщения от контроллера (не в том же сеансе).



  • @intrapro:

    По поводу передачи времени от сервера при получении st=1.

    Думаю, это работает,если это отдельный запрос от сервера (в нашей терминологии Redirect), а не ответ (response) на st=1.

    Сеанс в HTTP 1.0 - это только 1 запрос и 1 ответ.

    Именно поэтому контроллер уже не может ответить Done, если мы передаем команду как ответ на сообщение от MegaD.

    Да, так и есть. Главная суть, в том что TCP-соединение - это "запрос-ответ": http://www.ab-log.ru/forum/viewtopic.php?f=1&t=1195&p=26365#p26363

    По redirect… мыслей нет, поскольку у нашего "Redirect" есть 2 варианта:

    1. Ответ текущему контроллеру на основе его запроса, но в новой сессии TCP-соединения - это что-то типа "response to a request"

    2. Выдача команды другому контроллеру, на основе запроса текущего - это что-то типа "command on a request of master"

    Как вариант оставить как есть.



  • Обдумываю как с помощью intrahouse обрабатывать короткое и длинное нажатие одной и той же кнопки. Пока мыслей как это сделать нет.

    Сейчас имеем такой лог при нажатии и удержании кнопки, подключенной к MegaD:

    19.02 23:23:20.0065 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=15&cnt=62
    19.02 23:23:20.0072 MG3?22=TG&
    19.02 23:23:20.0073 192.168.12.21 <= localhost:10021 22:2
    19.02 23:23:21.0055 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=15&m=2&cnt=62
    19.02 23:23:21.0057 MG3?22=TG&
    19.02 23:23:21.0058 192.168.12.21 <= localhost:10021 22:2
    
    

    Как видите MegaD через 1 секунду после нажатия выдает серверу сообщение (m=2) о длительном нажатии кнопки. Однако в request у меня сейчас прописано mod_megad.php?pt=15, соответственно сервер и первое сообщение и второе сообщение от MegaD интерпретирует одинаково.

    Если в request прописать явно mod_megad.php?pt=15&m=2, то первое сообщение сервером вообще не будет обрабатываться. Как быть?

    UPD: единственное, что это режим входа называется P, а можно установить еще P&R, тогда при отжатии кнопки будет дополнительное сообщение типа mod_megad.php?pt=15&m=1&cnt=62.



  • @Alex_Jet:

    Обдумываю как с помощью intrahouse обрабатывать короткое и длинное нажатие одной и той же кнопки. … можно установить еще P&R, тогда при отжатии кнопки будет дополнительное сообщение типа mod_megad.php?pt=15&m=1&cnt=62.

    Все верно, длинное от короткого можно отличить только если отслеживать отжатие.

    mod_megad.php?pt=15&m=1 - короткое, сработает при отпускании

    mod_megad.php?pt=15&m=2 - длинное через секунду

    @Alex_Jet:

    Если в request прописать явно mod_megad.php?pt=15&m=2, то первое сообщение сервером вообще не будет обрабатываться. Как быть?.

    На самом деле для сервера mod_megad.php?pt=15 и mod_megad.php?pt=15&m=2 - это разные сообщения, попробуйте

    Просто mod_megad.php?pt=15 - сработает при нажатии, а уж сколько будут держать, определяется моментом отжатия



  • @intrapro:

    Все верно, длинное от короткого можно отличить только если отслеживать отжатие.

    mod_megad.php?pt=15&m=1 - короткое, сработает при отпускании

    mod_megad.php?pt=15&m=2 - длинное через секунду

    ОК, но после того как придет mod_megad.php?pt=15&m=2, кнопку отпустим и снова придет mod_megad.php?pt=15&m=1!!! Поэкспериментировал.

    1. Зажимаем кратковременно кнопку (вход в режиме P&R) и отпускаем ее:

    20.02 21:14:44.0242 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=0&cnt=1
    20.02 21:14:44.0244 MG3?7=TG&
    20.02 21:14:44.0244 192.168.12.21 <= localhost:10021 7:2
    20.02 21:14:44.0772 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=0&m=1&cnt=2
    20.02 21:14:44.0774 MG3?7=TG&
    20.02 21:14:44.0774 192.168.12.21 <= localhost:10021 7:2
    
    

    2. Зажимаем надолго кнопку (вход в режиме P&R) и отпускаем ее:

    20.02 21:14:46.0756 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=0&cnt=3
    20.02 21:14:46.0758 MG3?7=TG&
    20.02 21:14:46.0758 192.168.12.21 <= localhost:10021 7:2
    20.02 21:14:47.0751 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=0&m=2&cnt=3
    20.02 21:14:47.0759 MG3?7=TG&
    20.02 21:14:47.0759 192.168.12.21 <= localhost:10021 7:2
    20.02 21:14:48.0775 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=0&m=1&cnt=4
    20.02 21:14:48.0776 MG3?7=TG&
    20.02 21:14:48.0777 192.168.12.21 <= localhost:10021 7:2
    
    

    Значит:

    • если пришло pt=0, а следом pt=0&m=1 - то это короткое нажатие.

    • если пришло pt=0, а следом pt=0&m=2 - то это длинное нажатие.

    Как эти условия проверять в ih? Нужна какая-то доработка.



  • @Alex_Jet:

    Значит:

    • если пришло pt=0, а следом pt=0&m=1 - то это короткое нажатие.

    • если пришло pt=0, а следом pt=0&m=2 - то это длинное нажатие.

    Как эти условия проверять в ih? Нужна какая-то доработка.

    Да, вы правы. После m=2 приходит m=1 - это меняет дело 😞

    Нужны цепочки запросов:

    megad?pt=0 then megad?pt=0&m=2

    или просто

    megad?pt=0; megad?pt=0&m=2

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



  • @intrapro:

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

    Ну совсем наизнос работаете…

    UPD: Поменял режим работы входа на P. В итоге сообщение об отпускании теперь не приходит.

    • Короткое нажатие кнопки:
    22.02 00:13:46.0491 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=0&cnt=8
    22.02 00:13:46.0493 MG3?7=TG&
    22.02 00:13:46.0496 192.168.12.21 <= localhost:10021 7:2
    
    
    • Длинное нажатие кнопки:
    22.02 00:13:53.0077 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=0&cnt=9
    22.02 00:13:53.0078 MG3?7=TG&
    22.02 00:13:53.0079 192.168.12.21 <= localhost:10021 7:2
    22.02 00:13:54.0073 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=0&m=2&cnt=9
    22.02 00:13:54.0075 MG3?7=TG&
    22.02 00:13:54.0075 192.168.12.21 <= localhost:10021 7:2
    
    

    В request у меня прописано действие 7:2 для события /mod_megad.php?pt=0. Как видим во втором случае (длинное нажатие кнопки) это действие срабатывает и при событии /mod_megad.php?pt=0&m=2, а по идее не должно! Вот этот случай надо разрешить.



  • К Megad-2561 подключил TM/W26 считыватель типа CP-Z2L. В "Сообщения от MegaD" прописал запрос /mod_megad.php?pt=33&ib=d77516007000, включающий значение ключа. Однако таким образом контроллер команду не получает/не понимает…

    20.03 20:14:13.0652 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=33&ib=d77516007000
    20.03 20:14:13.0663 MG3?13=TG&
    20.03 20:14:13.0663 192.168.12.21 <= localhost:10021 13:2
    
    

    Если прописать "Redirect", то контроллер отрабатывает:

    20.03 20:15:41.0649 192.168.12.21 => localhost:10021 HTTP GET /mod_megad.php?pt=33&ib=d77516007000
    20.03 20:15:41.0651 192.168.12.21 <= localhost:10021 
    20.03 20:15:41.0652 Redirect to MG3
    20.03 20:15:41.0652 localhost => 192.168.12.21:80 HTTP GET /sec/?cmd=13:2
    20.03 20:15:41.0653 MG3?13=TG&
    20.03 20:15:41.0665 localhost <= 192.168.12.21:80 HTTP Done
    
    


  • @intrapro:

    Сделаем в следующем релизе в конце недели.

    Сегодня обновился, обратил внимание, что столбец redirect есть, однако он выходит за рамки экрана. Причем разрешение экрана - 1920х1200!!! На планшете (разрешение 1280х720) столбец Redirect почти не видно. И самое плохое - на планшете redirect вообще настроить не реально - появляется окно, высота которого чрезмерная и верхняя часть частично обрезается!

    PS: может быть столбец redirect переместить до столбца Note?



  • @Alex_Jet:

    может быть столбец redirect переместить до столбца Note?

    Сделали. Обновите систему и попробуйте.



  • @intrahouse:

    Сделали. Обновите систему и попробуйте.

    Спасибо, но обновится не могу. Пишет, что установлена последняя версия системы - v17.3.22.01



  • Сорри :oops:

    Попробуйте еще раз



  • Коллеги! Поскольку в MegaD реализован аппаратный I2C и есть возможность выводить информацию на I2C дисплеи прошу подумать над решением как это встроить в IH:

    i2c_cmd - команды (1 - инициализация; 2 - старт; 3 - стоп)
    Пример: http://192.168.0.14/sec/?pt=35&scl=34&i2c_cmd=1
    
    i2c_send - отправка данных в HEX-виде
    Пример: http://192.168.0.14/sec/?pt=35&scl=34&i2c_send=80
    
    i2c_read - считывание данных в HEX-виде (0 - на конце ACK; 1 - на конце NACK [конец связи])
    Пример: http://192.168.0.14/sec/?pt=35&scl=34&i2c_read=0
    
    i2c_sendp - отправка пакетных данных в HEX-виде
    Пример: http://192.168.0.14/sec/?pt=35&scl=34&i2c_send=780020
    
    

    По мне так:

    1. Нужно создать канал с запросом (/%pwd%/?pt=35&scl=34&i2c), который будет отображать на какие порты MegaD заведены линии SCL и SDA шины I2C.

    2. Скрипт на этом канале должен брать значения из другого канала (температура, влажность, давление, освещенность, состояние портов) или системную информацию (режим работы, системное время, состояние охраны, картинку и прочее) и через функцию отображения данных на дисплее (что, в какой строке, на какой позиции) эти данные выводить на дисплей текущего канала.

    3. Необходимо ввести "cron" для срабатывания скрипта канала чтобы данные на дисплее периодически обновлялись.

    4. Как вариант для дисплеев можно сделать соответствующее устройство в системе и привязывать его к соответствующему каналу. В оперативных (пользовательских) настройках такого устройства можно сделать:

    • выбор показаний, которые надо выводить на дисплей (можно выводить несколько - температура, влажность, уровень СО2 - с 5 секундной задержкой или в каждой строке - свое значение);

    • периодичность обновления информации;

    • настройку яркости дисплея, опять же через API MegaD, в зависимости от времени суток.

    В последней версии ПО чтобы вывести на дисплей крупные цифры можно дать команду "http://192.168.0.14/sec/?pt=33&text=25.8:", где 33 - линия SDA шины I2C; 25.8 - значение отображаемого параметра; : - знак отображения градуса для контроллера. Возможный формат отображения - 0.0 (3 символа), 25.8 (4 символа), -22.7 (5 символов). Скрипт для его центровки:

     0 )
    $my_temp = "s+$my_temp";
    elseif (strlen($my_temp) < 4 )
    $my_temp = "ss$my_temp";
    elseif (strlen($my_temp) < 5 )
    $my_temp = "s$my_temp";
    
    file_get_contents("http://192.168.0.110/sec/?pt=33&text=$my_temp:");
    ?>
    
    


  • Коллеги! Просьба, прокомментируейте, что называется "из первых уст" следующее:

    И вот я не совсем понимаю лог

    10.12.2018 10:33:25 localhost => 192.168.11.21:80 HTTP GET /sec/?pt=35&cmd=get (ОК)

    10.12.2018 10:33:35 192.168.11.21 => localhost:11021 HTTP GET /mod_megad.php?st=1 (ОК, перезагрузка)

    10.12.2018 10:33:35 192.168.11.21 <= localhost:11021 (а это что означает?)

    10.12.2018 10:33:39 localhost <= 192.168.11.21:80 HTTP temp:27.90/hum:8.20 (Как???)

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

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



  • @Alex_Jet:

    Коллеги! Просьба, прокомментируейте, что называется "из первых уст" следующее:

    И вот я не совсем понимаю лог

    10.12.2018 10:33:25 localhost => 192.168.11.21:80 HTTP GET /sec/?pt=35&cmd=get (ОК)

    10.12.2018 10:33:35 192.168.11.21 => localhost:11021 HTTP GET /mod_megad.php?st=1 (ОК, перезагрузка)

    10.12.2018 10:33:35 192.168.11.21 <= localhost:11021 (а это что означает?)

    10.12.2018 10:33:39 localhost <= 192.168.11.21:80 HTTP temp:27.90/hum:8.20 (Как???)

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

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

    Попробую прокомментировать

    Все становится понятным, если обратить внимание, что на первом месте всегда стоит инициатор запроса

    10.12.2018 10:33:35 192.168.11.21 => localhost:11021 HTTP GET /mod_megad.php?st=1 (перезагрузка от контроллера)

    10.12.2018 10:33:35 192.168.11.21 <= localhost:11021 (Плагин в ответ послал код ответа 200, сообщение пустое)

    Плагин всегда отвечает на входящие запросы, даже если нечего отвечать. Это правила хорошего тона

    А последнее сообщение получено в ответ на первое

    10.12.2018 10:33:25 localhost => 192.168.11.21:80 HTTP GET /sec/?pt=35&cmd=get (запрос от плагина)

    10.12.2018 10:33:39 localhost <= 192.168.11.21:80 HTTP temp:27.90/hum:8.20 (Как???)

    Этот вопрос уже год назад всплывал: https://frm.intrahouse.ru/viewtopic.php?f=16&t=13&start=50

    Если передать запрос, а затем перезагрузить контроллер в течение короткого времени, то после перезагрузки он присылает ответ на последний запрос. Объясняется это тем, то по стандарту TCP протокола, "если клиент не получает ответа в течение 10 секунд, то он повторяет процесс соединения заново". Это происходит на сетевом уровне, плагин об этом не знает, он отправил запрос GET и ждет или ответа или ошибки или таймаута. Если укладываемся в таймаут, сокет не закрывается.

    Запрос фактически приходит в контроллер после перезагрузки. Если посмотреть сетевой дамп, это все можно увидеть. Магия сетевых протоколов 🙂



  • Спасибо большое. Уже забыл, что задавал подобный вопрос.


Авторизуйтесь, чтобы ответить