Показаны сообщения с ярлыком owserver. Показать все сообщения
Показаны сообщения с ярлыком owserver. Показать все сообщения

5 февраля 2014 г.

Управление и оповещение через jabber в openHAB

Отлично, у нас есть показания открытой двери и замка. Теперь было бы неплохо, получать какие-нибудь оповещения о событиях. Например, для начала, о том что замок закрылся или открылся.

Я решил оповещения сделать на основе jabber, тем более, что данный вариант позволяет даже управлять openHABом из jabber. Создаем учетную запись (xmpp или jabber). Ищем секцию xmpp в openhab.cfg. Прописываем сервер, логин, пароль.
Отправляем команду help:

(15:22:48) I: help
(15:22:49) my****@jabber.org: Usage: 
update ⟨item⟩ ⟨state⟩ - sends a status update for an item
send ⟨item⟩ ⟨command⟩ - sends a command for an item
status ⟨item⟩ - shows the current status of an item
items [⟨pattern⟩] - lists names and types of all items matching the pattern
say ⟨sentence to say⟩ - Says a message through TTS on the host machine
⟩ ⟨script to execute⟩ - Executes a script


Теперь разберемся, как нам послать сообщение о смене статуса открытого замка. Для этого просто создадим новое правило в home.rules:

rule "Door Check Lock Send"
when
        Item Main_Door_Lock changed
then
        if(Main_Door_Lock.state==1)
        {
            sendXMPP("jabber@jabber.org", "Замок двери открыт!")
        }
        else if(Main_Door_Lock.state==0)
        {
            sendXMPP("jabber@jabber.org", "Замок двери закрыт!")
        }
        else{
            sendXMPP("jabber@jabber.org", "Неполадки с датчиком замка двери!")
        }
end


Очень помогает в написании правил функция авто-дополнения в дизайнере (Ctrl+Space), ибо документация по этому поводу хромает.

Поэкспериментировав понимаем, что время отклика оставляет желать лучшего. Смотрим лог owfs - датчик опрашивается openHAB'ом раз в минуту - это как раз настройка в openHAB. К сожалению на данный момент время обновления едино для всех датчиков 1-wire в openHAB. Поэтому ничего не остается, как сменить частоту обновления хотя бы на раз в 10 секунд.

Кеш owfs для датчиков по умолчанию 15 секунд. Поэтому, чтобы получать свежие значения, надо изменить его на 10 секунд. Пропишем в owfs.conf:
timeout_volatile = 10
#error_print = 1
error_print = 3
error_level = 2

error_print = 3 обозначает подавление логов - при опросе раз в 10 секунд из слишком много.

Протестировав я понял, что и 10 секунд слишком много. Но дальше увеличивать частоту опросов всех датчиков накладно. И вообще неплохо бы использовать unchached значения из owfs для датчиков, а кеш использовать только для датчиков, данные которых не критичны в времени опроса - например, датчики температуры. Но в openHAB пока с этим проблемы. Поэтому будем использовать небольшой хак. Для датчиков мы будем использовать exec binding и получать данные с файловой системы. Формат запроса:

in:  exec:"<[<commandline execute="" to="">:<refreshintervalinmilliseconds>:<transformationrule>]"

items:

Number Main_Door_Lock "Замок в двери C: [MAP(ru.map):%s]"<door>(Doors) { exec="<[/bin/cat /mnt/1wire/uncached/12.A214B2000000/sensed.A:5000:REGEX((.*?))]" }

В принципе, тут можно использовать и Contact.
Результат срабатывания правила:





Последний штрих - теперь нам надо настроить запуск приложения файловой системы owfs, потому что мы с него получаем данные. (Проверьте, что у вас запускается при старте в директориях rc.d).
# update-rc.d owfs defaults 30

Не забудьте выставить очередь запуска после owserver (у меня, как видно 30, а у owserver 20)!

2 февраля 2014 г.

Owfs - установка из исходников

Начнем с лирического отступления. Проанализировав показания термометра DS18B20 я понял, что он немного завышает показания.   Погуглив я нашел две причины: либо самонагрев датчика от частого опроса, либо неоткаллиброванный датчик. Решил получше изучить логи owfs.

1. Включаем логи: /etc/owfs.conf

error_print = 1 
error_level = 3 

Перезапускаем owserver и смотрим что у нас в логах. (Обратите внимание, что я рассказываю про версию из deb пакета в init.d скрипте которого уже указан путь к конфигу). А в логах у нас пусто. Помните, как мы устанавливали систему? Позже мы поставили rsyslod.

Ищем # whereis owserver , чтобы запустить его не в режиме сервиса , а в консоли.

