toksoft

По такой цене - другого там просто быть не может, но кажется меня уже кто-то опередил: github.com/fvollmer/open-desk-lamp-firmware Еще фокус не наводил, но в общем проблем не вижу. Что касается сервера,- то нужна логика обмена, протокол. tcp connections в общем удовольствие недешевое для realtime system. В плане времянок.

Таки да. Подскажите пожалуйста 1. Ссылку на ali на лампочку имени Xiaomi 2. Она цветная/диммируемая ? Я подозреваю что внутри таки 8266, а значит можно перезалить свою прошивку. Даже если что-либо другое, думаю можно будет побороть. Самое ценное в этой лампочке - это корпус. Этого я, к сожалению, повторить не смогу. Все остальное проблем не представляет. Мой концепт - отсутствие централизованного сервера. От слова совсем. Только тонкий клиент (browser). Если заморачиваться с мобильным клиентом, то его придется сопровождать. Лениво.

dhcp это отдельный вопрос. Обращаться будет полюбэ, и получит новый (или тот-же) адрес по окончанию lease time. dhcp кстати broadcasts шлет вне зависимости от того, хочет этого клиент или нет. ping - это другой тип запроса: icmp (en.wikipedia.org/wiki/Ping_(networking_utility). Кажется type 13. Его можно использовать как индикатор, но отнюдь не как критерий прошли пакеты или нет. Что касается бесшовного роуминга, то на самом деле можно использовать обычные точки доступа, подключенные к специальному коммутатору. Например такое решение: local.com.ua/forum/topic/69151-%D0%BF%D1%80%D0%BE%D0%B4%D0%B0%D0%BC-%D1%82%D0%BE%D1%87%D0%BA%D1%83-%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%B0-motorola-ap650-dual-ext-mesh-%D0%B1%D0%B5%D1%81%D1%88%D0%BE%D0%B2%D0%BD%D1%8B%D0%B9-%D1%80%D0%BE%D1%83%D0%BC%D0%B8%D0%BD%D0%B3/?tab=comments#comment-715088 Скорость соединения (а именно авторизации, например WPA2), зависит от TX/RX кристалла, и расстоянием до WiFi access point. dhcp - это уже другой протокольный уровень. При этом абсолютно пофиг будет это одна точка доступа или несколько. Главное выбрать ту, которая принимается лучше. Это все можно определить еще на этапе connectа, т.к. access point передает все эти параметры в широковещательных пакетах (не IP) . WiFi client может "на ходу" передоговариваться об использовании той или иной полосы частот (каналов). В разных странах, часть каналов может быть запрещена для использования, например от 13 и выше. Иногда есть еще ограничения на TX access point. Как правило из интерфейса не конфигурится (то, что не разрешено), но через cli (если есть) - с легкостью. Все это можно увидеть своими глазами, установив на компьютере соотв. утилиту, например WireShark, и поставить нужный фильтр. Это то, что касается уровня протокола, не транспорта (ARP запросы увидите). Если хочется посмотреть "в живую" на детали обмена протоколом на уровне транспорта WiFi, то можно использовать например ESP8266, или ESP32. Это из доступных и дешевых. В качестве мониторилки пакетов WiFi. Основная проблема,- это если оконечное устройство упрямо пытается "вцепиться" в access point, к которому оно было подключено раньше, вне зависимости от качества сигнала, и наличия других точек доступа, которые принимаются лучше. Это вопрос к firmware устройства.

1. local.com.ua: Кажется около 2000грн. Это не самая большая проблема. 2. Как вы себе представляете бесшовный роуминг имени WiFi ? Это ведь не GSM, в котором терминал защелкивает 5 БСок, и теоретически может переключаться между ними, без разрыва связи. Есть набор подчастот (канал в терминах WiFi), есть возможность перенегошиэйтить канал, есть b/g/n, есть уровень сигнала, устройства каждые ~100ms отправляют beacons, ... Переключение с одной точки доступа к другой, полюбэ потянет за собой повторную авторизацию. Это в общем больше от клиента зависит. Чисто теоретически, можно подключить несколько точек доступа, с абсолютно идентичной геометрией, зацепить их на это самое чудо-устройство путем проводов, и тогда останутся только проблемы "на стыке", т.е. в тех зонах, в которых сигнал от одной точки низкий, но по прежнему присутствует, а от другой более мощный. Что касается самого WiFi, мне кажется вы как-то его "не так" рассматриваете. Это такой себе транспортный протокол (на самом деле набор 10+ стандартов), который достаточно хорошо описан и стандартизирован, и в который можно инкапсулировать IP, который в общем то тоже описан до мелочей. В любом случае, WiFi никак не участвует в цепочке "от провайдера до шлюза", и никак не влияет на доступность шлюза. IP протокол в общем можно построить поверх любого транспортного,- хоть например через LORA, несмотря на 300 бод скорость. Не суть.

У проблемы есть 2 стороны: 1. Локальные проблемы, связанные с видимостью WiFi маршрутизатора/маршрутизаторов, с которыми соединяются оконечные устройства 2. "Глобальные проблемы", связанные с тем, что пакеты из вашей внутренней сети, уходят во внешний мир. Иногда достаточно далеко - в Китай например. Если проблема номер раз может быть решена относительно просто (бесшовный WiFi), или по простому, можно задать то-же имя (SSID) для каждого из маршрутизаторов - и проблем нет. В этом случае BSSID будут различаться, но имена (SSID) останутся такими-же. В списке доступных сетей просто появятся несколько WiFi точек доступа с одинаковыми именами. Можно кстати и с разными. Можно так же использовать WiFi "удлинители". То есть эта проблема решается достаточно просто. Вторая проблема,- это когда вендоры в обязательном порядке навязывают необходимость использования централизованного шлюза, мотивируя это разными "шашечками", типа "из любой точки мира", ... В общем неплохая идея, но в этом случае очень уместно "дорогая, подожди заходить в туалет, нужно перезагрузить WiFi точку доступа - и тогда появится свет". В этом случае мы зависим от: 1. WiFi access point 2. Доступность локального интернет-провайдера 3. Доступность транспортной сети от местного провайдера до сервера (шлюза) 4. Доступность самого шлюза Немного абсурдно: Оборудование установлено у вас. Все внутренние коммуникации, включая WiFi, который в общем-то не сильно зависит от внешних ресурсов (кроме некоторых моментов) по прежнему работают как часики, и тут локальный провайдер решает перезагрузить скажем свой BGP router. Минут 10 минимум. Занавес. Все это время, устройства, которые по сути своей обладают достаточной автономностью для непрерывной самостоятельной работы, превращаются в набор деталей, плат и корпусов. И такими останутся, потеряв свою ценность до 0, если по какой-либо причине vendor не сможет поднять свой шлюз, или примет решение о прекращении предоставления сервиса. Или по каким-либо причинам, в стране будет принята (не дай Бог конечно) какая-либо политика ограничения доступа к ресурсам внешнего мира, в рамки которой, по нелепой случайности, могут попасть подсети адресов, на которых развернуты шлюзы и их зеркала/реплики. К сожалению, в нашей стране, понятие SLA в применении к локальному провайдеру интернет - пустой звук. Дырка от бублика то есть. Если отключат инет на скажем час,- ессно будут возмущенные звонки в support, но это пожалуй и все. Коммерческая модель предоставления сервисов с SLA стоит денег, поэтому вендоры, которые поддерживают работоспособность шлюзов, оплачивают затраты на электроэнергию, зарплату обслуживающему персоналу, ... пытаются монетизировать сервис, предоставляя какой-либо минимальный набор услуг (бесплатный), с возможностью платного расширения. Эксплуатационные расходы то есть. Есть конечно вариант поднять локальный сервер, но это требует времени, квалификации, и по прежнему стоит денег - например за электроэнергию, которую потребит этот самый сервер.

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

Добавил поддержку еще пары сенсоров, итоговый список такой: 1. DS18B20 (датчик температуры) 2. DS1822 (датчик температуры) 3. DS18S20 (датчик температуры) 4. DS1820 (датчик температуры) 5. DHT11 (датчик температуры и влажности) 6. DHT21 (датчик температуры и влажности) 7. AM2301 (датчик температуры и влажности) 8. DHT22 (датчик температуры и влажности) 9. AM2302 (датчик температуры и влажности) 10. BMP180 (датчик температуры и давления, i2c) 11. BMP280 (датчик температуры и давления, i2c) 12. BME280 (датчик температуры, влажности и давления, i2c) 13. Si7020 (датчик температуры и влажности, i2c) 14. Si7021 (датчик температуры и влажности, i2c) 15. HTU21D (датчик температуры и влажности, i2c) 16. HDC1080 (датчик температуры и влажности, i2c) 17. TMP102 (датчик температуры, i2c) 18. LM75A (датчик температуры, i2c) 19. MCP9808 (датчик температуры, i2c) 20. SHT3X (датчик температуры и влажности, i2c) 21. MPL3115A2 (датчик температуры и давления, i2c) 22. MLX90614/MLX90615 (безконтактный датчик температуры, i2c) 23. TMP006 (безконтактный датчик температуры, i2c) 24. CCS811 (датчик CO и VOC, i2c) 25. BME680 (датчик температуры, влажности, давления и качества воздуха, i2c) 26. MS5611 (датчик температуры и давления, i2c) 27. MAX44009 (датчик освещенности, i2c) 28. BH1750 (датчик освещенности, i2c) 29. TSL2561 (датчик освещенности, i2c) Обновленная инструкция:www.stroimdom.com.ua/forum/attachment.php?attachmentid=645996&stc=1&d=1547502972 Как подключать: www.stroimdom.com.ua/forum/attachment.php?attachmentid=645998&stc=1&d=1547503024 Выложил для "посмотреть" прошивку и образ файловой системы: www.upload.ee/files/9427259/Thermostat_v12.rar.html Заработает на ESP8266 E/F/S. Образ FS под 4Mb (1+3). При подключении сенсоров, нужно понимать что 2 пуллапа имени 4.7к это для dev плат, если есть желание подключить "голый" сенсор - то нужно смотреть на схему подключения, и добавить пару пезисторов и конденсатор (согласно мануалу для каждого из сенсоров). Полярность подключения сенсоров (3.3v) желательно не перепутать, сенсор сгорит, т.к. защитный диод редко кто ставит. Cntr_Man_v1_1_rus.pdf Schema.pdf

Я в качестве пробы вмуровал в бетон 2х жильный электрический обогрев, имени 500Wt. И заложил сверху "нескользкой" плиткой. Года 2 назад. Теперь не использую, действительно, выключил,- и через минут 15 начинает появляться корка. За ночь образуется хорошая скользанка, разбить которую можно только ломом, ну или не выключать обогрев вообще. Площадь небольшая, но держать на поcтоянке 3+ месяца - немного дороговато ...

Добавил поддержку сенсора MAX44009 (освещенность в люксах). С интересом обнаружил что мои led lamps на самом деле далеки от заявленных характеристик "эквивалент 100/120Wt лампы накаливания". То есть глазами это воспринимается как яркий свет, но сенсор с этим не согласен. В принципе логично,- интегральная характеристика какой-то части спектра, которую честно сполняет сенсор. 12Wt led (e27) - около 70lx. Визуально - ярче чем 100Wt лампа накаливания.

Попробуйте "перевернуть" розетку при включении в 220В. 2 попытки. Судя по схеме,- должно помочь.

Получил наконец все возможные модификации MLX90614/15. Всего 4 разные модели. Оказалось что одна из модификаций MLX90614 двухлучевая. Как-то не обратил внимания вначале. 1 лучевой сенсор возвращает 2 параметра: 1. Температура объекта 2. Температура окружающей среды (ambient temperature) В случае 2х лучевого - 3 значения температуры. Диаграмма направленности и как использовать, достаточно неплохо описана в документации. 14/15 отличаются адресами регистров, и битовой маской некоторых регистров. У 14го есть уникальный идентификатор, состоящий из 4х байт. Что-то типа vendor id, model id и серийного номера кристалла. У 15-го - из 2х байт,- только vendor id/model id. У всех 4х vendor/model id оказались разными. В документации никакой информации касательно того, какие должны быть серийные номера. Извожу вендора, хочу получить детальное описание. Сенсор можно "на лету" перестроить на другой i2c адрес (ясное дело до 0x7f). Перезагрузка не обязательна, можно "извернуться" и без перезагрузки. Имея исходники общим объемом порядка 23000 строк плюсового кода, наконец то заставить компилятор оптимизировать "правильно". Меньше статических переменных - больше динамики,- и тогда единственное ограничение (для ESP8266) - это объем flash, который для 4Мб, позволяет загрузить около 570k бинарного кода (OTA). Если больше - то тоже можно, но уже только через шнурок. Можно конечно подрихтовать flash map, но ессно только путем уменьшения либо области EEPROM, либо файловой системы. Есть сборки с уже установленными 16Мб flash, но тут мне похоже крупно не повезло: пришла сборка с памятью, которая пишется только блоками по 1024 байта, т.е. сначала трем, потом пишем весь блок. Соотв. свободный RAM "просел" с 25kb до 23 с копейками.

В общем конечно не проблема. Есть другие ограничения, над которыми я пока думаю: 1. 10 разрядный АЦП. 2. NTC резисторы обычно имеют нелинейную характеристику (логарифмическую), и посчитать итоговую температуру можно 2 способами: a) B25/50 или B25/100, зная номинальное сопротивление при 25С - это обычно всегда указывается для любого NTC b) По 2 или 3м точкам (помимо известного сопротивления при 25С) 3. Термистор во время работы нагревается, и это тоже нужно учитывать. Этот параметр обычно указывается как Dr/Dt, и не всегда присутствует в случае "непородистых" NTC 4. Есть разные номиналы NTC, начиная например от 4.7Ohms до 100к, соотв. если делать универсальную систему, то нужно заморачиваться с широкодиапазонным DigiPot, который без прожига washer. Либо с несколькими, для разных диапазонов. Выбор NTC с нужным сопротивлением, зависит от того, на каком "конце" диапазона вы хотите получить максимальную точность измерений. Либо "универсальный" 10-15k, который будет достаточно точно измерять температуру "посередине", скажем от 0 до 60C. Дальше пойдет неслабая погрешность в измерениях. Я даже пробовал вычислять B25/50 у пары NTC, которые у меня были (от "породистых вендоров"). То есть типа моделировал ситуацию "сгорела плата контроллера, подставляем свой". Вопрос как подключить, и что (или как) выносить в интерфейс. Система и так получилась уже не сильно простой, и усложнять ее дополнительными параметрами, которые понятны достаточно узкому кругу специалистов, я не вижу особого смысла. Есть еще небольшое технологическое ограничение: В 2х юнитовом корпусе, у меня поместилось по 6 терминалов подключения с каждой стороны. 1,2 - питание устройства, 3,4,5,6 - i2c, DHT, DS датчики, и по 3 контакта для каждого из реле с другой стороны. i2c, DHT и DS, не отличаются по электрическому подключению, во всех случаях pullups. Отличаются по способу (протоколу) обмена информацией с контроллером, У DS свой, у DHT свой, у i2c свой. Можно подключить либо кучу i2c датчиков, либо DS/DHT в любых комбинациях,- помимо питания, к 2м разным терминалам, которые используются для i2c. Терминал для аналогового сенсора мне вынести некуда, и стоит ли ? Пытался совместить одновременное подключения DALLAS (кстати тот-же корпус TO-92) и i2c - на тех же терминалах, теоретически возможно, практически пока не получилось. С прорисовкой времянок возни много. Учитывая стоимость DALLASов, я пока не стал заморачиваться с NTC сенсорами. Попробовал залить компаундом TMP102 (i2c, температура) в гильзе - работает. В принципе, в гильзе заработает любой, который не требует доступа к окружающей среде (влажность и давление). С давлением заказал на пробу один мембранный,- посмотрю что получится. Тут многие жаловались на то, что у ESP софтовая реализация 2wires, но была бы аппаратная,- я бы не смог совместить подключение всех доступных датчиков на одних и тех же терминалах. P.S. Судя по диаграмме, у MCP9700 линейная кривая зависимости температуры/напряжения, но это все-равно аналоговый сенсор.

