Строю систему мониторинга поливного насоса и подключенного трубопровода. Пока доделал сенсорную сеть. Все подключается к плате микроконтроллера (на самом деле 4 Крошечный 3.0 доски), и плата запрограммирована на вывод строки форматированных данных (показаний) через заданные интервалы.
Я хочу подключить плату через USB-порт к Raspberry Pi (или какой-либо другой SBC), и пусть компьютер отправляет показания, которые он получает от сенсорной платы, на удаленный сервер для регистрации.
Я рассмотрел следующие варианты:
1 - Системный журнал ... Мне это сразу показалось возможным, потому что он, кажется, предлагает почти все, что мне нужно. Однако меня пугает сложность.
2 - ОТДЫХ ... Попросите RaspberryPI ОТПРАВИТЬ данные построчно по сети в CouchDB на сервере.
3 - HTTP ... Сохраняйте открытое HTTP-соединение с node.js и «записывайте» строки данных. Конечно, он должен быть получен вторым скриптом node.js для сохранения в БД.
Теперь к требованиям:
~ Он должен быть легким и относительно быстрым. Будет много данных (интервалы 1 с), и RaspberryPI не является электростанцией.
~ Я бы очень хотел вариант для сжатой строки. Связь осуществляется через 3G, и я надеюсь выбрать «небольшой» ежемесячный план.
~ Шифрование будет хорошо, но не обязательно. Паранойя сильна с быдлами ...
~ Мне действительно нужно, чтобы это было как K.I.S.S. насколько возможно.
Короче говоря, я думаю об этом как о каком-то последовательном соединении через сеть, когда компьютер передает строку за строкой другому компьютеру.
Итак, какой из вариантов, которые у меня есть, предпочтительнее? Или даже лучше, есть ли у кого-нибудь идея получше?
Я честно открыт для редактирования и даже перепоста вопроса, если у кого-то есть что-то хорошее.
РЕДАКТИРОВАТЬ:
Все комментарии и ответы на данный момент были оценены и рассмотрены.
Системный журнал действительно хорош, но мне действительно нужно избегать сложности и накладных расходов. Кроме того, после некоторого тестирования RaspberryPI, кажется, останавливается вскоре после запуска rsyslog.
К настоящему моменту решено, что СУБД будет CouchDB.
Очевидным вариантом было бы использовать curl или рудиментарный сервер node.js, чтобы выполнять REST-вызовы на сервер БД сразу после поступления данных. Это, хотя и просто и эффективно, по ряду причин не является предпочтительным. Безопасность также вызывает беспокойство; Мне не нравится идея миниатюрного ПК в поле, делающего прямые вызовы СУБД.
Причина, по которой я начинаю щедрость, заключается в том, что я надеюсь, что кто-то может предложить идею в следующих строках: «Какое-то постоянное соединение между удаленным миниатюрным ПК и СУБД. Данные будут отформатированы каким-то протоколом и пересылаться через это соединение. для получения на противоположном конце. Это соединение должно быть как можно более легким, с минимально возможными накладными расходами ".
Вы думали об использовании SMTP (электронной почты)? В Raspberry есть два процесса: один читает данные и добавляет их в файл, другой (возможно, в crontab) перемещает файлы (возможно, объединяет некоторые) и отправляет их по электронной почте на конечный компьютер. Таким образом, у вас не будет никакой связи между частотой выборки и частотой регистрации, если вас это устраивает (например, отправляя электронное письмо каждые 20 секунд или каждую минуту).
Почту можно сжать, зашифровать (с помощью SMTP TLS). Более того, он устойчив: в случае, если вы потеряли аплинк, данные мы отправим, когда ссылка будет восстановлена. С точки зрения вашего процесса ведения журнала ссылка всегда находится "вверх".
На сервере couchdb (или другом компьютере, подключенном к couchdb) вы создаете специального пользователя и помещаете в его .forward сценарий, который распаковывает сообщение и передает его в couchdb.
Если вы хотите аутентифицироваться, вы можете использовать множество схем от общего секрета до подписи PGP!
Мы делаем это для подпитки нашего хранилища данных, потому что нам не нужны какие-либо входящие соединения (https или ssh), по общему признанию, не с частотой дискретизации 1 с (но с большими данными).
И последнее, но не менее важное: вы можете тестировать каждый компонент индивидуально (регистратор, отправитель, получатель и db-feedder) без необходимости запуска всей инфраструктуры.
Как правило, все зависит от того, что вы делаете на другой стороне. Например: если вам нужно, чтобы эти данные перенаправлялись в Zabbix - вы используете Zabbix агент, для SNMP - вы используете snmpd, для обработки веб-приложений - HTTP и т. Д.
Rsyslog может быть хорошим вариантом для транспорта, потому что он уже может решить многие проблемы, с которыми вы можете столкнуться при разработке собственного решения (то есть при работе с REST, общим HTTP):
TLS будет иметь огромные накладные расходы - постарайтесь вообще не использовать его.
Вам нужно будет настроить ту же систему на другой стороне, тогда вы можете делать трюки с сообщениями по своему усмотрению, то есть вставлять их в mysql или / и postgresql база данных, или / и любой другой с DBI, или / и вперед в файл, или / и к именованный канал, или / и как ловушка snmp, или / и как Эл. адрес, и / или индивидуальное приложение и т.п.
Я использую аналогичную систему, которая есть у вас (Arduino + Raspberry), но я запускаю проприетарное приложение с его конкретной очередью и транспортом SOAP. Для простого обмена сообщениями я бы использовал rsyslog.
Вы также можете посмотреть RabbitMQ Поскольку это брокер сообщений, который как бы предназначен для решения этой проблемы.
RabbitMQ - это брокер сообщений. Основная идея довольно проста: он принимает и пересылает сообщения. Вы можете думать об этом как о почтовом отделении: когда вы отправляете почту в почтовый ящик, вы почти уверены, что мистер Почтальон в конечном итоге доставит почту вашему получателю. Используя эту метафору, RabbitMQ - это почтовый ящик, почтовое отделение и почтальон.
Основное различие между RabbitMQ и почтовым отделением заключается в том, что оно не работает с бумагой, а принимает, хранит и пересылает двоичные блоки данных - сообщения.
Вотэто сообщение, описывающее, как использовать его на Rpi.