#/usr/bin/owserver --debug  --error_level=9 --error_print=2 --foreground -c /etc/owfs.conf --pid-file /var/run/owfs/owserver.pid
DEBUG MODE
libow version:
        2.8p15


И снова пусто. Но не только у нас. Похоже, что в deb пакете owfs логирование выключено.

Посему удаляем owfs (сохраним init.d скрипты и owfs.conf - хотя они удалиться не должны). Качаем версию посвежее. Распаковываем tar -xvzf... Устанавливаем необходимое для компиляции и сборки.

#apt-get install autoconf libtool libusb-dev libfuse-dev make ed
#cd /usr/src/owfs-2.9p1
#./configure --help
#/owfs-2.9p1# autoreconf -i

Я сконфигурировал следующим образом (также можно добавить опцию --enable-owtraffic Enable bus traffic reports (default false) - очень интересная опция, дающая возможность отслеживать трафик в самой 1-wire сети):

#./configure --enable-debian --disable-owftpd --disable-owperl --disable-owphp --disable-parport --disable-owpython
# make -j4
# make install

По умолчанию все устанавливается в директорию /opt/owfs/ . Сделаем линк в /usr/bin , что бы было проще использовать и не переписывать скрипты запуска.

# for p in owfs owserver owhttpd owftpd owread owwrite owdir ; do ln -sf /opt/owfs/bin/$p /usr/bin/$p ; done

Пробуем запускать:

/usr/bin/owserver --debug  --error_level 9 --error_print 2 --foreground -c /etc/owfs.conf --pid-file /var/run/owfs/owserver.pid

Если все хорошо, перезапускаем сервер с помощью init скрипта и смотрим syslog. Отлично! Теперь укажем всем клиентским приложениям использовать tcp сервер (owserver) для работы, ибо usb устройство уже занято им (то есть все приложения пакета owfs должны работать через owserver - если он запущен, либо по одиночке). Пропишем в конфиг (он должен автоматически подхватываться (ключ -c) всеми init.d скриптами пакета owfs, которые у нас остались после установки deb пакета из репозитория):

# With this setup, any client (but owserver) uses owserver on the
# local machine...
! server: server = localhost:4304

В конфиге программы с репозитория эта строчка уже указана.

Но скрипта для приложения (не пакет) owfs в init.d нет (вообще странный пакет в репозитории дебиана - логов нет, управление не понятно, такое ощущение, что делал человек, плохо знакомый с owfs). Можем сделать на основе скрипта owhttpd и запускаем:

# /etc/init.d/owfs start
[ ok ] Starting 1-Wire owfs Daemon: owfs.
root@debtruck:/etc/init.d# ps -A | grep ow
 2478 ?        00:00:01 owserver
 3262 ?        00:00:00 owfs

Смотрим работающие логи.

5 января 2014 г.

Платформа умного дома OpenRemote. Знакомство. Подключаем 1-wire через owfs.

Пока я жду DS2406P+ и DS2408S+ занялся серверной и клиентской стороной умного дома.

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

OpenRemote это:

1) Сервер умного дома, работает на десятке платформ, даже на NAS Synology и Windows.

2) Онлайн-cреда для разработки приложения.

3) Мобильное приложение, которое загружает данные для своей работы из среды для разработки.




Поддерживаемые технологии.
AMX, KNX, Lutron, Z-Wave, 1-Wire, EnOcean, xPL, Insteon, X10, Infrared, Russound, GlobalCache, IRTrans, XBMC, VLC, panStamps, Denon AVR, FreeBox, MythTV и другие.

У нас есть owfs с показаниями термометра. Давайте посмотрим как нам связать все это дело воедино.

Установка.

Сubietruck похож на Raspberry Pi, поэтому мы воспользуемся следующим мануалом.

Процессор в Cubietruck версии ARMv7, который поддерживает операции с плавающей точкой на аппаратном уровне (Hard-float). Наш Debian ( ARMv7 (EABI hard-float ABI, «armhf») ) также поддерживает.

Вообще пишут, что использование java машины с плавающей точкой на аппаратном уровне может иметь проблемы со стабильностью и совместимостью. Посмотрим, что у нас в дебиане. Перед тем как ставить java я немного изучил возможные проблемы и какую все таки версию ставить. Читаем комментарий ANDREAS DROLLINGER по ссылке - в нем написано:

OpenJDK (IcedTea6 Zero VM) is slower than Oracle Java, but it is available for hard float installation and the Drools rule engine 5.1.1 works.


