Новый контроллер CM15

[nite_man]

Можно попробовать сделать следующее. Во-первых, вытащить батарейки из CM15A, если они там есть. Затем "очистить" устройство с помощью виндовой программы ActiveHome, идущей в поставке вместе с устройством. Для этого идем в меню Tools и выбираем clear interface из раскрывающегося списка. А сообщение о добавлении нового устройства появляется при каждой перезагрузки гибридного сервера? Сколько CM15A интерфейсов видно на странице Wizard --> Devices --> Interfaces на админском сайте?

[vlad]

Можно попробовать сделать следующее. Во-первых, вытащить батарейки из CM15A, если они там есть. Затем "очистить" устройство с помощью виндовой программы ActiveHome, идущей в поставке вместе с устройством. Для этого идем в меню Tools и выбираем clear interface из раскрывающегося списка. А сообщение о добавлении нового устройства появляется при каждой перезагрузки гибридного сервера? Сколько CM15A интерфейсов видно на странице Wizard --> Devices --> Interfaces на админском сайте?

На выходных попробую.

При перезагрузке сервера сообщений о новом устройстве нету. Интерфейс один.
Попробую вообще вытащить батарейку. Может в этом дело. При тестовом модуле батарейки не было.

[nite_man]

Батарейки надо обязательно вытащить. Они нужны только, когда CM15A работает сам в качестве контроллера (программируется из ActiveHome), и батарейки нужны для сохранения настроек при потере питания. В случае с LinuxMCE он работает, как интерфейс между x10 сетью и LinuxMCE сервером, являющемся контроллером. Посему батарейки могут только вредить. Что, по всей видимости и происходит в Вашем случае.

[vlad]

Вытащил, посмотрим.

[vlad]

Вынимание батареек не помогло. Отработало сутки и опять не отвечает. В логах Shutdown.

Может, возможно написать программку как safe_asterisk, которая будет следить за состоянием C15 и перезапускать его в случае shutdowna?
Какой механизм запуска CM15?

dcerouter_1008461:~# ps ax | grep CM15
7089 ? S 0:00 sh -c tail -f /var/log/pluto/41_CM15A.log | /usr/pluto/bin/ansi2html
7090 ? S 0:00 tail -f /var/log/pluto/41_CM15A.log

[nite_man]

CM15A интерфейс запускается, как и все остальные устройства, добавленные в LMCE, при старте или перезагрузке DCERouter-а. Перегрузить же только CM15A не получится, так как соответствующих команд нет в темплейте и самом интерфейсе. Посмотрите еще, что в логах DCERouter в то время, как в логе CM15 появляется shutdown. Ну и можно попробовать почистить интерфейс через ActiveHome.

[vlad]

Где можно найти исходники модуля CM15, а именно файла /usr/pluto/bin/CM15A

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

Проблемы как минимум две:
1) Как и раньше, интерфейс отваливается с завидной переодичностью, менялось железо, но и это не помогло.
2) Не удается заставить систему реагировать на MS13E. Причем в логах я вижу, что сигнал пришел, но что только я не пробовал в сценариях выбирать -- реакции нету. Причем судя по логам приходят сигналы ON и OFF, что и должно быть, а пишется, что в сценариях нужно выбирать tripped, хочется сделать обработку обоих событий. Для этого нужно смотреть механизм работы в принципе.

[nite_man]

Найти исходники CM15 можно в репозитарии LinuxMCE (branch LinuxMCE-0810). Для checkout запускаем команду:

Код: Выделить все

svn co http://svn.linuxmce.org/svn/branches/LinuxMCE-0810/src LinuxMCE-0810

Насчет проблемы со срабатыванием датчика ничего сказать не могу, так как у меня CM11. Включите уровень дебага в /etc/pluto.conf повыше и смотрите, приходит ли команда с датчика и на куда она посылается уже внутри LinuxMCE. Вопрос такой, а адрес датчика в админском интерфейсе указан правильно для этого датчика? Кем он контролируется - CM15? Было бы полезно увидеть скриншот с админского интерфейса со свойствами этого датчика.

[vlad]

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

Есть СМ11А, СМ15А, Датчик движения и освещенности MS13E, Дверной датчик DS18, Несколько включающих устройств, TM13

Как оказалось, при использовании CM11A датчик MS13 добавляется и работает, DS18 даже не отображается в логах (есть мысль, что проблема с ТМ13, но он согласно инструкции стоит на сети P и видит С11 -- стало быть должен видеть и сеть А)
При использовании CM15A датчик MS13 добавляется но не работает (в логах I think you Want C11 on, I think you Want C11 off), DS18 отображается в логах как I think you Want A1 off. C11 и А1 -- адреса датчиков. (Это при добавлении "10" в файле /etc/pluto.conf --> LogLevels)

Самое интересное, если датчик MS13 добавить на интерфейс CM11A, а потом переключить на CM15A -- то он работает и дальше!

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

Готов предоставить тестовую площадку с вышеуказанным оборудованием.

[nite_man]

Влад, я бы посоветовал Вам отписаться в этом топике. Думаю, что только автор CM15A интерфейса сможет Вам помочь. Ну или те пользователи, которые тоже его используют. Я, к сожалению, не сишник. Посему врядли разберусь в коде. Решение Вашей проблемы усложняется еще и тем, что разработчикам LinuxMCE интереснее возиться с Z-Wave и EnOcean. Но никак ни с X10.

Теперь мои пять копеек. Дверной датчик DS18 ни с CM11, ни с CM15 работать не будет. Это пожалуй что самый большой недостаток X10. Дело в том, что для автоматизации и охраны используются разные протоколы. Поэтому все датчики (кроме MS13) требуют наличия охранной панели.

Ну последнее, что хотелось бы заметить. Интерфейс CM15 в LinuxMCE очень сырой. Посему, если у Вас есть CM11, то лучше его и использовать. Тем более, что кроме наличия беспроводного модуля CM15A в случае применения в LinuxMCE никаких бонусов не дает. Да и то я не уверен, что работать он будет корректно. LinuxMCE интерфейс CM11A успели шлифонуть еще до Z-Wave бума. Так что он вполне юзабельный.