xRoom. Введение

kalina
Сообщения: 180
Зарегистрирован: Пн фев 22, 2016 11:01 pm
Благодарил (а): 29 раз
Поблагодарили: 90 раз

xRoom. Введение

Сообщение kalina » Пн авг 19, 2019 3:11 pm

Всем привет!

В данной статье хочу рассказать про будущий концепт построения своего умного дома на базе устройств под кодовым названием xRoom. Что это такое? xRoom это очередной мой проект, а если более точно - серия контроллеров, каждый из которых можно охарактеризовать как ПЛК, состоящий из двух плат - процессорной (верхней) и силовой (нижней). Обе платы будут расположены в DIN-реечном корпусе (D9MG или аналогичном).

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

Внедрение умного дома началось около трёх лет назад. До этого момента также были попытки автоматизации отдельных элементов, но системно я на это взглянул с появлением в своём поле зрения платформы MajorDomo. Так как я отношу себя к так называемым "железячникам", я сразу же начал искать пути входа в данную программную платформу через своё железо. Для этого я создал пост "Разработка собственного железа" , который потом перерос в раздел "Авторские проекты" (спасибо Сергею за поддержку идеи). Со временем точка входа была найдена - MуSensors . Совместно с Иваном (передовой майсенсоровец:-) ) мы разработали серию устройств различного назначения, глянуть можно здесь . Наиболее успешным оказался гейт MDMSGate . Успешность гейта я определил двумя факторами - стабильная и надёжная работа, а также, хоть и небольшой, а спрос. Я продал несколько десятков штук. за бугор, причём меня очень удивила география - в списке есть Австралия и Новая Зеландия. В страны СНГ - около 5 шт. Исходя из этого, хочу дать совет всем железячникам, кто хочет не только самостоятельно юзать свое железо, но и продвигать его в массы - пиартесь на зарубежных ресурсах. Так вот, родив номенклатуру устройств MySensors, я сразу же начал усиленно юзать их у себя дома. Ничего плохого как про свои устройства, так и про сам майсенсорс сказать не могу. Работают хорошо, да и сам проект майсенсор постоянно обновляется, выходят новые библиотеки, короче, проект живой и перспективный. В основном, пользователи майсенсорс используют радиомодули для общения между устройствами. Есть поддержка RS-485, но почему-то она не такая популярная.

Всё как бы хорошо и радужно, но все же.... Cо временем мне пришло понимание того, что я хочу и чего не хочу при использовании умного дома. ИМХО что одним из слабых мест в работе экосистемы умного дома есть использование усторйств с радиомодулями. Это относится к вопросу - провод или радио? На эту тему есть ярые сторонники как с одной, так и с другой стороны, спорить не буду, это моё личное мнение. Особенно, это касается использования батарейных устройств, которые имеют ограниченный ресурс. Кстати, мне понравилось вот это видео на эту тему. В проводной умный дом можно интегрировать радиоустройства и прочее (MajorDomo это позволяет сделать без всяких проблем), но радио не должен быть основным каналом, и это первое что я хочу изменить. Второе - это децентрализация. К сожалению, MуSensors не соответствует данным требованиям, и поэтому я оставляю его у себя как вспомогательный.

Вернемся снова к xRoom. xRoom будет иметь несколько модификаций, отличающиеся нижними платами. Верхняя плата для всех модификаций будет одна и та же. Она будет наподобие платы Arduino с микроконтроллером STM32F407, но с наличием интерфейсов связи (Ethernet + RS-485) и дополнительной защитой для входов/выходов. Формат нижней платы, а точнее перечень её железа, будет определять предназначение самого контроллера. Применение контроллера будет дифференцироваться в зависимости от помещения или, так сказать, по-английски, Room-а. Отсюда первая (основная) догма - для обслуживания различных помещений требуются определённый набора "железа" в контроллере. Например, для применения xRoom на кухне, уклон должен делаться на датчики, снятие показаний со счётчика, управление светом, движение. В ванной - уклон на датчики, свет, теплый пол, а в жилой комнате уклон на свет, розетки, жалюзи, движение и т.д. На рис. 1 показана топология расположения различных модификаций xRooma в квартире.
xRoom_01.jpg
xRoom_01.jpg (27.29 КБ) 2826 просмотров
Рис. 1. Топология контроллеров xRoom.

