Антон Лаудэр

про информационные технологии и личную эффективность

Не могу соединиться с базой данных

Сравниваю парусный спорт и бизнес

Делюсь впечатлениями от участия в парусной регате ⛵ Рассказываю какие уроки я извлек и провожу аналогию с бизнесом.

Этим летом в Краснодаре я познакомился с компанией предпринимателей «Эволюция», которые близки мне по духу. Мы общаемся, отдыхаем вместе и учимся друг у друга. Мы часто делаем то, что никогда раньше не делали. На этот раз мы устроили парусную регату — гонки на спортивных яхтах.

Регата проходила на озере в «Абрау Дюрсо». Это очень красивое место, которое напоминало мне Швейцарскую деревню. В день соревнований дул сильный порывистый ветер, что добавляло адреналина. Мы разбились на команды по 5 человек. В каждой команде был опытный капитан и 4 новичка таких, как я.

На вводном инструктаже я ничего не понял. Правил и понятий слишком много, запомнить сложно. Я запомнил только, что «травить» — означает приотпускать веревку, а «добирать» — натягивать. С этими знаниями я отправился к яхте.

Виталий, наш капитан, распределил роли в команде. Мне досталось управление стакселем и генакером. В первые 2 гонки я тянул веревки по команде капитана, не понимая что происходит. В первой гонке я не даже не понял где финиш и путал команды. Но к третьей гонке я втянулся и начал получать от процесса удовольствие.

Мне понравилось, что в парусном спорте всё сбалансированно: красота, азарт, сила ума, тела, и командная работа. Всё как в бизнесе.

1. Всё зависит от ветра Если ветра нет, то любые действия бесполезны. Можно поднять парус или опустить — яхта будет стоять на месте. В бизнесе ветер — это наше внутреннее состояние и состояние рынка. Если внутреннее состояние на нуле — действия не приносят результата. Если на рынке спроса нет — реклама не принесет результата. Но когда ветер придет, нужно быть готовым к нему: мобилизоваться, сфокусироваться, действовать быстро.
2. Всё зависит от команды Если кто-то из команды запутался или упустил момент, то усилия всей команды будут бесполезны. Важно чувствовать друг друга и поддерживать.
3. Всё зависит от умения быть в моменте Когда я бегаю, я могу отвлечься и поразмышлять о чем-то. Но на яхте так не получится. Стоит подумать о чем-то другом, тут же делаешь ошибки или упускаешь важные действия. А если не уследить за ветром, то можно получить гиком по голове. Яхтинг, как и бизнес, полностью отключает мысли от внешнего мира. Учит находится только здесь и сейчас.
4. Всё зависит от капитана Наш капитан был сильным лидером. Он тренируется с детства и знает о яхтах всё. Благодаря нему у нас получилось выиграть гонку. Я хочу быть таким же сильным и опытным капитаном в своем бизнесе.

До регаты я не понимал почему у этого спорта так много поклонников, а теперь я с вами!

Три типа MVP

MVP — минимальный полезный продукт. MVP делается для того, чтобы понять будет ли востребован продукт или новая фича продукта, не тратя на это много ресурсов. Ранее я думал, что для продукта создается только 1 вид MVP в зависимости от вида продукта. Например, лэндинг делается для услуг. А для собачьего ошейника MVP — это сделанный вручную макет.

Курс Digital Product Management внёс ясность. Для продукта должны быть сделаны 3 вида MVP. У каждого своя задача.

Concierge (Консьерж) MVP — Лэндинг, ролик, презентация. Выясняем как клиент решает проблему сейчас и демонстрируем новое решение.
Wizard of OZ (Волшебник страны ОЗ) MVP — Этот MVP уже можно потрогать. Он напоминает конечный продукт, но не использует сложных технологий. Используется для изучения поведения клиентов. Можно дать клиенту в руки и посмотреть что он будет делать с ним, как пользоваться, сколько раз в день.
Sales MVP — Позволяет понять как клиент будет вести себя при покупке. Пробуем продавать клиенту по разным каналам. Это может быть кнопка предзаказа на сайте или живая презентация.

