Привет! Хочу поделиться своим проектом для 1С, OneScript и CLI, над которым работаю уже около полугода.
Альпака Виталий смотрит как-то дерзко с вызовом и в то же время весело и с задором
Это, на самом деле, не первый мой рассказ о нем - я достаточно часто пишу на Инфостарт, но трафика ведь много не бывает, правда? Тем более, что данный проект может оказаться полезным любому 1С-нику (и, как ни странно, не только), и будет очень здорово, если о нем узнает еще больше людей
Проект называется "Открытый пакет интеграций", он же "ОПИ", он же "OpenIntegrations" в английской локализации по названию репозитория. Проект бесплатный и open-source - найти его можно на GitHub (ссылка, еще раз, будет в конце), и в сути своей он представляет из себя расширение, общие модули которого позволяют легко и просто работать с такими онлайн сервисами как: Telegram, VK, Viber, Notion, Airtable, Yandex.Disk, Dropbox, Slack, сервисами Google Drive, Sheets, Calendar и совсем немного с Twitter
Все реализованные методы представляют из себя законченные действия, вроде ОтправитьСообщение(), СоздатьПост() или ЗагрузитьФайл(), что позволяет не углубляться в работу API, а просто выполнять конкретные операции, необходимые в данный момент
Но это еще не все. Все же знают про OneScript? Это такая открытая реализация стековой машины, которая позволяет выполнять код 1С независимо от самой платформы. С его помощью можно писать скрипты и даже настоящие программы - считай полноценный ЯП общего назначения, только со знакомым синтаксисом 1С. Так вот ОПИ есть и на OneScript! Причем не только как библиотека, но и как CLI приложение
CLI приложение (приложение для командной строки Windows и Linux терминала), на самом деле, моя любимая часть проекта - чувствуется в отвязке от вендера какая-то легкость и творческость :) В целом, это приложение реализует все те же методы, что и расширение для 1С, только отдельно и на любой машине, без необходимости "ставить" для этого платформу.
Вот как это выглядит:
OInt CLI - версия Открытого пакета интеграций для командной строки. На данной гифке сначала вызывается справка, потом создается json клавиатуры для Telegram, а далее эта клавиатура, вместе с текстом, отправляется мне в личку ТГ через бота
Также у проекта есть большая и подробная документация на opeintegrations.dev, где можно найти описание всех функций, примеры кода и инструкции по началу работы с каждым конкретным API. Сам же ОПИ распространяется на двух языках: русском и английском, так что даже пользователи англоязычных конфигураций на этот раз не в пролете (документация и CLI версия тоже переведены)
Одна из страниц документации
Вот такой вот проект. Если вы работаете с 1С или даже просто ищите консольную утилиту для работы с любимыми онлайн-сервисами - буду очень рад, если загляните в мой репозиторий!
В этой статье мы рассмотрим все тонкости создания Proof of Concept (PoC) мобильного приложения, построенного с помощью фреймворка SwiftUI и бэкенда с использованием FastAPI. Дополнительно я продемонстрирую эффективные архитектурные паттерны для SwiftUI-приложений, в частности MVVMP в сочетании с принципами SOLID и Dependency Injection (DI). Для android код можно легко перевести на Kotlin с Jetpack Compose.
Зачем нам нужен бэкенд
Кто-то может сказать, что можно просто запихнуть всю логику в приложение, напрямую отправлять запросы в chatgpt и сделать приложение без бэкенда. И я согласен, это действительно возможно, но бэкенд дает несколько важных преимуществ.
Бэкенд служит основой для любого сложного приложения, особенно для тех, которые требуют безопасного управления данными, обработки бизнес-логики и интеграции сервисов. Вот почему надежный бэкэнд имеет решающее значение:
Безопасность: Бэкэнд помогает защитить конфиденциальные данные и токены аутентификации пользователей от атак типа MITM (Man-in-the-Middle). Он выступает в качестве защищенного шлюза между пользовательским устройством и базой данных или внешними службами, обеспечивая шифрование и аутентификацию всех данных.
Контроль над использованием сервисов: Управляя API и взаимодействием с пользователями через бэкэнд, вы можете отслеживать и контролировать использование приложения. Это включает в себя дросселирование для управления нагрузкой, предотвращение злоупотреблений и обеспечение эффективного использования ресурсов.
Интеграция с базой данных: Бэкэнд обеспечивает бесшовную интеграцию с базами данных, позволяя динамически хранить, извлекать и обновлять данные в режиме реального времени. Это важно для приложений, которые требуют учетных записей пользователей, хранят их предпочтения или нуждаются в быстром и безопасном получении больших объемов данных.
Модели подписки и Freemium: Реализация услуг по подписке или модели freemium требует наличия бэкенда для выставления счетов, отслеживания использования и управления уровнями пользователей. Бэкэнд может безопасно обрабатывать платежи и подписки, обеспечивая бесперебойную работу пользователей и соблюдая требования по защите данных.
Масштабируемость и обслуживание: Бэкэнд позволяет более эффективно масштабировать приложение. Логику на стороне сервера можно обновлять без необходимости передавать обновления клиенту, что упрощает обслуживание и ускоряет внедрение новых функций.
По сути, бэкенд — это не только функциональность, но и создание безопасной, масштабируемой и устойчивой среды для процветания вашего приложения.
Объяснение технического стека
SwiftUI: Лучший вариант для нативных приложений для iOS после выхода UIKit. Он декларативен и упорядочен, а XCode является незаменимым редактором благодаря эпл. Для android код можно легко перевести на Kotlin с помощью Jetpack Compose.
FastAPI: Выбран для бэкенда за его скорость, минимальное количество шаблонов и декларативность, редактируется с помощью превосходного Zed.dev.
ChatGPT API: Используется в качестве большой языковой модели (LLM); выбор может меняться в зависимости от необходимости кастомизации.
Ngrok: Реализует туннелирование с помощью простой команды CLI для выхода локального сервера в интернет.
Создание приложения для iOS
Теория: Архитектурные паттерны
MVVMP (Model View ViewModel Presenter):
Model: Представляет собой структуры данных, используемые в приложении, такие как Question, Answer, Questionary и FilledQuestionary. Эти модели просты и содержат только данные, следуя принципу KISS.
View: Отвечают только за представление пользовательского интерфейса и делегируют все данные и логику презентерам. Они не содержат никакой бизнес-логики и спроектированы так, чтобы быть простыми и сосредоточенными на рендере UI.
ViewModel: В SwiftUI ViewModel представлена объектом ObservableObject, который служит моделью наблюдения за изменяемыми данными. Здесь нет методов и логики.
Presenter: Presenter управляет всей логикой, связанной с модулем (экраном или представлением), но не бизнес-логикой. Он взаимодействует с доменным слоем для выполнения операций бизнес-логики, таких как взаимодействие с API или управление сохранением данных.
Domain Layer: Этот слой содержит бизнес-логику приложения и взаимодействует с внешними ресурсами, такими как базы данных, API или другие сервисы. Он состоит из нескольких компонентов, таких как сервисы, провайдеры, менеджеры, репозитории, мапперы, фабрики и т. д.
На самом деле, MP в MVVMP является инициалами Марка Паркера, а полная форма — «Model View ViewModel by Mark Parker».
Принципы СОЛИД:
Принцип единой ответственности: У каждого класса должна быть только одна причина для изменений.
Принцип открытость-закрытость: Компоненты должны быть открыты для расширения, но закрыты для модификации.
Принцип замещения Лискова: Объекты суперкласса должны быть заменяемы объектами подклассов.
Принцип разделения интерфейсов: Ни один клиент не должен быть вынужден зависеть от интерфейсов, которые он не использует.
Принцип инверсии зависимостей: Зависимость от абстракций, а не от конкретики, чему способствует DI.
Инъекция зависимостей (DI): Реализация с использованием DI-контейнера для соблюдения принципа инверсии зависимостей.
"onboarding" предоставляет список вопросов анамнеза, которые необходимо заполнить при первом запуске приложения. Ответы будут сохранены на устройстве и использованы для персонализированной диагностики в будущем. "doctor" — основной эндпоинт: он генерирует вопросы на основе предыдущих ответов и карты пользователя, либо возвращает результат диагностики.
Модели:
Промпты:
Модуль промптов использует GPT-3.5 от OpenAI для генерации ответов на основе пользовательского ввода, анамнеза и заполненных анкет. Он возвращает пользователю соответствующие вопросы и советы по диагностике здоровья. Как видите, ничего сложного здесь нет. Код элементарен, а промпты - просто набор четких инструкций для LLM.
Настройте окружение и запустите сервер с помощью fastapi dev main.py.
Я не буду показывать здесь весь исходный код, для этого есть GitHub. Найти его можно по адресу: HouseMDAI iOS App. Вместо этого я остановлюсь только на важных (IMO) моментах.
Начнем с краткого описания задачи: нам нужно приложение с текстовым полем на главном экране, возможностью задавать набор динамических вопросов и показывать ответ. Также нам нужен одноразовый онбординг. Итак, приступим к коду.
Первым делом нам нужны модели, и они довольно просты (принцип KISS).
Теперь давайте сделаем онбординг. Продолжаем следовать KISS и SRP (Single Responsibility Principle), никакой бизнес-логики в представлениях, только UI. В данном случае - только список вопросов с прокруткой. Все данные и логика делегированы презентеру. Единственное, что здесь интересно, это небольшой вспомогательный метод bindingForQuestion, который, вероятно, должен быть в презентере, но сейчас это не имеет значения.
Вы будете удивлены, но в презентере также нет никакой бизнес-логики!
Все по-прежнему simple, stupid и имеет только одну ответственность. Presenter должен содержать только логику своего представления. Бизнес-логика уровня приложения находится вне его юрисдикции, поэтому презентер просто делегирует ее наверх по стэку вызова.
Также можно заметить, что и View, и Presenter не инстанцируют ни одну из зависимостей, а получают их в качестве параметров при инициализации. Это соответствует принципу инверсии зависимостей, согласно которому модули высокого уровня не должны зависеть от модулей низкого уровня, но оба должны зависеть от абстракций. Это обеспечивает гибкость и упрощает тестирование, а также позволяет легко заменять зависимости или внедрять макеты для целей тестирования.
При использовании паттерна Dependency Injection зависимости предоставляются извне класса, а не инстанцируются внутри него. Это способствует развязке и позволяет упростить поддержку и тестирование кода.
Хотя в данном примере протоколы не используются явно, стоит отметить, что протоколы могут играть важную роль в коде, особенно для абстрагирования и облегчения тестирования. Определив протоколы для представлений, презентаторов и зависимостей, становится проще заменять реализации или предоставлять моки во время тестирования.
Если вы рассматриваете возможность использования протоколов в представлениях SwiftUI, необходимо помнить об одном важном моменте. Поскольку View в SwiftUI - это структура, она требует явного указания типов своих свойств. Это означает, что вам придется сделать её дженериком и пробрасывать тип через весь стек вызовов, что приведет к появлению большого количества шаблонного кода.
Однако существует альтернативный подход, предлагаемый MarkParker5/AnyObservableObject. Эта библиотека работает аналогично родным оберткам свойств SwiftUI, но убирает проверку типа во время компиляции в пользу проверки во время рантайма. Хотя такой подход может внести некоторые риски, их легко снизить, написав элементарные xcode тесты, которые просто инициализируют представления так же, как вы делаете это во время рантайма.
Используя эту альтернативу, вы можете упростить свой код и оптимизировать процесс работы с протоколами в SwiftUI.
Итак, если презентер не содержит бизнес-логику, то где же она? Это задача для доменного слоя, который обычно содержит сервисы, провайдеры и менеджеры. У них всех очень схожее применение, и разница между ними до сих пор является предметом дискуссий. Давайте создадим OnboardingProvider, который будет содержать всю бизнес-логику процесса онбординга.
Опять же, он выполняет только одну задачу: управление бизнес-логикой процесса onboarding. Такая инкапсуляция позволяет другим классам взаимодействовать с ним без необходимости беспокоиться о деталях его внутренней реализации, что способствует созданию более чистой и удобной кодовой базы.
Теперь давайте соберем все вместе в корне приложения.
Это приложение SwiftUI устанавливает свое начальное состояние с помощью оберток полей StateObject. Оно инициализирует OnboardingProvider, OnboardingPresenter и HomePresenter в своем методе init. Провайдер OnboardingProvider отвечает за управление данными, связанными с онбордингом, а OnboardingPresenter управляет логикой представления онбординга. HomePresenter управляет главным домашним представлением.
В теле сцены приложения проверяется, нужна ли регистрация на сайте. Если да, то она представляет OnboardingView с OnboardingPresenter. В противном случае она представляет TabView, содержащий HomeView с HomePresenter и, если доступно, ProfileView.
Теперь настало время для домашнего экрана. Логика проста:
Получаем сообщение от пользователя
Используя сообщение, запрашиваем список вопросов из бэкенда
Показываем вопросы по одному, используя встроенную push-навигацию.
Добавляем ответы к запросу и повторяем 2-4, пока бэкенд-доктор не вернет окончательный результат
Показываем финальный результат
Похоже, я пропустил 4-й пункт... или нет? Поскольку представление не может содержать никакой логики, эту часть выполняет его презентер.
Он управляет вводом сообщения пользователем и обновляет путь навигации на основе ответов от бэкенда.
При отправке сообщения метод onSend() отправляет его на бэкенд с помощью DoctorProvider и ожидает ответа. В зависимости от типа ответа он обновляет навигационный путь, отображая либо набор вопросов, либо окончательный ответ.
Аналогично, когда заполняется вопросник, метод onQuestionaryFilled() отправляет заполненный вопросник на бэкенд и соответствующим образом обновляет путь навигации.
Здесь есть небольшое дублирование кода между методами onSend() и onQuestionaryFilled(), которое можно было бы отрефакторизовать в один метод для обработки обоих случаев. Однако оставим это как упражнение для дальнейшей доработки.
Модуль Questionary (View+Presenter) почти является копией Onboarding и просто делегирует логику до HomePresenter, поэтому я не вижу необходимости показывать код. Опять же, для этого есть github.
Последнее, что я хочу показать, это две реализации DoctorProvider, единственной обязанностью которых является вызов API и возврат DoctorResponse.
Первая использует наш бэкенд:
Вторая вызывает openai api напрямую (подход backendless) и является практически копией модуля подсказок из бэкенда:
Обе реализации легко взаимозаменяются благодаря инъекции зависимостей:
Интегрируйте аутентификацию и базу данных пользователей в бэкенд. Можете использовать официальный шаблон FastAPI из FastAPI Project Generation.
Реализуйте логику аутентификации в приложении.
Сосредоточьтесь на улучшении дизайна приложения, чтобы повысить удобство работы с ним. Давайте создавать красивые приложения!
Заключение
Приведенные проекты и ссылки на код служат реальными примерами, чтобы дать толчок вашей собственной разработке. Помните, что красота технологии заключается в итерациях. Начните с простого, создайте прототип и постоянно совершенствуйте его. Каждый шаг вперед приближает вас к овладению искусством разработки программного обеспечения и, возможно, к следующему большому прорыву в технологиях. Счастливого кодинга!
О других интересных проектах периодически пишу в телеграм.
Для своих нужд искал расширение для поиска и подсвечивания ключевых слов разными цветами и чтобы цвета не повторялись минимум 15-20 раз. Из того, что удалось найти было одно расширение, которое полностью соответствует этой цели, и так же я случайно наткнулся на это расширение, которое так же соответствует цели, но помимо этого предоставляет и другие очень мощные функции. Спустя некоторое время пользования им я бы сказал, что поиск и выделение слов - это лишь 5% от реального потенциала расширения. Поскольку подробных мануалов для тонкой настройки поисковых функций автор не приводит в ознакомительном видео и на сайте, то настроить расширение и все его функции полностью под себя не получилось, но из ознакомительной информации видно, что они офигенные. Хоть приложение переведено на английский, это все равно не помогает разобраться во всем, т.к. для некоторых из функций нужно знание javaScript, css, html. Кое в чем, конечно, удалось разобраться, но еще много остается загадкой.
Этот пост пишу в качетве благодарности автору расширения, пусть это будет рекламой хоть он и не узнает об этом. Не часто встречаются такие классные приложения, которые были бы бесплатными. Аналогичные расширения, которые я встречал платные все до единого. Можете задонатить автору или написать отзыв о приложении.
Возможно, кто-то уже пользуется им, дайте знать пожалуйста. Может быть кто-то знает где искать людей, которые бы взялись за перевод расширения на русский (на энтузиазме) или любую другую информацию, которая бы была полезна для перевода (я в курсе о переводчиках), дайте знать.
Представьте, что каждый ваш страх — это невидимый монстр в бесконечном доме. Сможете ли вы найти выход и освободиться? Сегодня есть возможность узнать ответ — в нашей новой игре!
В мире умных домов часто приходится выбирать между удобством и функционалом. Раздумывая над тем, каким может быть идеальный умный дом, мы пришли к идее MajorDom — системе, которая стремится изменить этот баланс и упростить быт без жертв. В этом посте поделимся нашим видением и некоторыми основными принципами новой экосистемы, включая приватность, автономность и широкую поддержку устройств.
automate smart — not hard (MajorDom)
В этой статье мы не будем вдаваться во все подробности технических деталей, реализаций и протоколов, а сосредоточимся на более общем, абстрактном, пользовательском описании системы, иначе статья выйдет слишком длинной, но мы обязательно вернемся ко всем деталям позже
Домашние гаджеты
Сегодня существует много разных гаджетов для дома: светильники, шторы, обогреватели, пылесосы, датчика безопасности и микроклимата. Они созданы для того, чтобы облегчить жизнь, но не всё так однозначно.
Раньше каждое устройство имело свой протокол управления, свои стандарты, свои методы безопасности и каждому из них нужно было отдельное приложение или пульт. Чем больше устройств в доме, тем больше времени нужно посвятить управлению ими, что превращается в новую рутину. Это похоже на жонглирование слишком большим количеством мячей.
Приложения для домашних гаджетов
Существующие решения
Системы "умного" дома (или домашней автоматизации) должны были решить эту проблему, но до идеала им еще далеко. Есть два типа таких систем: проприетарные от цифровых корпораций и народные с открытым кодом. К сожалению, и у тех, и у тех есть минусы. Предлагаю составить график, в котором по оси x будет легкость использования сложной к простой, а по оси y - умность и функциональность системы.
График: легкость использования к умности системы
Окажется, что все проприетарные системы находятся где-то в центре-внизу. Они дают некоторый функционал, с которым может справиться обычный человек, потратив какое-то время на изучение. Чаще всего эти системы являются закрытыми и поддерживают только свой ограниченный список устройств в своем специальном приложении. Их функциональность сводится к замене физического выключателя кнопкой в телефоне или простыми голосовыми командами. Иногда встречаются элементарные автоматизации, точнее скрипты, которые нужно писать вручную.
В то же время они слишком зависят от облачных решений. Сбой сервера, изменения в политике, новые регуляции или простое отсутствие интернета означают отключение умного дома.
Но, что хуже всего, самые популярные системы принадлежат рекламным или маркетплейсным гигантам, зарабатывающим на продаже персональных данных пользователей. Это основа их бизнес-модели, из-за чего они не могут измениться, поэтому о доверии и приватности здесь не может быть и речи.
Осьминог монополии (отсылка к "standard oil octopus")
Тем, кто хочет больше возможностей или не хочет слежки, приходится переходить на открытые решения и платить за это сложностью настройки и установки. Это область выше и левее центра, но часто это того стоит. Открытые системы предлагают больше свободы, возможности интеграции с любыми устройствами и протоколами благодаря плагинам, неограниченные кастомизации и полный контроль. Единственное, это задачка для технарей, желающих проводить вечера за изучением форумов и разработкой. Точно так же некоторым нравится проводить часы в гараже перебирая все детали машины. Я не говорю, что это плохо, ведь у каждого есть свои хобби, но большинство людей хочет автомобиль, чтобы просто на нем ездить. Конечно, вы можете нанять профессионала, который займется всеми устройствами и безопасностью, потратив на это целое состояние. Но что, если вы не хотите ни нанимать профессионала, ни становиться им самостоятельно?
Мы хотим сделать систему, которая займет правый верхний угол: будет работать прямо из коробки, поддерживать широкий спектр устройств, надежно хранить данные пользователей, при этом будет умнее и функциональнее остальных.
График: легкость использования к умности системы (мажордом)
Экосистема умного дома
Поговорим о том, как устроены экосистемы умного дома и чем они отличаются от систем домашней автоматизации. Все начинается с устройств, напрямую управляющих домом: лампы, реле, модули с мотором. Это первый "физический" уровень. Вторым уровнем пусть будет интерфейс "application layer". Свяжем их через wifi или bluetooth.
Экосистема умного дома: приложение и устройство
Но представим, что у нас несколько устройств, у каждого по своему приложению. Выглядит не очень удобно, да?
Экосистема умного дома: несколько приложений и устройств
Теперь переведем устройства на более энергоэффективные радиопротоколы. Но как подключить их к смартфону? Добавим посредника в виде хаба, у которого с одной стороны радиомодуль, а с другой - тот же wifi. В качестве бонуса подключим к хабу все устройства того же производителя. Теперь в приложении может быть несколько устройств, но только одного бренда. Так выглядят закрытые "экосистемы". Каждая использует свои протоколы и стандарты, так что они не совместимы между собой.
Закрытые экосистемы умного дома с хабом
Но, что хуже, далеко не все приложения умеют общаться с хабом напрямую в пределах локальной сети (LAN) и используют сервер даже когда вы находитесь дома. Это тот случай, когда отключение интернета означает полный блэкаут, а наличие интернета - возможность удаленного управления домом из облака (доверяете ли вы облаку компании, зарабатывающей на продаже ваших персональных данных, но не заботящейся об их сохранности?).
Закрытые экосистемы умного дома с хабом и облаком
Чтобы это исправить, заменим проприетарный хаб на raspberry pi с какой-нибудь open source системой домашней автоматизации, а также добавим плагины для интеграции устройств. Это позволяет объединить все устройства в одну систему, например, чтобы программировать общие автоматизации или продвинутые сценарии. Уже лучше, но пропала одна мелочь под названием интерфейс.
Универсальный open source хаб умного дома
К счастью, некоторые open source решения идут комплектом с вебным фронтендом или даже мобильным приложением (но не всегда с user-friendly интерфейсом). Добавив еще пару плагинов, мы можем пробросить часть устройств (или все, если очень повезет) в приложение какой-то из экосистем. В таком случае хаб выступает посредником или адаптером для устройств сторонних производителей. Но теперь мы зависимы от этой экосистемы и получаем те проблемы, о которых шла речь в начале статьи. В качестве альтернативы, мы можем подключить другой плагин с кастомным облаком, но это уже становится или слишком сложно, или все еще недостаточно безопасно.
Универсальный open source хаб умного дома c инфраструктурой экосистем
Хочу заметить, что не всегда проприетарный хаб можно полностью заменить на кастомный. Часто вам понадобится иметь оба хаба (проприетарный и кастомный), чтобы система поддерживала оригинальные приложения и устройства. В итоге это может превратиться в запутанный клубок технологий.
Универсальный open source хаб умного дома c инфраструктурой экосистем (сложности)
Кстати, этот пример мне кое-что напоминает:
Нестабильная цифровая инфраструктура
Итак, у нас есть 4 уровня: устройства, хаб (автоматизации, программное управление), сервера, интерфейс (приложения, голосовые ассистенты, итд). Экосистема — это все 4 уровня и их связь, а не какой-то один. Чтобы все работало идеально, мы делаем не просто один из уровней, например, систему автоматизации на уровне хаба. Мы делаем все три верхних уровня: приложение, голосовой ассистент, облако и хаб с максимальной поддержкой устройств других производителей, таким образом получая максимальную совместимость и интеграцию всей системы из коробки: автономную, приватную, независимую и безопасную. Это - МажорДом.
Архитектура экосистемы умного дома MajorDom
Чем наша система будет умнее: наша философия
В фундаменте своей работы мы закладываем следующие принципы:
Полная приватность личных данных — дом не место для чужих глаз. Конфиденциальность — базовое право каждого пользователя.
Автономность — максимальная независимость от внешнего мира, отключенный интернет не должен стать проблемой
Легкость настройки и использования — технологии должны служить человеку, а не наоборот
Максимальная поддержка разных устройств, протоколов и интеграций - в дополнение к предыдущему пункту
Никаких искусственных ограничений — не быть эпл и дать возможность глубокой настройки и кастомизации тем, кому это нужно
Итак, мы собираемся заново изобрести умный дом. По нашему мнению, настоящий умный дом состоит из невидимой армии устройств, которые работают автономно в фоновом режиме, улучшая вашу повседневную жизнь и прикрывая вашу спину. По сути это цифровой дворецкий.
Настоящий умный дом должен быть независимым от внешнего мира. Никаких сбоев из-за отказа интернета или случайного сервера. Это полностью автономная экосистема, которой больше ничего не требуется: ни интернета, ни облачных сервисов, ни даже человека.
В то же время система должна быть простой в использовании. Никаких долгих установок и настроек. Отсутствие периодического изменения настроек. Никакого написания кода. Просто достать из коробки и включить. Технологии должны работать на вас, помните?
Описание MajorDom
Но как нам это сделать? Прежде всего, системе нужно имя. Мы выбрали для неё название MajorDom, которое отлично отражает её сущность. (от англ. majordomo — мажордом, дворецкий, управляющий домом)
Приватность
Пока остальные системы представляют собой черные ящики, мы считаем, что MajorDom должен иметь открытый исходный код, чтобы не было никаких скрытых манипуляций, любой человек мог открыть его, прочитать, выделить проблемы, предложить изменения или даже внести свой вклад.
Хотя исходный код общедоступен, данные пользователя защищены как никогда раньше. Чтобы сделать систему приватной и автономной, большая часть данных хранится локально на устройствах, в основном хабе. Это гарантирует конфиденциальность, а поскольку все данные хранятся локально, автоматизация и все остальные функции прекрасно работают даже при отсутствии интернета в отличие от систем, которые всегда полагаются на подключение к серверу, поскольку все данные хранятся где-то в интернете.
Но в некоторых случаях данные необходимо передавать через интернет, например, с помощью удаленного управления, когда вы не дома. В этом случае данные надежно шифруются (end-to-end), а ключи хранятся только на физических устройствах пользователя. Это означает, что вы всегда можете получить удаленный доступ к своему дому, но только вы и никто другой, включая админов и разработчиков.
Поддерживаемые устройства
Конечно, прежде чем настраивать автоматизации, в доме нужны устройства. Zigbee Alliance, переименованный в Connectivity Standards Alliance или CSA, — это объединение различных компаний, занимающихся умным домом, которые решили создать универсальный протокол связи для всех устройств домашней автоматизации. Они назвали этот протокол Matter. И MajorDom с ним совместим. Это означает, что вы можете добавить любое совместимое с Matter устройство в свою систему MajorDom. И это еще не все.
matter протокол
Matter изначально поддерживает только самые распространенные базовые устройства, поэтому мы создали протокол связи Merlin. Благодаря более гибкой архитектуре он не только существенно расширяет список поддерживаемых устройств, но и делает его бесконечным.
Мерлин протокол
В то же время мы понимаем, что сегодня только малая часть уже выпущенных устройств поддерживает один из этих протоколов, поэтому мы также собираемся добавить интеграции устройств, использующих zigbee, z-wave, wifi и BLE, таким образом став самой универсальной экосистемой.
Умная комната с устройствами на разных протоколах в системе MajorDom
Интерфейс
Мобильное приложение MajorDom на фоне хаба
Мы наконец-то собрали в одном месте все устройства, но как с ними общаться? Для этого мы разработали красивое мобильное приложение, доступное практически на всех платформах, включая устройства Android — телефоны, планшеты и часы, а также устройства Apple — iPhone, iPad, Mac, Apple Watch, Apple TV, CarPlay и даже новый шлем Vision Pro. Приложения так же включают виджеты, которые можно разместить на домашнем экране, экране блокировки или в любом другом месте, поддерживаемом операционной системой, что позволит управлять домом даже не запуская приложение.
По-настоящему умный дом большую часть времени должен работать автономно, в фоновом режиме, чтобы вы этого даже не замечали. Но как мы собираемся это автоматизировать, если никто не хочет писать скрипты?
Вместо этого:
Скрипты для автоматизаций умного дома
Для автоматизации мы добавили в приложение вторую вкладку, которая поможет легко настроить любой сценарий. Но это было слишком просто и мы пошли дальше.
Приложение MajorDom: вкладка автоматизаций
Чтобы еще больше упростить этот процесс, мы изобрели технологию умных предложений, которая предсказывает, что вы хотите автоматизировать. Иногда она настолько умна, что даже не требует помощи пользователя. Например, вы можете просто добавить все устройства и начать использовать их, не добавляя никакой автоматизации или сценария. Через некоторое время эта технология предложит сцены и автоматизацию на основе ваших привычек. Вы даже можете разрешить ей добавлять сцены и автоматизации без подтверждения, полностью в фоновом режиме. Настоящие умные автоматизации.
Арчи — умный голосовой ассистент
Автоматизация — это хорошо для ежедневной рутины, но иногда требуется более индивидуальный подход. Арчи в этом профессионал. В отличие от других "ассистентов", он понимает вас с высокой точностью, знает контекст, улавливает по несколько сложных запросов за сообщение и общается так, будто вы разговариваете с настоящим помощником, а не просто диктуете голосовые команды!
Умная колонка MajoDom Audio с голосовым ассистентом Арчи.
Перевод: — Арчи, проверь мое расписание — У вас встреча с командой разработки в 3 часа и планы на ужин в 7. Также, не забудьте, что сегодня день рождения у вашей мамы. У вас есть достаточно времени на звонок между 4 и 6 часами вечера
Арчи предназначен не только для контроля дома, но и для каждого аспекта повседневной жизни, от управления заметками до предоставления общей информации и голосовых уведомлений.
Как настоящий профессиональный мажордом, Арчи говорит на многих языках. Он может одновременно слушать до трех заранее выбранных языков и отвечать на соответствующем.
Арчи унаследовал все основные ценности MajorDom: конфиденциальность, автономность, простота в использовании и настоящая умность. Он может работать офлайн, но интернет расширяет его возможности до неограниченного диапазона, а благодаря использованию крупных языковых моделей, навыки этого ассистента ближе к настоящему искусственному интеллекту, чем когда-либо прежде в истории человечества.
Демонстрация голосового ассистента Арчи в мобильном приложении MajorDom на фоне умной колонки MajorDom Audio и хаба MajorDom Hub.
Работа из коробки: делаем свои устройства
"Люди, серьезные на счет софта, должны делать своё железо" — эта цитата особенно актуальна для умного дома. Это единственный способ обеспечить беспроблемную интеграцию множества протоколов из коробки. То же самое касается ассистента: не каждая платформа потянет офлайн распознавание, обработку и синтез речи. К тому же, полностью доверять ему можно только тогда, когда знаешь, что на устройстве нет постороннего ПО с доступом к микрофону. Вот почему мы разрабатываем два собственных устройства: хаб MajorDom Hub для управления устройствами, автоматизацией и порталом в экосистему — это как руки дома. И колонка MajorDom Audio для голосового ассистента — уши и голос дома.
Умная колонка MajorDom Audio и хаб MajorDom Hub
И еще кое-что… для активных пользователей
Мы хотим максимально упростить интеграцию идей пользователей — будь то аппаратное или программное обеспечение. С этой целью мы спроектировали два основных инструмента, позволяющих каждому внести свой вклад.
«Idea Forge» (Кузница идей)
Во-первых, при разработке MajorDom мы создали «Idea Forge» (Кузницу идей). Эта платформа превращает предложения пользователей в реальные фичи. Любой желающий может предоставить идеи через форму на сайте. Необязательно быть программистом; достаточно одной светлой мысли. Эти предложения затем появляются на доске голосования сообщества, что позволяет каждому влиять на процесс разработки. Демократия в действии. Самые популярные идеи рассматриваются к реализации командой MajorDom. Речь идет не только о пользователях; речь идет о превращении пользователей в создателей.
Но это не просто игра в ожидание. Если вы любите приключения или просто не можете дождаться, вы можете засучить рукава и написать любую фичу самостоятельно.
Во-вторых, мы максимально упрощаем работу для всех разработчиков. Разрабатываем модульную прошивку хаба с поддержкой плагинов и удобные библиотеки с подробной документацией.
Заключение
На данный момент проект находится в стадии активной разработки, но большая часть упомянутого уже реализована, включая ядро системы, интеграции некоторых протоколов, удаленное управление, автоматизации, офлайн часть Арчи и мобильное приложение. Дальнейшие новости будем публиковать здесь, но так же рекомендую подписаться на соответствующие страницы проекта в социальных сетях. Записаться на ранний доступ можно на сайте majordom.io в один клик.
Присоединиться к проекту
Проект является довольно сложным и масштабным, а качественный результат требует много часов работы профессиональных инженеров, программистов и дизайнеров. В современном капиталистическом мире только коммерческая разработка может гарантировать стабильный результат.
Предзаказы, Кикстартер, Донаты
В будущем проект будет опубликован на кикстартер — платформу краудфандинга, на которой можно будет оформить самые ранние предзаказы устройств, но поддержать проект финансово можно уже сейчас на patreon или buymeacoffee.
Стать частью команды
В нашей команде уже есть дизайнеры, инженеры софта для фронта, бэка, мобильных приложений, хаба и голосового ассистента. В то же время мы ищем промышленных дизайнеров, embedded инженеров для железа, а так же программистов, разбирающихся в низкоуровневых деталях популярных протоколов в сфере умного дома. Если вы занимаетесь чем-то другим, но хотите присоединиться к проекту, пишите свои предложения, будем рады всем.
Инвесторам
Мы также рассматриваем получение инвестиций от $50k pre-seed раунда за долю компании. Говоря о цифрах, текущий рынок умного дома оценивается в 100 миллиардов долларов США, с прогнозируемым ростом до 600 миллиардов в 2033 году. Похоже на отличную возможность вложения.
В посте постараюсь кратко рассказать про сабж, почему это не сложно, не дорого и экономически выгодно. И как из этой идеи родился новый opensource проект.
Первую статью публиковал на хабре, там есть технические детали и подробная предыстория.
Краткая предыстория
Построили дом, смонтировали радиаторную систему отопления с газовым котлом. Находясь в доме зимой, ощутил разницу температуры в доме в течение дня, потому что на котле стояла фиксированная температура, а на улице она была не фиксированная. В итоге в доме то +18, то +28, нехорошо.
Далее были поиски готовых решений управления котлом для поддержания внутри дома заданной температуры, и на тот момент был, вроде бы, только Zont, но мне он не подошел, т.к. в доме я использую Home Assistant, нормальной интеграции zont'а в Home Assistant нет до сих пор, а управлять отоплением из отдельного приложения не хотелось.
Путь диайвайщика
Собственно, за неимением других вариантов начал разрабатывать свой девайс и прошивку для котлов c OpenTherm, который занимается расчётом температуры отопления и управлением котлом в целом. Проект решил опубликовать на github и написать статью на хабре, увидел к этому интерес у людей и продолжаю развивать. В последних версиях прошивки была добавлена возможность управления контроллеров без Home Assistant, напрямую из браузера с компьютера/телефона:
Скриншот страницы управления отоплением и ГВС
Про экономическую целесообразность и комфорт
Когда на котле установлена фиксированная температура, температура в помещении может сильно меняться в течение дня. Например, на улице -30 и мы ставим на котле 60 градусов, за ночь температура поднялась до -10, а температура на котле все те же 60 градусов. И котёл может перегреть дом до 28-30 градусов.
Это мало того, что это не комфортно, но и лишний расход газа, который, по моим наблюдениям, мог составить на 3-5 тыс. рублей в месяц (в зависимости от размера дома).
Именно по этой причине целесообразно использовать погодозависимое регулирование температуры. На примере моего дома при установленной температуре 22.5 градуса это теперь выглядит так:
Пик до 24 град. связан с нагревом солнцем через окна
Кроме этого, экономия может быть достигнута за счёт установки более низкой температуры (12-15 градусов) на период длительного отсутствия, например, если это дом для эпизодического проживания.
Использование в квартирах. Я лично использую один девайс в квартире под сдачу с автономным отоплением. Потому что есть арендаторы, которые не умеют или боятся менять температуру на котле. И иногда греют квартиру до 30 градусов и потом удивляются счетам за газ. Установка девайса и беспроводного bluetooth датчика температуры полностью избавил меня от звонков по этому поводу :)
Почему это недорого
Для устройства используется плата ESP8266 или ESP32, цена которых на али/авито от 200 до 800 рублей.
Если умеете и любите паять, цена основной платы и компонентов для самостоятельный сборки выходит примерно в 1200 рублей без корпуса или 1500 рублей с корпусом. Платы можно заказать через pcbway/jlcpcb или вовсе собрать на макетке, а компоненты я брал в Чип и Дип. В собранном виде девайс может выглядеть вот так:
Если не умеете или не любите паять, то есть готовые устройства на ozon, цена от 2500 до 4000 рублей, искать по запросу esp opentherm (не реклама, это не мои девайсы, я их вообще не собираю на продажу). Или Zont за 12-15 тысяч рублей.
Итого: от 2000 до 4000 рублей за комфорт и экономию в долгосрочной перспективе.
В заключение хочу сказать, что весь этот путь от изучения протокола OpenTherm до создания своего DIY проекта и разработка прошивки полностью себя оправдал, в доме воцарилась стабильная температура, а я получил моральное удовлетворение от процесса :)
Прошивка с открытым исходным кодом и полностью бесплатная.
Привет, любители технологий! Сегодня я рад представить вам S.T.A.R.K. (Speech and Text Algorithmic Recognition Kit). Если вы когда-либо мечтали создать голосового ассистента, который будет современным, продвинутым и невероятно интуитивным, S.T.A.R.K. - лучшее решение.
Почему именно S.T.A.R.K.?
Автономность и конфиденциальность: S.T.A.R.K. работает полностью на устройстве, гарантируя сохранность ваших данных.
Распознавание контекста: С S.T.A.R.K. вы можете легко определять контекст и параметры для последующих запросов, а также одновременно выполнять несколько команд.
Асинхронные команды: Запустите задачу и продолжайте использовать ваш голосовой ассистент. S.T.A.R.K. уведомит вас о завершении.
Множественные ответы: Получайте обновления в реальном времени для текущих задач, будь то мониторинг процесса загрузки или отслеживание доставки.
Продвинутый синтаксический анализ: Специальная синтаксическая система упрощает извлечение любого параметра из строк.
Расширяемость с помощью ведущих языковых моделей: Улучшите когнитивные способности S.T.A.R.K., интегрируя его с ведущими языковыми моделями, такими как ChatGPT.
Поддержка нескольких языков: Взаимодействуйте со своим голосовым ассистентом на нескольких языках.
Полная настройка: Создавайте сложные команды, интегрируйте различные голосовые или текстовые интерфейсы и даже переопределяйте существующие классы.
Поддержка сообщества: Присоединяйтесь к репозиторию STARK-PLACE и пользуйтесь библиотекой расширений от сообщества.
Присоединяйтесь к нам
Для более подробного изучения каждой функции и понимания всех возможностей S.T.A.R.K. посетите официальную документацию и репозиторий на GitHub. Если вам понравился фреймворк, не забудьте добавить звезду ⭐ репозиторию.
Apple как-то попытались сделать серверную ОС, но у них так и не получилось обеспечить необходимую безопасность ядра. плюнули, но объявили, что всё их оборудование невероятно защищено. ага. то-то сливы все знаменитостей с айфонов. или кто-то думает, они там гламурно на андроидах сидят?
и закрытый код гарантирует наличие ошибок в коде. потому что код пишут люди, а люди склонны ошибаться. примером - мелкософт со своими бесконечными обязательными обновлениями, резкой сменой версий, и тому подобными плюшками мегакорпорации. умолчу про ntfs. но эти хоть сервера делают. всякие. не всегда раньше помогало, но вот не прошло и 50 лет от основания компании, как голая система может сама себя защитить. ура!
и да. в пентагоне давным давно запретили айфоны. теперь и у нас запрещают в учреждениях. потому что очень безопасно. даже слишком.
в Южном парке хорошо прошлись.
а линукс, основа андроида, изначально серверная система с суперзащищённым, по умолчанию, ядром, код которой перепроверяется открытым сообществом. то есть - любым человеком. просто по приколу. в этом принципиальная идея, открытый код.
обычный, нерутованнный андроид, без закладок и бэкдоров, взломать практически невозможно, не зная характерных особенностей конкретной версии андроида или аппаратных средств, используемых под его управлением.
причём яблоки используют наработки открытого сообщества, поэтому, по его правилам, ОБЯЗАНЫ открыть свой код. но нет. не открывают.
так что давайте сначала научим животное слушаться, а потом решим, любить его, или нет.