На первый взгляд функционал пересекается, но вот пропорции различных датчиков и актуаторов (синие прямоугольнички) для различных помещений точно будут отличаться (по крайней мере в моём случае).

Вторая догма - работа каждого контроллера должна быть автономной и децентрализованной, по заранее заложенной в него программе. Все контроллеры должны быть равноправны и подчиняться более высокому по архитектуре контроллеру. В моём случае это будет RPI3, на котором будет крутится MajorDomo. Контроллеры не должны инициировать передачу данных или любых других запросов в магистрали, связывающей межкомнатные контроллеры (красная линия на рис. 1), а только обрабатывать их. По данной магистрали MajorDomo будет собирать статистические данные контроллеров и позволит организовать дополнительный канал управления, функцией которого будет осуществление межкомнатного взаимодействия между контроллерами.

А где тогда основной? Основное управление контроллером, и, соответственно, подключенными к нему узлами, осуществляется по специальному алгоритму, реализованному в виде загруженной программы. Например, нажимая на кнопку установленного на стене включателя, мы получаем сигнал на включение лампы и включаем её. Но если мы хотим выключить ту же лампу с помощью телефона, нам надо отправить команду на выключение через дополнительный канал. Для этого мы заходим на веб интерфейс MajorDomo и нажимаем на соответствующую кнопку (или вызываем из какого-либо сценария).

Магистраль, связывающая устройства внутри комнаты (зелёная линия на рис. 1), обслуживается внутренней программой контроллера, на ней строится внутренняя подсеть. К данной подсети планируется подключать датчики, панели отображения или дополнительные контроллеры имеющие RS-485 интерфейс. Сам xRoom в такой магистрали будет служить мастером. Таких вспомогательных магистралей может быть несколько. Как межкомнатная, так и внутрикомнатная магистрали будут основываться на стандартных интерфейсах Ethernet и RS-485. Отсюда и третья догма - все сосновые каналы связи и управления - проводные, а протоколы обмена - стандартные. Для Ethernet это будет MQTT или Modbus TCP, а для RS-485 Modbus RTU.

Работа сети RS-485 по протоколу модбас, в основном, строится по схеме мастер-слейв. То есть одному физическому порту любого устройства может назначаться один из этих режимов работы, а во всей сети может быть только один мастер. Одновременная работа в режимах мастер и слейв требудет нескольких физических портов, причем появление нового мастера - это новая подсеть. Топология на рис. 1 построена именно по этой схеме. Использование Ethernet даст возможность на одном физическом порту организовать несколько каналов, подключаемых через разные виртуальные (логические) порты. Это значительно расширит функциональность.

Проводной умный дом требует решения проблемы с большим объёмом проводов. Зачастую такой вариант приемлем на стадии ремонта/стройки, когда эту проводку можно скрыть. Либо укладывать её в короба и пускать наружу. Также, этот вариант будет дороже по стоимости. По данному вопросу рекомендую к просмотру вот это видео.

В начале статьи я не зря охарактеризовал xRoom как ПЛК, он действительно будет таковым. Имеющиеся на рынке ПЛК мне не подходят из-за ориентации их железа на производственные потребности. Возможно, появилось уже что-то новое и я об этом не знаю. Если у кого-то есть такая информация - делитесь. Что касается программирования (загрузки управляющего алгоритма), а если боле точно, то загрузки FBD программы, в этом мне поможет один из моих партнеров - компания производитель ПЛК для систем автоматизации. На данный момент я не буду оглашать название этой компании по понятным соображениям. Они предоставляют мне возможность использования своих наработок в этой сфере, а именно среду программирования FBD. Из таких блоков будет строится алгоритм управления контроллером. Главный плюс в этом, это возможность составить алгоритм управления контроллером людьми не имеющими навыков программирования.
xRoom_02.jpg
xRoom_02.jpg (75.21 КБ) 2826 просмотров
Рис. 2. Подключение контроллера xRoom.


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