Делюсь инсайтами из курса Digital Product Management by University of Virginia

Роль менеджера продукта

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

Тема простая. Но если глянуть в вакансии на HH, то видно какая каша в требованиях к менеджерам проектов и менеджерам продуктов. Менеджер проекта в некоторых компаниях тестирует гипотезы, а менеджер продукта работает с MS Project. Хотя эти занятия сложно уживаются рядом. А значит будут сложности. Зная своё место, можно с самого начала построить правильные отношения с коллегами и сильно упростить жизнь себе и другим.

В идеальном мире менеджер продукта выдает в отдел маркетинга и продаж Product-Market Fit (или еще говорят Habbit-Market Fit). То-есть рабочий и востребованный рынком продукт, который легко продавать и масштабировать.

Инструменты менеджера продукта

У менеджера продукта очень большой инструментарий: Lean Startup, Design Thinking, HADI, AIDOOR, HOOK и другие. Без этих инструментов создать продукт будет сложно. Важно научиться применять эти инструменты правильно и в нужный момент. Прослушивание курса и экзамены помогли мне навести порядок в голове и разложить все инструменты по полочкам.

Я впервые узнал о методике HOOK. И очень жаль, потому что упустил много важного при разработке моего первого продукта — Сервисфона. Самый сложный этап при внедрении продукта — формирование новых привычек у пользователей. Например, в Сервисфоне важно, чтобы пользователи вносили в систему данные о звонках. Если этого не делать, то пользы от продукта не будет. Если сотрудники автосервиса в первый месяц не привыкли вносить данные, то мы теряем клиента. Заставить — нельзя, можно только мотивировать. Подробнее с основными тезисами HOOK можно ознакомиться тут.

Как я проектировал систему охраны для коттеджного поселка

На рынке охранных систем очень много решений, но ниша современных беспроводных охранных сигнализаций показалась мне свободной. Отечественные производители предлагают устройства из 80-х годов: огромные короба с микросхемами, отсутствие современных интерфейсов и сложные настройки. Менеджеры по продажам в крупных интернет-магазинах не могут разобраться с функциональностью и подсказать нужное решение.

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

Задача

Со слов заказчика:

У нас тут есть 5 соседних домов (мой и ближайшие соседи) в каждом должна быть одна или две тревожных кнопки (на радиоканале), световая сигнализация на фасаде, и выход на ревун (можно один общий, на все дома). Для чего — в случае чрезвычайной ситуации жилец дома нажимает тревожную кнопку, соседи должны иметь возможность определить, в каком доме ЧС и прийти на помощь. Также нужно установить объемный датчик в одной комнате (в двух домах), с выходом по радиоканалу (на что выход — телефон, сирена какая то, пока не определились).

Я начал со структуры требований. Разбил требования на пункты и пронумеровал.

Список требований

Требования, которые вытекают из условий задачи:
Т1. В каждом доме 1-2 тревожные кнопки на радиоканале.
Т2. Световая индикация на фасаде.
Т3. Ревун общий или один на всех.
Т4. Соседи должны определить в каком доме ЧС.
Т5. Датчик объема в двух домах с выходом по радиоканалу.
Т6. Выход на телефон (GSM).

В ходе проектирования были добавлены еще 2 требования:
Т7. Децентрализация. Если связь с главным узлом потеряна, это не должно приводить к отключению всей системы.
Т8. Если отключение тревоги проходит под принуждением, то необходимо оповестить об этом соседей.

Какие решения есть на рынке?

Я погуглил и прочитал форумы. Задал вопросы специалистам. Позвонил в компании, которые занимаются системами охраны.

Вот системы которые я рассматривал:
— Стрелец
— Болид
— Альтоника
— Астра
— Jablotron
— Visonic
— AJAX
— Лунь

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

Примеры решений

