Уже есть раздел Подписаться. Определенно требуется дополнение — Отписаться, с возможностью вносить туда как блоги целиком, так и отдельных авторов. Причем было бы замечательно, если бы автор блога-статьи видел статистику по отписавшимся — возможно, это мотивировало бы на написание качественной статьи в будущем, а не рекламного шлака.
Данный случай, когда от работоспособности камеры зависит здоровье человека, требует стабильного подключения. Вы сами описали множество недостатков, как раз связянных с этим: длительность подключения, потеря сигнала, проприетарное нестабильное ПО, зависимость от китайских облаков. Может в данном случае можно было бы пожертвовать качеством картинки, но подобрать камеру, которая лишена перечисленных недостатков? Есть такие варианты?
Как житель РФ и владелец нескольких камер этого же производителя, столкнулся еще с тем, что доблестный РКН в борьбе с телеграмом, заблокировал адреса AWS, через которые работали камеры — как следствие, их полная недоступность и неработоспособность. Потом адреса разблокировали, но осадок остался.
Действительно, esp8266 — чрезвычайно нестабильная система. Дня не проходит, чтобы какой-нибудь из модулей самопроизвольно не отключился от сети (работают в системе метео-наблюдения). Интересно, как со стабильностью у esp32?
То есть всё, что касается Ардуино — на Хабр, а программирование для esp8266 и прочих микроконтроллеров — на ГТ? Где логика?
А если статья про получение данных с сенсоров, которые работают и там и там? Вылавливать такие статьи на захламленном купленными блогами Хабре?
Либо я отстал от жизни, либо не понимаю — а зачем же нужен телефон, чтобы приготовить кусок мяса? Чтобы задать время жарки? А что мешает его задать парой кнопок на самом гриле?
Еще раз убеждаюсь, что лучший вариант организации «информативных» домов — это продумывание и создание их на стадии капитального ремонта. Тогда и провода можно протянуть куда угодно в любом количестве, и подрозетники установить где надо!
Вы внимательно читали статью и смотрели код? Я нигде не говорил, что писать под Arduino-IDE — сложно. В статье сказано, что при большом количестве датчиков программа превращается в нечитаемую простыню кода, в которой становится трудно ориентироваться и что-либо понимать. Поэтому предложен ООП-подход, значительно сокращающий количество кода, увеличивающий читаемость, и позволяющий легко расширять возможности программы.
Целью проекта было, в первую очередь, упростить написание кода под Ардуино-Esp — без сторонних прошивок, и второе — научиться получать данные с Aqara, и отправлять их для хранения-обработки. Максимальный охват датчиков в проекте — и не планировался, так как проект задуман как концепт, где каждый сможет элементарно добавить свой датчик. Естественно, при необходимости, как автор проекта — смогу помочь и код уйдет в репозиторий.
Для того, чтобы работать с датчиками, в любом случае понадобится шлюз от Xiaomi — иных решений не встречал. При включенном на шлюзе режиме разработчика — становится возможным слушать передаваемые в сети данные с датчиков: модуль, запущенный на Малинке, проверяет те данные, что транслирует шлюз, парсит их на предмет нужных данных, и далее отправляет на сайт для хранения.
Как житель РФ и владелец нескольких камер этого же производителя, столкнулся еще с тем, что доблестный РКН в борьбе с телеграмом, заблокировал адреса AWS, через которые работали камеры — как следствие, их полная недоступность и неработоспособность. Потом адреса разблокировали, но осадок остался.
А если статья про получение данных с сенсоров, которые работают и там и там? Вылавливать такие статьи на захламленном купленными блогами Хабре?
Какой-то колхоз, зато в надписью Сделано в России.