Для межкомнатных магистралей используются гальванически развязанные проводные интерфейсы, а для внутрикомнатной - обычный RS-485.

Первый прототип контроллера (точнее верхней платы, см. рис. 3) находится на этапе тестирования. В следующей статье я подробно о нём напишу. Возможно, к этому времени будет спаяна и нижняя плата.
xRoom_03.jpg
xRoom_03.jpg (716.65 КБ) 2826 просмотров
Рис. 3. Верхняя плата контроллера xRoom.

К концепту ещё есть целый ряд разнообразных вопросов, на которые у меня пока нет ответов. Например, где в комнате устанавливать контроллер? Как вести от него шлейф проводов? Как разрулить команды, которые одновременно приходят от физических элементов управления и от MajorDomo для одного и того же ресурса? И многое другое... Поэтому, буду рад конструктивной критике и предложениям, которые позволят двигаться вперёд.

Теперь хотелось бы подытожить всё описанное выше.

1. Умный дом должен быть проводным.
2. Одна комната/помещение - один контроллер.
3. Децентрализация и автономность - это must have в таких системах.
4. Объединение надёжности работы ПЛК с кастомным решением по железу даст хороший девайс.
5. Простое и понятное создание прикладной программы на основе FBD блоков даст возможность вовлечь в этот процесс "обычных смертных" (людей не обладающими навыками программирования).
Raspberry PI3 + образ 3.31 | MDMSGate | Lighting | LightingX2 | Power | Multisensor
Chainik
Сообщения: 1386
Зарегистрирован: Вс янв 10, 2016 11:05 am
Благодарил (а): 228 раз
Поблагодарили: 433 раза

Re: xRoom. Введение

Сообщение Chainik » Пн авг 19, 2019 5:08 pm

Больше контроллеров хороших и разных!

Ситуация у тех, кто заинтересовался темой УД, как правило, делятся на 2 варианта: 1) проводка не сделана и 2) провода "похоронены" под чистовой отделкой. Даже если ремонта еще не было, человек, зачастую, не представляет, что ему понадобится, где это будет находится и как в итоге будет организована работа всего этого хозяйства.
У кого ремонт остался позади, остается единственный вариант - беспроводные технологии. Они вынуждены покупать дорогие фирменные решения. Некоторые, правда, "дружат с паяльником" и способны "наколхозить" что-то самостоятельно. Но таких меньшинство.

Основной вопрос при использовании беспроводных технологий (помимо надежности работы сети) заключается в том, что датчики все равно надо как-то запитывать. Тут опять 2 варианта: батарейки или миниатюрные преобразователи (220 > 12/5/3,3 В), т.е. без "розетки" не обойтись.

Мне кажется (а я, будучи "чайником", имею право на дилетантское мнение), что "на коне" будет тот, кто заставит надежно работать дешевые датчики с Али (50 - 200 руб.) "по воздуху" с одновременным обеспечением легкой интеграции устройства в систему УД.
Мое некомпетентное вИдение этого такое: должно быть некое миниатюрное и недорогое устройство, содержащее преобразователь питания (220 > 12/5/3,3 В) и некий беспроводной интерфейс. В это устройство мы втыкаем датчик (1-wire, I2C, АЦП и т.д.), либо подключаем "железку", работающую по принципу "замкнуто/разомкнуто" (выключатель без фиксации, геркон, датчик движения, датчик протечки и т.д.).
Как дополнительный вариант - исполнение этого устройства для питания от батарейки.

А дальше с нашими устройствами "общается" сервер. Либо напрямую, либо через промежуточную "железяку-хаб".
Разумеется, обязательно должна быть обеспечена обратная связь: мы в любой момент должны иметь возможность со стороны сервера "спросить", какое значение параметра на конкретном датчике, или в каком состоянии находится конкретный геркон. С моей точки зрения, не нужно, чтобы наши устройства сами посылали значения с подключенных к ним датчиков при изменении, а с другой стороны, устройства всегда должны посылать серверу (или промежуточному хабу) сигнал при срабатывании выключателей, герконов, датчиков движения и т.д. Но это уже вопрос идеологии и веры. :)

