Включение чего угодно по HTTP без заморочек c OpenWRT

1. Настройте сетевое подключение вашего ПК на автоматическое получение IP-адреса и подключите роутер Ethernet-кабелем (после перепрошивки WiFi-интерфейс будет отключен)
2. Войдите на страницу администрирования роутера (адрес по умолчанию 192.168.0.254 пользователь:admin, пароль:admin )
3. На вкладке System Tools > Firmware upgrade выберите скачаную ранее прошивку, нажмите «Upgrade» и дождитесь, пока индикатор загрузки дважды дойдет до 100%.
4. Так как сетевые параметры OpenWRT по умолчанию отличаются от TP-LINK'овских — самый простой способ переинициализировать интерфейс — отсоединить и снова подсоединить ethernet-кабель.
5. Заходим на роутер по telnet (192.168.1.1 — адрес «свежей» OpenWRT по умолчанию) и задаем пароль командой passwd — теперь роутер доступен по SSH (и недоступен по telnet).

Для настройки статического IP в сегменте 192.168.1.x сделаем следующее:

uci set network.lan.proto=static
uci set network.lan.ipaddr=192.168.1.222
uci set network.lan.netmask=255.255.255.0
uci set network.lan.gateway=192.168.1.1
uci set network.lan.dns=8.8.8.8
uci changes
uci commit
/etc/init.d/network restart

Где 192.168.1.1 — адрес шлюза в нашей сети, а 192.168.1.222 — незанятый IP, который и будет присвоен нашей коробочке. Команда «uci changes» предоставляет возможность просмотреть все внесенные изменения. Я стараюсь не пренебрегать этой возможностью, так как устройство с неправильно настроенным интерфейсом, будучи недоступным извне, превращается в «зомби». На случай, если все таки неприятность произошла, в OpenWRT предусмотрен «режим восстановления»: при загрузке, как только кнопка «WPS» начнет мигать, зажмите ее — MR3020 загрузится с сетевыми параметрами по умолчанию.
Если в сети работает DHCP, можно задать автоматическую конфигурацию:

uci set network.lan.proto=dhcp
uci set network.lan.hostname=etherelay
uci commit
/etc/init.d/network restart

Вторая строчка необязательна, но может быть крайне полезна для поиска устройства. Можно будет обращаться к устройству не по IP, а по hostname, если сеть это поддерживает. Если хотите на 100% избежать поиска устройства в сети — применяйте статическую конфигурацию.
Полезно также запретить работу встроенного в наш TP-LINK dhcp-сервера:

uci set dhcp.lan.ignore=1
uci commit
/etc/init.d/dnsmasq restart

Все, можно отключать нашу коробочку от компьютера (все равно ssh-сессия уже оборвалась после последней команды) и подключать ее к роутеру или свитчу.

На все, что происходит с клавиатурой (или другим устройством ввода) генерируется событие ввода, видимое в соответствующем ему файле (в нашем случае /dev/input/event0, но это частный случай, обусловленный тем, что других устройств ввода не подключено). Структура события определяется в заголовочном файле input.h:

 struct input_event {
         struct timeval time;
         __u16 type;
         __u16 code;
         __s32 value;
 };

Где type сигнализирует о типе элемента ввода (кнопка клавиатуры или перемещение мыши/джойстика и т.п ), code — код элемента, специфичный для каждого типа (например, для клавиатурного события EV_KEY здесь будет передан номер клавиши), а value — это, соответственно, какое воздействие и какой величины (для устройств, поддерживающих это) было произведено. Например, при нажатии клавиши «Q» на клавиатуре мы получим:

root@OpenWrt:~# cat /dev/input/event0 | hexdump 
0000000 505b 0ed9 0009 6bdd 0004 0004 0007 0014
0000010 505b 0ed9 0009 6be6 0001 0010 0000 0001
0000020 505b 0ed9 0009 6bec 0000 0000 0000 0000
0000030 505b 0ed9 000a 2756 0004 0004 0007 0014
0000040 505b 0ed9 000a 275e 0001 0010 0000 0000
0000050 505b 0ed9 000a 2762 0000 0000 0000 0000