Опаньки... Это как ? Что значит "легло все радио" ? Сутки присутствовала широкополосная помеха (сотни мегагерц) достаточной мощности, чтобы "погасить" как передатчики, так и приемники ? Или помеха была кратковременная, но достаточной мощности, чтобы пожечь приемники и/или передатчики ? Или может косячные прошивки оборудования, в которых не был предусмотрен мониторинг и авторестарт ? Фото зеленых человечков и ихнего средства передвижения у вас не осталось ? Что за "сказки на ночь" ?

Я к тому, что использование промышленного протокола и, даже возможно, промышленного железа, не делает само решение "промышленным".

Дык он же вроде как аналоговый ? Я пока старательно избегаю аналогов. Только цифра. Иначе придется DigiPot на пате ставить, 3 или 5% точность обычных резисторов (для делителя) будет явно недостаточно. Погрешность будет большая ...

Можно я попробую ? В чем отличие "промышленного" решения от любительского ? Это явно не оборудование. Сейчас можно скупить сравнительно за небольшие деньги (например на local.com.ua) вполне себе промышленное оборудование, которое ставится в data centers. Вопрос в том, как все эти элементы оборудования соединить между собой, как отконфигурировать, нужно не забыть просчитать тепловыделение и обеспечить вентиляцию, как минимум 2 PDU (Power distribution Unit). Когда строится новый datacenter/powerplant/... все это просчитывается заранее, централизованно закупается, к этому моменту уже есть планы протяжки кабельного хозяйства, размещения оборудования, электромагнитной изоляции, системы пожаротушения, систем информирования, ... Когда емкость центра исчерпывается - строят новый. По сравнению с глобальными расходами на все это хозяйство, покупка дополнительного контроллера или коммутатора - капля в море. В случае любительского решения, все может быть точно таким же, включая первоначальные планы. Оборудование может быть такое же, или даже "круче". Не проблема. Проблема в том, что даже в частном доме, есть такая штука как внутренняя отделка, включающая в себя плитку, финишные покрытия, ... Если что-либо забыл - фсе. Либо дальше не расширяемся, либо ковыряем стены/потолок/плитку. Смена платформы - процесс тоже достаточно болезненный, т.к. бюджет как правило ограниченный. Ну и решения приходится выбирать не те "которые правильные", а те, которые могут быть установлены в данном конкретном месте. Или может у вас на каждом этаже по серверной с кондиционированием и гарантированным питанием установлено ? Вряд-ли. Цена сопровождения может оказаться несколько великоватой (например замена аккумуляторов в UPSах, замена хладоагента в системах кондиционирования, хотя-бы раз в год проверять системы пожаротушения, ...). Беспроводные решения "выросли" именно из таких потребностей - мобильность и возможность относительно безболезненного переконфигурирования/перестановки. "промышленное" решение на текущий момент подразумевает под собой не "навороченное железо", а архитектура/бесперебойность/сопровождение. Для примера (мой случай),- вы в командировке, где-то далеко (12+ часов полета), звонит жена, и говорит что на 2м этаже пропал свет, и не работают розетки. Понятное дело - нужно звать электрика. Придет электрик, посмотрит на ваш зоопарк, и вежливо пошлет куда подальше. Предположим даже что вы дистанционно сможете указать один или более элементов сети, которые нужно проверить/заменить. А там все самописные/самопальные бляхи, и как они работают - знаете только вы. И все это не считая вороха проводов, которые присутствуют у вас в каждой из точек коммутации, в которых тоже сможете разобраться только вы.