Стрелец-ПРО
Недостатки: Если отключить главный пульт, то система работать не будет. В главном доме при моей конфигурации не будет работать режим “снятие под принуждением”. Стоимость более 170 тыс. руб. Это без GSM модуля. Кроме того, с наличием на складах сейчас есть проблемы, потому что система поставляется в новые больницы.

Наименование Цена
РР-И-ПРО, (БЕЗ АКБ ) Контроллер радиоканальных устройств Стрелец-ПРО 12 942
Пульт-РР-ПРО, Пульт управления сегментом 10 780
РР-ПРО, (БЕЗ АКБ) Контроллер радиоканальных устройств 6 230
БПИ RS-И, Блок преобразования интерфейсов 5 578
БП-12/0,5 Блок бесперебойного питания с АКБ 2,2 А/ч 4 533
Пульт-ПРО, Пульт управления 5 678
Брелок-ПРО, радиобрелок управления. 2 823
Икар-ПРО, охранный извещатель объемный оптико-электронный 2 648
Маяк-12К, Комбинированный оповещатель 486

Альтоника 201
Преимущества в том, что все дома могут быть автономны. Впечатляет дальность действия радиоканала — до 5 км! Есть и GSM модуль, но он не влезает в коробку (для него нужен отдельный корпус). Меня смутило то, что я не понимал как можно интегрироваться с этой системой. Что если мне нужно сделать 5 звонков на мобильные в случае тревоги? Как я это реализую? Стоимость решения более 180 тыс.

Наименование Количество Цена Сумма
РИФ-ОП4(RS-201TDm) 5 10 880 54 400
RS-201R20, Приемник групповой Риф Стринг 5 12 170 60 850
RS-201TK2, Тревожная радиокнопка 10 3 070 30 700
Риф-КТМ-N, Выносная клавиатура 5 2 420 12 100
РАПАН-20ПББП,368,Источник питания 5 700 3 500
АКБ-7-12, Аккумулятор12В, 7Ач 5 680 3 400
АК-433, Антенна круговой направленности 5 3 690 18 450
Маяк-12К, Комбинированный оповещатель 1 486 486
183 887

Астра
Общая стоимость более 60 тыс. руб. без GSM-модуля. Решение мне понравилось. Только не понял что будет если отключить главный пульт? И смогу ли я получить сигнал тревоги, например, на одноплатный компьютер чтобы реализовать свой сценарий? Позвонил в несколько компаний, но ответы на эти вопросы получить не смог.

Астра-812 Pro Прибор приемно-контрольный с встроенной клавиатурой и радиомодулем
Наименование Цена Количество Сумма
Астра-812 Pro 7 761 1 7 761
Астра-РИ-М РР 2 400 5 12 000
Астра-3221 1 312 5 6 560
Астра-РИ-М РПДК (ИО 10110-1) 1 062 5 5 310
Астра-8131 2 809 4 11 236
Астра-712/0 исп. 2А 2 427 5 12 135
Маяк-12-К 486 5 2 430
Астра-5121 1 767 2 3 534
60 966

AJAX
В процессе поиска наткнулся на интересный проект — AJAX. Мне понравился сайт компании. Описание устройств на доступном для потребителя языке. Написал в чат, задал вопросы и сразу получил ответы.
Сделал заказ. Со мной связался менеджер, к сожалению, технически не подкованный. На вопросы он ответить не смог, скидку делать отказался. Зато пытался делать мне Upsale, не разобравшись в моей проблеме. И это немного раздражало.

Из минусов:
— Нет открытого API, интеграции с MQTT или любым протоколом для умного дома. Нельзя, например получить сигнал тревоги и реализовать свой сценарий. Это есть в планах развития, но непонятно когда будет реализовано.
— Хабы (центральные узлы системы) нельзя связать между собой. В моём случае, если поставить во все дома по хабу, то нельзя будет передать сигнал тревоги на хаб соседа.
— Ретрансляторы связаны с хабом через слабый радиоканал (используется радиомодуль RFM69). Заявлена дальность до 2 км, но по факту можно надеяться лишь 100-200 метров.
— Ретрансляторы не связаны друг с другом. Только с хабом. Нельзя поставить два ретранслятора подряд, чтобы увеличить дальность покрытия.

