Создать ssh-сервер на Go можно при помощи модуля golang.org/x/crypto/ssh.

А при помощи пакета github.com/gliderlabs/ssh можно разработать ssh-сервер легко и быстро. Ssh подразумевает не только доступ к оболочке(shell), но и прочие возможности: файловый сервер(sftp), проброс портов.

README пакета gliderlabs/ssh содержит минимальный пример, выводящий строку "Hello world" любому подключенному ssh-клиенту.

Реализуем же полноценный терминальный интерфейс.

В данной статье речь пойдет про Apple HomeKit Accessory Protocol (HAP): внутренности и разработку контроллера.

Apple HomeKit создан для взаимодействия контроллера (по умолчанию iOS-устройства, приложение Home) и множества устройств(аксессуаров). Протокол открыт для некоммерческого использования, загрузить его можно с сайта Apple. На основе этой версии протокола создано несколько open-source проектов, и когда говорят про HomeKit на каком-нибуль Raspberry Pi обычно подразумевают установку homebridge и плагинов для создания совместимых аксессуаров.

Обратная же задача - создание контроллера - не такая распространенная и из проектов мне удалось найти лишь pypi.org/project/homekit/.

Поставим задачу создать контроллер, например, для управления аксессуарами с Android-телефона и попробуем ее решить. Для простоты будем работать только с IP-сетями, без Bluetooth.

Дано:

несколько gRPC-сервисов, каждый слушает свой порт.

сервисы могут доверенно подключаться друг к другу, для аутентификации используется Mutual TLS.

некоторые процедуры предназначены только для внутреннего пользования, доступ извне к ним должен быть ограничен

Найти:

единую точку входа для API (API Gateway) для gRPC, HTTP/2.

Дисклеймер: решение так и не найдено, зато проведено исследование gRPC-отражения (reflection). Много ссылок.

В 2017м году я начал писать проект на nodejs — реализацию протокола ObjectServer от Weinzierl для доступа к значениям KNX. В процессе написания было изучено: работа с бинарными протоколами, представление данных, работа с сокетами(unix sockets в частности), работа с redis базой данных и pub/sub каналами.

Проект достиг стабильной версии. В это время я потихоньку ковыряю другие языки, в частности Dart и Flutter как его приложение. На полке пылится без действия купленный во времена студенчества справочник Г.Шилдта.

Настойчивая мысль переписать проект на C поселилась в голове. Рассматриваю варианты Go, Rust, отталкивающие иными синтаксическими конструкциями. Начать никак не получается, идея откладывается на время.

В данной статье речь пойдет о реализации мобильного клиента Flutter.

Какого именно мобильного клиента?

В предыдущей публикации описана система программных аксессуаров:
bobaoskit — аксессуары, dnssd и WebSocket.

Аналог программного аксессуара — реальный объект. Лампочка, переключатель, cd/кассетный проигрыватель, радио плеер, термостат, датчик температуры, датчик движения и т.д… Набор аксессуаров определяется фантазией и программным кодом. Можно реализовать хоть шахматную доску. Для такой доски надо иметь поле управления(control) move, принимающее объект { from: "e2", to: "e4" } для примера и сервисные поля для сброса фигур и т.д… Скрипт аксессуара обработает запрос на управление полем move, примет решение можно ли перемещать фигуру, и вернет(или нет) статус с положением фигур на всем поле.

На текущий момент поддерживаемые типы аксессуаров с минимальным функционалом следующие: "switch", "temperature sensor", "thermostat", "radio player".

Про шахматы далее речи не пойдет. Если интересно и в таком случае, добро пожаловать под кат.

Таким образом я описал строение системы управляемых программных аксессуаров.

Упрощенная модель включает в себя главный процесс(bobaoskit.worker) и скрипты аксессуаров(использующие объекты bobaoskit.sdk и bobaoskit.accessory). От главного процесса идет запрос к аксессуару для контроля некоторых полей. От аксессуара, в свою очередь, идет запрос к главному на обновление статуса.

В качестве примера возьмем обычное реле.

При входящей команде реле может иногда не изменить свое положение в силу различных причин(зависло оборудование, и прочее). Соответственно, сколько мы не будет отправять команд, статус меняться не будет. И, в другой ситауции, реле может поменять свое состояние при команде от сторонней системы. Его статус в таком случае изменится, скрипт аксессуара может среагировать на входящее событие о смене статуса и отправить запрос главному процессу.

Нет предела совершенству. Казалось бы, все работало хорошо, исправлялись мелкие баги и прочее.

Сейчас я расскажу, во-первых, о проблемах, с которыми столкнулся за все время, прошедшее с момента предыдущей статьи, и, во-вторых, о решениях, которые способствовали текущему статусу проекта.

Добрый вечер всем.

Возникла задача написать свой immersive CLI на node.js. Ранее для этой цели использовал vorpal. В этот раз захотелось обойтись без лишних зависимостей и, помимо этого, рассматривал возможность по-другому принимать аргументы команд.

С vorpal команды писались следующим образом:

setValue -s 1 -v 0

Согласитесь, каждый раз писать -s — не очень удобно.

В конце концов, команда преобразовалась в следующую:

set 1: 0

Каким образом это можно реализовать — под катом

В данной публикации я покажу как с нуля настроить и запустить homebridge(реализация HomeKit Accessory Protocol на nodejs) на базе Raspberry Pi, Weinzierl KNX BAOS 838 module kBerry и bobaos.

В первой статье я рассказал о цели, сделал небольшое описание проекта. В данной публикации я расскажу о текущем положении дел и развитии проекта.

История не повторяется, история улучшается.

Цитата с пачки табака. Далее я показажу, что улучшилось за четыре месяца работы над проектом.

Если вы не знакомы с системами автоматизации и стандартом KNX, то нужную информацию можете получить в гугле или с официальных сайтов. Если же вы работаете с данным стандартом — то многие вещи вам будут понятны, и, возможно, вас, как и меня, давно интересует вопрос каким же образом можно получить доступ к физической шине KNX, минуя IP роутеры.

Далее я покажу каким образом я решил для себя эту задачу, используя Raspberry Pi и модуль KNX BAOS 838 kBerry от Weinzierl.