В общем-то рекомендует нам использовать OpenJDK 6 с IcedTea6 (с поддержкой таки hard float), оно немного помедленней, ну и ладно, у нас нагрузка не высокая, будет критично - переустановим. Смотрим, что есть у нас в наличии.

root@debtruck:~# apt-cache search icedtea-6-jre
icedtea-6-jre-cacao - Alternative JVM for OpenJDK, using Cacao
icedtea-6-jre-jamvm - Alternative JVM for OpenJDK, using JamVM


Судя по довольно интересным статье сравнения JamVM немного получше, чем Cacao, поэтому буду пробовать его. Ставим:

# apt-get install icedtea-6-jre-jamvm
root@debtruck:~# which java
/usr/bin/java
# java -version
java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1~deb7u1)
root@debtruck:~# which java
/usr/bin/java
# java -jamvm -version
java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1~deb7u1)
JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching)
# export JAVA_HOME=/usr

Редактируем /etc/java-6-openjdk-armhf/jvm-armhf.cfg перенеся -jamvm KNOWN в начало списка.

# java -version
java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1~deb7u1)
JamVM (build 1.6.0-devel, inline-threaded interpreter with stack-caching)

Видим, что у нас JamVM используется по умолчанию.

Качаем контроллер.
# cd /usr/src/
# wget http://download.openremote.org/

У меня скачался OpenRemote-Controller-2.1.0_SNAPSHOT-2013-06-17.zip.

Настройка и использование OpenRemote

Теперь давайте создадим пользователя под которым будет запускаться контроллер. ( #adduser openremote , #su openremote ). Создадим под root директорию /srv/or/ дадим chown openremote на нее. Распакуем архив в нее.
$ cd /srv/or/bin
$ chmod +x openremote.sh
$ ./openremote.sh run
....
INFO: Server startup in 19386 ms
Регистрируемся на сайте. Заходим в online редактор. Я обычно не доверяю таким онлайн штукам. Но да ладно, в принципе есть исходники - пишут, что можно и оффлайн устанавливать дизайнер, но пока я смысла в этом не вижу. Создаем новый Device.



Теперь создаем команду (тут можно не прописывать хост и порт каждый раз в версии 2.2, там есть config for controller onewire. В версии 2.1. пока его нет).



Теперь создаем сенсор.



Теперь перейдем во вкладку "Дизайн". Создадим новую панель Android (у меня только андроид :) ). Добавим в нее пару Label - один просто текст, во втором выберем наш сенсор. Ну вот вроде и готово. Перейдем по адресу http://openremoteserver:8080/controller/ и нажмем Sync with Online Designer, тем самым загрузим созданное приложение на контроллер OpenRemote (Что интересно, можно делать это и оффлайн, тем самым сохранив бекап с приложением - в онлайн редакторе есть возможность сохранить приложение как zip файл, а на контроллере импортировать). После синхронизации заходим на веб-консоль ( http://192.168.xx.xx:8080/webconsole/ ) и нажимаем найти контроллер, после этого вебконсоль находит наш локальный контроллер, нажимаем на него и видим наше созданное приложение. И опять не работает. :)

Проблема вот в чем, по умолчанию owserver отвечает только по адресу localhost:4304 , то есть контроллер по имени благополучно подключается, а вот по ip (127.0.0.1) нет. Поэтому пропишем так server: port = 127.0.0.1:4304 (для доступа из сети просто пишем server: port = 4304) в owfs.conf. Перезапускаем сервер owserver: #service owserver restart . Работает:



Для установки приложения на мобильный телефон, устанавливаем приложение для андроид и оно само находит контроллер в локальной сети - подключаемся, работает.
Добавляем строчку cd /srv/openremote/bin в openremote.sh, иначе при запуске из другого места могут вылезти косяки. Скрипт init.d для контроллера

#!/bin/sh
### BEGIN INIT INFO
# Provides:          openremote
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start daemon at boot time
# Description:       Enable service provided by daemon.
### END INIT INFO

#!/bin/sh

User=openremote
orpass=/srv/openremote/bin

case "$1" in

stop)
        echo "Stopping OpenRemote Controller..."
        su -l $User -c "$orpass/openremote.sh stop" > /dev/null 2>&1 &
        ;;

start)
        # start OpenRemote in background mode
        su -l $User -c "$orpass/openremote.sh start" > /dev/null 2>&1 &
        echo "OpenRemote Controller started..."
        ;;

restart)
        $0 stop
        sleep 5
        $0 start
        ;;
*)
        echo "usage: $0 { start | stop | restart}" >&2
        exit 1
        ;;

esac

Ну и автозапуск update-rc.d.

ps. Вообще для доступа через интернет ip адрес контроллера должен быть внешним.