Плюсы:
— Впечатляют заявленные характеристики надежности (ниже подробнее расписал). Особенно резервирование: 2 GSM модуля и Lan из коробки.
— Начинка устройств современная, и есть система автообновления прошивки.
— Встроенные ИБП. Не нужно монтировать отдельный короб для аккумулятора.
— Наличие мобильного приложения и даже приложение для MacOS. Хотя, я уже приготовился работать с COM-портами, глючными Windows-программами и всем чем угодно.
— Дизайн. Легко впишется в любой интерьер.

Надежность системы
— Система имеет 4 канала связи: радиоканал, интернет и 2 GSM модуля. В случае недоступности одного из каналов используется резервный. GSM используется для уведомления соседей (помимо сирены и мобильного приложения). Если недоступна основная сим-карта, звонок и SMS будут отправлены через резервную сим-карту.
— Хабы и ретрансляторы имеют резервное питание на 35 часов.
— Датчики и извещатели работают по радиоканалу и питаются от батарей. Срок службы батареи — 2 года. Уведомление о необходимости замены батарей будет направлено через мобильное приложение.
— В случае выхода из строя центрального хаба, ретранслятор берет на себя функцию управления датчиками и извещателями.
— Система распознает глушение радиоканала и использует хоппинг частот. Если одна частота занята, будет использована резервная.
— Система распознает повреждение корпуса, демонтаж хаба или ретранслятора (в корпус встроен акселерометр).

Наименование Количество Цена Сумма
Центральный контроллер (Хаб) 1 13 750 13 750
Ретранслятор 4 5 018 20 070
Датчик объема 2 4 470 8 940
Свето-звуковой индикатор уличный 5 5 590 27 950
Карманный брелок 5 1 350 6 750
Настенная сенсорная клавиатура 5 4 250 21 250
98 710

Схема расположения оборудования

Ретрансляторы желательно расположить в прямой видимости хаба. С этим могут быть проблемы, но у нас должно получится. Датчики и извещатели очень простые в плане монтажа. Не требуют ни питания, ни проводов. Прикрутил отверткой пару шурупов и готово.

Выводы
Пока об опыте эксплуатации говорить рано, напишу об этом позже. На подбор оборудования и проектирование системы у меня ушло 4 дня. Меня удивило, что на рынке так мало современных решений. Вот вам свободная ниша для IoT стартапа — бери и делай.

Хорошая подборка книг и курсов для бизнес-аналитика

BABOK (Для понимания границ бизнес-анализа)
Карл Вигерс. Разработка требований к программному обеспечению
Alistair Cockburn. Writing Effective Use Cases
Mike Cohn. User Stories Applied: For Agile Software Development
Scrum Guide

Еще список книг: http://systems.education/books

Онлайн-курсы

Разработка ПО
https://www.coursera.org/specializations/product-management
https://www.coursera.org/specializations/software-development-lifecycle
https://www.coursera.org/specializations/agile-development
https://www.coursera.org/specializations/software-design-architecture
Базовые знания о стратегическом анализе и бизнес-требованиях
https://www.linkedin.com/learning/paths/become-a-business-analyst
https://www.udemy.com/business-analysis-ba/
Курс от mail.ru «Постановка задачи на разработку ПО»: https://stepik.org/course/1128/promo
Agile
https://www.linkedin.com/learning/agile-requirements-foundations
https://www.linkedin.com/learning/cert-prep-agile-analysis-iiba-aac
Требования
https://www.coursera.org/specializations/requirements-engineering-secure-software
https://www.coursera.org/learn/client-needs-and-software-requirements
https://www.linkedin.com/learning/requirements-elicitation-and-analysis
https://www.udemy.com/developing-requirements/
Use Case
https://www.udemy.com/course/usecases/
Техники моделирования
https://www.udemy.com/visual-modeling-master-class/

