LINUX.ORG.RU
Форум — Development  

Мало жрущий скриптовый веб сервер для умного дома

 ,


1

4

Хочу на роутер Asus RT-14U с 32 мб(-10мб для ОС) озу поставить сервер умного дома Чтобы с датчиков на esp8266 собирал и обрабатывал данные
ЯП точно не должен быть компилируемым. И с поддержкой бд

Из личных предпочтений:
* Питон не люблю из-за табов
* Руби - няшка
* Луа - готов терпеть
* nodejs умею но он стал сильно жирным :-/
* перл -хз
* пхп - нормально отношусь, но боюсь что не влезет. Особенно с апачем

У кого есть подобный опыт?

★★★★
← С++, очень странные сегфолты
С помощью чего мержить две сильно разошедшиеся ветки? →

Фигней не занимайся. По своему опыту: бери raspberry pi 3/4 (RAM 2GB) + homeassistant + esphome

И тебе будет счастье.

futurama ★★★★★
()

Тебе нужен компилируемый ЯП без сборки мусора. C, C++, Rust - выбирай на вкус. Другие языки не уместятся в 10 MB. Также нужно очень внимательно относиться к выбираемым фреймворкам.

В целом присоединяюсь к советам выбрать другую железку. Сейчас не 1990-е, чтобы пытаться влезть в 10 MB. Какой-нибудь TLS-стек легко может отожрать больше.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 2)

32 мб(-10мб для ОС)
ЯП точно не должен быть компилируемым

Поддержу предыдущего оратора, тебе нужен нормальный компилируемый ЯП. Я бы выбрал Rust, но это моя вкусовщина.

hippi90 ★★★★★
()

nginx unit + шт-то-там.

Нуили рачт изучи, тоже неплохо, один бинарь всё в себе будет держать.

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Legioner

Другие языки не уместятся в 10 MB

OpenWRT с ядром <= 2.6 так не считает.

Shadow ★★★★★
()

А попробуй на базе OpenWRT сделать. Там lua

Shadow ★★★★★
()
Ответ на: комментарий от Legioner

Другие языки не уместятся в 10 MB

Да ладно. Lua, microPython. Там сотен килобайт достаточно. Сам «бэк», конечно, на чем-то вроде Cи будет (OS на базе ядра Linux или «чистая» прошивка).

И с поддержкой бд

microPython + sqlite3

Stack77
()
Последнее исправление: Stack77 (всего исправлений: 2)

V lang

C + musl + libuv

D + libuv

Go влезет точно в 10 Мб, оптимален для целей сборки данных и отдачи вебни

menangen ★★★★★
()

Рассмотри так же Go. В шебанге можно написать go run — будет скриптовый. Да и компиляется он мгновенно в любом случае.

WitcherGeralt ★★
()

Собрираешь ты данные с датчиков. А дальше как эти данные будут использоваться? Графики рисовать? Тупо втыкать в веб-страничку с таблицей этих данных – температура, влажность в комнатах, окно/дверь открыто/закрыто, … Оно? Или как-то по-другому будет?

futurama ★★★★★
()
Ответ на: комментарий от Stack77

У него слегка противоречивые требования, но при желании можно взять питон, и урезать ядро, так что всё уместится в 32 Мбайт zram

menangen ★★★★★
()

Фигней не занимайся. По своему опыту: бери raspberry pi 3

fornlr ★★★★★
()

Windows IoT Core

anonymous
()

Посмотерл на требования, сказал про себя "ого"... =)))

Ну, положим, как бы я решал эту задачу.

