Но, при этом, массово пропагандируем, что не с +7(111) звонят только мошенники?
Вполне достаточно банки и фин. учреждения, сотовые операторы, страховые компании, гос. учреждения, жкх и т.п.
Это огромный массив людей. Коррумпируем их или трояним их терминалы с +7(111) номером и имеем канал связи для мошенничества, которому люди массово доверяют из-за предыдущей пропаганды.
Например, можно законодательно обязать все учреждения, совершающие звонки гражданам, использовать определенный код, например +7(111), где можно обеспечить все мероприятия безопасности начиная от стационарных номеров и заканчивая регистрацией всех звонящих сотрудников по паспорту, авторизацией по биометрии и т.п.
Т.е. любой микро-ИП будут прогонять через семь кругов ада и диких расходов просто чтобы получить телефонный номер для звонков клиентам? Отличная идея, вполне в духе текущих законодателей.
Но это ПО попытается установиться снова автоматически. Для его отключения нужно зайти в BIOS
Интересно, как это работает? В винде, которую ставит ASUS, есть ещё какое-то отдельное bloatware, которое мониторит настройки bios и скачивает дополнительный мусор?
Тогда для его отключения правильнее просто не использовать вендорскую сборку ОС. Или это в винде уже из коробки есть какой-то функционал для OEM вендоров загаживать систему?
Ну если согласны, что реализация на yaml конечного автомата, реализующего динамическое отображение статуса ворот намного сложней, чем указание ssid и psk, которые по любому и Вам нужно будет указывать, то больше незачем. Я удовлетворен.
Нет, не согласен, очередное ваше глупейшее передёргивание.
с какого перепугу Вы вдруг решили, что подключать автоматику ворот к HA надо абсолютно всем?
Я не заявлял, что абсолютно всем надо подключать автоматику ворот к HA, это в вашем воображении какие-то мысли мне приписаны.
непонятно, почему перепрошить мои ноды под тот же HA - это на порядок сложнее готового решения? HA что-ли разучился поддержке ESP32 и GPIO на них?
Что подразумевается под поддержкой HA ESP32 и GPIO на них? HA может поддерживать mqtt, esphome API, modbus, ещё какие-то протоколы, но при чём тут конечные устройства и их GPIO?
Учитывая ваши странные заявления выше по треду о том, как сложно найти готовое реле на ESP с исходниками прошивки, я начинаю подозревать, что с esphome/home assistant вы познакомились не далее как вчера и слабо себе представляете, как это всё взаимодействует.
для меня даже изучать "готовое решение", с большой вероятностью окажется дольше, чем написать десяток-другой строк кода для расширения функциональности этого проекта
Очень похоже на классический синдром NIH. Повторюсь - изобретать велосипед интересно, я сам не прочь иногда этим заняться, но это не очень практично.
В моем проекте HTTP не между нодами, а между компьютером или смартфоном и нодами.
Клиент посылает сигнал на открытие ворот вызовом Get gate_open HTTP серверу
Это не HTTP вызов между нодами? Я говорил конкретно про этот обмен, что раз уж вы экономите каждую копейку и каждый ресурс, делать его надо на modbus.
Вы опять отказываетесь увидеть иные точки зрения. Например, мои дочки или жена вполне в состоянии прошить МК через USB шнурок. Но даже не возьмутся отыскивать правильные пины внутри схемы для самостоятельного подключения USB-UART адаптера. Мало ли, где буду я, в тот момент, когда надо будет обновить прошивку.
Повторюсь (в чётвертый раз) - я уже признал точку зрения, что со всеми описанными ограничениями, экономией каждой копейки, отсутствием мобильной связи - ваш вариант вполне разумен. Да, эксплуатацтия такого варианта (когда, например, пользователям нужно физически подключать ноды к программатору, чтобы их перепрошить) тоже сурова, но таковы ограничения, я всё понимаю.
Зачем? Просили пример конечного автомата на yaml - пример я привёл. Давайте я ещё раз повторю (в третий раз) свой тезис, а то вы старательно от него уходите вбок.
В вашем случае, с вашими ограничениями, при условии, что не требуется дальнейших модификаций/исправлений/добавлений, ваше решение вполне разумно. Во всех остальных случаях, при наличии связи с мобильного клиента, при желании расширений возможностей, при желании универсальности, вариант с esphome неизменно надёжнее и гибче.
Добавление новых модулей в ваш код, подключение ваших нод к HA, управление вашими нодами (да даже просто OTA) - всё это будет на порядки сложнее готовых решений. Отсюда и выбор - инвестировать своё время в возможности esphome/tasmota и другие или замыкаться на ограниченное решение.
Хоть в таком виде согласились со мной.
Я с вами не соглашался, это просто ещё одно проявление вашей глупой демагогии.
в коде на 25К количество ошибок, в среднем, должно быть на три порядка меньше, чем в коде на 50М
В среднем - возможно, и я об этом уже сказал.
Если у этого простого кода столько же пользователей, сколько у продукта - возможно. Во всех остальных случаях - нет, не будет выигрывать.
Количество строк кода не является ни единственной, ни ключевой переменной в формуле количества ошибок.
для конечного изделия достаточно модуля без него за 183 рубля
Это всё равно дороже.
На ESP8266 мне ни разу не удалось поднять одновременно больше трех HTTP сессий
Странно, если я правильно помню, в том самом глючном esphome на миллионы строк кода с ошибками на esp8266 лимит в 5 активных, собственно, как и в исходниках вендора. Я уже не говорю о том, что HTTP между нодами для сценариев с экономией денег (а значит и ресурсов нод) - это очень расточительно, когда есть какой-нибудь modbus, например.
приобретения конечным пользователем хотя бы USB-UART адаптера
Что выглядит абсолютно разумным ходом, если мы экономим каждую копейку.
Для пользователя, далекого от МК и электроники, это может иметь принципиальное значение
Это тот же самый пользователь, который лихо паяет автоматику открытия ворот для вашего модуля? Это он не сможет воткнуть rx/tx/gnd выводы адаптера в пины чипа?
Вы понимаете, что сравниваете очень сильно разные вещи? Я несколько сообщений назад согласился, что в вашем случае, с вашими ограничениями, при условии, что не требуется дальнейших модификаций/исправлений/добавлений, ваше решение вполне разумно. Как пример разработки под ESP - тоже отличный вариант.
Во всех остальных случаях, при наличии связи с мобильного клиента, при желании расширений возможностей, при желании универсальности, вариант с esphome неизменно надёжнее и гибче.
Представьте, что завтра вы захотите добавить в модуль ворот автовключение света с диммированием, градусник, контроль воздуха. Где это проще и надёжнее сделать - в вашем коде или в esphome?
Если человек искренне считает, что код "Hello, World!" менее надежен и содержит больше ошибок, чем, скажем, Linux Kernel, то значит этот человек вообще не имеет отношения к программированию.
Если человек проводит подобные аналогии, скорее всего, ему хочется просто глупой демагогии, а не обсуждения.
В противном случае, Вы занимаетесь сравнением решений, различающихся в стоимости на порядок.
Соглашусь. Но согласитесь, что если бы для вас действительно была так важна стоимость решения, вы бы брали ESP8266 за 100 рублей, а не ESP32-C3 за 400.
Взять мой код и прошить его одной командой точно проще
Взять ваш код, _прописать конфигурационный файл_ и прошить его одной командой.
То есть от только недавно восхваляемого Вам esphome Вы уже предлагаете отказаться, так как ESP8266/ESP32 используют "нестабильное беспроводное соединение"? )))
Вы явно не читаете о чём я пишу. Нестабильное беспроводное соединение у вас между клиентом и точкой доступа, вы сами об этом писали в статье. И да, esphome необязательно использует wi-fi, он умеет и проводной ethernet.
Поэтому простой код, решающий простую конкретную задачу, в подавляющем большинстве случаев, будет выигрывать в надежности у универсального комбайна на все случаи жизни.
Если у этого простого кода столько же пользователей, сколько у продукта - возможно. Во всех остальных случаях - нет, не будет выигрывать.
С каких пор его можно установить на ESP32, а не хотя бы Малинку?
Где именно я обещал его установку на esp32?
А Вы не в курсе, что за МКАД есть жизнь?
Спасибо, в курсе, я живу за МКАДом. Повторюсь - в статье вы опустили критичное ограничение в виде отсутствия мобильной связи. Предполагать, что комментаторы сами догадаются, что именно это привело вас к костылям - несколько странно.
Ссылку на готовые прошивки Вы предоставить не смогли.
Так я вроде и сказал про "собирание готовой прошивки". Или писать свой код тоже проще, чем писать конфигурационный yaml?
Признали, что в статье автономная система, не зависящая от HA, что заметно повышает её надёжность и область применения.
Нет в статье никакой автономной системы, у вас, как минимум два модуля, которые общаются через сетевой протокол и нестабильное беспроводное соединение. И надёжность самописной прошивки, как бы, в подавляющем большинстве случаев ниже, чем надёжность вылизанного годами и сотнями тысяч пользователей конструктора.
Про область применения тоже сомнительное утверждение. Почитайте документацию esphome и возможности, которые там есть из коробки.
Мне не нужен нормальный мобильный клиент
Вы же сами вроде писали?
прошивки только для управления воротами с мобильника не нашел
Вот home assistant клиент отлично подходит для дополнительной функциональности управления с мобильника. Если вы в вашей wi-fi сети (а ваше управление со странички, я так понимаю, работает только в ней), то и клиент home assistant в ней будет прекрасно работать.
уровня сигнала ближайших сот на моем участке и его окрестностях недостаточно даже для голосовых вызовов
Это довольно серьёзное ограничение, про которое, мне кажется, не было упомянуто в статье. Тут соглашусь, что это неизбежно вынуждает двигаться в сторону нестандартных костылей.
Я даже прошивки только для управления воротами с мобильника не нашел, которая, как у меня, на JS мониторит положение ворот и учитывает предыдущие показания датчиков и предыдущую поданную команду.
Мне кажется, это потому, что сам подход к решению проблемы довольно неоднозначный. Прямое взаимодействие двух ESP нод по TCP/IP, прямое подключение пользовательским терминалом (телефоном) к ESP я тоже мало где встречал, отсюда и отсутствие большого количества решений.
Классическое решение же в наличии нормального сервера (home assistant и другие), который собирает данные с ESP нод и уже на основании этих данных производит какие-то управления ESP нодами. Там и нормальный мобильный клиент Android/ios со всеми плюшками, который будет сам пушить вашу геолокацию в home assistant, без необходимости закладывать в машины отдельные esp32 девайсы.
Да и при наличии AndrodAuto, клиент Home Assistant позволит вам просто на экран авто вывести кнопку открытия ворот.
WiFi реле на ESP32-C3-DEVKITM-1 с обратной связью от автоматики и исходники, опубликованные мной на GitHub
Ну мой комментарий был о том, что это - изобретение велосипеда. Которое полностью понятно в качестве хобби и возни, но с точки зрения решения проблемы - оно несравнимо сложнее доработки готового реле и собирания готовой прошивки.
Ну добавьте еще и оптопару после транзисторного каскада усиления перед реле
Чтобы что? У меня на плате управления ворот датчик открытия - это 24V AC и мне для отслеживания его при помощи пина ESP8266 достаточно простейшей схемы из диода, конденсатора (он не обязателен, можно фильтровать программно) резистора и оптопары. В случае с 5V DC достаточно резистора и оптопары.
Это еще надо постараться найти готовое реле, производитель которого предоставляет не только его схемотехнику, но и исходники прошивки.
Для абсолютно всех готовых реле на ESP8266/ESP32 доступны исходники esphome/tasmota и ещё десяток других готовых конструкторов прошивок. Да, может быть какая-то суперэкзотика (у shelly вроде есть такое), где rx/tx пины для заливки прошивки выведены только на самом процессоре, но даже для таких реле, как правило, есть ota механизмы заливки esphome.
Но и тогда доработка его схемотехники будет заметно сложнее, чем при использовании DevKit.
Спаять простейшую схему с оптопарой и подключить к готовому реле сложнее, чем распаивать ESP32 самостоятельно? Не соглашусь. Первое мне удалось выполнить сходу лет 5 назад, имея нулевой опыт пайки, за второе я бы не взялся даже сейчас.
Много Вы знаете реле, для которых производитель предоставляет исходные тексты прошивки?
Повторюсь - абсолютно все реле на esp8266/esp32. Только не производитель, а разработчики esphome и прочих.
к нему еще потребуется транзисторный каскад усиления и реле, только для того, чтобы обеспечить вход
Зачем каскад усиления и зачем реле для входа? Мне казалось это через обычную оптопару делается.
интерфейсных проблем больше, а толку меньше
В готовом реле со входами больше проблем и меньше толку? Я прекрасно понимаю желание поиграться с чем-то и изобрести велосипед, но если задача решить проблему, а не поиграться - то готовое реле (даже если требуются доработки) с готовой прошивкой всегда будет проще.
Не встречал ни одного реле на esp8266/esp32, на котором бы не было хоть где-то выведено инпутов, как минимум rx/tx. Вон старое Sonoff SV - реле с сухим контактом, 3 инпута, esphome ставится, 400-500 рублей.
Это люди с хорошим системным мышлением и плохой памятью, они не любят долгие проекты, презирают нюансы и забывают имена. Поэтому они все упрощают и ускоряют. У меня квадратный в проекции дом с самой простой крышей, с минимальной длиной коммуникаций. Поэтому он теплый, надежный и дешевый.
Люди с другой стороны, аккуратные, любящие все по полочкам, документацию сделают это на порядок дороже, дольше и аккуратней. Их дом будет с флигелями. подогреваемой кровлей и умным домом. Но не будет достроен.
Очень сомнительные утверждения, которые полностью расходятся с тем, что лично я вижу в реальной жизни. Долгостроев по тетради в клеточку на порядок больше, чем долгостроев, которые начинались с хоть какой-то вменяемой рабочей документации. Я уже не говорю о том, что любые последующие модификации/ремонт долгостроев по тетради в клеточку - это игра в рулетку, когда нет никакого понимания, где, что и как именно было построено.
Ну и презирание нюансов - это тоже отличная заявка на получение лишнего геморроя через несколько лет после завершения строительства.
Я не слышал что кто-то из интернационального крупняка отменял "вечные" бонусы.А если и отменят, то местячковые из-за этого сразу шумиху поднимут и не только рекламную, а ещё и лоббировать свои интересы начнут.
Microsoft делал это такое количество раз, что странно, как об этом можно было не услышать. При отключении Mesh и переходе на SkyDrive, а потом на OneDrive выдавалось кажется 15 GB + 25 GB loyalty, причём вначале одной цифрой, потом их специально подробили на две, потом первую порезали до 7GB, а потом до 5GB, потом, чтобы сохранить вторые 25GB надо было заходить и чего-то там кликать, а потом вторые 25 GB просто принудительно порезали до 10GB.
Немного не по теме, но было бы очень удобно, если бы в версиях L1 Lite без lorawan и с w5500, пины lorawan были бы доступны как обычные GPIO в дополнительной клемной колодке или как гнёзда на плате (по аналогии с SOCKET регионами). А то получается, что 6 пинов пропадают вникуда, найти их где-то на плате, кроме задней площадки и контактов отсутствующих резисторов не удалось.
Но, при этом, массово пропагандируем, что не с +7(111) звонят только мошенники?
Это огромный массив людей. Коррумпируем их или трояним их терминалы с +7(111) номером и имеем канал связи для мошенничества, которому люди массово доверяют из-за предыдущей пропаганды.
То есть кому-то нужно будет проходить бюрократический ад получения номера +7(111), а кому-то нет? Сразу прекрасное поле для коррупции.
А что сейчас мешает клиентам вести белые списки?
Т.е. любой микро-ИП будут прогонять через семь кругов ада и диких расходов просто чтобы получить телефонный номер для звонков клиентам? Отличная идея, вполне в духе текущих законодателей.
Интересно, как это работает? В винде, которую ставит ASUS, есть ещё какое-то отдельное bloatware, которое мониторит настройки bios и скачивает дополнительный мусор?
Тогда для его отключения правильнее просто не использовать вендорскую сборку ОС. Или это в винде уже из коробки есть какой-то функционал для OEM вендоров загаживать систему?
Пока на телевизор можно поставить kodi/jellyfin и т.п. - не вижу никакой проблемы в закрытости экосистемы.
KDE Connect же есть для этого, чтобы не перепечатывать циферки.
Нет, не согласен, очередное ваше глупейшее передёргивание.
Я не заявлял, что абсолютно всем надо подключать автоматику ворот к HA, это в вашем воображении какие-то мысли мне приписаны.
Что подразумевается под поддержкой HA ESP32 и GPIO на них? HA может поддерживать mqtt, esphome API, modbus, ещё какие-то протоколы, но при чём тут конечные устройства и их GPIO?
Учитывая ваши странные заявления выше по треду о том, как сложно найти готовое реле на ESP с исходниками прошивки, я начинаю подозревать, что с esphome/home assistant вы познакомились не далее как вчера и слабо себе представляете, как это всё взаимодействует.
Очень похоже на классический синдром NIH. Повторюсь - изобретать велосипед интересно, я сам не прочь иногда этим заняться, но это не очень практично.
Это не HTTP вызов между нодами? Я говорил конкретно про этот обмен, что раз уж вы экономите каждую копейку и каждый ресурс, делать его надо на modbus.
Повторюсь (в чётвертый раз) - я уже признал точку зрения, что со всеми описанными ограничениями, экономией каждой копейки, отсутствием мобильной связи - ваш вариант вполне разумен. Да, эксплуатацтия такого варианта (когда, например, пользователям нужно физически подключать ноды к программатору, чтобы их перепрошить) тоже сурова, но таковы ограничения, я всё понимаю.
Зачем? Просили пример конечного автомата на yaml - пример я привёл. Давайте я ещё раз повторю (в третий раз) свой тезис, а то вы старательно от него уходите вбок.
Добавление новых модулей в ваш код, подключение ваших нод к HA, управление вашими нодами (да даже просто OTA) - всё это будет на порядки сложнее готовых решений. Отсюда и выбор - инвестировать своё время в возможности esphome/tasmota и другие или замыкаться на ограниченное решение.
Я с вами не соглашался, это просто ещё одно проявление вашей глупой демагогии.
В среднем - возможно, и я об этом уже сказал.
Количество строк кода не является ни единственной, ни ключевой переменной в формуле количества ошибок.
Это всё равно дороже.
Странно, если я правильно помню, в том самом глючном esphome на миллионы строк кода с ошибками на esp8266 лимит в 5 активных, собственно, как и в исходниках вендора. Я уже не говорю о том, что HTTP между нодами для сценариев с экономией денег (а значит и ресурсов нод) - это очень расточительно, когда есть какой-нибудь modbus, например.
Что выглядит абсолютно разумным ходом, если мы экономим каждую копейку.
Это тот же самый пользователь, который лихо паяет автоматику открытия ворот для вашего модуля? Это он не сможет воткнуть rx/tx/gnd выводы адаптера в пины чипа?
5 секунд в гугле https://github.com/muxa/esphome-state-machine/ там же и примеры.
Вы понимаете, что сравниваете очень сильно разные вещи? Я несколько сообщений назад согласился, что в вашем случае, с вашими ограничениями, при условии, что не требуется дальнейших модификаций/исправлений/добавлений, ваше решение вполне разумно. Как пример разработки под ESP - тоже отличный вариант.
Во всех остальных случаях, при наличии связи с мобильного клиента, при желании расширений возможностей, при желании универсальности, вариант с esphome неизменно надёжнее и гибче.
Представьте, что завтра вы захотите добавить в модуль ворот автовключение света с диммированием, градусник, контроль воздуха. Где это проще и надёжнее сделать - в вашем коде или в esphome?
Если человек проводит подобные аналогии, скорее всего, ему хочется просто глупой демагогии, а не обсуждения.
Соглашусь. Но согласитесь, что если бы для вас действительно была так важна стоимость решения, вы бы брали ESP8266 за 100 рублей, а не ESP32-C3 за 400.
Взять ваш код, _прописать конфигурационный файл_ и прошить его одной командой.
Вы явно не читаете о чём я пишу. Нестабильное беспроводное соединение у вас между клиентом и точкой доступа, вы сами об этом писали в статье. И да, esphome необязательно использует wi-fi, он умеет и проводной ethernet.
Если у этого простого кода столько же пользователей, сколько у продукта - возможно. Во всех остальных случаях - нет, не будет выигрывать.
Где именно я обещал его установку на esp32?
Спасибо, в курсе, я живу за МКАДом. Повторюсь - в статье вы опустили критичное ограничение в виде отсутствия мобильной связи. Предполагать, что комментаторы сами догадаются, что именно это привело вас к костылям - несколько странно.
Так я вроде и сказал про "собирание готовой прошивки". Или писать свой код тоже проще, чем писать конфигурационный yaml?
Нет в статье никакой автономной системы, у вас, как минимум два модуля, которые общаются через сетевой протокол и нестабильное беспроводное соединение. И надёжность самописной прошивки, как бы, в подавляющем большинстве случаев ниже, чем надёжность вылизанного годами и сотнями тысяч пользователей конструктора.
Про область применения тоже сомнительное утверждение. Почитайте документацию esphome и возможности, которые там есть из коробки.
Вы же сами вроде писали?
Вот home assistant клиент отлично подходит для дополнительной функциональности управления с мобильника. Если вы в вашей wi-fi сети (а ваше управление со странички, я так понимаю, работает только в ней), то и клиент home assistant в ней будет прекрасно работать.
Это довольно серьёзное ограничение, про которое, мне кажется, не было упомянуто в статье. Тут соглашусь, что это неизбежно вынуждает двигаться в сторону нестандартных костылей.
Несмотря на то, что, на мой взгляд, идея с опросом уровня сигнала и открытия ворот довольно костыльная, я погуглил и вижу, что даже её можно реализовать на esphome.
Получение уровня сигнала https://community.home-assistant.io/t/get-list-of-access-points-ssids-in-reach/411895/16, REST провайдер управления и считывания датчиков/реле https://esphome.io/web-api/index.html, REST клиент для вызова этого провайдера https://esphome.io/components/http_request.html с клиентских ESP32.
Мне кажется, это потому, что сам подход к решению проблемы довольно неоднозначный. Прямое взаимодействие двух ESP нод по TCP/IP, прямое подключение пользовательским терминалом (телефоном) к ESP я тоже мало где встречал, отсюда и отсутствие большого количества решений.
Классическое решение же в наличии нормального сервера (home assistant и другие), который собирает данные с ESP нод и уже на основании этих данных производит какие-то управления ESP нодами. Там и нормальный мобильный клиент Android/ios со всеми плюшками, который будет сам пушить вашу геолокацию в home assistant, без необходимости закладывать в машины отдельные esp32 девайсы.
Да и при наличии AndrodAuto, клиент Home Assistant позволит вам просто на экран авто вывести кнопку открытия ворот.
Ну мой комментарий был о том, что это - изобретение велосипеда. Которое полностью понятно в качестве хобби и возни, но с точки зрения решения проблемы - оно несравнимо сложнее доработки готового реле и собирания готовой прошивки.
Чтобы что? У меня на плате управления ворот датчик открытия - это 24V AC и мне для отслеживания его при помощи пина ESP8266 достаточно простейшей схемы из диода, конденсатора (он не обязателен, можно фильтровать программно) резистора и оптопары. В случае с 5V DC достаточно резистора и оптопары.
Для абсолютно всех готовых реле на ESP8266/ESP32 доступны исходники esphome/tasmota и ещё десяток других готовых конструкторов прошивок. Да, может быть какая-то суперэкзотика (у shelly вроде есть такое), где rx/tx пины для заливки прошивки выведены только на самом процессоре, но даже для таких реле, как правило, есть ota механизмы заливки esphome.
Спаять простейшую схему с оптопарой и подключить к готовому реле сложнее, чем распаивать ESP32 самостоятельно? Не соглашусь. Первое мне удалось выполнить сходу лет 5 назад, имея нулевой опыт пайки, за второе я бы не взялся даже сейчас.
Повторюсь - абсолютно все реле на esp8266/esp32. Только не производитель, а разработчики esphome и прочих.
Зачем каскад усиления и зачем реле для входа? Мне казалось это через обычную оптопару делается.
В готовом реле со входами больше проблем и меньше толку? Я прекрасно понимаю желание поиграться с чем-то и изобрести велосипед, но если задача решить проблему, а не поиграться - то готовое реле (даже если требуются доработки) с готовой прошивкой всегда будет проще.
Не встречал ни одного реле на esp8266/esp32, на котором бы не было хоть где-то выведено инпутов, как минимум rx/tx. Вон старое Sonoff SV - реле с сухим контактом, 3 инпута, esphome ставится, 400-500 рублей.
Прекрасный пример презирания нюансов в виде копеечной гильзы на ввод в дом.
Очень сомнительные утверждения, которые полностью расходятся с тем, что лично я вижу в реальной жизни. Долгостроев по тетради в клеточку на порядок больше, чем долгостроев, которые начинались с хоть какой-то вменяемой рабочей документации. Я уже не говорю о том, что любые последующие модификации/ремонт долгостроев по тетради в клеточку - это игра в рулетку, когда нет никакого понимания, где, что и как именно было построено.
Ну и презирание нюансов - это тоже отличная заявка на получение лишнего геморроя через несколько лет после завершения строительства.
Microsoft делал это такое количество раз, что странно, как об этом можно было не услышать. При отключении Mesh и переходе на SkyDrive, а потом на OneDrive выдавалось кажется 15 GB + 25 GB loyalty, причём вначале одной цифрой, потом их специально подробили на две, потом первую порезали до 7GB, а потом до 5GB, потом, чтобы сохранить вторые 25GB надо было заходить и чего-то там кликать, а потом вторые 25 GB просто принудительно порезали до 10GB.
Немного не по теме, но было бы очень удобно, если бы в версиях L1 Lite без lorawan и с w5500, пины lorawan были бы доступны как обычные GPIO в дополнительной клемной колодке или как гнёзда на плате (по аналогии с SOCKET регионами). А то получается, что 6 пинов пропадают вникуда, найти их где-то на плате, кроме задней площадки и контактов отсутствующих резисторов не удалось.