И еще вопрос, знакомы ли вы с контроллерами MegaD?
Последний раз редактировалось Chainik Пн авг 19, 2019 5:39 pm, всего редактировалось 1 раз.
stellhawk
Сообщения: 262
Зарегистрирован: Чт ноя 08, 2018 5:51 am
Благодарил (а): 10 раз
Поблагодарили: 82 раза

Re: xRoom. Введение

Сообщение stellhawk » Пн авг 19, 2019 5:19 pm

встает вопрос цены. сколько по деньгам для потребителя обойдется плата контроллера?
kalina
Сообщения: 180
Зарегистрирован: Пн фев 22, 2016 11:01 pm
Благодарил (а): 29 раз
Поблагодарили: 90 раз

Re: xRoom. Введение

Сообщение kalina » Пн авг 19, 2019 7:29 pm

Chainik писал(а):
Пн авг 19, 2019 5:08 pm
И еще вопрос, знакомы ли вы с контроллерами MegaD?
Ознакамливался с их характеристиками на сайте производителя. Лично не работал. Это, наверное, наиболее близкий аналог того, что я хочу сделать. Есть ряд моментов (хардварных) которые меня не устраивают. В целом девайс отличный!
stellhawk писал(а):
Пн авг 19, 2019 5:19 pm
встает вопрос цены. сколько по деньгам для потребителя обойдется плата контроллера?
На данный момент есть идея и прототип (не полностью спаянный), а вот видения цены, и вообще коммерции в целом, пока нет.
Raspberry PI3 + образ 3.31 | MDMSGate | Lighting | LightingX2 | Power | Multisensor
stellhawk
Сообщения: 262
Зарегистрирован: Чт ноя 08, 2018 5:51 am
Благодарил (а): 10 раз
Поблагодарили: 82 раза

Re: xRoom. Введение

Сообщение stellhawk » Пн авг 19, 2019 8:15 pm

kalina писал(а):
Пн авг 19, 2019 7:29 pm
Chainik писал(а):
Пн авг 19, 2019 5:08 pm
И еще вопрос, знакомы ли вы с контроллерами MegaD?
Ознакамливался с их характеристиками на сайте производителя. Лично не работал. Это, наверное, наиболее близкий аналог того, что я хочу сделать. Есть ряд моментов (хардварных) которые меня не устраивают. В целом девайс отличный!
stellhawk писал(а):
Пн авг 19, 2019 5:19 pm
встает вопрос цены. сколько по деньгам для потребителя обойдется плата контроллера?
На данный момент есть идея и прототип (не полностью спаянный), а вот видения цены, и вообще коммерции в целом, пока нет.
хотя бы не о коммерции речь. а о себестоимости. железка на вид приличная и стоит не мало должна.концепция может и хороша но может просто проверку ценой не пройти
akouz
Сообщения: 247
Зарегистрирован: Ср июл 09, 2014 3:48 pm
Благодарил (а): 6 раз
Поблагодарили: 40 раз

Re: xRoom. Введение

Сообщение akouz » Вт авг 20, 2019 12:12 pm

Когда-то давным-давно, в прошлой жизни, я десять лет был разработчиком ПЛК и распределенных систем АСУ ТП. А потом, тоже очень давно, почти 25 лет назад, судьба забросила меня в фирму, которая делала (и до сих пор делает) оборудование для "умного дома". Тогда это было большой экзотикой.

И, конечно же, поначалу я фыркал, что, мол, для "умного дома" они все делают неправильно: надо ставить ПЛК, интерфейс RS485, Модбас, и т.д., и т.п., все по списку. Но, поработав в этой области изрядный срок (я уволился оттуда через 8 лет) и поварившись в специфике "умного дома", я понял, что был неправ. Решения, наработанные для промышленной автоматизации, неоптимальны для автоматизации домов.