Полезные интернет-ресурсы

https://www.iiba.org/
https://www.bridging-the-gap.com
https://www.modernanalyst.com/Home.aspx
https://www.batimes.com/
https://businessanalystlearnings.com/
https://www.ba-cube.com/
http://analyst.by/

procd — контроль процессов для OpenWrt

На нескольких устройствах, которые я использую в умном доме, установлены одноплатные компьютеры Onion Omega2. Это что-то между Raspberry Pi и ESP8266. Компьютер стоимостью 10$ на базе MIPS-процессора с Linux, Wi-Fi, Ethernet, UART, ШИМ, I2C, SPI, USB и GPIO. Классная игрушка!
Операционная система омеги базируется на OpenWrt, поэтому можно использовать много популярных библиотек, например Python. Только вот нет привычного менеджера процессов systemd. Я где-то читал, что команда создателей OpenWrt работает над интеграцией systemd, но по срокам пока ничего не известно.

Зато есть procd — родной для OpenWrt менеджер процессов. Он позволяет следить за процессами и перезапускать их в случае сбоев.
Для настройки сервиса достаточно создать файл в /etc/init.d/

Пример файла:

#!/bin/sh /etc/rc.common
USE_PROCD=1
START=98
STOP=1

start_service() {
	procd_open_instance
	procd_set_param respawn ${respawn_threshold:-3600} ${respawn_timeout:-5} ${respawn_retry:-5}
	procd_set_param command /root/relay/controller.py
	procd_set_param stdout 1 # forward stdout of the command to logd
	procd_set_param stderr 1 # same for stderr
	procd_close_instance
}

Что тут важно:
параметр /root/relay/controller.py — это путь к нашему скрипту Python
параметр respawn — если процесс завершился раньше чем respawn_threshold, то это считается сбоем. И после respawn_retry попыток сервис останавливается.

Последовательность действий:

  1. Создаем скрипт запуска:
nano /etc/init.d/controller
  1. Устанавливаем права на запуск скрипта:
chmod +x /etc/init.d/controller
  1. Добавляем сервис в автозапуск при перезагрузке:
/etc/init.d/controller enable
  1. Запускаем сервис:
/etc/init.d/controller start

Для проверки можем убить процесс. Например, так: killall controller.py
procd сразу же его перезапустит.

Работа с очередью MQTT в Python

Заметка для начинающих. Хочу показать пример работы с MQTT на Python.
Я использую MQTT в реле, которое управляет световыми приборами в доме. Реле подписывается на топик и ждет команды. В зависимости от поступившей команды, реле подает напряжение на приборы.

Импортируем класс и создаем инстанс

Тут я сразу создаю флажок connected_flag. Он мне будет нужен для работы с коллбэками.

import paho.mqtt.client as mqtt

mqttc = mqtt.Client('relay_listener')
mqttc.on_message = on_message
mqttc.on_connect = on_connect
mqttc.on_disconnect = on_disconnect
mqttc.on_publish = on_publish
mqttc.on_subscribe = on_subscribe
# Uncomment to enable debug messages
#mqttc.on_log = on_log
# Признак успешного соединения
mqttc.connected_flag=False

Подключаемся к серверу

Теперь самое интересное. Я использую loop_start() для того, чтобы mqtt клиент начал делать попытки подключения. Как только подключение установится, сработает событие on_connect, в котором я поставлю флажок connected_flag.

Первая распространенная ошибка — делать только одну попытку подключения. Нет никакой гарантии что связь с сервером будет в момент первой попытки соединения. Мы же работаем с «домашним» сетевым оборудованием. В итоге скрипт периодически будет вылетать с ошибкой при запуске и заметим мы это не сразу.

