Comments 30
Зачем для этого лезть в веб-интерфейс?
Было бы неплохо четко описать, что предлагается в качестве альтернативы. Вот я почему-то решил, что мне вебинтерфейс на роутере под OpenWRT больше не мил и я почему-то не хочу сделать значок на рабочем столе, который отправит этому роутеру команду по ssh. Что вы предлагаете в качестве решения? Как это будет выглядеть? Сколько времени настраиваться? Какие преимущества будут получены?
В случае с роутером, в идеале, предлагается подключить по USB/WiFi девайс с экранчиком и кнопками, который будет предоставлять панель управления роутером с возможностью наблюдения за параметрами системы (нагрузка, uptime, скорость на интерфейсах), изменения IP адресов, просмотра выданных DHCP-сервером адресов, блокировки MAC и тому подобных задач. К примеру, хочешь отмонтировать внешний жёсткий, подключённый к роутеру? Просто возьми девайс в руки, выбери приложение управления точками монтирования, выбери диск и пункт unmount в меню — всё в непосредственной близости от роутера и диска. По сути, подошёл к роутеру, потыкал кнопочки, готово.
Ещё одно преимущество системы — через какое-то время использования её на десктопе я начал воспринимать её как системный трей. Громкость, по крайней мере, там настраивать удобнее, да и треки переключать во время работы не так напряжно =)
Сколько времени настраиваться? Я сейчас в основном тестирую чистую установку по собственноручно написанному гайду. Сегодня утром взял недавно полученную Raspberry Pi 3, USB numpad и I2C дисплей. От чистой Raspbian Jessie до рабочей установки pyLCI прошло где-то минут 20 — и это я ещё решил проблему DNS и поменял случайно взятый нерабочий дисплей на другой.
(Кстати говоря, такие интерфейсы на своих SOHO-роутерах делает MikroTik и у них довольно неплохо получается. И ещё — к UCI (конф. система OpenWRT) довольно легко цепляться через консольные команды, что является, по моему опыту, одним из самых удобных векторов взаимодействия в рамках pyLCI. На OpenWRT я свою систему ещё не тестировал, но одной из целей моего недавнего рефакторинга было именно исключение зависимостей, которые могут не быть доступны под OpenWRT.)
Ещё одно преимущество системы — через какое-то время использования её на десктопе я начал воспринимать её как системный трей. Громкость, по крайней мере, там настраивать удобнее, да и треки переключать во время работы не так напряжно =)
Сколько времени настраиваться? Я сейчас в основном тестирую чистую установку по собственноручно написанному гайду. Сегодня утром взял недавно полученную Raspberry Pi 3, USB numpad и I2C дисплей. От чистой Raspbian Jessie до рабочей установки pyLCI прошло где-то минут 20 — и это я ещё решил проблему DNS и поменял случайно взятый нерабочий дисплей на другой.
(Кстати говоря, такие интерфейсы на своих SOHO-роутерах делает MikroTik и у них довольно неплохо получается. И ещё — к UCI (конф. система OpenWRT) довольно легко цепляться через консольные команды, что является, по моему опыту, одним из самых удобных векторов взаимодействия в рамках pyLCI. На OpenWRT я свою систему ещё не тестировал, но одной из целей моего недавнего рефакторинга было именно исключение зависимостей, которые могут не быть доступны под OpenWRT.)
Что из себя представляет "девайс с экранчиком и кнопками"?
Комбинация из HD44780-совместимого экрана и кнопок. Могут висеть на как одном интерфейсе (экран I2C + кнопки I2C, или Ардуино с шилдом), так и на разных (кнопки USB + экран GPIO). Как оба подключены, так и сойдёт — главное, чтобы можно было получать информацию с кнопок и передавать её на дисплей =)
Если у вас уже есть Arduino, на который все равно придется писать какой-то скетч, то зачем нужна библиотека на питоне? Отправить запрос по USB и прочитать ответ можно даже средствами bash.
… Таким образом перекинув наиболее сложную часть в код на МК. Это совсем не цель этого проекта. pyLCI — это фреймворк, легко расширяемый приложениями на Питоне, как и различными устройствами ввода и вывода. Он позволяет быстро добавлять новые функции, которые он может выполнять. Это немного больше "библиотеки", и не совсем влезает в МК — да и не место там ему, слишком много ограничений.
Да, на Ардуино можно сделать терминал через UART. Можно даже разговаривать с USB через Bash. Но в данном случае Arduino+шилд работают как просто мост USB->LCD&кнопки. Не в последнюю очередь потому, что такая комбинация — простой способ поддерживать компьютеры только с USB, а ещё она есть у некоторых людей, которые интересуются pyLCI.
Да, на Ардуино можно сделать терминал через UART. Можно даже разговаривать с USB через Bash. Но в данном случае Arduino+шилд работают как просто мост USB->LCD&кнопки. Не в последнюю очередь потому, что такая комбинация — простой способ поддерживать компьютеры только с USB, а ещё она есть у некоторых людей, которые интересуются pyLCI.
Да нет, на МК сохраняется ровно тот же самый код — опрос состояний кнопок и управление LCD. От этого все равно никуда не деться.
Собственно, суть моего вопроса была в практичном применении, ведь обычно фреймворки создаются для того, чтобы что-то упростить. Вот я и пытаюсь понять, что именно этот фреймворк упрощает. Пока все выглядит как странный и ресурсоемкий способ решать элементарные задачи. Я даже посмотрел список применений на сайте и все равно в недоумении — зачем питон, если все равно все делается через обращения к внешним утилитам (типа amixer, shutdown и т.д.)
Собственно, суть моего вопроса была в практичном применении, ведь обычно фреймворки создаются для того, чтобы что-то упростить. Вот я и пытаюсь понять, что именно этот фреймворк упрощает. Пока все выглядит как странный и ресурсоемкий способ решать элементарные задачи. Я даже посмотрел список применений на сайте и все равно в недоумении — зачем питон, если все равно все делается через обращения к внешним утилитам (типа amixer, shutdown и т.д.)
Он упрощает взаимодействие между пользовательскими приложениями и устройствами ввода-вывода, предоставляя hardware abstraction layer, элементы UI и возможность сосуществования приложений. Кроме всего прочего, для него не нужен МК. Достаточно GPIO, доступных из Linux, или I2C, или UART, или вообще HID. Всё благодаря HAL. Благодаря Python можно легко делать гибкий и мощный интерфейс, да ещё и язык достаточно простой и в то же время распространённый для того, чтобы иметь низкий порог вхождения.
Используя pyLCI, можно сконцентрироваться непосредственно на главной цели приложения.
Используя pyLCI, можно сконцентрироваться непосредственно на главной цели приложения.
возможность сосуществования приложений
Это интересно. Но хотелось бы конкретных примеров. И, если уж речь идет об слое абстракции, то хотелось бы прояснить ряд моментов — как сервис узнает о том, что подключено, скажем, к Arduino воткнутому в роутер через USB? Нужна какая-то специфическая прошивка для Arduino или есть коммуникационный протокол? Как присваиваются имена найденным устройствам и субустройствам (кнопкам, экранам и т.д.)?
язык достаточно простой и в то же время распространённый
Этот язык прожорливее Явы и медленнее JS. Это неважно на десктопах и серверах, но может оказаться очень неприятным на слабых роутерах и SoC. Отдельно хочу отметить, что установщик pyLCI заточен под apt, который есть не везде, а конфигурация службы под systemd — на роутерах с OpenWRT вроде как используется init.d
Нужна какая-то специфическая прошивка для Arduino или есть коммуникационный протокол?
Прошивка для Arduino и драйвер pyLCI для передачи команд по последовательному порту. На Arduino можно передавать команды HD44780, а принимать коды нажатых клавиш. Предельно просто =)
Как присваиваются имена найденным устройствам и субустройствам (кнопкам, экранам и т.д.)?
Конфиги, конфиги и ещё раз конфиги (на самом деле, всего один файл ;-) ) Автоматическое использование всех сколь-либо подходящих устройств, т.е., по сути, автоконфигурация — на первый взгляд звучит здорово, но не могу даже придумать ситуацию, где это доставило бы больше преимуществ, чем проблем. Захватывать автоматически HID устройства — катастрофа, захватишь основную клавиатуру и в систему нормально не войдёшь. Сканить GPIO — дохлый номер. I2C — по нему много что подключено, и выглядит в принципе одинаково. А софт, который у меня на Линуксе посылал AT во все доступные порты каждые 10 секунд, (modemmanager вроде) я прибил с особой жестокостью, врагу не пожелаю. Так что — whitelists и конфиги с чётко заданными параметрами.
экранам
В конфиге же указывается размер дисплея, если он больше 16x2 (значение по умолчанию). Дисплей пока поддерживается только один. По сути, работа с интерфейсом со стороны пользователя однопоточная =) Прикол в том, что много дисплеев — это дико широкая штука. У каждого своё представление, как оно работает, и мало у кого это представление легко перекладывается на реальность. Сделать универсальную многодисплейную среду — большая работа. И ещё — для просто вывода информации на дополнительные экраны давно есть LCDproc. Работает, проверено временем.
А вот возможность подключения больше одного устройства ввода будет в этом месяце =)
Этот язык прожорливее Явы и медленнее JS.
Уж точно не прожорливее Явы. Медленнее JS? Возможно, но в оптимизацию JS-движков вкладываются большие деньги. Кроме всего прочего, ядро использует стандартные библиотеки Python 2.7 и не занимает слишком много памяти — да и в случае необходимости можно пожертвовать отзывчивостью интерфейса =)
Отдельно хочу отметить, что установщик pyLCI заточен под apt, который есть не везде, а конфигурация службы под systemd — на роутерах с OpenWRT вроде как используется init.d
Да, я это указал в конце статьи. Но насчёт отсутствия фундаментальных несовместимостей я позаботился, насколько мог =)
Сюда уже смотрели? По сути, Hello World.
Ух круто!
Я ща делаю проектик для carpc, всё никак никак не напишу статью сюда о нём… часть функционала по рисованию интерфейсов пересекается с вашим проектом… блин ща убегать надо, не успею поподробнее почитать.
P.S. Ещё кстати актуально не только текстовыми дисплеями ограничиватся, но и чемнить типа oled 128x64 и с возможностью объединения их в группы
Я ща делаю проектик для carpc, всё никак никак не напишу статью сюда о нём… часть функционала по рисованию интерфейсов пересекается с вашим проектом… блин ща убегать надо, не успею поподробнее почитать.
P.S. Ещё кстати актуально не только текстовыми дисплеями ограничиватся, но и чемнить типа oled 128x64 и с возможностью объединения их в группы
Проблема с не-текстовыми дисплеями — нужно написать драйвер со слоем абстракции для трансляции текста в пиксели, а это время, которого у меня пока что не так много. Ещё встревает то, что у меня пока нет таких OLED =) А вот 16х2 дисплеев у всех навалом. И ещё — я сейчас стараюсь сделать HD44780 дисплеи до конца — отловить баги, проверить с разными размерами, добавить драйверов для различных шилдов, потом уже можно думать.
Объединять в группы, конечно, тоже хорошая идея, но, как и с предыдущим пунктом, нужно сначала хорошо всё распланировать. Кстати, можете чуть поподробнее описать, как Вы себе представляете такое объединение? А то вариантов больше, чем один =)
Насчёт логики — у меня есть код для создания меню (ui/menu.py), к примеру. Не проверял, но по результатам последнего рефакторинга должен растягиваться на неограниченное кол-во строк. Так что — используйте на здоровье =)
Объединять в группы, конечно, тоже хорошая идея, но, как и с предыдущим пунктом, нужно сначала хорошо всё распланировать. Кстати, можете чуть поподробнее описать, как Вы себе представляете такое объединение? А то вариантов больше, чем один =)
Насчёт логики — у меня есть код для создания меню (ui/menu.py), к примеру. Не проверял, но по результатам последнего рефакторинга должен растягиваться на неограниченное кол-во строк. Так что — используйте на здоровье =)
вот например в моей реализации автокомпа будет суммарно три (четыре в идеале) дисплея, один отладочный текстовый 16x2, два OLED в мангитоле и дополнительный на месте штатного компа авто.
И тут например нужно управление ими в одном контексте, например при выборе пунктов меню на 1 дисплее меняет содержимое второго (например список приложений слева, его показатели нагрузки справа)
либо например на одном отображается список пунктов меню, во втором загрузка процессора и т.п., в третьем мониторинг какойнить железяки.
И тут например нужно управление ими в одном контексте, например при выборе пунктов меню на 1 дисплее меняет содержимое второго (например список приложений слева, его показатели нагрузки справа)
либо например на одном отображается список пунктов меню, во втором загрузка процессора и т.п., в третьем мониторинг какойнить железяки.
У меня есть несколько идей на этот счёт.
Прежде всего, есть LCDproc. Это похожее и давно существующее решение, которое пересекается с целью моего, но не совсем. Оно позволяет выводить на дисплеи всякую статистику, данные плеера и прочее. Если вам просто нужно выводить обновляющуюся информацию — для этого можно использовать LCDproc.
Ещё — используя pyLCI, можно выдавать отдельным приложениям отдельные дисплеи. Дисплей с меню — отдельный, для какого-то приложения — второй, для ещё какого-то — третий. Фича ещё не готова, но много времени не займёт — просто пока нет актуального юзкейса.
Прежде всего, есть LCDproc. Это похожее и давно существующее решение, которое пересекается с целью моего, но не совсем. Оно позволяет выводить на дисплеи всякую статистику, данные плеера и прочее. Если вам просто нужно выводить обновляющуюся информацию — для этого можно использовать LCDproc.
Ещё — используя pyLCI, можно выдавать отдельным приложениям отдельные дисплеи. Дисплей с меню — отдельный, для какого-то приложения — второй, для ещё какого-то — третий. Фича ещё не готова, но много времени не займёт — просто пока нет актуального юзкейса.
помимоописания желательно добавить примеры фото/видео. И при описании возможностей непонятна архитектура и пути взаимодействия.
Видео добавил, сейчас сделаю главное фото получше =)
Насчёт архитектуры — могу скоро сделать пост, где напишу простое приложение (одно из запланированных на ближайшее время) и заодно объясню архитектуру. Вас заинтересовал бы такой пост?
Пока что можно почитать main.py, если интересует ядро. Правда, это один из файлов, на который пока нет страницы RTD — но в течение недели я её напишу.
Насчёт архитектуры — могу скоро сделать пост, где напишу простое приложение (одно из запланированных на ближайшее время) и заодно объясню архитектуру. Вас заинтересовал бы такой пост?
Пока что можно почитать main.py, если интересует ядро. Правда, это один из файлов, на который пока нет страницы RTD — но в течение недели я её напишу.
За кассу из спичечных коробков 5+!!! ;)
По-моему экран маловат. Надо добавить возможность подключения многострочного экрана.
Для простых задач по администрированию всё можно уложить в две-четыре строки =) А так — да, согласен. Потом буду экспериментировать с TFT и OLED.
По-моему кто-то публиковал хабре статью по простому подключению терминала по bluetooth к смартфону. Т.е. "штатными средствами" на COM-Bluetooth и на телефоне программа BT-Terminal
Да, я так давно делал сам с Raspberry Pi и HC-05 =) У этого своё применение и свои ограничения.
По крайней мере планшет с клавиатурой очень близок к "Создание беспроводного терминала с LCD и кнопками для управления без тянущихся повсюду проводов "
Тут прикол ещё и в системе приложений и дешёвом железе, которое можно прикрепить и оставить, как я сейчас делаю со своими девайсами =) А ещё — носимые устройства, встраиваемые интерфейсы, гибкость и тому подобное. Да, консоль — это круто. GUI — тоже. Но есть ниша, которую не занимает ни один, ни другой.
Гм. А если зайти с другого бока и сделать терминал для UART в таком же форм-факторе...
Это отдельный проект, но тоже достаточно неплохой. С другой стороны, как терминал для UART я использую Asus EEE PC. Клавиатура лучше, экран большой, ещё и SSH поддерживает ;-)
Не, просто подумалось не о полноценном терминале, а о таком "ограниченном", именно для определенных задач — при подключении автоматом логинится как какой-нибудь "лохоюзер", и может пускать по нажатию кнопок подготовленные для этого юзера шелл-скрипты.
Да, что-то типа алгоритма expect в железе с HID input =) Это, конечно, идея со своими закавыками, но это одна из моих целей для носимого компьютера — использовать Arduino Pro Micro как UART2HID адаптер, чтобы иметь пассворд-менеджер, управление компьютером и тому подобное — и всё по USB/wireless с компьютера на теле.
Идея хорошая, думаю надо найти единомышленников, доработать, секретов не раскрывать. Мое виденье — это консоль, должна быть универсальной для разных платформ (различаться будет програмная часть), дисплей большой OLED, клавишами можно поиграться — забить на кнопки спец функции, заменить на микрики или сенсорные… и тп и тд много идей… Свой ум и действие надо продавать…
Ска жем я как потребитель был бы рад видеть такую штуку у себя на стене — в плане консоли управления умным домом, температура и тп
Ска жем я как потребитель был бы рад видеть такую штуку у себя на стене — в плане консоли управления умным домом, температура и тп
Секретов… Оно всё Open-source =) А вот слой для спецфункций на клавиши уже в планах. С разными ОС немного сложнее, но тоже возможно.
Никто не мешает, в принципе, продавать готовые устройства для подключил-и-консоль. Если оно будет более-менее успешным, буду делать Кикстартер для распространения таких устройств. Ну а пока что просто постараюсь поддерживать как можно больше уже существующих =)
Никто не мешает, в принципе, продавать готовые устройства для подключил-и-консоль. Если оно будет более-менее успешным, буду делать Кикстартер для распространения таких устройств. Ну а пока что просто постараюсь поддерживать как можно больше уже существующих =)
Sign up to leave a comment.
pyLCI — внешний интерфейс для Raspberry Pi и других Linux-устройств