1. В ESP память тоже не бесконечная. runtime как бы места немало занимает, остается порядка 40к RAM. 2. На счет паскаля для atmega/ESP - не слышал. На asmе трудоемко - больше времени занимает. Содержимое String, именно при таком подходе, может быть изменено внутри процедуры, а потом discarded при возврате из процедуры. Соотв. компилятор может зарезервировать место на стеке для нового инстанса содержимого String. const дает компилятору понимание того, что содержимое контейнера (String) меняться внутри процедуры не может, и резервировать место для строки на стеке не нужно.

Можно пару "добрых советов" ? 1. url = F("https://api.telegram.org/") ; 2. void sendmes ( const String mmes ), а еще лучше "&" или "*" 3. Naming convention

Добавил поддержку MLX90614/15 (безконтактное измерение температуры) и BME680. Бесконтактный датчик дает 2 показания температуры: температура объекта, и температура окружающей среды. Температуру объекта меряет достаточно точно, в принципе, возможно использование в качестве датчика обнаружения движения, на расстояниях до 3х метров. BME680 - монстр. Тяжело программится, за основу взял ессно "родную" библиотеку BOSCH. Монтажные отверстия на плате 1.75mm, вместо 2+mm, как на других платах с датчиками. По сравнению с BME280, более точно меряет относительную влажность, показания не так "прыгают". Температура и давление - отличий с BME280 не замечено. TVOC, или точнее сопротивление газа тоже в общем меряет неплохо, но нужно учитывать то, что показания стабилизируются через ~20 минут после каждого включения (вначале показания завышены - типа качество воздуха хуже). Все датчики "прогнал" через жесткий тест - 15 минут на конвекторе, потом 30 минут в морозильную камеру. Из победителей - TMP102. В течении ~17 секунд показания выходили на стабильные, как для конвектора, так и для морозильной камеры. В аутсайдерах - SHT30 и SHT31. Различаются отсутствием нагревательного элемента в младшей модели. В морозильной камере начал "косячить", приблизительно в течении минуты, перед тем, как показать реальные показания. HDC1080, который был у меня "эталоном", при резком изменении условий, тоже крайне медленно выходил на реальные показания температуры и влажности. Видать используется какой-то хитрый метод типа "половинного деления" при расчетах температуры.