Сразу после loop_stop() я снимаю флаг mqttc._thread_terminate. Думаю, это баг текущей версии компонента MQTT. Если этого не сделать, то перестанет работать loop_forever().

loop_forever() подвешивает основной поток навечно в режиме ожидания.

mqttc.loop_start()
mqttc.connect(mqtt_credentials_from_file_dict.get("localnet").get("host"), 1883, 60)

# Попытки соединения
while not mqttc.connected_flag: #wait in loop
	time.sleep(1)

mqttc.loop_stop()
mqttc._thread_terminate = False

mqttc.loop_forever()

Подписываемся на топик

Вторая распространенная ошибка. Посмотрим на on_connect.
При обрыве соединения с сервером важно каждый раз вызывать subscribe. Если сделать subscribe только в момент первого соединения, то клиент забудет название канала, на который подписан.

def on_connect(mqttc, obj, flags, rc):
	if rc == 0:
		mqttc.connected_flag=True
		res = mqttc.subscribe(listen_topic, 2)
		if res[0] != mqtt.MQTT_ERR_SUCCESS:
			logging.info(str(datetime.datetime.now()) + " The client is not subscribed")

	if rc == 1:
		logging.info(str(datetime.datetime.now()) +  " Connection failed: incorrect protocol version")
	if rc == 2:
		logging.info(str(datetime.datetime.now()) +  " Connection failed: invalid client identifier")
	if rc == 3:
		logging.info(str(datetime.datetime.now()) +  " Connection failed: server unavailable")
	if rc == 4:
		logging.info(str(datetime.datetime.now()) +  " Connection failed: bad app_id or access_key")
	if rc == 5:
		logging.info(str(datetime.datetime.now()) +  " Connection failed: not authorised")

Получаем и обрабатываем сообщение

Тут вроде бы ничего особеного. Но есть третья распространенная ошибка. Не забывайте, что Python может работать с несколькими потоками. И если мы будем обращаться к одному и тому-же ресурсу одновременно, то получим ошибку. Так что добавляем Lock() или аналог при необходимости.

def on_message(mqttc, obj, msg):
	print(str(datetime.datetime.now()) +  " Recieved data. Topic: "+msg.topic+". Msg:"+str(msg.payload))

Подбираю удобный интерфейс для управление умным домом

Для управления домом я использую систему OpenHab (OH). В OH настроена вся логика управления домашними устройствами. Например, если в комнате нажали выключатель №3, то OH должен включить потолочные светильники №7 и №8.

В OpenHab есть мобильное приложение для управления устройствами. Но оно неудобное. Например для того, чтобы включить лампу в спальне, нужно пролистать внушительный список из 40 устройств.

Так выглядит приложение OpenHab Basic UI:

Basic UI нам не подходит. Так что будем подбирать что-то другое.

Критерии:
— Приложение должно быть совместимо с планшетом и смартфоном
— Приложение должно быть простое в использовании и интуитивно понятное (гости не должны проходить специальное обучение чтобы включить кондиционер в гостинной)
— Приложение должно легко настраиваться (у меня нет пары месяцев на программирование интерфейса)
— Приложение должно быть красивым, не выбиваться из дизайна самого дома

Что рассматриваем:
— Habpanel (родной интерфейс системы OpenHab)
— CometVisu (система визуализации для KNX и OpenHab)
— Apple Homekit

Habpanel
Выглядит приятно. Посмотрите:

Я приступил к созданию интерфейса в Habpanel. Для этого в Habpanel есть специальный режим «Редактирования». Нужно нарисовать панельки и добавить на них витжеты. На выходе должен получиться html.

В процессе создания я столкнулся с проблемами:
— В режиме редактирования не видно самого витжета. Приходится постоянно переключаться между режимами чтобы понять что происходит;
— Интерфейс получается не адаптивным. Для смартфона и планшета нужно создать 2 разных интерфейса. А это еще 2 дня к разработке и вечные правки в двух-трёх местах;
— Я не нашел удобного витжета для управления LED подсветкой. Попробовал использовать стандартный и почувствовал боль. А у меня в каждой комнате есть LED.

