Прикупил THGN132N. Постараюсь в выходные добраться и собрать декодер.
А кто-нибудь знает, можно ли этот датчик заставить принудительно отправить сигнал, чтобы не ждать несколько минут, пока он соизволит что-то послать?
По-моему никак нельзя, он даже после смены батарейки не сразу по-моему отправляет. Данные отправляются раз в 40 секунд, так что ждать не очень долго.
Неудобно ждать 40 сек, когда каждые несколько секунд прилетает какой-нибудь пакет… 433Mhz не самая свободная частота…
Оказалось, что через несколько секунд после нажатия на reset датчик отправляет пакет.
В общем, получилось принять пакет и декодировать их странноватый манчестер. А вот разобрать получаемые 80 бит в температуру, влажность и т.п. пока не получается… Принимаемый пакет не очень похож на документацию (
В общем, с датчиком THGN132N все получилось.
Столкнулся с проблемой, что уже на расстоянии около 6 метров и одной стеной значительная часть пакетов приходят поврежденными. Как с этим бороться примерно понятно (фактически пакет передается дважды и за счет манчестера есть дублирование данных, а также CRC для контроля целостности).
Планирую сначала решить проблему с дальностью приема, потом выкладывать. Может ли кто-то помочь с проверкой работы на датчиках, отличных от THGN132N (1D20)? У Oregon для каждого типа датчика свое расположение данных о температуре/влажности и т.п.
Говори что делать - у меня есть 1d20 и ec40.
Скачать https://www.dropbox.com/s/ymkgz7w69shmwd2/rfsniffer и запустить.
Допущения:
- Пока запускается только на WB5, т.к. предполагает, что RFM69 подключен к /dev/spidev32766.0, а его DIO2 подключен к /dev/lirc0
- Mqtt доступен по localhost без авторизации
- Датчики 1d20(проверен), ec40 - нужно пробовать, структура пакета взята из интернета
Можно прямо на WB набрать:
mkdir Test
cd Test
wget https://www.dropbox.com/s/ymkgz7w69shmwd2/rfsniffer
chmod +x rfsniffer
./rfsniffer
Дальше он будет в консоль писать все попытки получить и декодировать пакеты. При обнаружении валидного пакета от Oregon будет что-то типа:
09/06 18:47:03 [8820] RF Recieved: Oregon:type=1D20 id=51 ch=1 t=23.2 h=39. RSSI=-102 (-103)
09/06 18:47:03 [8820] Msg from RST Oregon:type=1D20 id=51 ch=1 t=23.2 h=39
После этого в интерфейсе WB появится(обновится) устройство :
Нужно какое-то время подождать и прислать мне файл /run/Main.log. Также, хочется получить какие-то данные по расстоянию и препятствиям до датчиков.
У меня датчик стоит в нескольких метрах от WB через бетонную стену. “Бьется” около 20-30% пакетов, но есть идеи как это полечить.
C дальностью вроде разобрался. Прием от Oregon работает стабильно. Нужно тестирование на других датчиках Oregon и других Wiren Board, т.к. могут всплыть какие-то особенности…
Были опасения в высоком потреблении CPU, т.к. много шума и каждый принятый пакет нужно пропустить через пачку декодеров. Подозрения не оправдались. На фоне wb-rules нагрузка незаметна совсем.
Готов собрать демон с конфигурационными файлами и т.п. Евгений, поможете с пакетированием? Детали, лучше обсудить по почте.
Важно понимать, что мой декодер может работать только вместо стандартного. В связи с этим, нужно ли добавить декодирование еще каких-то устройств? nooLite?Поддержка передачи команд, а не только прием?
У меня WB3 готов присоединиться к тестирования, Да поддержка noolight была бы не плоха. Я им пользуюсь.
C WB3 есть несколько вопросов к Евгению:
- Распаян ли DIO2 на WB3. Если DIO2 не приходит на SOC, то это проблема. Судя по описанию, он должен приходить на 53й GPIO.
- Есть ли для WB3 ядро с поддержкой linux драйвера lirc и dev tree с /dev/lircXX, подключенным к GPIO53?
Если ответы на все вопросы “ДА”, то можно пробовать. Для поддержки приема noolight мне потребуется либо устройство, либо записанные пакеты, отправляемые устройством. Как их записать, я расскажу.
Про передачу пока не особо думал, т.к. не придумал зачем. Технически вроде ничего сложного нет.
См. схему: http://contactless.ru/wiki/images/4/45/СхемаWB3.5.pdf
Он сидит на одном пине с чип селектом модуля NRF24, подключается через запаиваемую перемычку SJ7
Ядро сейчас общее для всех выпускавшихся Wiren Board.
Дампы с примерами в старом формате (конвертируются в новый тривиально): rfm69-linux/tests.py at master · wirenboard/rfm69-linux · GitHub
Расшифровка протокола и описание (в конце файла): rfm69-linux/noolite.py at master · wirenboard/rfm69-linux · GitHub
Ещё дампы: rfm69-linux/noolite.txt at master · wirenboard/rfm69-linux · GitHub
Подробно про протокол: Взламываем беспроводное управление светом nooLite / Habr и Разбираем протокол новых датчиков Noolite / Habr
- Судя по всему без паяльника подключение DIO2 невозможно.
- У Вас есть устройство /dev/lirc0 ?
Я готов тестить на WB4
Устройство есть
А где эта перемычка находится, чтото на чертеже не видно. А в живую непонятно, на плате много потенциальных мест.
От нулайта нужно только передача команд.
Прошу прощения, я ошибся. Перемычка там есть, но она там нужна только для использования процессорных плат от Olimex, такое дальше образцов не пошло.
Сигнал с DIO2 приходит на GPIO 53, в ядре на этом GPIO уже висит устройство lirc0. Т.е. всё, что нужно сделать, это поменять в rfsniffer spidev на правильный.
Отлично, я сделаю настройку через параметры и попробую автоматически определять через переменные окружения. Я, честно говоря, не ожидал такого разнообразия устройств.
У нас обычно просто разные конфиги для разных устройств при установке пакета делаются, есть стандартный механизм.
Вы если сделаете конфиг (совсем здорово, если в JSON), то дальше мы всё сделаем как в остальных пакетах.
JSON конфиг я сделаю чуть позже. Сейчас доступны параметры командной строки:
-D - debug mode. Write good but not decoded packets to files
-s - set custom SPI device. Default /dev/spidev32766.0
-l - set custom lirc device. Default /dev/lirc0
-m - set custom mqtt host. Default localhost
-S - set custom mqtt host. Default 500000
-r - reset RSSI Threshold after each packet. 0 - Disabled. Default 0
-? - help
Т.е. нужно запустить: ./rfsniffer -s /dev/spidevXXX.YYY, в соотвествии с номером spi порта радиомодуля для Вашей версии устройства. Бинарник доступен там же ( https://www.dropbox.com/s/ymkgz7w69shmwd2/rfsniffer )
Возник интересный вопрос - у меня есть spidev1.5/1.6/1.7 какой из них использовать - major у них одинаковый, minor - 5,6,7.
Пробую с бинарником (на spidev1.5).
Если я не ошибаюсь, то
WB3 /dev/spidev1.5
WB4 /dev/spidev1.4
В любом случае, если ошибиться с устройством - он должен выдать ошибку, либо зависнуть на ожидании успешной инициализации.
Ну пока получаем
4/06 14:31:22 [21022] RF got data 6430 bytes. RSSI=-89
14/06 14:31:23 [21022] RF got data 10544 bytes. RSSI=-89
14/06 14:31:23 [21022] Recieved 10544 signals. Not decoded
14/06 14:31:24 [21022] RF got data 2122 bytes. RSSI=-90
14/06 14:31:25 [21022] RF got data 6284 bytes. RSSI=-89
14/06 14:31:26 [21022] RF got data 10418 bytes. RSSI=-88
14/06 14:31:26 [21022] Recieved 10418 signals. Not decoded
14/06 14:31:27 [21022] RF got data 2182 bytes. RSSI=-88
14/06 14:31:28 [21022] RF got data 6214 bytes. RSSI=-89
Он ведь как чтонибудь поймает, сразу скажет?