Як цiкаво ... Есть компиляторы (+ linker), которые превращают текст программы в машинный код, а есть интерпретаторы, которым на вход подается примерно тот же самый текст (например "скриптовый язык"), который "превращается в код на лету". Иногда, интерпретаторы используют некие элементы компиляции, чтобы значит не парсить текст, а распарсить единоразово, превратив в некий псевдокод (метакод), исполнение которого интерпретатором, происходит гораздо быстрее. Беда интерпретаторов в том, что оные требуют относительно много ресурсов (камень + память, как минимум). Засовывать такого монстра в кристалл, с точки зрения здравого смысла, в общем не очень оправдано. Может быть оправдано экономией высококвалифицированных кадров (разработчиков), которых в случае скриптового языка можно впоследствии заменить более дешевым ресурсом. "недо-Java",- хороший пример. Человекочасов на разработку Java engine, было, я думаю, потрачено немеряно. Разработчики системы явно не горели желанием повторить полноценный Java (или Javascript) engine на своей платформе. А теперь внимание вопрос: А как система должна общаться с внешним миром ? Мониторинг/управление/конфигурирование ? Шнурками ? Я еще помню времена СМ4/1420, когда серийный интерфейс был одним из немногих доступных способов связать 2 устройства, и скорость 115200 была пределом мечтаний. А почему весь этот анахронизм перекочевал в 21й век, когда ethernet есть практически у всех устройств, а у тех у которых нет, есть WiFi ? С уже давно как устаканившимися стандартами и протоколами. Наверное потому, что когда-то, этот самый серийный интерфейс, за неимением более доступной альтернативы, был принят в качестве "стандарта", более чем 2 крупными компаниями. 9600kbps. Wow ... Это что за хня такая ? Если у кого-либо есть устройство, которое поддерживает serial, в той или иной его форме, то единственной целью этого устройства, должен быть link между физическим устройством (объектом мониторига/управления), и ethernet, или каким-либо другим скоростным промышленным контроллером, имеющим доступный, открытый и описанный протокол. Не, я конечно понимаю, что при проектировании, скажем data center, где-либо в SF или Bay Area, эnот самый serial interface может оказаться востребованным, причем по разным причинам, но нафига, спрашивается, тащить весь этот антиквариат, упакованный в современные красивые корпуса к себе домой, или в офис ?