Стандартный витжет для управления LED в Habpanel. Три спектра, цифры. Спектры зависят друг от друга. И если случайно нажать не туда, то цвета на верхнем спектре пропадают и вернуть нельзя. Почуствуй себя мастером по подбору красок!

CometVisu
Мне понравилась идея управлять домом на 3D карте. Чем-то напоминает фантастические фильмы. Если бы я снимал кино, то делал бы интерфейс тут.

Покопавшись в документах и исходниках CometVisu, я понял что быстро создать удобный интерфейс не получится. Как минимум нужно отрисовать 3D-карты этажей. И со смартфона управлять домом не получится. Такой интерфейс подойдет, если прикрепить несколько планшетов на каждом этаже. Оставлю эту идею на будущее.

Apple Homekit
Наверное, самое популярное приложение для управление умным домом. Раньше в Homekit можно было подключать только устройства, сертифицированные Apple. К счастью Apple открыла протокол и разработчики написали интерфейсы для взаимодействия с Homekit. Например, сервер Homebridge эмулирует iOS HomeKit API и позволяет легко подключать любые устройства. Энтузиасты уже разработали Homebridge Plugin for OpenHAB2. Так что я легко настроил связку Openhab2 > Homebridge Plugin > Homebridge > HomeKit. Выглядит сложновато. Но работает идеально, как часы. И быстро, потому что написано на NodeJS.

Я добавил управление освещением в гостинной и вот что получилось:

В компании Apple разработали действительно удобные элементы управления умным домом. Даже управление LED-подстветкой не вызвало вопросов. Все очень доступно и понятно. Управлять устройствами можно с ноутбука, планшета или Apple TV. Можно настраивать разные сценарии. Например: «Включить подсветку в прихожей, когда я подъезжаю на машине к дому», «Пропылесосить и проветрить дом, если меня нет дома в понедельник с 10 до 14», «Прогреть машину сразу после того как я включил чайник утром».

Но есть некоторые нюансы, которые важно знать:
— В доме постоянно должно быть включено одно из устройств Apple. Это может быть Apple TV, iPad или умная колонка. Если устройство потеряет сеть, управлять домом не получится. На этот случай у меня есть резервное неудобное приложение OpenHab Basic UI.
— Apple Homekit не работает по VPN. Это мне, как разработчику, не удобно. В доме полным ходом идет ремонт и я делаю все настройки удаленно. Нет смысла дышать пылью в процессе отладки. К счастью, эта проблема решилась установкой дополнительного сервера Homebridge в моей домашней сети.

Сегодня приступаю к настройке системы вентилиции в Homekit. Там много нюансов. Обязательно, напишу об этом позже.

Мой первый «Умный дом» на OpenHab

Моим самым любимым занятием в детстве были конструкторы. Спасибо родителям, у меня их было много: «юный техник», «юный химик», всевозможные лего и мозайки. Потом я увлекся радиодеталями: собирал цветомузыку, радиоприемники и мелкую электронику по схемам из советских журналов.


Во взрослой жизни все гораздо интереснее. Игрушки стали серьезнее. А если получается что-то нужное и хорошее, то заказчики благодарят деньгами. В хорошее время живем!

Недавно ко мне обратился клиент с просьбой настроить «Умный дом». С предыдущим подрядчиком они не сработались и проект остался в готовности 70%. Я поехал смотреть объект — двухэтажный загородный дом в районе Рублевского шоссе. При осмотре меня напугало отсутствие проектной документации, сотни висящих проводов без маркировки и полное отсутсвие технического задания. На момент осмотра хозяйка дома даже не понимала как включить обычное освещение, не говоря уже о вентиляции, отоплении и LED-подсветках. Во мне говорил опыт управления проектами и золотое правило PM-а «No scope — no go!». Но я не сдержался и начал делать. Желание помочь клиенту и поиграть в электронику победило здравый смысл.

