MajorDoMo

Victor_S писал(а):Хм.. если у Вас охранная сигнализация с выводом на монитор охранной фирмы , то никакого совмещения функций, серверов и даже собственного монтажа Вам не позволят.

Вы ошибаетесь, у меня есть два объекта на которых смонтированы охранные системы своими силами. Сотрудники ОВО без проблем подписали акты и приняли под охрану. Достаточно согласовать то что вы наворотили, причем как выяснилось никакой нормативной базы по количеству датчиков, их расположению и обвязке не существует, все на уровне инструкций-рекомендаций.

Victor_S писал(а):С присутствием людей у датчика очень плохо... Выстраивать логику наличия/отсутствия людей в помещении по датчику движения, ИМХО, не очень здорово...

Очень даже здорово, например если у меня в течении часа нет движения отключается насос ГВС, что экономит кучу газа на нагрев воды.

Victor_S писал(а):Да, кстати, домофон у меня "продвинутый" и может без сервера сообщать об открытой калитке, а для сервера(МД) я отдельно геркон поставил...

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

Собствено мы кудато в методологию ушли.
Мне интересно Сергей как автор модуля готов немного скорректировать его? Я так понимаю что от галочки введенной вчера не только я немного другого функционала ожидал. А кому оно не надо могут галочку не ставить.

zelevova писал(а):Я так понимаю что от галочки введенной вчера не только я немного другого функционала ожидал. А кому оно не надо могут галочку не ставить.

Прошу прощения, но какого функционала Вы ожидали?
Собственно, только установил и ещё не тестировал, возможно чего недопонял из скринов. Мне кажется это именно то, что просили все:

Kod.Begemot писал(а):У меня вопрос - а как обстоит дело со сценариями по умолчанию? Можно их как-то в модуле отключить? Сценарии такие в меге нужны подчас для упрощенного управления, как бы "аварийный режим", а тут они "лезут и мешают", и return(); помогает отнюдь не всегда.

zelevova писал(а): Категорически поддерживаю. Может у каждой кнопки добавить галочку "выполнять сценарий по умолчанию"? Или что то типа того...

AHgpeu писал(а): полностью присоединяюсь к мнению. абсолютно нелогичная вещь. возможно, нужная для первичной настройки.
сервер должен уметь намного больше простого функционала устройства, а не дублировать его зачем-то..

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

протестировал. результат -- полная копия и основная проблема не решена...

основная проблема модуля в том, что он опрашивает состояние модуля после отработки скрипта и ЛЮБОГО обращения к Меге и обращения Меги к серверу, как я понял.
если между ответом и опросом отправить другую команду, как в примере ниже, то получится примерно следующее:
- нажата кнопка. начало работы скрипта
- другая команда
- опрос 2 (от другой команды)
- ответ (от скрипта )
- опрос 1 (от скрипта )

в результате в опросе 1 система получает не те данные, что ожидаются, и всё ломается.

пример: в модуле обрабатывается ВМЕСТО команды по умолчанию скрипт (в котором Relay.status это выход меги): вроде стандартный код функции switch(). всё должно работать... а не тут то было.

как это работает:
1. при первичном "включении света" свет включается (срабатывает switch()) и почти сразу гаснет (срабатывает запоздавшая первая проверка)
2. далее переключается нормально
3. ...до тех пор, пока 'Relay.status' не поменяется откуда угодно ещё (например со сцены)
4. go to 1 =-)

UPD:
собственно, это моё видение проблемы, могу и ошибаться.
по идее, нужно не выполнять опрос меги при return ""; или галочке, поскольку в таком случае, опять же по идее, состояние Меги то не меняется.
возможно, это снимет ошибку

UPD 2:
а в идеале ... переделать модуль на примерно следующий алгоритм (сам не возьмусь, слишком слабое знание внутренней архитектуры MajorDoMo):

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

если сервер сам отправляет команду Меге, то проверять ОТВЕТ Меги (Done).
и уже если ответа нет, или он не корректен, то проверить состояние Меги.

если отправляется собственная команда, не включенная в модуль, то не проверять ответ вообще. оставить на откуп пользователя все проверки.

Сорри, я от обилия информации начинаю теряться
По порядку. За обработку события от меги отвечает код метода processRequest, который расположен в модуле megad (/modules/megad/megad.class.php со строки 283). Если его посмотреть, то в нём уже заложен алгоритм, при котором проверка состояния меги после ответа системы идёт только в том случае, если ответ был не пустым. Проверка состояния выполняется по таймеру через секунду после ответа. Если ответ был пустым, то запрос состояния меги не производится.

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

ну вот нормально же сидели! (с)
такая теория загублена на корню)

а если серьёзно, аж в код полез.. признаю, Вы абсолютно правы.
но вся грусть в том, что проблема есть. и отловить её не получается... больше ну никаких идей.
икс-рей тоже не поможет, там выдаётся только последнее изменение/вызов. нужно логирование как минимум...

Извиняюсь, что вклиниваюсь в разговор. Один вопрос только: будет ли добавлена возможность перепрошивки МегаД по сети в Мажоре как это сделано здесь http://www.ab-log.ru/smart-house/ethern ... re-upgrade?
Кстати, у меня тоже получается двойное переключение если пытаться выключить (включить) свет из меню. Но я пока сильно не разбирался.

Прошивка по сети поддерживается с самого начала (если не ошибаюсь). По крайней мере в актуальной версии она есть точно:
Advanced->Firmware update.

По поводу поддержания новых функций - походу скоро опять понадобится модуль обновлять, т.к. в прошивке обнаружились проблемы при использовании большого количества цифровых датчиков, и очевидно будут изменении в формате передачи серверу состояния устройства. Также ожидается в основной версии поддержка I2C датчиков (и дисплеев?) и ИК-управления техникой (об этом уже писали здесь, кажется).

AHgpeu писал(а):а если серьёзно, аж в код полез.. признаю, Вы абсолютно правы.
но вся грусть в том, что проблема есть. и отловить её не получается... больше ну никаких идей.
икс-рей тоже не поможет, там выдаётся только последнее изменение/вызов. нужно логирование как минимум...

В код можно понатыкать DebMes для логирования и поиска проблемы -- с обновлением слетит, но можно потестировать интенсивно не обновляясь. Я, к сожалению, с такой проблемой не сталкивался и мне её воспроизвести будет сложнее.

Столкнулся с проблемой.
Пункт меню (выключатель) связан со свойством. Свойство привязано в МегаД к выходу реле.
Проблема: после нажатия пункта меню проходит ПЯТЬ секунд, перед тем как свет загорится. И еще ПЯТЬ секунд, до того как на кнопке появится надпись Ок.
Игото 8-10 секунд выполняется одна команда. Если надо много - выходят дикие задержки, что дико раздражает.
Пытался отлаживаться - ерунда какая-то получается, не могу найти причину.
По поводу - когда это появилось: наверное где-то в момент введения ВебСокетов.
Еще, вроде в новый год обновлялся - стало сильно лучше (1 сек. задержка), уже обрадовался, но обновившись 5-ого числа, все вернулось обратно.
Ну, а если переключаю аппаратной кнопкой на МегаД - получается почти мгновенно.

Может кто сталкивался и проблему порешали?