Я думаю, со временем вы это тоже поймете.
kalina
Сообщения: 180
Зарегистрирован: Пн фев 22, 2016 11:01 pm
Благодарил (а): 29 раз
Поблагодарили: 90 раз

Re: xRoom. Введение

Сообщение kalina » Вт авг 20, 2019 5:26 pm

akouz писал(а):
Вт авг 20, 2019 12:12 pm
Когда-то давным-давно, в прошлой жизни, я десять лет был разработчиком ПЛК и распределенных систем АСУ ТП. А потом, тоже очень давно, почти 25 лет назад, судьба забросила меня в фирму, которая делала (и до сих пор делает) оборудование для "умного дома". Тогда это было большой экзотикой.

И, конечно же, поначалу я фыркал, что, мол, для "умного дома" они все делают неправильно: надо ставить ПЛК, интерфейс RS485, Модбас, и т.д., и т.п., все по списку. Но, поработав в этой области изрядный срок (я уволился оттуда через 8 лет) и поварившись в специфике "умного дома", я понял, что был неправ. Решения, наработанные для промышленной автоматизации, неоптимальны для автоматизации домов.

Я думаю, со временем вы это тоже поймете.
Я не считаю решения для промышленной автоматизации в чистом виде приемлемыми для домашней автоматизации. Основное что я хочу позаимствовать - это надёжность. MajorDomo и прочие современные достижения никуда не денутся.

Где-то я слышал про объяснения мужа жене, что в туалете не работает свет из-за того, что лёг сервер. Так вот, у меня похожая ситуация)) И похоже терпение жены подходит к концу)) Может и я частично рукожопый, но мне наконец-то пришло понимаю того, как сделать работу автоматизации более надёжной. Это я и описал выше. Но для этого придётся жертвовать ремонтом....

К концу недели должны прийти печатные платы для "нижних" плат контроллера. Я постараюсь сразу же их спаять, проверить и написать следующий пост/статью про первый контроллер xRoom. Тогда будет понятней мой концепт в железе.

Хотел у вас спросить, в чём именно вы были неправы?
Raspberry PI3 + образ 3.31 | MDMSGate | Lighting | LightingX2 | Power | Multisensor
akouz
Сообщения: 247
Зарегистрирован: Ср июл 09, 2014 3:48 pm
Благодарил (а): 6 раз
Поблагодарили: 40 раз

Re: xRoom. Введение

Сообщение akouz » Ср авг 21, 2019 3:05 am

kalina писал(а):
Вт авг 20, 2019 5:26 pm
Хотел у вас спросить, в чём именно вы были неправы?
В том, что хотел наработки пром.автоматики применять для УД.

---------------

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

ПЛК в своем классическом виде является хорошим тому примером. Гальванические развязки везде где только можно, магистрально-модульная архитектура для быстрой замены блоков, развитая самодиагностика, и т.п. Языки программирования ПЛК - это отдельная песня, укромная гавань для посвященных, эклектическая смесь ассемблера (IL), релейно-контактных схем (LD), логических схем (FBD), Модулы (ST) и диаграмм состояний (SFC). Все это застандартизовано, застыло навеки и пахнет нафталином.

Программа в ПЛК исполняется максимально быстро, по кругу, снова и снова, чтобы сбой в одном из циклов исполнения не успел оказать существенного влияния на техпроцесс. Исполняющий основной цикл процессор не должен отвлекаться ни на что другое, любые сложные программы ему противопоказаны. Он непрерывно должен лупить основной цикл: "ввод - программа пользователя - вывод", все остальное должны делать вспомогательные процессоры. Конечно, сейчас развелось множество "почти ПЛК", в которых ради удешевления все задачи взвалены на один микроконтроллер, но это в ущерб надежности.

---------------

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