Как выяснилось, мозг умного дома — это одноплатный компьютер (аналог Raspberry Pi) с установленной системой OpenHab. OpenHab — система управление умным домом с открытым исходным кодом.

Интерфейс OpenHab:

В момент первого осмотра удалось каким-то чудом перезапустить сервер OpenHab. И частично в доме заработал свет. Но счастье продолжалось не долго, потому что у компьютера сломался SSD-диск и больше сервер не загружался. Решено было начать с замены этого компьютера. Я заказал Intel NUC с SSD от того же Intel и оперативной памятью от Crucial. Железо обошлось в 13 тыс. руб. Это конечно не промышленное решение, но точно надежней безымянного «китайца» и в несколько раз производительнее. За пару дней я поднял и настроил новый сервер с OpenHab и поехал пробовать на объекте. Новый сервер заработал сразу же без «танцев с бубном». Да будет свет! В доме заработало освещение. Ура!

Компьютер Intel NUC:

Кстати о освещении. Ко всем выключателям уже была подведена витая пара, которая подключена к самодельному контролеру на базе Omega2. Omega2 — это недорогой контролер (700 руб.) с Linux системой внутри. На контроллере крутится скрипт на Python. Этот скрипт принимает команды от выключателей и передает их на сервер OpenHab по протоколу MQTT. Сервер OpenHab принимает команды и отправляет их на реле, которое подает электричество на осветительные приборы. Реле, кстати, тоже оказалось самодельным на базе того-же Omega2. Классная штука. Зачет инженеру, который спроектировал эту систему.

Так выглядит Omega2:

А это реле:

С освещением, кажется, разобрались. Впереди меня ждет система вентиляции с модулем управления JL201 и LED-панели на чипе ws281.

Как работать с требования к сайту, сервису или программе?

На моей первой работе заказчик (начальник) сидел у меня за спиной. Я не тратил время на документы, а сразу же «пилил» код. Работа была организована по принципу — утром «хотелки», вечером релиз. Биллинговая система, которую мы разрабатывали, постепенно разрасталась, её всё сложнее было поддерживать. Там были кнопки, про которые никто не мог точно сказать для чего они и как работают. Некоторые кнопки не использовались, а некоторые настройки могли порушить работу системы и их было опасно трогать.

В то время я увлекался книгами по программированию и учился создавать красивый код и пользовательский интерфейс. Успех продукта я видел в правильном коде и красивых кнопочках. Про работу с требованиями я узнал спустя несколько лет.

Прошло 20 лет с тех пор, как я выпустил и внедрил на предприятии свою первую программу. Появились сотни классных книг и курсов по разработке ПО. Уже никому не нужно рассказывать о важности технического задания (ТЗ).

В небольших проектах заказчик присылает разработчику ТЗ, а разработчик пишет список вопросов после изучения ТЗ. Спустя несколько встреч и цепочки писем получается что-то похожее на список требований в свободной форме. Только проблема в том, что в таком виде с требованиями сложно работать и нельзя однозначно сказать, всё ли мы учли. Риск и цена ошибки на этом этапе очень большие.

Решение — разложить требования по типам и уровням. На это может уйти пару часов. Но в результате получаем ясность в голове и уверенность в правильности действий. Про это есть отличная книга Карла Вигерса «Разработка требований к программному обеспечению». На мой взгяд, это библия для аналитика.

Вигерс выделяет три уровня требований:
— Бизнес-требования (высокоуровневые цели (ПОЧЕМУ?))
— Пользовательские требования (цели/задачи пользователей, которые будут выполняться с помощью ПО (КТО?)
— Функциональные требования (функциональность ПО, которая должна быть создана (ЧТО?))

Типы требований по Вигерсу:
— Нефункциональные требования (атрибуты качества, ограничения, бизнес-правила)
— Системные требования (для комплексных систем — интеграционные требования)

.

Ранее Ctrl + ↓