где первые 8 байт (505b 0ed9 000* ****) — время события, следующие два байта (0001) — тип события (EV_KEY), затем два байта номера клавиши (0010), которые для алфавитно-цифровых клавиш соответствуют скан -коду в Set 1. Кстати, нажатия всяких «прокачанных» клавиш вроде регулировки громкости, управления воспроизведением и т.п. отправляются во второй обработчик, созданный для клавиатуры (в нашем случае /dev/input/event1). Для них не генерируется событие автоповтора, что может оказаться весьма кстати — помните, я писал о «бонусной» возможности устройства работать на ввод? Последние 4 байта (0000 0001 или 0000 0000) указывают на то, что произошло нажатие или отпускание соответственно. Пакеты, состоящие из нулей — это специальные разделительные события EV_SYN, а зачем нужны события с типом 4 я не знаю. Определения для типов и кодов заданы в том же input.h, и подробнее описаны в этом документе. Дальше начинается самое интересное. Хотя большая часть событий передается от устройства в пространство пользователя, некоторые события могут идти в обратном направлении. Это сделано для поддержки, например, джойстиков с отдачей или (та-дам!) светодиодов. То есть, записав в /dev/event/input0 событие с типом EV_LED, кодом LED_CAPSL и значением 1, мы скомандуем клавиатуре зажечь светодиод «Caps Lock». Достаточно подробно о работе с устройствами ввода, особенно USB, рассказывают статьи Брэда Хардса (Brad Hards) The Linux USB Input Subsystem и Using the Input Subsystem (продолжение первой статьи, даже с примером кода для управления светодиодом). Жаль что я их нашел слишком поздно, когда задача уже была решена экспериментальным путем. Между прочим, мне очень повезло — последние снэпшоты, а так же бета 12.09 имеют одну особенность, из за чего отсылка событий работает нестабильно, если файл устройства постоянно не читать. Именно для этого предназначена команда

cat /dev/input/event0 > /dev/null &

Я экспериментировал сначала с прошивкой r31214, где таких особенностей не было, поэтому светодиод у меня загорелся сразу — если бы этого не произошло, то я бы еще долго искал верный путь.

#!/bin/sh

KB_LEDS=/dev/input/event0
EV_LED="x00x11"
LED_NUML="x00x00"
LED_CAPSL="x00x01"
LED_SCROLLL="x00x02"
TURN_ON="x00x00x00x01"
TURN_OFF="x00x00x00x00"
DT_DUMMY="x00x00x00x00x00x00x00x00"

#формируем 16-байтовые посылки для отсылки в файл клавиатуры
NUM_ON=$DT_DUMMY$EV_LED$LED_NUML$TURN_ON
NUM_OFF=$DT_DUMMY$EV_LED$LED_NUML$TURN_OFF
CAPS_ON=$DT_DUMMY$EV_LED$LED_CAPSL$TURN_ON
CAPS_OFF=$DT_DUMMY$EV_LED$LED_CAPSL$TURN_OFF
SCROLL_ON=$DT_DUMMY$EV_LED$LED_SCROLLL$TURN_ON
SCROLL_OFF=$DT_DUMMY$EV_LED$LED_SCROLLL$TURN_OFF

#"костыль", обеспечивающий чтение файла клавиатуры на время записи
if ! ps | grep -qe "[c]at $KB_LEDS"; then  cat $KB_LEDS > /dev/null & fi

#берем команду  из "переменной" command GET-запроса
#если эапроса нет - берем команду из первого аргумента
if [ -z "$QUERY_STRING" ]; then COMMAND=$1;
else
COMMAND=`echo "$QUERY_STRING" | sed -n 's/^.*command=([^&]*).*$/1/p'`
printf "Content-type: text/plainrnrn"
fi

#посылка события в файл обработчика
case $COMMAND in
        num_on)
                printf $NUM_ON  > $KB_LEDS;;
        num_off)
                printf $NUM_OFF > $KB_LEDS;;
        caps_on)
        	printf caps_on > /var/rrr
                printf $CAPS_ON > $KB_LEDS;;
                
        caps_off)
        	printf caps_off > /var/rrr
                printf $CAPS_OFF > $KB_LEDS;;
        scroll_on)
                printf $SCROLL_ON > $KB_LEDS;;
        scroll_off)
                printf $SCROLL_OFF > $KB_LEDS;;
        num_pulse)
                printf $NUM_ON  > $KB_LEDS
                sleep 1
                printf $NUM_OFF > $KB_LEDS
                ;;
        caps_pulse)
                printf $CAPS_ON > $KB_LEDS
                sleep 1
                printf $CAPS_OFF > $KB_LEDS
                ;;
        scroll_pulse)
                printf $SCROLL_ON > $KB_LEDS
                sleep 1
                printf $SCROLL_OFF > $KB_LEDS
                ;;
        *)      WRONG_ARG=1;;
esac

#обновляем информацию в файле текущего состояния светодиодов
if [ -z $WRONG_ARG ]
then
        STATE_FILE=/var/ledstate
        DEFAULT_STATE={"num":false,"caps":false,"scroll":false}
        if ! [ -e $STATE_FILE ]; then  echo $DEFAULT_STATE > $STATE_FILE; fi
        AFFECTED_LED=`echo $COMMAND | sed -r -e 's/_[a-z]+$//'`
        NEW_STATE=`echo $COMMAND | sed -r -e 's/^[a-z]+_//' -e 's/on/true/' -e 's/off|pulse/false/'`
        sed -i -r 's/"'"$AFFECTED_LED"'":[a-z]+/"'"$AFFECTED_LED"'":'"$NEW_STATE"'/' $STATE_FILE
fi

