Сервер + клиент (android,win) для доступа к контроллерам умного дома ab-log (а так же доступ через TelegramBot):
- Серверная часть ASP .NET8. Поддерживаемые платформы: Linux, Windows, Mac. Сервер имеет свой полноценный WEB интерфейс. При желании собственный серверный WEB.UI можно использовать без клиента удалённого доступа (тем более, что реализован удалённый доступ через TelegramBot)
- Интерактивный доступ к серверу через TelegramBot. Если сравнивать этот вариант взаимодействия с клиентом удалённого доступа, то функционал тут не совсем полноценный. В следствии естественных ограничений возможностей клиента Telegram в нём затруднительно реализовывать сложную логику взаимодействия пользователя с элементами управления. Однако у Telegram доступа есть важная особенность: удалённая настройка сервера (через интернет) возможна только средствами Telegram доступа. Разумеется, сервер можно настроить локально через его же WEB интерфейс, но в случае необходимости удалённого редактирования этих настроек через интернет - потребуется именно Telegram доступ. Штатные клиенты удалённого управления равноправны между собой, а клиенты Telegram персонифицированы. Другими словами: для пользователей Telegram вы можете персонально указывать права к тому или иному функционалу, а штатные клиенты для сервера не отличаются правами между собой.
- Удалённый клиент .NET MAUIBlazor Hybrid через промежуточный MQTT (например через бесплатный сервис MQTT hivemq.cloud). Поддерживаемые платформы: Windows, Android. Полноценный клиент, который ни чем не уступает локальному/серверному web клиенту. Если быть точным, то это буквально одно и то же решение Blazor с той лишь разницей, что серверный web клиент общается с сервером на прямую, а удалённый клиент делает то же самое, но через промежуточный MQTT сервер. Важное ограничение в том, что штатные удалённые клиенты не имеют возможности удалённо редактировать серверные настройки (для этого пригоден TelegramBot доступ).
- Локальный WEB сервер для взаимодействия с управляющими контроллерами через LAN и удалённым клиентами (TelegramBot + MQTT)
- Клиент удалённого доступа к серверу .NET MAUIBlazor Hybrid, который общается с серверной частью через любой промежуточный MQTT v5.
- Интерактивный доступ к системе через TelegramBot
- Сценарии: пакеты команд с базовой логикой ветвления по условию
- Триггеры: автозапуск сценариев/команд по событию
- Доступ к USB камерам сервера средствами решения FlashCap
Important
Сценарии и триггеры требуют тщательного тестирования. В общем механизм реализован, но для отладки этих инструментов нужна промышленная тестовая эксплуатация в реальных кейсах работы системы.
Серверная часть представляет из себя ASP.NET8 приложение (порт по умолчанию 5000) со своим собственным веб клиентом Blazor UI
.
Для Linux или Windows рекомендуется сконфигурировать работу приложения в качестве службы.
Есть рабочий пример файла демона под Linux, но вы можете сконфигурировать службу по своему усмотрению.
Клиент Telegram (по сравнению с клиентами удалённого доступа) хоть и ограничен в плане функциональности, но имеет несколько важных преимуществ.
- Удалённая настройка сервера возможна только через Telegram. Штатные удалённые клиенты как и серверная часть конфигурируют только своё персональное/локальное MQTT подключение. Для возможности удалённо настраивать серверное приложение без доступа к нему локально - потребуется доступ через Telegram.
- Отсутствуют лимиты на трафик в отличие от MQTT, где такое ограничение может быть. Например предлагаемый hivemq.cloud в бесплатной версии ограничен 10GB в месяц. Израсходовать такой MQTT лимит - сложная задача, но на такой случай Telegram доступ останется.
- Для Telegram есть возможность разграничить права для каждого клиента - персонально, в то время как штатные клиенты удалённого доступа все равны между собой и имеют одинаковый полный доступ к удалённой системе.
- Получение уведомлений от удалённой системы. Штатные клиенты удалённого доступа в этом плане пассивны. Клиент удалённого доступа не получает уведомлений пока не запущен, в то время как Телега всегда оповестит и даст возможность оперативно среагировать.
Прежде всего нужно указать токен TelegramBot и включить автозапуск. Ручной запуск/перезапуск/остановка службы TelegramBot недоступен. Для того что бы бот запустился нужно указать токен, включить автозапуск (разумеется сохранить настройки) и перезапустить серверное приложение. Бот стартует при запуске самого приложения (если включён автозапуск). Кнопка "Проверка токена" только проверяет корректность токена, но не запускает фоновую службы бота. Пока сервер бота запущен и исправно функционирует (указан правильный токен) клиентам телеги нужно что-то написать этому боту (что угодно). Бот запоминает всех пользователей, которые писали когда либо ему. Таким образом пользователи попадают в соответствующую таблицу "Пользователи. Права доступа". Обновить список пользователей можно либо кнопкой F5 (обновить страницу), либо специальной кнопкой в правом верхнем углу данной области. Имея доступ к сохранённым пользователям им можно выдавать права (или отключать их).
Для удалённого доступа клиентов к системе может быть использован Telegram, но функционал в нём не полноценный, хотя Telegram всё таки имеет некоторые преимущества в сравнении с штатными удалёнными клиентами. Помимо стандартных настроек: сервер, порт, логин и пароль существуют дополнительные:
- размер пакета (bytes max) - ограничение на максимальный размер одного сообщения MQTT
- идентификатор клиента - не для авторизации, а для персонализации логов. Серверная часть ведёт логи действий и для того что бы в этих логах можно было понять от чьего имени была выполнена та или иная команда рекомендуется каждому клиенту дать своё уникальное имя
- постоянное подключение - признак того, что подключение к MQTT должно быть запущено автоматически при старте программы
- шифрование - установка парольной фразы для шифрования всего трафика между серверной частью и удалёнными клиентами (за исключением Telegram). Каждое сообщение/пакет будет зашифровано методом AES/RFC2898 с применением вашей парольной фразы. Эта настройка должна быть одинаковой для сервера и всех её клиентов (win, android)
- префикс MQTT - имена топиков будут модифицироваться/дополняться на лету, для того что бы разные группы пользователей могли подключаться к своим удалённым серверам через один общий MQTT сервер не конфликтуя между собой. Эта настройка должна быть одинаковой для сервера и всех её клиентов.
Настройки клиента схожи с серверными. Префикс имён топиков, сервер и парольная фраза должны быть идентичными с серверными для согласованности, а логин/пароль могут быть персональными. Идентификатор клиента обязательно должен быть у каждого свой, иначе в логах будет не отличить узлы друг от друга
Приложение .NET MAUIBlazor Hybrid может быть установлено на Windows или Android устройство. Серверная часть приложения и контроллеры AbLog должны находиться в одной сети
Непосредственная работа с контроллерами выполнена через так называемую ретрансляцию HTTP/HTML. При каждом обращении к контроллеру сервером выполняется обычный HTTP запрос к контроллеру, а из ответа HTML средствами AngleSharp формируется DOM и уже с ним происходит взаимодействие. Таким образом достигается адаптивность на случай если в прошивке контроллера произойдут изменения. .
Использование шифрования трафика MQTT парольной фразой обеспечит достаточную анонимность что бы ни кто не мог увидеть данные, которые ходят между серверной частью и удалённым клиентом. В то же время: серверная часть так же как и удалённый клиент Все данные открыто хранят в своей локальной БД. Если злоумышленник получит доступ локальному диску сервера или клиента - он получит доступ в том числе и к логинам/паролям MQTT, что позволит получить полный доступ к данному программному решению. Следует иметь ввиду, что удалённый клиент хранит у себя только настройки MQTT, а всё остальное для него проходит в режиме онлайн через MQTT транспорт.
Уровни прав регулируются только для TelegramBot доступа. Для него можно отдельно разрешить разные области доступа. Что касается доступ через удалённый клиент, то разграничений по правам нет. Вы можете добавлять/удалять пользователей средствами управления аккаунтами MQTT. Технически вы можете везде (на сервере и удалённых клиентах одновременно) использовать один и тот же аккаунт MQTT, но тогда для того что бы отключить одного клиента вам придётся перенастроить и серверную часть и на всех удалённых клиентах. Если же для каждого узла использовать отдельные логин/пароль, то отключение одного отдельно взятого клиента будет проходить безболезненно. Например hivemq.cloud в бесплатной версии позволяет заводить до сотни аккаунтов на сервер.
В качестве СУБД используется SQLite. Это касается как удалённого клиента так и сервера. В то же время: удалённый клиент хранит у себя только настройки подключения к MQTT, а остальные настройки хранятся в БД серверной части.
Вы можете использовать любой MQTT сервер, в т.ч. свой собственный. Единственное требование, что бы была поддержка протокола MQTT v.5.
На данный момент бесплатный тарифный план имеет следующие ограничения:
- 100 одновременных подключений устройств к серверу.
- 10 GB трафика в месяц.
- До 3 дней хранения retention сообщений.
- 5 MB максимальный размер одного сообщения.
10 гигабайт в месяц - это довольно много, но если вдруг у вас кончится трафик, то вы можете просто удалить и заново создать сервер в личном кабинете hivemq.cloud и счётчик начнётся с нуля. В таком случае вам конечно потребуется сменить настройки сервера и удалённых клиентов. На удалённых клиентах настройки меняются только локально, а серверная часть в дополнении к локальному изменению имеет возможность менять эти настройки через Telegram.
Если у вас один единственный сервер MQTT, то по умолчанию все клиенты и сервер вместе с ними находятся в едином контуре. Т.е. имена MQTT топиков и подписки на них в рамках одного сервера будут разносить данные из разных контекстов в единую кучу. Избежать этого позволяет использование префиксов MQTT топиков. Благодаря префиксам имена топиков становятся уникальными в зависимости от рабочего контура. Таким образом разные группы пользователей могут работать не мешая друг другу.
Текущая версия решения: 4
- v1 представляла из себя сервер под Android (Xamarin), а удалённый доступ предоставлялся через TelegramBot. Проект закрыт.
- v2 приложение работало как под андроидом так и под Windows, Mac и Linux. В роли транспортного протокола использовался IMAP. Проект закрыт.
Первые две версии имели ряд критических недостатков (прежде всего из-за выбранных архитектурных решений/подходов и были окончательно закрыты). Идея хоститься на Android изначально мне очень нравилась, но надёжность хостинга в службах на этих устройствах была непредсказуема/недостаточна. У некоторых производителей Android устройств (например Xiaomi и другие китайфоны) работа OS жёстко ограничена. В погоне за максимальной производительностью службы (Foreground services) там могли быть внезапно остановлены вопреки ожидаемому поведению, которое официально задокументировано Android. Использование протокола IMAP как транспортного тоже показало свою ненадёжность в зависимости от почтового хостинга.
- v3 представляет из себя полноценное стабильное приложение. Для серверной части использовался Webassembly (client side) + Backend через REST/API. С выходом NET8 приложение было переработано под WebApp.