По железу. Во-первых и сразу я бы оставил роутер в покое. Роутит и файерволлит, вот и пусть себе спокойно роутит и файерволлит без дерготни. Иначе это называется «Чем мы занимаемся? Да седьмую шапку шьём…» (Поговорка, распространённая в ряде дружественных контор по мотивам одной древней побасёнки.

Лучше бы «контроллер» вынести на отдельную малинку, как уже посоветовали в треде неоднократно. Если этого не сделать, то формально ничего плохого не случится, но… зачем? Ресурсов вычислительной системы всегда может не хватить и всё откажется работать в самый неприятный момент. К тому же, в ядре Linux совсем не зря есть параметр IP_ADVANCED_ROUTER, который имеет смысл включать именно на «роутере», на «хосте» незачем. Там ещё от него ряд параметров ядра зависит, но нафиг нам на «сервере» таблица маршрутизации (routing table), например?

В общем, я могу написать как было бы на мой взгляд лучше, но считайте что я Вас предупредил – лучше бы отдельную малинку прикрутить и не париться. Хотя, в принципе, предлагаемый мною вариант может и на малинке и на роутере пойти.

По решению. Во-вторых, я бы вспомнил о такой незаслуженно забытой технологии как CGI. Веб-сервер отдаёт клиенту html, css, javascript в самом простейшем виде. От клиента он получает http(s) запрос к CGI (common gateway interface) вида

http://.../cgi-bin/test.cgi?имя=значение&имя1=значение1&...

Ваша задача – получить веб-сервером строку от браузера и передать её на вход «скрипта» CGI. Исторически такие «скрипты» писались на perl, C, хотя ни кто не запрещает хоть на bash писать. Например:

#!/bin/bash
	echo "Content-type: text/html"
	echo ""
	echo '<html>'
	echo '<head>'
	echo '<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">'
	echo '<title>Environment Variables</title>'
	echo '</head>'
	echo '<body>'
	echo 'Environment Variables:'
	echo '<pre>'
	/usr/bin/env
	echo '</pre>'
	echo '</body>'
	echo '</html>'
	exit 0

Этот скрипт выдаст в документ html все нужные переменные окружения. Важным моментом является то, что от веб-сервера скрипт их получает через эти самые environment variables, дальше он парсит нужное (QUERY_STRING, методы GET/POST/PUT), делает какую-то магию и возвращает результат бразеру. Браузер уже отображает что там вернулось. По сути дела, эти «скрипты» это не более чем стандартные unix-процессы со своими stdin, stdout, stderr каждый. И, отсюда, следует вторая проблема с ними – каждый процесс при каждом обращении запускается заново. Если у Вас есть логин в некую БД, то всё может оказаться очень печально. Нет, ни php, ни python, ни ruby с рельсами ничего нового, к сожалению, не привнесли в дело обработки запросов. FastCGI не в счёт, но об этом ниже.

Но как вариант для встраиваемок этот вариант вполне пойдёт. Например, если я хочу сделать для такого же роутера как у Вас, это называется CPE или Customer Premises Equipment, конфигурационную панель, то неужели Вы думаете что я поволоку туда всю инфраструктуру php? Ну Вы же не серьёзно! =))) Именно на cgiшках и делают… Я Вам это гарантирую. =)))

По серверам. Из существующих серверов напрямую и без проблем CGI поддерживаются lighttpd, apache, thttpd (на последний я бы обратил внимание особо, т.к. это сервер для кофемашин и газонокосилок.

Таким образом, у Вас получается две части проекта – опрос данных с устройств и складирование в какую-нибудь базу и отображение данных в веб-интерфейсе, котрые вытягиваются из базу по запросу. CGI позволяет отдавать любой формат – json, xml, html, кроче, что угодно. Отображать в браузере Вы можете тоже как угодно – хоть single page web-appication создать.

Если нужно обрабатывать большое число запросов или база на back end тяжёлая, то имеет смысл задуматься о применении FastCGI. По сути, это почти те же CGI, но стартующие уже при загрузке системы и общающиеся по сокету, т.е., их можно размещать на удалённой машине и запросы от веб-сервера будут передаваться через сокет. Т.е., все те же переменные окружения будут пересылаться на удалённую машину (можно и на локальную, само собой) и тут же парситься, обрабатываться, через веб-сервер клиенту в браузер будет возвращаться ответ. Несомненный плюс – приложение будет отрабатывать запросы пока жив хост, на котором оно работает. Есил есть СУБД, то раз залогинились при старте и дальше этого делать не нужно. Тот fastcgi что есть в php так и работает, кстати. Хотя, в том что CGI запускается при каждом запросе и завершается после отработки запроса, есть и плюс – не будет фрагментации памяти, проблемы, которая по временам здорово подбешивает, особенно при «длинных» запросах и на скромных ресурсах системы. Система сама должна зачистить использованные ресурсы после завершения процесса. С FastCGI можно нарваться на неприятности. В особенности если памяти немного. FastCGI офигенно поддерживается тем же nginx, хотя по размерам он и больше thttpd.

Почему я рекомендую не драть мозг, а использовать «стандартный» веб-сервер? Потому что в принципе можно взять ту же libevent (чтобы не париться с парсингом http-запросов и получить всё и сразу) и написать с её помощью некий веб-сервер (дадада, в 40 строк, ага). Но я бы предпочёл взять мелкий сервер типа thttpd и сконцентрироваться на логике приложения и веб-интерфейса (тот же ajax там реализовать или ещё что, чтобы приложение было бы более-менее современным, технологии это позволяют). Кроме того, использование сервера позволяет не сильно заниматься реализацией поддержки SSL/TLS и аутентификации. Сомневаюсь чтобы Вы хотели поделиться содержимым Вашего умного дома с соседями, ну, например, home video с камер видеонаблюдения. Так что, эти вопросы либо самостоятельно решать, либо пусть ими сервер занимается.

По языкам. Я бы рекомендовал воспользоваться С, благо дело тема эта проработанная годами и существует море библиотек. Например, https://github.com/rafaelsteil/libcgi для построения самих по себе CGI и FastCGI (разница в коде буквально на пяток строк). И https://github.com/ac000/libctemplate если нужны templates для веб-страничек. Хотя, можно и без них, если понимаете что делаете. В результате сторона чтения из СУБД и отображения этой информации в веб-интерфейсе будет плёвая по запрашиваемым ресурсам. Сторона сбора информации и размещения её в СУБД по идее, тоже, если опять же на С. =) Т.е., проект должен получиться максимально лёгким в части требуемых ресурсов. Счёт идёт на килобайты, даже не на сотни килобайт. Да, даже на роутере такое можно сгородить и даже будет работать, но… смысл?

В принципе, конечно, на python тоже можно поднять веб-сервер с поддержкой CGI, но чего-то не втыкает меня вся инфраструктура питона (сам питон, да ещё потом гуано всякого потребуется вагон и маленькая тележка).

По СУБД. Рекомендовали sqlite3. Можно, конечно, но я бы рекомендовал посмотреть в сторону Berkeley DB (теперь это Oracle Embedded). Это именно что встраиваемая СУБД. SQL там нет (точнее, есть, но считайте что нет, он там через зад). В код на С/С++ она добавляется именно как бибилотека, позволяет хранить данные в виде key-value, в общем, если загуглите, то с лёгкостью найдёте. Душевно рекомендую.

Ну вот, как-то вот так, в общем и целом.

P.S. И да, в зависимости от того, что именно Вы хотите, возможно что я бы даже и не стал бы городить огород со всем этим, а просто снимал бы данные с устройств и обрабатывал бы их посредством MQTT (гуглите mosquitto) на телефоне/планшете. Если там планируется сбор телеметрии и только (типа, показания счётчиков, температура, простейшие действия типа открыть-закрыть шторы), то в принципе, этого должно хватить. В каком-нибудь там IoTManager. Тогда вообще всё просто. Должно быть приложение (пусть будет номер 1), читающее данные с устройств и/или записывающее команды на устройства, должен быть «сервер» mosquitto, где для устройств созданы топики, с которыми работает приложение номер 1 (как публикует там данные, так и получает публикации), ну и IoTManagerом мы читаем-пишем данные на пользовательском устройстве. В разы проще. Ну и см. libmosquitto (хоть там и С, да).

Moisha_Liberman ★★
()
Последнее исправление: Moisha_Liberman (всего исправлений: 1)

посмотри как в slitaz сделано. там админская панель через веб-сервер организована. мне очень нравится. скриптуется на баше, вроде, но, скорее всего, ничего не мешает взять любой другой яп.

anonymous
()

делай на питоне.

на фласке сделаешь отображение состояния датчиков. модули на питоне отрабатывают события.

радужный дизайн ради дизайна это бред. хотя кому-то нравится (пипол хавает)

питон занимает в 10 раз меньше оперативы, чем nodejs.

scaldov ★★
()
Ответ на: комментарий от anonymous

МОжно меньше. При большом желании до мегабайта.

Dark_SavanT ★★★★★
()

Так в OpenWRT есть uhttpd который в cgi умеет. Хоть на шелле пиши свою морду. Lua опять же есть искаропки.

Stanson ★★★★★
() 
 PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                       
17739 drsm      20   0  766516  10180   4188 S 164.5  0.1   1:03.75 siege                                                                                         
17450 drsm      20   0    2316   1292   1236 R  33.2  0.0   0:13.21 busybox
drsm ★★
()
Ответ на: комментарий от theNamelessOne

Python тоже компилируется в байткод, но его же не называют компилируемым. Специально же уточнил про сравнение с С и С++

ergo ★★★
()

Питон не люблю из-за табов

Я пишу на Python 3 только с табами, а можно чисто на пробелах, просто смешивать нельзя два этих способа

Так что правильно что на 1 место поставил Python, теперь разупорись и спокойно применяй питошку :)

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от bga_

