Спасибо за комментарий, все замечания однозначно по делу. Да, акцент прежде всего идет на посуточную аренду, а долгосрочная имеет свои требования и подводные камни, на которые следует обратить внимание.
Как уже отмечали в некоторых комментариях - пока имеем дело с прототипом и активно занимаемся разработкой и тестированием. Предварительно экспериментируем с электромеханическим замком, работающим в связке с модулем реле, платой и внешним источником питания на батарейках. Такой замок остается в закрытом состоянии при отключении источника питания.
Работаем с собственным API серверной части, который пока доступен только для нашего мобильного приложения. Используем его для большинства используемых алгоритмов, включая управление доступом и журналами посещений. Публичная открытость для интеграции пока рассматривается как возможный вариант, но заявлять не спешим.
Алгоритм открытия разрабатывается на основе шифрования цифрового ключа, интерпретация которого со стороны замка позволит аутентифицировать пользователя и принять решение о предоставлении доступа. При таком подходе для долгосрочной работы будет достаточно заводской прошивки и процедуры регистрации устройства, а дальнейшие процессы будут использовать необходимые константы и переменные из замка + цифрового ключа.
Удаленное открытие замок не поддерживает. По крайней мере обсуждаемый вариант, не поддерживающий интеграцию со шлюзами умного дома, не имеет такой возможности. Это решение принято в первую очередь из соображений безопасности.
Часть устройства, которая находится с внешней части двери, может быть подвержена грубой силе. Боимся, что этого сложно избежать в случае с любым умным замком, привлекающим к себе внимание. Вывод этой части из строя нарушит функциональность считывания NFC-сигнала, но не позволит добраться до контрольного устройства замка. Ремонт не понесет существенных затрат (корпус + считыватель/метка), а временным решением станет физический ключ, поставляемый в комплекте с замком.
Спасибо за комментарий! Связь на коротком расстоянии без подключения к интернету - решение, которое довольно успешно себя показало на фоне процветания аналогичного способа оплаты покупок. Вспоминаем распространенные проблемы из повседневной жизни, связанные с дверьми, и получаем решение: замок с технологией NFC, предлагающий достаточно удобный и безопасный метод входа, который устраняет необходимость в использовании физических ключей. Так или иначе, мы решили сконцентрироваться именно на этой технологии, а многие из особенностей нашего продукта сформированы в целях устранения потенциальных уязвимостей.
Ваша идея с QR-кодами выглядит достаточно интересно и определенно найдет своих поклонников. Но навскидку возникает вопрос о стоимости такого решения. Может комплектующие и обойдутся не столь дорого, но какое потребление будет у такого устройства в режиме ожидания, пока к нему не поднесут QR-код?
Решение же с биометрией мне кажется очень перспективным, но, насколько мне известно, в России запрещена регистрация биометрических персональных данных в собственных информационных системах организаций. Могу быть не прав в этом вопросе, но по крайней мере сбор биометрии регулируется законом о персональных данных, что может вызывать определенные проблемы при создании такого решения.
Здравствуйте, спасибо за комментарий! Статья опубликована в корпоративном блоге компании, демонстрирует собственное решение, но тем не менее обращает внимание на ключевые по мнению автора преимущества и недостатки других способов входа. Рассмотреть все аналоги и их конкурентные преимущества попросту сложно в формате одной статьи, но мы открыты для дискуссии в комментариях.
В качестве первой версии предлагаемого продукта мы рассматриваем врезной электромеханический замок. Мы пока не заявляем о способе установки замка, так как устройство еще тестируется и финальный вариант дизайна не утвержден. Однако по оценкам установка не доставит особых хлопот и потребует дополнительное сквозное отверстие для соединения составляющих замка с внешней и внутренней стороны двери.
Это же решение не требует дополнительного питания через саму дверь и не нуждается в подключении к шлюзу умного дома. Что это дает?
1. Снижение совокупной стоимости системы. 2. Упрощение процедуры установки и настройки. 3. Полная автономность замка. Пользователь может получить доступ к замку не переживая, что интернет-соединение между хабом-провайдером/хабом-замком может быть нарушено. Мы смещаем акцент на мобильный телефон и осуществляем большинство ключевых процедур через него, включая выдачу доступа и отправку уведомлений. Разумеется, приложение не централизует всю логику в себе - серверная составляющая нашей экосистемы берет ответственность за часть работы алгоритмов. 4. Повышенная безопасность. Вытекающая из автономности безопасность характеризуется минимизацией риска несанкционированного доступа. Уязвимых мест в системе попросту становится меньше, что позволяет сконцентрироваться на безопасности процессов передачи и обработки данных на стороне замка и мобильного приложения. Любопытная статья по данной теме: https://www.okbsapr.ru/library/publications/konyavskaya_2007_8/
Также необходимо отметить, что подписка является опциональным решением и все базовые функции умного замка доступны и без нее. Это вовсе не значит, что обычный человек или арендодатель лишится контроля над всеми своими устройствами, если не оплатит ее, нет. Подписка предоставляет попроступредоставляет больше вариантов использования: возможность управлять всеми устройствами из одного приложения, дополнительные функции для управления доступом и увеличение лимитов. В разделе "Подписка" на нашем сайте есть сравнительная таблица, которая позволит внести большую ясность касаемо данного вопроса.
В заключение затрону техническую часть вопроса. Опять же повторюсь, что мы не торопимся разглашать аспекты технической реализации из-за активного процесса разработки и тестирования. Вовсе не потому, что нам есть что скрывать, и не потому, что "под капотом" наш замок собран из китайских комплектующих. Лично я считаю, что заниматься перепрошивкой готовых вариантов для такого продукта - не самая выгодная идея. Вся суть заключается в технологии NFC, а не в код-паролях, отпечатках пальца и других способах открытия, имеющихся в подобных вариантах. Именно поэтому мы сотрудничаем с российскими производителями по вопросам проектирования и производства собственного микроконтроллера и будем рады поделиться результатами работы в этом направлении. Как только, так сразу!
Под миграциями в данном контексте подразумевается набор инструкций, определяющих изменения, которые мы хотим внести в схему базы данных. Создается набор файлов, в которых описывается, что конкретно нужно выполнить. Например, мы можем создать миграцию CreateUsersTable, в которой укажем, что при запуске миграции нужно создать таблицу users с определенными полями, а при откате миграции - удалить таблицу. И дальше можно будет при помощи команд php artisan migrate и php artisan migrate:rollback изменять базу данных в соответствии с определенными нами правилами
Спасибо за конструктивный комментарий! Соглашусь с замечанием, что API и бэкенд - две крупные темы, которым можно посвятить отдельные обсуждения, но тем не менее они тесно связаны. В контексте статьи я стремился преподнести концепцию API (в частности Web API, но, как я уже понял, с переходом у меня получилось не очень) и немного углубиться в подробности разработки, как раз таки связанные с серверной частью. Но думаю, что действительно можно было бы провести более четкое разграничение между API и бэкенодм, берущим на себя ответственность за процессы на стороне сервера, бизнес-логику, обработку данных, хранение и аутентификацию.
Думаю, что его выбор во многом зависит от требований конкретного проекта. Возможно по определенным критериям получится обойти альтернативные варианты. Но да, абсолютно согласен, что API Platform действительно достоен внимания, хоть на него не так часто обращается внимание в статьях/рейтингах/опросах. А касаемо API и Web API - да, свою ошибку, вводящую в заблуждение, понял ;) Буду исправляться!
Да, большое спасибо за уточнение! Касаемо миграций БД: В разделе про путь разработки я описывал шаги от проектирования ER-диаграммы к релизу конечной точки API. Прежде чем работать с данными и возвращать их через API необходимо создать саму базу данных, с чем собственно и помогают миграции. В контексте Laravel они представляют собой что-то вроде системы контроля версий, позволяющей определять схемы БД приложения и управлять таблицами.
Вы правы, API применяется совершенно в различных областях (API операционных систем, библиотек, графические API и т.д.). Акцент статьи направлен на Web API в силу их распространенности и важности в современных ИТ-решениях. Думаю, что я сделал слишком резкий переход от общего к частному, из-за чего сложилось такое ощущение недосказанности. Но в любом случае спасибо, что подметили, поработаю над этим!
Добрый вечер, спасибо за комментарий и советы! Мы экспериментируем, набираемся опыта и работаем над собой. Несомненно может показаться, что наши инженеры впервые занимаются этим делом, но некоторые основы уже были получены за школьные годы. Инженер Максим, например, год занимался робототехникой и даже стал победителем соревнований «KubSU Robotics-2018». В любом случае это полезный опыт, хоть и не продвинутого уровня :) Про Arduino и серийное производство понимаем, эти две вещи совмещать не собираемся. Но тем не менее мы посчитали, что Arduino - достаточно неплохой вариант, чтобы сделать первый прототип нашего будущего замка. В дальнейшем, когда реализуем и отточим мельчайшие детали, будем договариваться о производстве. Технологию умного дома начали рассматривать относительно недавно, но уже ждем поставки новых комплектующих. Смотрим в сторону Thread и BLE.
Спасибо за комментарий, все замечания однозначно по делу. Да, акцент прежде всего идет на посуточную аренду, а долгосрочная имеет свои требования и подводные камни, на которые следует обратить внимание.
Как уже отмечали в некоторых комментариях - пока имеем дело с прототипом и активно занимаемся разработкой и тестированием. Предварительно экспериментируем с электромеханическим замком, работающим в связке с модулем реле, платой и внешним источником питания на батарейках. Такой замок остается в закрытом состоянии при отключении источника питания.
Работаем с собственным API серверной части, который пока доступен только для нашего мобильного приложения. Используем его для большинства используемых алгоритмов, включая управление доступом и журналами посещений. Публичная открытость для интеграции пока рассматривается как возможный вариант, но заявлять не спешим.
Алгоритм открытия разрабатывается на основе шифрования цифрового ключа, интерпретация которого со стороны замка позволит аутентифицировать пользователя и принять решение о предоставлении доступа. При таком подходе для долгосрочной работы будет достаточно заводской прошивки и процедуры регистрации устройства, а дальнейшие процессы будут использовать необходимые константы и переменные из замка + цифрового ключа.
Удаленное открытие замок не поддерживает. По крайней мере обсуждаемый вариант, не поддерживающий интеграцию со шлюзами умного дома, не имеет такой возможности. Это решение принято в первую очередь из соображений безопасности.
Часть устройства, которая находится с внешней части двери, может быть подвержена грубой силе. Боимся, что этого сложно избежать в случае с любым умным замком, привлекающим к себе внимание. Вывод этой части из строя нарушит функциональность считывания NFC-сигнала, но не позволит добраться до контрольного устройства замка. Ремонт не понесет существенных затрат (корпус + считыватель/метка), а временным решением станет физический ключ, поставляемый в комплекте с замком.
Спасибо за комментарий! Связь на коротком расстоянии без подключения к интернету - решение, которое довольно успешно себя показало на фоне процветания аналогичного способа оплаты покупок. Вспоминаем распространенные проблемы из повседневной жизни, связанные с дверьми, и получаем решение: замок с технологией NFC, предлагающий достаточно удобный и безопасный метод входа, который устраняет необходимость в использовании физических ключей. Так или иначе, мы решили сконцентрироваться именно на этой технологии, а многие из особенностей нашего продукта сформированы в целях устранения потенциальных уязвимостей.
Ваша идея с QR-кодами выглядит достаточно интересно и определенно найдет своих поклонников. Но навскидку возникает вопрос о стоимости такого решения. Может комплектующие и обойдутся не столь дорого, но какое потребление будет у такого устройства в режиме ожидания, пока к нему не поднесут QR-код?
Решение же с биометрией мне кажется очень перспективным, но, насколько мне известно, в России запрещена регистрация биометрических персональных данных в собственных информационных системах организаций. Могу быть не прав в этом вопросе, но по крайней мере сбор биометрии регулируется законом о персональных данных, что может вызывать определенные проблемы при создании такого решения.
Здравствуйте, спасибо за комментарий! Статья опубликована в корпоративном блоге компании, демонстрирует собственное решение, но тем не менее обращает внимание на ключевые по мнению автора преимущества и недостатки других способов входа. Рассмотреть все аналоги и их конкурентные преимущества попросту сложно в формате одной статьи, но мы открыты для дискуссии в комментариях.
В качестве первой версии предлагаемого продукта мы рассматриваем врезной электромеханический замок. Мы пока не заявляем о способе установки замка, так как устройство еще тестируется и финальный вариант дизайна не утвержден. Однако по оценкам установка не доставит особых хлопот и потребует дополнительное сквозное отверстие для соединения составляющих замка с внешней и внутренней стороны двери.
Это же решение не требует дополнительного питания через саму дверь и не нуждается в подключении к шлюзу умного дома. Что это дает?
1. Снижение совокупной стоимости системы.
2. Упрощение процедуры установки и настройки.
3. Полная автономность замка. Пользователь может получить доступ к замку не переживая, что интернет-соединение между хабом-провайдером/хабом-замком может быть нарушено. Мы смещаем акцент на мобильный телефон и осуществляем большинство ключевых процедур через него, включая выдачу доступа и отправку уведомлений. Разумеется, приложение не централизует всю логику в себе - серверная составляющая нашей экосистемы берет ответственность за часть работы алгоритмов.
4. Повышенная безопасность. Вытекающая из автономности безопасность характеризуется минимизацией риска несанкционированного доступа. Уязвимых мест в системе попросту становится меньше, что позволяет сконцентрироваться на безопасности процессов передачи и обработки данных на стороне замка и мобильного приложения. Любопытная статья по данной теме: https://www.okbsapr.ru/library/publications/konyavskaya_2007_8/
Также необходимо отметить, что подписка является опциональным решением и все базовые функции умного замка доступны и без нее. Это вовсе не значит, что обычный человек или арендодатель лишится контроля над всеми своими устройствами, если не оплатит ее, нет. Подписка предоставляет попросту предоставляет больше вариантов использования: возможность управлять всеми устройствами из одного приложения, дополнительные функции для управления доступом и увеличение лимитов. В разделе "Подписка" на нашем сайте есть сравнительная таблица, которая позволит внести большую ясность касаемо данного вопроса.
В заключение затрону техническую часть вопроса. Опять же повторюсь, что мы не торопимся разглашать аспекты технической реализации из-за активного процесса разработки и тестирования. Вовсе не потому, что нам есть что скрывать, и не потому, что "под капотом" наш замок собран из китайских комплектующих. Лично я считаю, что заниматься перепрошивкой готовых вариантов для такого продукта - не самая выгодная идея. Вся суть заключается в технологии NFC, а не в код-паролях, отпечатках пальца и других способах открытия, имеющихся в подобных вариантах. Именно поэтому мы сотрудничаем с российскими производителями по вопросам проектирования и производства собственного микроконтроллера и будем рады поделиться результатами работы в этом направлении. Как только, так сразу!
Под миграциями в данном контексте подразумевается набор инструкций, определяющих изменения, которые мы хотим внести в схему базы данных. Создается набор файлов, в которых описывается, что конкретно нужно выполнить. Например, мы можем создать миграцию CreateUsersTable, в которой укажем, что при запуске миграции нужно создать таблицу users с определенными полями, а при откате миграции - удалить таблицу. И дальше можно будет при помощи команд
php artisan migrateиphp artisan migrate:rollbackизменять базу данных в соответствии с определенными нами правиламиСпасибо за конструктивный комментарий! Соглашусь с замечанием, что API и бэкенд - две крупные темы, которым можно посвятить отдельные обсуждения, но тем не менее они тесно связаны. В контексте статьи я стремился преподнести концепцию API (в частности Web API, но, как я уже понял, с переходом у меня получилось не очень) и немного углубиться в подробности разработки, как раз таки связанные с серверной частью. Но думаю, что действительно можно было бы провести более четкое разграничение между API и бэкенодм, берущим на себя ответственность за процессы на стороне сервера, бизнес-логику, обработку данных, хранение и аутентификацию.
Думаю, что его выбор во многом зависит от требований конкретного проекта. Возможно по определенным критериям получится обойти альтернативные варианты. Но да, абсолютно согласен, что API Platform действительно достоен внимания, хоть на него не так часто обращается внимание в статьях/рейтингах/опросах.
А касаемо API и Web API - да, свою ошибку, вводящую в заблуждение, понял ;) Буду исправляться!
Да, большое спасибо за уточнение! Касаемо миграций БД:
В разделе про путь разработки я описывал шаги от проектирования ER-диаграммы к релизу конечной точки API. Прежде чем работать с данными и возвращать их через API необходимо создать саму базу данных, с чем собственно и помогают миграции. В контексте Laravel они представляют собой что-то вроде системы контроля версий, позволяющей определять схемы БД приложения и управлять таблицами.
Вы правы, API применяется совершенно в различных областях (API операционных систем, библиотек, графические API и т.д.). Акцент статьи направлен на Web API в силу их распространенности и важности в современных ИТ-решениях. Думаю, что я сделал слишком резкий переход от общего к частному, из-за чего сложилось такое ощущение недосказанности. Но в любом случае спасибо, что подметили, поработаю над этим!
Добрый вечер, спасибо за комментарий и советы! Мы экспериментируем, набираемся опыта и работаем над собой.
Несомненно может показаться, что наши инженеры впервые занимаются этим делом, но некоторые основы уже были получены за школьные годы. Инженер Максим, например, год занимался робототехникой и даже стал победителем соревнований «KubSU Robotics-2018». В любом случае это полезный опыт, хоть и не продвинутого уровня :)
Про Arduino и серийное производство понимаем, эти две вещи совмещать не собираемся. Но тем не менее мы посчитали, что Arduino - достаточно неплохой вариант, чтобы сделать первый прототип нашего будущего замка. В дальнейшем, когда реализуем и отточим мельчайшие детали, будем договариваться о производстве.
Технологию умного дома начали рассматривать относительно недавно, но уже ждем поставки новых комплектующих. Смотрим в сторону Thread и BLE.