Константы EV_LED, LED_NUML, LED_CAPSL, LED_SCROLLL, как я уже говорил, определены в input.h. Время нас не волнует — забиваем его нулями. Конечно, код получится компактнее, если формировать «события» «на лету», исходя из полученной команды, а не просто отсылать заранее набитые шаблоны в свитче, но мне показалось, что так понятнее основная идея. Нам все так же необходимо чтение из файла событий во время записи в него, откуда и возник пресловутый костыль. Повторюсь, в этом не было необходимости в более ранних сборках, и, скорее всего, не понадобится в будущем. Но пока придется мириться. Последний фрагмент модифицирует файл текущего состояния светодиодов, который состоит из одной примерно такой строчки:

{"num":true,"caps":false,"scroll":false}

Если такого файла нет — он будет создан со всеми значениями «false». В OpenWRT директория /var/ — в оперативке, а значит — файл создается после каждой перезагрузки, когда все светодиоды как раз выключены. Уютненькая схемка! Как вытащить параметры из HTTP — запроса я прочитал, наверное здесь (прочитал давно и ссылку не сохранил, только строчку кода, но здесь очень похоже). Скрипт выводит «Content-type: text/plain», если вызван через CGI, потому что иначе результат запроса будет 502 (Bad Gateway), а не 200(OK), что не смертельно, но некрасиво.

<!DOCTYPE html>
<html>
<head>
    <title>Relay control</title>
    <meta http-equiv="content-type" content="text/html; charset=utf-8">
    <script type="text/javascript">
        function command(action)
        {
            url="/cgi-bin/ctlrelay?command="+action;
            url=url+"&fuie=" + Math.random(); 
            var xmlhttp=new XMLHttpRequest(); 
            xmlhttp.open("GET",url,false);
            xmlhttp.send();
        }
        function get_status()
        {
            var xmlhttp=new XMLHttpRequest();
            xmlhttp.onreadystatechange=function()
            {
                if (xmlhttp.readyState==4 && xmlhttp.status==200)
                {
                    ledstate = JSON.parse(xmlhttp.responseText)
                    for (led in ledstate)
                    {
                        document.getElementById(led).checked=ledstate[led]
                    }
                }
            } 
            xmlhttp.open("GET","/ledstate?fuie="+ Math.random(),false);
            xmlhttp.send();
            setTimeout("get_status()",500);
        }
    </script>
</head>

<body onload="get_status()">
<div class="controls">
<div class="control">
<label for="scroll">Scroll Lock LED</label>
<input id="scroll" type="checkbox" onclick="if (this.checked) command ('scroll_on'); else command ('scroll_off')">
</div>
<div class="control">
<label for="caps">Caps Lock LED</label>
<input id="caps" type="checkbox" onclick="if (this.checked) command ('caps_on'); else command ('caps_off')">
</div>
<div class="control">
<label for="num">Num Lock LED</label>
<button id="num" type="button" onclick="command('num_pulse')">1s blink</button>
</div>
</div>
</body>
</html>

Сначала я хотел использовать JQuery.get(), но потом посчитал излишним привлекать JQuery ради всего лишь пары GET-запросов. У нас есть две JavaScript функции. Первая, command(action), запускает наш скрипт, передавая «команду» в праметре «command» GET-запроса. Какую именно — определяется в событиях onclick элементов управления. Это выглядит не очень элегантно, спору нет, но дает хорошее представление о том, как все работает. Вторая функция, get_status() запускается по событию onload, запрашивает файл с текущим состоянием светодиодов (тот, который формируется в конце скрипта) и отражает его на элементах управления страницы. По невероятному стечению обстоятельств файл состояния представляет из себя JSON-представление ассоциативного массива, и доступ к данным мы очень просто получаем с помощью JSON.parse(). Повтор запроса каждые полсекунды позволяет отслеживать измения состояния, произведенные с другого клиента. Добавка в url fuie=Math.random() нужна для того, чтобы адрес каждый раз был уникальным — тогда браузер не сможет отказаться от запроса страницы, посчитав, что она уже есть в кэше. Как можно догадаться из названия переменной, особенно склонен к такому поведению Internet Explorer.

Неплохо добавить в коммутируемую цепь предохранитель. Транзистор в схеме 5 работает с почти максимальным коллекторным током — желательно взять с током срабатывания поменьше, или хотя бы транзистор помощнее. На выходы твердотельного реле нужно поставить демпфирующую RC-цепочку при работе на двигатель или другую индуктивную нагрузку. Компоненты подбирались лишь по критерию доступности и цены в ближайшем (ко мне) оЧень Дорогом радиомагазине — при наличии выбора можно подобрать у нормального продавца «твердотелку» на нужный ток с широким диапазоном I_F и на том закрыть вопрос с коммутацией. Кроме того, представленная модель включения неточна: плата клавиатуры ведет себя как источник тока по отношению к нашему «светодиоду» только при напряжении на аноде 2.5В и выше — я старался, по возможности, обеспечить падение напряжения, сходное с таковым у заменяемого светодиода, чтобы плата «не почувствовала» подмены.