ты так и не сказал что это будет. сбор данных понятно. просто отображать их в веб-странице?

futurama ★★★★★
()

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

PS Ничего из списка не особо, питон более-менее. И он походу наиболее подходящ.

anonymous
()

Задача настолько тривиальная, что можно посоветовать даже Bash + CGI (uhttpd его поддерживает и предустановленной во всех сборках OpenWRT с LUCI).

Я сам лично писал экспортер для Prometheus на Bash, в качестве сервера правда взял lighttpd, но только из-за того что там не надо копаться в коде сервера чтобы поменять параметры. Плеваться от баша не начал, но уже недолго до этого момента оставалось :)

Был опыт и в написании вебморды для щелкания реле с помощью GPIO на C + FastCGI + lighttpd. Получилось что-то порядка 140 строк не учитывая клиентские HTML и JS. FastCGI взял потому что нужен был именно демон, можно было отделаться CGI и строк было бы ещё меньше.

И да, не надо все переусложнять хитрой серверной логикой. Хостить надо статический HTML, JS (, CSS) и из него дергать методы в API бэкенда. Это обеспечит минимальную нагрузку на устройство.

ArkaDOSik ★★
()
Последнее исправление: ArkaDOSik (всего исправлений: 1)

Был похожий опыт, для меня самым лучшим решением стало купить дешевый нетбук и на нем бы крутился вебсервер. При этом в отличии от Raspberry у тебя будет сразу монитор + клавиатура.

Из проблем были только вздутые конденсаторы на материнской плате. Перепаять для меня не проблема.

dicos ★★
()

Попробуй picolisp. Он идеально заточен под веб + бд

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← С++, очень странные сегфолты
Development
С помощью чего мержить две сильно разошедшиеся ветки? →