1. А что такое "по настоящему программируемый" ? Вы хотите путем модификации кода реализовать все хотелки, или параматризацией параметров ? Детальные требования есть ? 2. C++: Начинайте прямо сейчас, тогда через год-полтора вас перестанут беспокоить вопросы "где, что, и почему так дорого". Начинающий плюсовик может рассчитывать на минимум 1500$ в месяц. Да, еще не забудьте, что плюсы на большом компьютере, это совсем не то, что на embedded device. 3 & 4. Хотите "промышленной надежности" ? Разрабатываете свою плату с изрядным "запасом", заказываете "промышленный монтаж", можно заказать заливку компаундом, если есть желание. Хоть проводное, хоть беспроводное. Пофиг. Комплектующие (процессоры, память, периферия, ...) одинаковые, как в "промышленном", так и в любительском решении. Вопрос в том, как они соединены между собой, на какой основе, чем экранированы, и еще миллион вопросов. Да,- делать "промышленное решение", при этом не озаботившись качеством кода ("да хоть С++ выучу") - дело абсолютно бесперспективное. То есть "по простому", вы наверное узнали стоимость комплектующих из которых собраны "промышленные решения" (не более 25% от стоимости конечного изделия), и решили что цена конечных решений необоснованно завышена ? Да, на сегодня элементная база доступна всем, google помогает с datasheets, но это почему-то не привело к тому, что у каждого в доме установлены свои собственные разработки. Подсказать почему ? P.S. Чуть не забыл: Если нет английского,- лучше не начинайте вообще. Купите какое-то готовое решение, и хорошо проведите сэкономленное время. 99% мануалов и спецификаций - они на английском.

