Голосовые ассистенты работают удобно, но почти всегда через облако: нужна сеть, есть задержка, и речь уходит на внешние серверы. На устройстве обычно либо примитивный команды, либо слишком тяжёлая платформа.
Я проверил, можно ли закрыть этот разрыв на микроконтроллере STM32N6 со встроенным NPU: распознавать произвольную речь локально, в реальном времени и с потреблением около 0.2 Вт.
Умный дом - одна из самых спорных тем для обсуждений и понимания. Для одних это обязательное голосовое управление, для других - наличие умных сценариев управления светом, для третьих комплексное управление светом, климатом безопасностью с одного устройства.
Для лучшего восприятия ограничимся определением умного дома как комплексным управлением светом (основной свет, подсветка, шторы), управления климатом (обогреватели, кондиционеры, осушители, увлажнители) и безопасностью (замки, датчики присутствия). Поведение устройств может определяться как изолировано (включение/выключение света в гостиной), так и объединено в единые сценарии (ночной режим, основной режим, режим охраны).
В этом смысле умный дом это не просто набор программируемых или удаленных (смартфон, умная колонка) переключателей, а единая система управления, связанная единой целью с понятной логикой.
Одна из основных проблем при проектировании заключается в противоречии между гибкостью управления и удобством. Привычная модель поведения подразумевает для управления наличие простых выключателей, приближенных к зоне влияния (выключатель света находится в той же комнате, выключатель света рабочей зоны располагается рядом с рабочей зоной). С другой стороны умный дом предполагает дополнительный комфорт, позволяющий сразу включать или выключать свет в разных зонах в соответствии со сценариями. Сценарий «Сон» может предполагать, например, общее выключение света, закрытие штор и снижение температуры.
Mesh‑сети в целом, и, в частности Meshtastic, уже давно не новая история. Почти все, кто называет себя радиолюбителем имеет одну‑две ноды в ящике своего рабочего стола. А с недавнего времени начал прослеживаться вполне ощутимый интерес к этой теме среди людей и вовсе далеких от радиоэкспериментов и подобной электроники. Чтобы не повторяться и не копировать информацию из десятков или сотен уже написанных статей и постов на профильных форумах буду рассматривать только свой вопрос, пропустив базовое объяснение, что такое mesh‑сеть, meshtastic и связанные темы.
Передо мной, в рамках моей профессиональной деятельности, встала задача обеспечить устойчивой связью две независимых группы специалистов, находящихся в разных городах на пересеченной местности (можно считать, что в условиях полевых работ).
Такие очевидные решения, как мобильная связь, высокоскоростной интернет и прочее невозможны. Реально доступен только еле‑еле живой спутниковый интернет от известного национального провайдера, который реально дает скорости ~128-512кбит/сек.
Радиосвязь с использованием носимых радиостанций — штука хорошая, но дорогая. Для выполнения моей задачи нужно как минимум 2 приличных ретранслятора (у меня есть одна Hytera, которая обошлась в совершенно нереальные деньги), нормальный интернет, и 2–3 десятка самих радеек, средняя цена которой тысяч 8 (беру среднюю цену с маркетплейсов для TYT MD UV390). Все это дорого, да и инфраструктурно сложно, ведь ретрансляторы требуют 220В, которых в поле нет, поскольку группы мобильные, а дальности не хватит, если определить одно место и поставить основательно.
Ресурсы современных одноплатных микрокомпьютеров вполне могут синтезировать речь с приемлемым качеством, используя технологии нейросетей. В этой статье пример кейса с добавлением «голоса» к отечественному микрокомпьютеру Repka-Pi 4.
Используем программные синтезаторы речи (TTS, Text-to-Speech) eSpeak NG и Pipe.
Вы сможете использовать приведённые в статье коды сервера синтезатора речи, созданного на базе Piper и FastAPI. Этот сервер запускается через systemd автоматически при включении питания Repka-Pi и получает запросы на синтез речи от внешних клиентов через HTTP. Получив такой запрос, сервер ставит его в очередь на «озвучивание». При этом клиент может не дожидаться окончания синтеза, а продолжать свою работу.
Из любопытства была у меня идея попробовать снять показания со счётчика удалённо, но так как был уже установлен древний дубовый счётчик Энергомера СЕ102, то вкладываться в замену не хотелось. Однако межповерочный интервал начал подходить к концу и я начал задумываться насчёт замены счётчика на более продвинутый (с интерфейсами связи). Начал выбирать варианты в виде LoRaWan, Zigbee, RS-485, но оказалось, что по современному законодательству счётчики электроэнергии меняет ресурсоснабжающая организация (так называемый «гарантирующий поставщик»). С надеждой ждал, что электрик придёт и поставит современный навороченный счётчик с кучей интерфейсов, но всё оказалось не совсем так...
Представитель ресурсоснабжающей организации установил новый счётчик МИР С-05.10-230-5(80)-G2Z1B-KNQ-S-D.
Прокладывать кабели в деревянном доме всегда сложно. На этапе сборки стен в бревнах или брусе сверлят отверстия и сразу закладывают кабели. После сборки изменить кабельную систему почти невозможно: приходится прокладывать линии снаружи — в трубах или кабель-каналах, что портит интерьер.
В этом проекте заказчик сначала планировал автоматизировать только отопление, но уже в процессе решил сделать полноценный умный дом. К этому моменту дом уже был построен.
В статье расскажем, как удалось превратить этот дом в умный с минимальными вмешательствами.
Приходите к нам на WBCE 2026 — выставка и конференция по автоматизации. Отчёты с прошлых выставок.
Несколько лет назад я решил купить электросамокат, чтобы ездить на работу. Я уже какое-то время пользовался прокатом самокатов, но устал от необходимости «охоты» на них или отсутствия их рядом с домом, когда мне нужно было ехать в офис.
Мой выбор остановился на Äike T. Не потому, что он оказался лучше других самокатов: на самом деле, его цена была даже выше других, и в этом ценовом сегменте рынка явно имелись скутеры с более высокими параметрами.
Однако я выбрал Äike, потому что его производили в моей стране, а мне нравится по возможности поддерживать местные компании. Äike («молния» на эстонском) был спроектирован и изготавливался в Эстонии, прямо в Таллине. Насколько я могу судить, разработчики использовали не так много стандартных компонентов. Конструкция была разработана с нуля, модуль IoT и аккумуляторные блоки тоже производили локально, и так далее. Нельзя сказать, что это однозначно лучше, ведь при этом усложняется обслуживание самоката, но сам продукт мне показался амбициозным.
Ещё одной причиной покупки стало то, что у производителя была сестринская компания Tuul («ветер» на эстонском), занимавшаяся прокатом электросамокатов. Это тоже были скутеры Äike, и из всех конкурентов мне больше всего нравились Tuul/Äike, поэтому я по возможности пользовался их прокатом.
В прошлом году компания Äike обанкротилась. В будущем это не предвещало ничего хорошего: станет всё сложнее находить запчасти, ведь они были нестандартными. Но возникли у меня и более актуальные опасения, связанные с возможностью пользоваться самокатом. У него нет ручной функции включения/отключения. Для включения и выключения, открывания аккумуляторного отсека, переключения в режим транспорта и так далее необходимо было приложение.
С ростом популярности умных замков и систем контроля доступа, пользователи столкнулись с серьезной проблемой — отсутствием единого стандарта. Производители используют собственные протоколы, что усложняет интеграцию, снижает безопасность и увеличивает стоимость внедрения.
Протокол Aliro — попытка индустрии решить эту проблему и создать универсальный и безопасный стандарт для систем доступа в умном доме.
Индустрия 4.0+ — это универсальный подход к построения умного производства, в котором данные, средства автоматизации и цифровые модели позволяют управлять промышленными объектами эффективнее. Однако интереснее всего оказывается практика реализации такого подхода. В этой статье вы узнаете, почему в реальности переход на новые принципы автоматизации оказывается не простым для подавляющего большинства предприятий, и как мы воплощаем Индустрию 4.0+ за счет применения ИИ, цифровых двойников, граничных вычислений (Edge) и облачных технологий.
Meshtastic позволяет обмениваться сообщениями через LoRa mesh-сеть даже без доступа к интернету. Но можно ли связать такую сеть с обычной электронной почтой?
Как получать и отправлять email там, где нет интернета и мобильной связи? Я сделал Python-шлюз для Meshtastic, который позволяет передавать письма через LoRa mesh-сеть и также писать ответ в сеть, который потом отправится как обычная почта.
Скрипт проверяет почтовый ящик через IMAP, разбивает письма на небольшие фрагменты и отправляет их через Meshtastic-ноду в сеть. В обратную сторону всё работает похожим образом: сообщение из mesh-сети можно отправить в определённом формате, после чего шлюз превратит его в обычное email-письмо и отправит получателю.
В статье я расскажу, как устроен этот шлюз, как решалась проблема ограниченного размера LoRa-пакетов, как реализована фрагментация сообщений и как подключаться к Meshtastic-ноде через USB или Bluetooth, автоматически находя её текущий адрес.
Современные IoT-устройства, несмотря на компактные размеры и ограниченные ресурсы, представляют собой полноценные embedded-системы. Под пластиковым корпусом бюджетного гаджета часто скрывается стандартный Linux-компьютер с собственным ядром, драйверами, файловыми системами и сетевыми службами.
Статья посвящена проведению полного цикла реверс-инжиниринга типовой IP-камеры: от аппаратного анализа печатной платы до закрепления в операционной системе с root-правами.
Разберём путь от подключения к внутренним отладочным интерфейсам устройства до реализации устойчивого удаленного root-доступа по Wi-Fi. На примере IP-камеры Aceline AIP-O4 наглядно рассмотрим типовую архитектуру бюджетного IoT-девайса и классические ошибки, допускаемые вендорами при проектировании безопасности.
Привет, Хабр. Этой статьей я открываю сезон, который многие называют «зимняя романтика и гололед», а я теперь буду называть сезоном «внезапной наледи в тени леса».
В прошедшие выходные мой хороший друг решил прокатиться за город. Скорость была абсолютно штатная, даже чуть ниже разрешенной – около 80 км/ч. Асфальт сухой, солнце слепит глаза, в машине играет приятный подкаст. И тут – въезд в тень лесополосы. Обычно он знает, что там может быть сыро, но в этот раз природа подготовила сюрприз в виде наледи.
Машина клюнула носом, корму мгновенно поставило в занос, а через секунду мир совершил кульбит, и мой друг повис на ремне безопасности, глядя в перевернутое небо.
Хорошо, что все живы, отделались ушибами и испугом. Но когда мы сидели у него на кухне и разбирали произошедшее (а он, как любой айтишник, начал с вопроса «почему?»), меня посетила мысль: Почему, черт возьми, современный автомобиль, напичканный электроникой, не предупредил его об этой ловушке?
Ведь информационные технологии давно уже должны были сделать такие сюрпризы невозможными. Давайте разберем по полочкам, какие именно IT-решения могли бы предотвратить этот переворот, если бы они были не просто в машине, а работали в едином контексте.
Хочу поделиться опытом разработки двупортового конвертора USB2RS485. Зачем изобретать повторно велосипед расскажем в статье. Посчитаем сколько потрачено.
Последние пару лет я наблюдаю за тем, как меняется запрос аудитории. Не алгоритмический, а именно человеческий. Тот, который формируется не в рекламных кабинетах, а в усталости, в раздражении от очередного «продуктивного утра», в тихом желании закрыть все вкладки и просто выдохнуть.
Чтобы разобраться, что стоит за этим ощущением, я погрузилась в несколько крупных международных отчётов: Kantar Marketing Trends, Artlist AI Trend Report, Pinterest Predicts, TikTok What's Next, а также данные Google Trends по запросам вроде slow life, mindfulness, burnout recovery. И вот что получилось.
Общая картина складывается из трёх больших движений. Первое: люди хотят замедлиться. Не из лени, а из зрелости. Второе: они ищут человеческое, настоящее, неидеальное. Третье: им важны маленькие группы, где есть доверие, а не массовые платформы, где есть охват.
Теперь по порядку.
Подробное руководство по подключению котлов Vaillant (электрического eloBLOCK и газового atmoTEC) к Home Assistant через протокол eBUS, демон ebusd и MQTT. Разбираем аппаратную часть, конфигурационные файлы, управление мощностью и автоматизацию отопления.
Задачи в нашей небольшой команде разделены строго: Лев отвечает за аппаратную часть, схемотехнику и проект в целом, а Марк — за инженерию данных, разметку виброакустических датасетов и алгоритмы каскадной фильтрации.
В этой статье мы хотим поделиться набитыми шишками при проектировании прототипа: почему стримить аудио работающего двигателя фуры в облако — это экономическая утопия, как организовать непрерывный сбор данных без блокировки процессорного ядра и почему перенос цифровой обработки сигналов (DSP) на борт микроконтроллера стал для нас единственным выходом.
4 дня логов из Telegram, 29 погодных параметров, куча ложных корреляций — и одна формула в конце. Как я с помощью Claude Opus разобрался, почему котёл работает неэффективно, и что с этим делать.
Меня зовут Алексей, я застройщик. Идея заняться умными домами появилась у нас с партнерами около пяти лет назад: направление казалось перспективным, но до практической реализации дело долго не доходило. Ситуация изменилась, когда появился объект, на котором мы получили полную свободу действий.
Этот дом мы строили с нуля — от коробки до финальной эксплуатации. Мы самостоятельно сформировали инженерную концепцию, подобрали оборудование и выстроили логику автоматизации. Проект стал для нас испытательной площадкой: здесь мы отрабатывали подходы, проверяли решения на практике и последовательно корректировали систему по мере развития дома.
Знакомая ситуация: садишься писать контент‑план, а в голове - пусто. Хотя буквально вчера за ужином придумал три отличные темы. Куда они делись? Правильно - растворились, потому что не были записаны.
Я несколько лет работаю с контентом и продуктовыми гипотезами, и в какой-то момент понял простую вещь: проблема не в отсутствии идей. Проблема в том, что мы не умеем их собирать. В этом тексте расскажу, как я выстроил систему хранения идей, какие грабли собрал на пути и какие инструменты реально работают.
Привет, меня зовут Саша. Я руковожу группой разработки MVP-продуктов и моя жизнь очень тесто связана с IOT и умными девайсами. По работе я привык быстро собирать прототипы, проверять гипотезы и доводить их до минимально рабочего состояния.
Но эта история - не про рабочий проект.
Она началась с фразы моего друга:
«Слушай, а можно сделать так, чтобы котёл на даче был умным?»
Спойлер: можно. Ещё один спойлер: на выходе получилось мобильное приложение, кастомные Android-виджеты и планы на кухонный информационный центр.
