По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Итак, вы полностью укомплектовали и настроили ваш умный дом. И конечно, вам нравится периодически показывать выпендриваться перед друзьям, как круто включать лампы, проигрывать видео и фильмы подсказкой голосовому помощнику, приготовить кофе или регулировать термостат коснувшись приложения на экране смартфона. Поздравляем!
Но если вы любитель автоматизации (как и мы), который редко останавливается на достигнутом, то возможно будете разочарованы количеством необходимых программ, которые нужно загрузить, интерфейсов, которые вам придётся усваивать, чтобы управлять гаджетами. Скорее всего, будут отдельные приложения для управления освещением, медиацентром, термостатом и приложение Google Home, который изо всех сил (но безнадежно) старается собрать всё это воедино.
Большая вероятность того, что некоторые приложения будут несовместимы с другими и, вероятно, многие из них не будут работать, если они не в одной сети с гаджетом. Представьте если бы мы смогли управлять всем этим из одного интерфейса, на засоряя телефон или компьютер сотнями приложений, через интерфейс, который доступен как на смартфонах, так и на компьютерах, а также с помощью сторонних сценариев вне зависимости от того, находимся ли мы в одной сети с умным домом или нет. Интерфейс, который был бы легким и простым в использовании?
А что если мы будем делать это через мессенджер или чат? В конце концов, разве не легче было бы контролировать наш дом, гаджеты и облачные сервисы через тот же интерфейс, который мы используем для отправки фотографий котиков нашим друзьям, и через бот, полностью адаптированный к нашим потребностям?
В этой статье я покажу вам, как настроить команды и процедуры в дополнение к существующим сетапам умного дома. В данном руководстве мы используем два основных инструмента:
Telegram: существует много мессенджеров и платформ, но до сих пор попытки многих из них (Facebook Messenger, Whatsapp, Hangouts и т.д.) в предоставлении пригодного для разработчиков API, мягко говоря, были тщетны. Ушли те дни, когда все использовали XMPP или IRC в качестве своего мессенджер. Сегодняшний мир мессенджеров очень разнообразен.
Кроме того, поскольку в интересах многих крупных игроков создавать изолированные ИТ экосистемы, наиболее часто используемые решения не поставляются с официально поддерживаемыми API/интерфейсами разработчиков. Мало того: некоторые из них активно отговаривает пользователей от использования чего-либо, кроме официального приложения, для взаимодействия с платформой (почитайте, как Whatsapp может забанить вас).
В этом чрезвычайно разнообразном мире, состоящем из нескольких несвязанных островов, Telegram представляет собой радостное исключение: их официальный bot API хорошо задокументирован и поддерживается, и для тех, кто знает немного программирования, очень легок в интеграции.
Platypush: Platypush поставляется с плагином для Telegram и бэкэндом. Так что давайте начнем и создадим первый бот для автоматизации управления домом!
Создание Telegram-бота
Начните беседу с Botfather.
Наберите /start, а затем /newbot для создания нового бота. Задайте боту ник и имя.
Вы получите ссылку, чтобы начать беседу с вашим ботом и уникальный API-ключ. Сохраните его где-нибудь, так как он нам понадобится для конфигурации плагина platypush.
Конфигурация бота в platypush
1. Установите platypush с основными расширения и интеграцией с Telegram:
pip install 'platypush[http,db,telegram]'
apt-get install redis-server
[sudo] systemctl start redis
[sudo] systemctl enable redis
2. Изучите platypush хотя бы немного, если еще не сделали этого. Определите несколько вещей, которыми вы хотите управлять/автоматизировать - источники света, музыку, датчики, базу данных, роботы - и установите/настройте соответствующие расширения.
В этой статье мы рассмотрим, как настроить наш новый бот для управления освещением Philips Hue, воспроизведением музыки и потоковой передачей PiCamera.
3. Добавьте настройки Telegram в файл ~/.config/platypush/config.yaml:
chat.telegram:
api_token: <your bot token>
backend.chat.telegram:
enabled: true
Бэкэнд-система позволяет получать события (например, новые сообщения, вложения, запросы и т.д.) и создавать на них пользовательские "хуки". Плагин позволяет писать вам чаты, программно отправлять сообщения и вложения, администрировать каналы и т.д.
Допустим, мы хотим, чтобы бот реализовал следующие команды:
/start
Приветствие пользователя
/help
Показать доступные команды
/lights_on
Включить свет
/lights_off
Выключить свет
/music_play
Включить музыку
/music_pause
Приостановить музыку
/music_next
Перейти на следующую песню
/music_prev
Перейти на предыдущую песню
/start_streaming
Начать удаленное вещание PiCamera
/stop_streaming
Остановить удалённое вещание PiCamera
Всё что мы должны сделать это создать действие в конфигурационном файле platypush config.yaml. В этом контексте вы должны:
Установить и настроить плагины Philips Hue, mopidy и PiCamera:
pip install 'platypush[hue,mpd,picamera]'
# Hue lights configuration
light.hue:
# Hue bridge IP address
bridge: 192.168.1.10
# Default groups to control
groups:
- Living Room
# MPD/Mopidy configuration
music.mpd:
host: localhost
port: 6600
# PiCamera configuration
camera.pi:
vflip: False
hflip: False
Чтобы не засорять файл config.yaml, создайте новый файл с названием ~/.config/platypush/include/bot.yaml:
# /start command handler
event.hook.OnTelegramStartCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: start
then:
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Welcome! Type /help to see the available commands"
# /help command handler
event.hook.OnTelegramHelpCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: help
then:
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Available commands:
- /lights_on
- /lights_off
- /music_play [resource]
- /music_pause
- /music_prev
- /music_next
- /start_streaming
- /stop_streaming
"
# /lights_on command handler
event.hook.OnTelegramLightsOnCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: lights_on
then:
- action: light.hue.on
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Lights turned on"
# /lights_off command handler
event.hook.OnTelegramLightsOffCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: lights_off
then:
- action: light.hue.off
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Lights turned off"
# /music_play command handler
event.hook.OnTelegramMusicPlayCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: music_play
then:
- if ${cmdargs}:
- action: music.mpd.play
args:
resource: cmdargs[0]
- else:
- action: music.mpd.play
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Music playing"
# /music_pause command handler
event.hook.OnTelegramMusicPauseCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: music_pause
then:
- action: music.mpd.pause
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Music paused"
# /music_prev command handler
event.hook.OnTelegramMusicPrevCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: music_prev
then:
- action: music.mpd.previous
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Playing previous track"
# /music_next command handler
event.hook.OnTelegramMusicNextCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: music_next
then:
- action: music.mpd.next
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "Playing next track"
# /start_streaming command handler
event.hook.OnTelegramCameraStartStreamingCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: start_streaming
then:
- action: camera.pi.start_streaming
args:
listen_port: 2222
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "PiCamera streaming started. Check it out with vlc tcp/h264://hostname:2222"
# /stop_streaming command handler
event.hook.OnTelegramCameraStopStreamingCmd:
if:
type: platypush.message.event.chat.telegram.CommandMessageEvent
command: stop_streaming
then:
- action: camera.pi.stop_streaming
- action: chat.telegram.send_message
args:
chat_id: ${chat_id}
text: "PiCamera streaming stopped"
Подключите файл конфигурации бота в config.yaml:
include:
-include/bot.yaml
Запустите platypush:
# Manual start
platypush
# Service start
systemctl start platypush.service
Создайте беседу в вашим ботом перейдя по ссылке, выданной BotFather и начните говорить ему, что делать:
Сейчас бот доступен любому мы этого явно не хотим. Представьте, что кто-то включит на полную громкость System Of A Down- Jet Pilot вам ночью. Так себе пробуждение. Можно настроить бэкэнд Telegram так, чтобы он принимал сообщения только из определенного списка идентификаторов чатов (в Telegram chat_id используется как для частных пользователей, так и для групп).
Отправьте сообщение боту и откройте журналы platypush или проверьте его стандартные выходные данные. На экране появятся следующие сообщения:
2020-01-03 19:09:32,701| INFO|platypush|Received event: {"type": "event", "target": "turing", "origin": "turing", "id": "***", "args": {"type": "platypush.message.event.chat.telegram.CommandMessageEvent", "chat_id": your_chat_id, "message": {"text": "/help", ...}, "user": {"user_id": your_user_id, "username": "****", "is_bot": false, "link": "https://t.me/you", "language_code": "en", "first_name": "***", "last_name": "***"}, "command": "help", "cmdargs": []}}
Скопируйте chat_id своего пользователя и вставьте в бак-энд файл:
backend.chat.telegram:
authorized_chat_ids:
- your_user_id
Теперь бот ответит ошибкой, если вы попытаетесь отправить сообщение от неавторизованного пользователя.
Вы также можете пригласить своего бота в групповой чат и позволить вашим друзьям или членам семьи регулировать свет в вашем доме, если вы захотите!
Что дальше?
В этой статье мы изучили только одну специфическую особенность интеграции Telegram - способность бота реагировать на события в команде, запускать действия и отвечать текстовыми сообщениями.
Как видно из списка поддерживаемых событий Telegram, можно сделать больше, например:
Создавать обработчики, когда кто-то делится контактной информацией - когда-нибудь думали разрешить боту автоматически хранить новые контакты, отправленные вам вашими друзьями в чате?
Создавайте обработчики при совместном использовании документов, видео или изображения - например, автоматически загружайте все файлы мультимедиа, отправленные в чат, на жесткий диск или удаленную папку Dropbox.
Выполнять действия с текстовыми сообщениями вместо команд - можно использовать TextNewsEvent, например, если вы предпочитаете вводить "включить свет" вместо "/lights_on."
Сделайте снимок на камеру наблюдения и отправьте ее себе командой send_photo. Можно также развернуть несколько ботов, например, для каждого устройства, чтобы можно было запускать действия на конкретном устройстве из связанного чата или вместо этого использовать один бот в качестве точки входа и доставлять сообщения другим устройствам через MQTT, Kafka или HTTP API.
Формат файла ZIP уменьшает размер файлов, сжимая их в один файл. Этот процесс экономит дисковое пространство, шифрует данные и позволяет легко обмениваться файлами с другими. Вот как можно сжать и разархивировать файлы с помощью PowerShell.
Как архивировать файлы с помощью PowerShell
Начнем с сжатия некоторых файлов в ZIP-архив с помощью командлета Compress-Archive. Он берет путь к любым файлам, которые вы хотите сжать - несколько файлов разделяются запятой - и архивирует их в указанном месте назначения.
Сначала откройте PowerShell, выполнив поиск в меню «Пуск», а затем введите следующую команду, заменив PathToFiles и PathToDestination на путь к файлам, которые вы хотите сжать, а также на имя и папку, в которую вы хотите перейти, соответственно:
Compress-Archive -LiteralPath <PathToFiles> -DestinationPath <PathToDestination>
Когда вы указываете путь назначения, обязательно укажите имя файла архива, иначе PowerShell сохранит его как .zip.
Примечание. Кавычки вокруг пути необходимы только в том случае, если путь к файлу содержит пробел.
В качестве альтернативы, чтобы сжать все содержимое папки и все ее подпапки, вы можете использовать следующую команду, заменив PathToFolder и PathToDestination на путь к файлам, которые вы хотите сжать, а также на имя и папку, которую вы хотите. чтобы перейти соответственно:
Compress-Archive -LiteralPath <PathToFolder> -DestinationPath <PathToDestination>
В предыдущем примере мы указали путь к каталогу с несколькими файлами и папками без указания отдельных файлов. PowerShell берет все внутри корневого каталога и сжимает его, а также все подпапки.
Командлет Compress-Archive позволяет использовать подстановочный знак (*) для дальнейшего расширения функциональности. При использовании символа вы можете исключить корневой каталог, сжать только файлы в каталоге или выбрать все файлы определенного типа. Чтобы использовать подстановочный знак с Compress-Archive, вы должны использовать вместо этого параметр -Path, так как -LiteralPath не принимает их.
Выше мы рассмотрели, как включить корневой каталог и все его файлы и подкаталоги при создании архивного файла. Однако, если вы хотите исключить корневую папку из Zip-файла, вы можете использовать подстановочный знак, чтобы исключить ее из архива. Добавляя звездочку (*) в конец пути к файлу, вы указываете PowerShell только захватить то, что находится внутри корневого каталога. Это должно выглядеть примерно так:
Compress-Archive -Path C:path ofile* -DestinationPath C:path oarchive.zip
Далее, скажем, у вас есть папка с кучей файлов разных типов (.doc, .txt, .jpg и так далее), Но вы хотите сжать только один тип. Вы можете указать PowerShell архивировать их, не затрагивая явно. Обозначение команды будет выглядеть так:
Compress-Archive -Path C:path ofile*.jpg -DestinationPath C:path oarchive.zip
Примечание. Подкаталоги и файлы корневой папки не включаются в архив этим методом.
Наконец, если вам нужен архив, который сжимает файлы только в корневом каталоге и во всех его подкаталогах, вы должны использовать подстановочный знак «звезда-точка-звезда» (*. *) Для их сжатия. Это будет выглядеть примерно так:
Compress-Archive -Path C:path ofile*.* -DestinationPath C:path oarchive.zip
Примечание. Подкаталоги и файлы корневой папки не включаются в архив этим методом.
Даже после завершения архивирования вы можете обновить существующий заархивированный файл с помощью параметра -Update. Это позволяет заменять старые версии файлов в архиве новыми версиями с такими же именами и добавлять файлы, созданные в корневом каталоге. Это будет выглядеть примерно так:
Compress-Archive -Path C:path ofiles -Update -DestinationPath C:path oarchive.zip
Как распаковать файлы с помощью PowerShell
Помимо возможности архивировать файлы и папки, PowerShell имеет возможность разархивировать архивы. Процесс даже проще, чем их сжатие; все, что вам нужно, это исходный файл и место для данных, готовых к распаковке.
Откройте PowerShell и введите следующую команду, заменив PathToZipFile и PathToDestination на путь к файлам, которые вы хотите сжать, а также на имя и папку, в которую вы хотите перейти, соответственно:
Expand-Archive -LiteralPath <PathToZipFile> -DestinationPath <PathToDestination>
Папка назначения, указанная для извлечения файлов, будет заполнена содержимым архива. Если папка не существовала до разархивирования, PowerShell создаст папку и поместит содержимое в нее перед разархивированием.
По умолчанию, если вы пропустите параметр -DestinationPath, PowerShell разархивирует содержимое в текущий корневой каталог и использует имя файла Zip для создания новой папки.
В предыдущем примере, если мы опускаем -DestinationPath, PowerShell создаст папку «Архив» по пути C:Usersuser и извлечет файлы из архива в папку.
Если папка уже существует в месте назначения, PowerShell выдаст ошибку при попытке разархивировать файлы. Однако вы можете заставить PowerShell перезаписывать данные новыми, используя параметр -Force.
Вы должны использовать параметр -Force только в том случае, если старые файлы больше не нужны, поскольку это необратимо заменит файлы на вашем компьютере.
Создание единого устройства обработки пакетов - маршрутизатор (или коммутатор уровня 3, который теперь обычно называют просто коммутатором), являющийся наиболее распространенным примером, был до этого момента в центре внимания. Пришло время соединить маршрутизаторы вместе. Рассмотрим сеть на рисунке 1.
Приложение, работающее на хосте A, должно получить некоторую информацию от процесса, запущенного на F. Устройства B, C, D и E, конечно же, являются обработчиками пакетов (маршрутизаторами). Для пересылки пакетов между хостами A и F маршрутизатор B будет вызван для пересылки пакетов на F, даже если он не подключен к F. аналогично маршрутизаторам C и D потребуется пересылать пакеты как A, так и F, даже если они не подключены ни к одному из этих хостов.
В том разделе рассматривается следующий вопрос:
Как сетевые устройства создают таблицы, необходимые для пересылки пакетов по свободным от петель путям в сети?
Ответ гораздо сложнее, чем может показаться на первый взгляд, поскольку на самом деле в нем содержится несколько проблем:
Как устройства узнают о топологии сети, какие каналы связи подключены к каким устройствам и назначениям.
Как плоскости управления принимают эту информацию и создают в сети пути без петель?
Как плоскости управления обнаруживают изменения в сети и реагируют на них?
Каким образом уровни управления масштабируются для удовлетворения потребностей крупномасштабных сетей?
Какие политики реализованы на уровне управления и как?
Все эти проблемы будут рассмотрены далее.
Обнаружение топологии
Сетевые диаграммы обычно показывают всего несколько типов устройств, включая маршрутизаторы, коммутаторы, системы, подключенные к сети (различные типы хостов) и различные типы устройств (например, межсетевые экраны). Они часто связаны между собой каналами, представленными в виде линий. Пример представлен на рисунке 2.
Сетевые диаграммы, как и многие другие формы абстракции, скрывают много информации, чтобы сделать встроенную информацию более доступной. Во-первых, сетевые диаграммы обычно находятся где-то между логическим и физическим представлением сети. Такие диаграммы обычно не показывают каждое физическое соединение в сети. Например, сетевая диаграмма может показывать связку каналов как одну линию связи или один физический провод, который был мультиплексирован как несколько логических каналов (например, Ethernet или какой-либо другой канал широковещательной передачи, который представляет собой один физический канал, используемый несколькими устройства для связи).
Примечание В сетевой инженерии часто возникает некоторая путаница с термином мультиплексирование. Многие инженеры склонны рассматривать совместное использование двух виртуальных каналов как единственную форму сетевого мультиплексирования. Однако всякий раз, когда есть несколько устройств, совместно использующих одну линию связи, ситуация, в конечном счете требующая некоторой формы адресации, временного разделения трафика или частотного разделения трафика, используется мультиплексирование. Виртуализацию можно рассматривать как второй уровень мультиплексирования или мультиплексирование поверх мультиплексирования.
Во-вторых, сетевые схемы часто не учитывают логическую сложность сервисов. Однако плоскость управления не маскирует такого рода сложности.
Вместо этого плоскость управления должна собирать информацию о сети локально и с других плоскостей управления, объявлять ее другим устройствам, на которых работает плоскость управления, и создавать набор таблиц, которые плоскость данных может использовать для пересылки трафика через каждое устройство в сети от источника к месту назначения. В этой статье мы рассмотрим проблему:
Как плоскость управления узнает о сети?
Этот вопрос можно разбить на несколько частей:
О чем пытается узнать плоскость управления? Или, возможно, каковы компоненты топологии сети?
Как плоскость управления узнает об устройствах, подключенных к сети?
Какие основные классификации используются при описании объявления информации о сети?
Узлы сети, границы и достижимый пункт назначения.
Первая проблема, которую необходимо решить, на самом деле является мета-вопросом: какие виды информации должна изучать и распространять плоскость управления, чтобы строить пути без петель в сети? Однако небольшое предупреждение по поводу следующего материала статьи: сетевые термины трудно однозначно определить, поскольку отдельные термины часто используются для описания множества "вещей" в сети, в зависимости от контекста, в котором они используются.
Узел
Узел либо обрабатывает пакеты (включая пересылку пакетов), либо отправляет пакеты, либо принимает пакеты в сети. Термин взят из теории графов, где их также можно назвать вершинами, хотя этот термин более широко применяется в сетевой инженерии. В сети есть несколько типов узлов, в том числе:
Транзитный узел: любое устройство, предназначенное для приема пакетов на одном интерфейсе, их обработки и отправки на другом интерфейсе. Примерами транзитных узлов являются маршрутизаторы и коммутаторы. Их часто просто называют узлами, так они будут именоваться здесь в статье, а не транзитными узлами.
Конечный узел: также называется конечной системой или хостом: любое устройство, предназначенное для запуска приложений, которые генерируют и/или принимают пакеты от одного или нескольких интерфейсов. Это сетевые источники и приемники, чаще всего эти узлы на самом деле называются хостами, а не конечными узлами, чтобы отличать их от shorthand узлов, что обычно означает транзитный узел.
В этих двух определениях есть много очевидных дыр. Как должно называться устройство, которое принимает пакет на одном интерфейсе, завершает соединение в локальном процессе или приложении, генерирует новый пакет, а затем передает этот новый пакет из другого интерфейса? Проблема усложняется, если информация, содержащаяся в двух пакетах, примерно одинакова, как в случае с прокси-сервером или каким-либо другим подобным устройством. В этих случаях полезно классифицировать устройство как конечное или узел в определенном контексте, в зависимости от роли, которую оно играет по отношению к другим устройствам в контексте. Например, с точки зрения хоста прокси-сервер действует как устройство сетевой переадресации, поскольку работа прокси-сервера (в некоторой степени) прозрачна для хоста. Однако с точки зрения соседнего узла прокси-серверы являются хостами, поскольку они завершают потоки трафика и (как правило) участвуют в плоскости управления так же, как и хост.
Граница (край)
Граница - это любое соединение между двумя сетевыми устройствами, через которое пересылаются пакеты. Номинальный случай - соединение точка-точка (point-to-point), соединяющее два маршрутизатора, но это не единственный случай. В теории графов ребро соединяет ровно два узла. В сетевой инженерии существуют понятия мультиплексированных, многоточечных и других типов мультиплексированных каналов. Чаще всего они моделируются как набор соединений point-to-point, особенно при построении набора маршрутов без петель в сети. Однако на сетевых диаграммах мультиплексированные каналы часто изображаются как одна линия с несколькими присоединенными узлами.
Достижимый пункт назначения
Достижимый пункт назначения может описывать один узел или службу, или набор узлов или служб, доступных через сеть. Номинальным примером достижимого пункта назначения является либо хост, либо набор хостов в подсети, но важно помнить, что этот термин может также описывать службу в некоторых контекстах, таких как конкретный процесс, запущенный на одном устройстве, или множество вариантов службы, доступных на нескольких устройствах. Рисунок 3 иллюстрирует это.
В сети, показанной на рисунке 3, достижимые пункты назначения могут включать:
Любой из отдельных хостов, например A, D, F, G и H
Любой из отдельных узлов, например B, C или E
Служба или процесс, работающий на одном хосте, например S2.
Служба или процесс, работающий на нескольких хостах, например S1.
Набор устройств, подключенных к одному физическому каналу или границе, например F, G и H
Этот последний достижимый пункт назначения также представлен как интерфейс на конкретном канале или на границе сети. Следовательно, маршрутизатор E может иметь несколько достижимых пунктов назначения, включая:
Интерфейс на линии, соединяющей маршрутизатор E с C
Интерфейс на линии, соединяющей маршрутизатор E с B
Интерфейс на линии, соединяющей маршрутизатор E с хостами F, G и H
Сеть, представляющая достижимость для хостов F, G и H
Любое количество внутренних служб, которые могут быть объявлены как отдельные адреса, порты или номера протоколов
Любое количество внутренних адресов, присоединенных к виртуальным каналам связи, которые не существуют в физической сети, но могут использоваться для представления внутреннего состояния устройства (не показано на рисунке3)
Таким образом, концепция достижимого пункта назначения может означать множество разных вещей в зависимости от контекста. В большинстве сетей достижимый пункт назначения - это либо одиночный хост, одиночный канал (и хосты, подключенные к нему), либо набор каналов (и хосты, прикрепленные к этим каналам), объединенные в один достижимый пункт назначения.
Теперь, почитайте материал про топологию сетей.