harabudjasim

Promise.all() подойдет если есть много почти одинаковых не зависящих друг от друга запросов, например надо спросить об активности 10и пользователей.
В приведенном примере есть прямая зависимость: сделать второй запрос ЕСЛИ первый вернул true. Поэтому они должны идти строго один за другим, поэтому тут лучше await.

Лучше всего об этом скажут логи. В логах будет видна ошибка или сигнал процессу.
К сожалению, это сильно зависит от хостера, если у вас только контейнер (как в Heroku например), то логи собирает сама система и их надо искать в heroku-cli. Если у вас виртуальная машина - то логи надо собирать самому, через logging или еще какието инструменты.

Быстрое решение - посмотреть в сторону параметра --restart при старте контейнера. Это позволит перезапускать контейнер при падении.

Пожалуй, самое известное соревнование в Kaggle: https://www.kaggle.com/c/titanic
По нему очень много примеров и даже пару книжек написано.

Если я все правильно понимаю, то нужно предотвратить добавление в базу записей с текстом из "заблокированной" таблицы.

Попробуйте добавить проверку в pre_save сигнале. Вот примерный механизм.
https://stackoverflow.com/a/6462188
В случае если надо предотвратить save - просто бросаете исключение.

В очень больших проектах недопустима перерисовка всего дерева DOM на каждое изменение стора (что и будет происходить при store.subscribe(render)). Provider позволяет подключить на определенный компонент определенный стор, чего не позволяет простой импорт стора из файла. Такое себе разграничение SPA на отдельные фичи. connect() позволяет подключить только выбранные экшены и данные в определенном компоненте. Так более наглядно видны зависимости компонента и правильно происходит подписка на изменения. В таком случае компонент будет перерисовываться только при изменениях тех данных что к нему подключены а не всего стора.

input в питоне получает данные от пользователя только по нажатию Enter. Тоесть пока не нажат Enter, введенный текст находится в буфере терминала и недоступен программе. Можно начать с того что подвязаться на нажатия клавишь а не на ввод полной строки и собирать введенные сообщения вручную в программе. В момент когда надо вывести новое сообщение в лог: откатываем каретку на начало строки (\r), выводим сообщение лога, переносим строку, выводим буфер неоконченного сообщения пользователя.

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

Электромагнит включить паралельно с фоторезистором (добавить транзисторов-усилителей по вкусу).
Пока темно у резистора большое сопротивление и весь ток идет на магнит. На рассвете резистор будет поглощать свет, терять сопротивление и через него пойдет ток. В какой-то момент тока на магните станет недостаточно чтоб удерживать дверь и она откроется.

Контроллеры для такой задачи не нужны, да и мороки с ними много, то им 5 вольт подавай, то герметичность.

Я бы отказался от реализации этого проекта на основе коптера. Я бы начал с более простой платформы, типа машинки. Перед тем как занятсья непосредственно SLAM Вам прийдется запустить и стабилизировать коптер (чем меньше бюджет - тем больше приходится допиливать самому в плане стабилизации). Самодельные коптеры не летают из коробки, даже если Вы делаете по инструкции их нужно настраивать и настраивать. А автопилот, да еще и с полетами с препятствиями и подавно.
Автопилот и построение карты это очень большая задача, я думаю ее с головой хватит на диплом, там сбор и анализ данных чего только стоит.
Если же так сильно хотите запустить все это на коптере - отложите идею с коптером на последний этап, когда все остальное уже будет готово. Сделайте сначала на машинке.

Первое что приходит в голову Virt2real.
А если смотреть шире то можно поискать любые дев киты от Broadcom. У них часто на кристале кроме ARM идет еще и трансмиттер какой-нибудь.

Самое первое, основная характеристика проекторов - это яркость лампы (диодов). Ламповые проекторы дают около 3000 люмен, диодные не прыгают выше 1000 люмен (большинство 300 люмен), наладонные выдают около 100-150.
На сайте MPro110 нигде не написана яркость, поэтому можно предположить что она такая-же как у обычных наладонных, максимум стационарных диодных.

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

Вообще, если хотите работать за проектором, заплатите лучше за стационарную ламповую модель или дорогую диодную, на таких мелких наладонниках Вы ничего не увидите.

"Я вобще не представляю как, но хочу все сразу и идеально"

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

Если вернуться к вопросу, у всех примерно одинаковая архитектура, от нее далеко не уйдешь:

Компьютер - Канал связи - Удаленное устройство - Датчик или силовой агрегат

Все эти элементы могут быть очень разными, это и создает такое множество реализаций умных домов. Но суть у всех все равно одна и та-же.

Как по мне, так это очень комплексная задача. Ее нужно разделить на несколько подзадач, например, сбор, обработка, отображение и управление.

Для сбора и управления отлично подходят ардуины, также и как расширители портов.

Обработка и отображение можно организовать на каком-то планшете с линуксом на борту. Есть такая штука как Sunxi, это линукс для китайских планшетов, достаточно быстрый, планшет сразу даст и ARM для обработки данных и экран и тачскрин. А шины данных в планшете можно найти,обычно они распаяны и их можно использовать под свои нужды.

Теперь замечания:
Про реалтайм в такой системе можно сразу забыть. И не пытаться его сюда приплести. Реалтайм нужен для управления топливной системой, тормозами, еще чемто, где бой идет за микросекунды. Для мониторинга или управления печкой он абсолютно не нужен, обычный линукс вполне справится с поставленными задачами, залержка в 100 милисекунд при включении печки или обновлении позиции на GPS это вполне нормальные показатели. Проверьте отклик обычного навигатора, там цифры похуже бывают.
Итог: реалтайм - системы для более жизненноважных элементов. они сложны и трудоемки, у Вас и без этого будет мороки :).

Ардуины и другие development boards. Они все расчитаны на работу в тишине и покое, на столе, в серверной, в шкафу. В автомобиле же есть куча вещей которые будут влиять на эти хрупкие девайсы: вода, вибрация, грязь, нестабильное питание.
Подумайте о защите этих устройств или готовьтесь к самостоятельной их разработке. Я бы сделал вариант ардуино с нужной мне обвязкой на одной плате и залил бы все компаундом, чем надеялся что ардуиновская этажерка не развалится от вибрации.

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

На сайте ардуино есть целая куча готовых примеров использования этого шилда, вот ссылка на их сайт: arduino.cc/en/Reference/GSM
Если Вы уже имели дело с ардуиной, то подключить внешние устройства Вам не составит труда, в другом случае, ознакомьтесь сначала с самой платформой ардуино и все само станет на свои места.
При наличии GSM-шилда, ардуиной можно управлять как с помощью СМС или звонков, так и с помощью браузера.

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

ИМХО, не вижу смысла в использовании 3.0 на контроллерах. Мелкие контроллеры попросту не выдадут такую производительность. Большие уже требуют операционку для полноценной работы.
По вопросу: вот первые выдачи гугла (запрос ARM USB 3.0)
com.odroid.com/sigong/blog/blog_list.php?bid=153
www.ti.com/lsds/ti/dsp/embedded_processor.page?DCM...