Да не клею я никаких ярлыков. В схожей ситуации, мне пришлось уходить от так мной любимого бренда Elko/ETI. Вопросы цены и доступности. Сейчас на складах дорогостоящее оборудование никто особо не накапливает. Только предзаказ. P.S. Китайская комплектовка, модули, ... - сейчас неотъемлемая часть любого устройства.

Есть такие замечательные термины CAPEX (капитальные вложения) и OPEX (операционные затраты). В большинстве случаев, частные лица, сами того не осознавая, стараются увеличить капексы, с целью последующей минимизации опексов. В качестве капитальных затрат считаются как вложенные средства (оборудование, работа), так и свои ресурсы (время и усилия). И все это с целью минимизировать операционные затраты, чтобы значит в последствии не выкладывать ежегодно ~30% от суммы первоначальных вложений (предположим 15000$ * 0.3 =4500$). "породистое" вероятнее всего более надежное чем "беспородное", но стоимость сопровождения системы может оказаться "неподъемной", в конце концов даже если у вас есть "прямо сегодня" 20000$, которые вы готовы потратить на умный дом, то это не значит что у вас окажутся средства завтра, на сопровождение оного в будущем. Попытка "продаванов" путем "тонкого троллинга" "вытянуть" кэш из желающих, увенчается успехом только тогда, когда у этих самых желающих достаточно средств. Если оных (средств) нет, то затея бесперспективна, хотя конечно наверное "стимулирует" желающих зарабатывать больше, с целью типа, "инвестиций в будущее" В случае когда нет желающих вложить 15000$ в "породистую" систему, и потом ежегодно нести расходы на сопровождение, люди стараются в первую очередь получить желаемый ими функционал, ценой своих усилий, и удешевления стоимости оборудования. Я думаю что персонажи, которые готовы "прямо сейчас" выложить 15000$ за систему, и осознают какие операционные затраты ожидают их в будущем, просто не заходят именно на эту ветку форума.

www.espressif.com/en/products/hardware/esp8266ex/overview en.wikipedia.org/wiki/Tensilica 8266 не нуждаются в роутерах для обмена информацией друг с другом.

У ESP8266 можно менять TX level. Есть WatchDog, который sonoff "предусмотрительно отключили". Наверное, чтобы не нервировать клиентов перезагрузками. Итого - если косяк в прошивке - модуль "намертво" виснет. Я, прежде чем "делать свое", хотел использовать одну из альтернативных прошивок для sonoff, понял что проще написать с 0, чем рихтовать косяки.