Любые централизованные системы, в том числе ПЛК (как частный случай), крайне нежелательны, даже как составная часть общей системы. B идеале надо все "раздробить" до уровня, когда каждый выключатель "разговаривает" с назначенным ему реле самостоятельно и независмо от кого бы то ни было. Полностью децентрализованная система позволяет наращивать и изменять функционал "по кусочкам", частями. Соответственно, идеальная парадигма надежности УД - "мягкая деградация", когда выход из строя отдельного устройства ломает только какую-то связанную с ним мелкую функциональность, нo не оказывает влияния на работу всей системы и не доставляет больших неудобств пользователям. И все это на фоне жестких требований к цене и к простоте инсталляции.

Интерфейс со свободной топологией прокладки кабеля, без терминаторов. "Мастер-слэйв" означает централизованныю систему, значит, не годится для УД: мастер упал - все перестало работать. Нужен "производитель-потребитель": любой (производитель) может отправить широковещательное сообщение когда угодно, а кому надо (потребитель) услышит и использует его. Примеры: KNX, CAN.
За это сообщение автора akouz поблагодарил:
kalina (Чт авг 22, 2019 1:07 pm)
Рейтинг: 1.18%
akouz
Сообщения: 247
Зарегистрирован: Ср июл 09, 2014 3:48 pm
Благодарил (а): 6 раз
Поблагодарили: 40 раз

Re: xRoom. Введение

Сообщение akouz » Чт авг 22, 2019 3:54 pm

Рано или поздно ломается все.

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

Однако есть еще одно "но". Чаще ломаются деталюшки, работающие на пределе или за пределами своих возможностей.

Самое простое - перегрев. Здесь действует закон де-Граафа, известный еще из (советского) школьного курса химии: "скорость химической реакции увеличивается в 2 раза при повышении температуры на 6 градусов". Например, практически в прямом виде этот закон можно применить для расчета ожидаемого времени жизни электролитических конденсаторов: если конденсатор по даташиту имеет время жизни 1000 часов при 85С, то расположенный рядом с нагревающимися деталями и в рабочем режиме имеющий темературу 55С, он проживет примерно 1000*(2^5) часов, то есть, около 3 лет, после чего имеет полное право сдохнуть. В аналогичных условиях "долгоживущий" электролитический конденсатор, имеющий время жизни, скажем, 2000 часов при 105С, "проживет" в среднем примерно 63 года. Большая разница. Тех, кто заинтересуется подробностями, отшлю к весьма достойной книге Лонгботтома "Надежность вычислительных систем", М, 1985

Если покупать дешевые китайские изделия от неизвестно-каких-производителей, то весьма вероятно нарваться на детали, которые будут работать от силы несколько лет, после чего имеют законное право сдохнуть. Если покупать дорогие изделия европейских или американских производителей "с именем", то более-менее вероятно получить надежное и долговечное изделие. Хотя, конечно, "полную гарантию дает только страховой полис" (с). В качестве примера, последняя купленная мною лампочка Филипс проработала всего неделю и бездарно сдохла.

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

Но заранее, без детального анализа, сказать насколько долговечной и надежной будет та или иная система, практически невозможно. Так что неизвестно какой "промышленный ПЛК" в смысле надежности - отнюдь не панацея, а просто кот в мешке.
За это сообщение автора akouz поблагодарили (всего 2):
Chainik (Чт авг 22, 2019 5:02 pm) • kalina (Чт авг 22, 2019 7:31 pm)
Рейтинг: 2.35%
Chainik
Сообщения: 1386
Зарегистрирован: Вс янв 10, 2016 11:05 am
Благодарил (а): 228 раз
Поблагодарили: 433 раза

Re: xRoom. Введение

Сообщение Chainik » Чт авг 22, 2019 5:12 pm

Надежнее всего не использовать ничего сложнее каменного топора. Точно не подведет! :)

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

На самом деле очень многое зависит от грамотности производителя "железа". От того, насколько правильно все спроектировано, от подбора (и тщательного тестирования) отдельных комплектующих и конечного продукта. При большом количестве подделок - задача непростая (https://ab-log.ru/forum/viewtopic.php?f ... 5&start=94).
Ответить