toksoft

Прошло 9 дней с MQTT. Hаботает стабильно: При обрыве или пропаданию/появлению inet восстанавливает связь с MQTT сервером, все "неприятности" связанные с WiFi extender пофиксил на стороне кристалла. Таки реализовал все что планировал. Ну или почти все. Остались вопросы по аппаратной части, которые хотел, но пока не смог реализовать: 1. Универсальное питание 9 - 240V (пока только 90-240V). 2. Обнаружение 9 - 240V на управляющих входах (пока только 90-240V). Получилась следующая картина мира: Само устройство может работать как в автономе (без инет, конфигурирование через встроенную точку доступа), так и при наличии internet connection, т.е. помимо встроенной точки доступа, можно еще подключить к домашней сети. Статикой, или dhcp. Пр этом есть возможность управления через интерфейс, помимо конфигурирования программ. Если устройств несколько, то вне зависимости от наличия inet, они "разговаривают" друг с другом, т.е. если например к одному из устройств подключен выключатели, а к другому исполнители - будет работать пока не пропадет питание. С 2х сторонним MQTT возможности явно расширились, теперь осталось ими воспользоваться (HomeAssistant или что-либо другое). Для 2го аппарата (к которому подключаются датчики) реализовал аналогичную схему. Список поддерживаемых датчиков: DS18B20/DS1822/DS18S20/DS18S20/DS1820(датчик температуры) DHT11(датчик температуры и влажности) DHT21/AM2301 (датчик температуры и влажности) DHT22/AM2302 (датчик температуры и влажности) SHT1x (датчик температуры и влажности) AM2320(датчик температуры и влажности, i2c) BMP085(датчик температуры и давления, i2c) BMP180(датчик температуры и давления, i2c) BMP280(датчик температуры и давления, i2c) BME280(датчик температуры, влажности и давления, i2c) Si7020/Si7021 (датчик температуры и влажности, i2c) SHT2x (датчик температуры и влажности,i2c) HTU21D (датчик температуры и влажности,i2c) HDC1080(датчик температуры и влажности, i2c) HDC2080(датчик температуры и влажности, i2c) TMP102(датчик температуры, i2c) LM75A(датчик температуры, i2c) MCP9808(датчик температуры, i2c) SHT3x (датчик температуры и влажности,i2c) MPL3115A2 (датчик температуры и давления, i2c) LPS331AP/LPS25H (датчиктемпературы и давления, i2c) SPL06(датчик температуры и давления, i2c) MS5611(датчик температуры и давления, i2c) MS8607(датчик температуры, влажности и давления, i2c) MLX90614/MLX90615 (безконтактный датчик температуры, i2c) TMP006/TMP007 (безконтактный датчик температуры, i2c) CCS811(датчик COи VOC, i2c) SGP30(датчик CO2и VOC, i2c) BME680(датчик температуры, влажности, давления и качества воздуха, i2c) MAX44009(датчик освещенности, i2c) BH1750(датчик освещенности, i2c) TSL2561(датчикосвещенности, i2c) OPT3001 (датчик освещенности, i2c) VEML6070(датчик ультрафиолетового излучения UVA, i2c) VEML6075(датчик ультрафиолетового излучения UVA и UVB, i2c) SI114x (датчикосвещенности: Visible, IR, UV, i2c) Еще осталось реализовать поддержку пары TE датчиков давления и, пожалуй, хватит. После того, как снял со щитков и перепрошил 16 аппаратов, добавил возможность прошивки "по воздуху". "стандартный" OTA меня не устроил, пришлось писать свой. Все устройства "ходят наружу" только по 3м поводам: 1. DNS resolve 2. MQTT 3. Отправка управляющих пакетов аналогичным устройствам (включить, например, свет в Чернигове из Киева, при этом не используя никаких платформ и сервисов, кроме 2х устройств).

Плата обошлась около 1200 нрн, брал в аккурат вперед китайским новым годом. В реале выглядит так: На официальном сайте (www.orangepi.org/downloadresources/) есть несколько вариантов прошивок (образов). Я проверял с Debian Server Jessie и Ubuntu Server. Карта SD - 32Gb. Какой класс - честно говоря не знаю, достал из старого телефона. Сам образ состоит из 2х разделов: Второй раздел (ext4) я ессно отресайзил, т.к. на оставшиеся 200 с копейками килобайт особо ничего не доставишь. Получилось так: eth0 поднялась сразу (dhcp), особых чудес не замечено. Сборка, честно говоря, "немного сыроватая". Фрагмент из syslog Repository пакетов (apt-get) для платформы, как для меня - более чем. gcc есть, и он таки работает, все библиотеки на месте. С WiFi косяки следующие: nmtui глючит безбожно, как 2.4, так и 5gHz сеть находит через раз. Ну раз глючит, тогда можно воспользоваться традиционным методом /etc/network/interfaces.d/wlan0 и /etc/wpa_supplicant/wpa_supplicant.conf Так вроде-как работает, правда поднимает интерфейс (с получением адреса) минуты 3. Корпуса, на момент когда я покупал плату, не было, и это хорошо, т.к. оказалось что кристалл неслабо греется. Я запускал make в 4 потока - нагрелся градусов до 70, так что просто коробочкой я боюсь не отделаюсь, нужны радиаторы и, наверное даже вентиляторы. При старте, единственным доступным редактором будет vi (даже не vim), так что рекомендую сразу-же установить joe или mc, если нет опыта (или желания) работать с динозаврами. Я сознательно нарезал под fs 16Gb, т.к. мне еще устанавливать Home Assistant, тоже думаю с image, который можно путем scp переложить на fs, создать партицию, а потом dd. Можно конечно переразметить и зафлешить emmc на самой плате и установить ос туда, но я пока не хочу - текущий релиз уж слишком "попахивает" даже не бетой, а альфой. Все остальные "удобства" обычного Linux такие же как и на desktope, кроме конечно Xов, которые я не ставил, т.к. для моих задач они не особо нужны. Честно говоря, несмотря на некоторые "незручностi", работает в общем неплохо. Чем-то напоминает сервера 2000х, которые имели приблизительно аналогичные параметры В принципе, эту штуку можно безо всяческих проблем приспособить под WiFi extender "по совместительству", т.к. standalone получается немного дорого. C SD картой наблюдаются некоторые странные "чудеса". Захотел я запустить fsck на раздел. Ну поставил count 1, перезагрузился раз. Два. А потом и 3. Неа, не чекает никакими силами. Сам раздел (с count 10) выглядит так: Карта RAM (top):

На 2х метрах работает без проблем. Все датчики. Не проверял, но думаю что с пулапами 4.7 заработает и на 5 метрах. Можно даже на обычном телефонном кабеле В общем конечно да, без спецсредств, на большие расстояния (более 10м) не получится.

InSAn - спасибо, но я все-таки сторонник цифры. Такая себе модель микросервисов, в рамках которой я не хочу думать о физических характеристиках сенсора, а хочу иметь эксклюзивно цифровой интерфейс к этому самому сенсору. Унифицированный. Например i2c. Как эти сенсоры внутри себя компенсируют температуру, давление, дрифт по старению кристалла,- я знать в деталях абсолютно не хочу. Я хочу иметь абсолютные показания, с точностью один знак после запятой, и использовать те модели, которые доступны "в широкой продаже" на розничном рынке.

Вроде как поборол. Товарищи китайцы достаточно оперативно выкатили прошивку на английском, в которой теперь можно немного потюнить repeater. Надеюсь что это не персональная сборка для меня, а будет доступно для всех. Была еще одна неприятная проблема, которая заключалась в DHCP bug. Как это проявлялось: Repeater подключен к маршрутизатору (asus rtn66u), имеет свой IP, один открытый udp порт. В самом ASUS lease time я ставил неделю, соотв. ожидалось что lease time будет "унаследован" repeaterом, и все устройства которые к нему подключены, будут реконнектиться крайне редко, т.к. в случае WiFi, смена адреса (dhcp uni/multicast) означает переустановление соединения. Вначале так все и было. После пары перезагрузок начались интересные чудеса. С периодичностью 4-20 минут, этот самый repeater стал творить странное, а именно выдавать на router DHCP DISCOVER. После всех приседансов (DHCP OFFER, ...), repeater успешно устанавливал новый (на самом деле тот-же IP), но при этом почему-то адресно раздавал lease time подключенным к нему устройствам, по какому-то случайному закону, при этом так-же адресно "прогоняя" DHCP OFFER на все подключенные к нему устройсва. Устройсва были в некотором недоумении, но при этом дисциплинированно отваливались от repeaterа, и потом долго трясли рогами, пытаясь понять подключены они или нет, т.к. beacons с payload продолжали ходить как ни в чем не бывало. Китайцы признали проблему, но вот с обещанием починить как-то не очень. Надеюсь что когда-нибудь пофиксят. Пока порекомендовали factory reset. Помогает. Такой себе workaround. По большому счету, правильный повторитель должен работать через WDS, но там цены начинаются от 150$. Из "дешевой" альтернативы есть github.com/martin-ger/esp_wifi_repeater Единственное но,- не более 4х устройств к одной точке доступа. Побороть можно, но уже на ESP32. Физический предел для именно этого кристалла - 64 устройства. Стоимость самого кристалла, платы питания, корпуса, приближается к 8$, которые стоит Xiaomi repeater, так что пока я буду активно "настаивать на устранении ошибки" В идеале конечно исходники прошивки решили бы все мои проблемы,- но это я думаю, малореально.

Продолжаются чудеса от WiFi extender. Судя по всему, снова обновилась прошивка. Наверное что-то "стало лучше", но пока из "улучшений" наблюдается следующая картина: В случае если клиент, который подключен через этот самый extender не проявляет сетевой активности в течении 10 минут, то disconnect. На уровне WiFi, причем извините за мой французский - "через жопу". Т.е. клиент (или notebook, или ESP8266/ESP32) получают disconnect, и сам extender подтверждения disconnectа не ждет, т.е. отключенный клиент считает что он все еще подключен и, при попытке какого-либо запроса, возникает ощутимая задержка, пока клиент приконнектится повторно. В случае с "условно пассивными" элементами умного дома, т.е. теми, которые постоянно "слушают" сокет на предмет возможного коннекта, нужно повторно переконнекчиваться, причем обнаруживать внештатную ситуацию, при которой disconnect приезжает некорректно. Похоже что мои мегаинвестиции имени 8$ за "дешевый" WiFi extender начинают вылазить боком. Буду менять.

Приехал мой Orange PI. В точности как на картинке. Тем временем реализовал поддержку MQTT. 3.1.1. Полную. В общем ничего сложного. Выглядит так: Соберусь с силами, попробую поднять Home Assistant (docker container). Еще не совсем понятно как там писать сценарии,- думаю разберусь. В качестве тестовой платформы использовал customer.cloudmqtt.com и console.ng.bluemix.net/

Поапдейтилcя MI home (android). Теперь при выборе WiFi extender, пишет "Shortcuts aren't supported on this device". Раньше просто показывал уровень сигнала. Сейчас показывает ничего. Я выбрал европейский сервер, с китайским неудобно. В принципе не фатально, мне это устройство нужно именно в качестве WiFi extender, и устанавливал я MI home только для того, чтобы поднять устройство. Надо бы как-то промониторить куда стучится этот зверек, и перерезать шлангочку путем firewall rules. Remote control server + закрытая архитектура - это похоже таки зло.

Сервер управления свой ? Europe, China, US ?

сегодня, в районе 6 утра с копейками кажется обновилась прошивка WiFi extender. Всплеск трафика + все устройства, которые имеют доступы к домашней сети (dhcp) через extender сменили ipшники. Никаких других аномалий не замечено. Мне не дает покоя мысль, что я не купил устройство, а просто взял во временную аренду некие сервисы, которые предоставляются устройством, и cloud services, которые кстати разные, для разных регионов. И я эти сервисы не контролирую, от слова совсем.

Небольшой пример по разборке с китайским сенсором (SPL06-001). 1. Datasheet: www.tim-crystal.com/Data/tim-crystal/upload/file/20170524/SPL06-001_datasheet_V2.0.pdf Confidential. Wow ... 300-1200 hpa с точностью 0.006 hpa в диапазоне от минус 40 до плюс 85. Очень некисло. Так, а как с этого зверька снимать показания ? Смотрим вначале на самый простой пример - тепература: t = c0 / 2 + c1 * tread / kT Ага, значит как коэффициэнты, так и raw показания температуры могут быть отрицательными. Это важно, и нужно будет учесть при рассчетах. Кристалл имеет 9 коэффициэнтов, по которым рассчитываются корректирующие значения температуры и давления. Без проблем вычитываются из регистров, нужно только не забывать о знаке (+/-). Давайте рассмотрим на примере коєффициєнта с00. Разрядность - 20 бит. int16 мало, значит int32. Оставшиеся 12 бит можно заюзать под что-то другое, или просто "забить". Вычитываем 3 байта, и пакуем в int32: c00_32 = (uint32_t)(byte1<<16)|(byte2<<8)|byte3 ; Запаковали,- теперь знак. В примере выше абсолютно пофиг будет ли это int32_t или uint32_t. Почему ? А потому, что знак в 20 бите, а не в 32м. Есть правда нюанс заключающийся в том, что некоторые компиляторы, единыжды закастив в один тип (например в uint32_t), потом "втихаря" будут кастить в него же, несмотря на попытки закастить в int32_t, но в случае с Teslenica все путем. if ( byte1&0x80 ) { c00_32 ^= 0xFFFFF ; c00_32 = 0 - c00_32 - 1 ; } О,- теперь все Ok. Можно конечно и в одну строчку,- но тогда будет менее понятно. Нужно определиться будем ли мы жить в целочисленной арифметике, или придется уходить на float. Что для этого нужно ? Посмотреть на размерность коэффициэнтов, и вычитываемых значений температур. 16/20/24. Немало ... Максимальное значение коэффициэнта (котрый определяется выбранным oversampling) 7864320. с0 (int16), да еще и деленный на 2 - это потенциальная потеря точности на целочисленной арифметике, значит дление убираем: t = c0 + c1 * tread * 2 / kT t /= 2 ; А что с raw temperature (tread) ? Там 24 бита, но все-равно остается шанс того, что вычитается скажем, значение 0xFF, а потом поделившись на 6 значное число, станет нулем, и точность поплывет. Значит нужно умножать не на 2, а уже, например, на 10000. Опаньки. Можем не поместиться. Значит int64. Если навести резкость на формулу для рассчета давления, то там все еще печальнее, уже подбираемься к пределу int64. Можно соптимизировать, можно перепрыгнуть на float. В документации сказано что нужно выбрать тип температурного сенсора, при помощи которого были получены калибровачные параметры. ASIC или MEMS. Правильный ответ - MEMS. В случае выбора oversampling более 8, нужно еще ставить бит сдвига в регистре, и потом учитывать, несмотря на заверения в manualе, что типа "не повлияет никак". Повлияет. Если учитывать, то эта штука может измерять высоту с точностью до 3см. Теоретически может даже и сантиметр, но там уже шумы давить надо, и усложнять алгоритмы. Если использовать в качестве алтиметра, то лучше поместить в негерметичную коробочку, чтобы исключить влияние движения воздуха - чувствительность весьма и весьма похвальная. Смотрим на типа "рабочий пример": github.com/RT-Thread-packages/spl0601/blob/master/spl06_01.c hdev->calib_param.c00 = (int32_t)h<<12 | (int32_t)m<<4 | (int32_t)l>>4; hdev->calib_param.c00 = (hdev->calib_param.c00&0x080000)?(0xFFF00000|hdev->calib_param.c00):hdev->calib_param.c00; |= 0xFFF00000 Опаньки,- а это что за фокусы ? Это мы так хитро "по китайски" adjusим в минус ? Учитывая что этот коэффициэнт участвует в формуле в качестве одного из операндов, ошибка в общем будет достаточно небольшая, но она таки будет. И нафига спрашивается тулить везде каст имени int32_t ? А присмотреться повнимательнее к формуле рассчета давления, то можно понять что формула неоптимальна. "ненавязчивое" загрубление результата. Короткое итого - точность 3 сантиметра. Проверено экспериментально, путем включения на разных этажах, с заранее известными высотами.

Таки поборол китайский датчик SPL06-001. Температура/давление. Для дронов. С температурой неожиданностей нет, давление конечно меряет шикарно. По спецификации обещали +/- 5 см (измерение высоты). По моему погорячились,- подтверждаю точность 10см. Документация - мрак. Написано одно, на самом деле программится совсем иначе Стоимость - 1.20$. если брать пару десятков - меньше доллара (вместе с dev платами). Очевидно был какой-то прототип, с которого скопировали. Удачно скопировали. Как алтиметр - лучшего не видел, даже у TI. Измерение температуры - достаточно инерционное, даже при минимальном усреднении. Специфика дронов ...

Пришел мой WiFi extender имени XIAOMI: www.aliexpress.com/item/Original-Xiaomi-Pro-300M-WiFi-Amplifier-WiFi-Repeater-2-4G-Wifi-Signal-Extender-Roteador-APP-Control/32869257183.html?spm=a2g0s.9042311.0.0.27424c4d6iW62O В комплекте переходник US->EU, и инструкция на 3х листочках на китайском. Установил MI Home (Android, ~60Mb), запустил. Предложило повключать все что только можно (в частности BT), и запросила немеряно доступов, включая storage, и доступ к камере. Это типа значит чтобы bar code вычитать на упаковке. На самом деле скачать можно без QR кода. Только диапазон 2.4. Интерфейс (слава Богу) на английском. При подключении попросило l/p к WiFi маршрутизатору, и через секунд 30, успешно приконнектилась, создав AP c приставкой "_plus". Никаких элементов управления в самом приложении я не нашел. Справедливости ради стоит отметить, что MIMO таки работает, связь хорошая. Теперь немного о технических нюансах: После сетапа, устройство появилось в качестве клиента основного WiFi маршрутизатора (dhcp). Что было бы если бы я отключил dhcp - сложно представить, не пробовал. Появились 2 новые точки доступа: одна с BSSID устройства (и SSID с приставкой _plus), и вторая, с BSSID "родной" точки доступа, без SSID (hidden, на другом канале). В общем конечно ничего, но в зоне где доступны обе сети (родная и extenderа), есть определенные проблемы с подключениями WiFi клиентов, т.е. автопереключение глючит. Никаких "органов управления" в телефонном приложении я не нашел. Интересно что будет, если я поменяю пароль на основном WiFi. Может я в чем-то просто не разобрался ? Для моих задач в общем с головой, я не планировал "бесшовный роминг", и подключение с выбором любой из 2х сетей. Пару дней полетало все, перезагрузок и "выпаданий" не замечено, но дискомфорт остался. Что будет если "отвалится" интернет на маршрутизаторе ? А замена пароля как ? Autoupdate самой фирмвари отключить нельзя, только addonов в приложении. А что на счет приватности ? Мне лень было анализировать трафик, но одна мысль о том, что я типа "зааутсорсил" сегмент своей сети, причем безо всяческих гарантий и условий, вызывает вопросы.

Вместо стрелочных манометров на системе водоочистки хочу поставить цифровые датчики. MS5803-14BA . TE блин ... Дорого. На 30 бар стоит еще дороже. Есть китайский аналог, по протоколу обмена и командам совпадает с TEшным. Видать скопировали, надеюсь что удачно. 2$, правда без dev платы, только сам сенсор. Схема подключения оригинальностью не отличается. Уплотнительное колечко в комплекте. Как этот самый датчик физически инсталлировать в трубу - пока думаю.

Для самих сенсоров, в формате devboards, я использую www.aliexpress.com/store/product/szomk-diy-plastic-electrical-box-equipment-box-shell-enclosure-20-pcs-59-26-12mm-enclosure-housing/1006252_32567329247.html?spm=a2g1y.12024536.productList_1690906.pic_20 ессно за исключением случаев, когда нужно например запихнуть i2c в гильзу и залить,- тогда нужна своя плата, например 4.9 * 30мм

Универсальность. Где-то нужно температуру/давление померять, где-то влажность, где-то UVA/UVB. TVOC/CO. Городить огород для каждого сенсора отдельно - много мороки. Одно устройство для всего. Что подключаем - то и будет работать. Управление/история показаний ведется по 3м параметрам, вне зависимости от того, сколько датчиков подключено. Можно выбирать "на ходу". Задачи для всех датчиков такого типа (кроме компасов, акселерометров и обнаружителей жестов) достаточно однотипные - щелкнуть каналом реле в случае выхода показания за пределы, и сохранить показания за период. Ну и, ясное дело передать остальным устройствам что случилось,- каждое среагирует согласно локальной программе. "дешево и сердито" - bme280. Давление/влажность/температура. Можно DALLAS в гильзе - я использую для измерения температуры в качестве погружного датчика. Для теплого пола - TMP102. Гильза, плата, 2 резистора, конденсатор, харьковская EVA для заливки солнечных батарей. Если нужно CO/TVOC - CCS811. BME680 не совсем "тот" TVOC меряет. Если датчик меряет давление/влажность, то при выносе на улицу лучше сделать так, чтобы дождь напрямую не попадал на датчик. Можно для простоты использовать готовые dev boards, паять самому smd морочливо. Дешевле и лучше в домашних условиях точно не получится. Например такое: www.aliexpress.com/item/1-8-5V-GY-BME280-GY-BME280-3-3-precision-altimeter-atmospheric-pressure-BME280-sensor-module/32847825408.html?spm=2114.search0104.3.9.ab11301ddiupka&ws_ab_test=searchweb0_0,searchweb201602_3_10065_10068_319_10059_10884_317_10887_10696_321_322_10084_453_10083_454_10103_10618_10307_537_536_10902,searchweb201603_45,ppcSwitch_0&algo_expid=37eb4984-0eb3-45db-9110-b33b3961ea22-1&algo_pvid=37eb4984-0eb3-45db-9110-b33b3961ea22&transAbTest=ae803_4 Если нужны очень точные показания давления, то тогда MPL3115A2 или MS5611/MS8607. Они изначально для дронов,- там хорошая точность.

Заказал. Всего, с блоком питания и доставкой, получилось около 1200 грн. Китаец скинул все что мог, с учетом нового года (+2 недели). Корпусов для OPI3 пока еще не поотливали - некритично. Пошарился по форумам - обещают полноценную System V. Это здорово упростит задачи как по конфигурированию, так и по разработке. Уже есть куча готовых образов как сервера, так и WS. WS мне как-бы ни к чему, посему сервер. ssh2/X в общем должно хватить с головой. HA туда затянуть в общем проблем не составляет. Есть уже готовые образы. За этим самым HA еще тянется неслабый шлейф приблуд, без которых оный не заработает. В принципе понятно python/Java разработчик стоит несравненно дешевле плюсовика, но побочный эффект в том, что это получается не standalone приложение с библиотеками и файлами ресурсов, а целый зверинец инструментария/runtime. Frameworkа для разработки на самой платформе не нашел (или еще не разобрался), но gcc есть, так что проблем допилить что-либо не вижу. Портов на плате - тьма тьмущая, есть USB3 HUB, наверное все-таки такая плата больше бы подошла для какого-нибудь AV center, но у меня на нее немного другие планы. Хотелось бы в дополнение к HA, нарисовать некое middleware, которое поможет мне выводить информацию с моих камер наблюдения на TV (HDMI). Поигрался с domotikz - не, не то. C концепцией OpenHub еще не разобрался. По идее вездеход, можно построить все чего душа пожелает, но нужно пару недель повникать. Присматриваюсь к Node Red, но пока что-то у меня туго с пониманием как эта штука заводится и управляется. Добавлено через 49 минут itc.ua/blogs/spetsialist-po-kiberbezopasnosti-umnyie-lampochki-hranyat-parol-ot-wi-fi-v-nezashifrovannom-vide/ Похоже не во всех лампах 8266.

Допилил еще с 10 поддерживаемых датчиков. пока проблемы только с одним - Senserion SGP-30. То-ли мне бракованный образец попался, то ли он от рождения такой. Заводится, работает 2-3 минуты, потом все. Перестает отвечать на команды. Ни тебе ACK, ни NOACK. Перезагрузка и/или 0x0006 не спасает - только power off. С Senserion датчиками, по факту проблем было больше всего SHT30/31, SHT20/21. Модели "официально" различаются типа "точностью" измерений, но это далеко не все. Различаются времянки, частичная поддержка некоторых i2c команд. Есть еще SHT1х -это вообще мрак какой-то. Видать вначале пожадничали на лицензию имени i2c, по финалу получилось 4 провода, но несовместимых ни с чем. В документации как-то опрометчиво пообещали что "будет работать совместно с I2C устройствами", но в реалиях - будет с крайне ограниченным количеством. Если сенсор требует signal strech/restart - досвидос, не заработает, ну или заработает, со значительными потерями во времени, и достаточно сложным кодом. Оставил "про всяк випадок" поддержку датчика,- может когда-нибудь пригодиться. Задумался над MQQT. TLS без шансов, SSL можно, но по причине ограниченного объема памяти есть нюансы, plain text authentication, т.е. только в пределах локального сегмента сети, дальше пусть брокер релеит - можно. За пару недель доделаю, как раз подоспеет мой Orange Pi 3, будет с чем повозиться.

Платформа явно превышает требования HA. Можно что-то подселить. Подселить можно что-то "готовое", и дальше настраивать путем изменения опций конфигурации, а можно написать свое. Или "допилить" уже написанное кем-то. Для этого есть как минимум 2 варианта: 1. Скомпилировать/интерпритировать на самой платформе, используя Python, Java, C/C++, ... 2. Писаться и отлаживаться с большой машины и перенести "уже готовое" на target platform Для 1го сценария, по идее должны существовать такие себе IDE, т.е. графические оболочки, облегчающие сборку и отладку. Худьший сценарий - текстовій редактор, командная строка, и makefile (не для всех сценариев). И gdb, если доступен для этой платформы, думаю домступен - Linux все таки На текущий момент, у меня нет представления что есть как для пункта 1, так и для пункта 2.

Образ и setup не проблема, спасибо. Я думаю что CentOS туда запихнуть смогу. Для собственного комфорта. В общем конечно все равно - главное версия ядра, и инструментарий. Может подскажете,- в какой dev среде это чудо кодится ? gcc + makefile на самой платформе ? Или Keil а потом шить образ ? Плата такая: www.aliexpress.com/item/Orange-Pi-3-Set2-OPI-3-Power-Supply-H6-2GB-LPDDR3-8GB-EMMC-Flash-Gigabyte-AP6256/32969768551.html?spm=a2g0s.13010208.99999999.259.f5ff3c00jMhMr3 Цена ессно гораздо меньше. С такими ресурсами, я смогу все свои камеры застримить на TV (HDMI). Ну и докинуть все то, что я не смог реализовать на ESP разных видов и мастей, помимо Home Assistant. Что-то мне подсказывает, что рано или поздно моя alarm system на ESP32 тоже переедет на эту же платформу. Закажу,- где-то через месяц создам новую ветку "малинка" и как ее усетапить.

Про интеграцию ламп. Если я правильно понял, то они не поддерживают MQTT. Навел резкость на Raspberry Pi 3. Если заморачиваться с Home Assistant - думаю самое оно. Под Windows эта конструкция заводится очень грустно, да и нет смысла держать включенной постоянно большую машину.

Пока видится интеграция путем MQTT. plain text/password, т.е. Home Assistant должен жить в локальной сети, ну или через какой-нибудь брокер.

Понятно. lafaet - можно я позадаю ''чайниковские" вопросы ? Технически задача не сложная, но все-таки хочется использовать уже имеющиеся модели управления, а не изобретать велосипед. Насколько я вижу, есть разные frameworks и конструкторы, которые взаимодействуют с конечным устройством путем полноценного 2х стороннего MQQT. То есть понятное дело, что рисовать свой конструктор в пределах каждого из кристаллов - не самая лучшая идея, равно как и пытаться запихнуть в кристалл с RAM ~80kb логику распознавания голоса. Это значит что в каждый из кристаллов нужно добавить поддержку MQQT, в той или иной реализации. Поскольку практического опыта именно с Xiaomi home assistant у меня нет, то мне нужно понимать что требуется от кристалла, что нужно параметризировать в WEB config кристалла, т.е. какие параметры нужно менять, какие отдавать наружу, и в каком виде принимать команды. Например POST/GET /mqqt/relay1/control ON, параметры цветовой температуры и интенсивности лампы. Судя по всему, вы этот этап уже прошли, и "остановились" на том, что прошивка самого кристалла на лампе, не позволяет реализовать все "хотелки" должным образом.

Ок, а как бы вы видели для себя сам процесс управления лампой ? WEB страница подходит ? Если есть несколько таких ламп, то какие могут быть сценарии ? Типа разлить текущие параметры одной лампы по всем остальным ? Или может какой-то более продвинутый вариант ?

Все логично и правильно, но есть нюансы. Самый главный нюанс, это формализация протокола обмена между устройствами. У оных сущности в общем-то отличаются. Так, например, в случае диммируемой цветной лампочки, я думаю имеет смысл передавать RGB + intensity. то есть лампочка должна отдавать текущие параметры наружу, и принимать команды от других устройств и/или сервера. Теперь вопрос: А кто должен инициировать обмен информацией, в случае модели клиент/сервер ? Тут есть 2 варианта: 1. Клиент - который периодически (или по событию) стучится к серверу, отдает статус, и принимает команды 2. Сервер самостоятельно опрашивает/командует клиентами Для сценария N1, чтобы все работало "гладко", нужно чтобы сервер имел возможность коннектититься к устройству, и командовать, при наступлении некоего события. У себя, я организовал сценарий N2. Это позволяет реализовать практически полную автономность, типа сервер "живой" - командует. "неживой" - устройства работают в автономе, согласно заданным программам. Сами устройства ессно имеют возможность взаимодействовать друг с другом, даже при отсутствии WiFi точки доступа, благо ESP8266/ESP32 это позволяют. Например одно устройство на выключателе света, второе на лампочке, или на любой другой нагрузке. Пока есть питание, все будет работать безо всяческих проблем. Конфигурить правда придется каждое устройство отдельно, подключаясь к встроенной точке доступа - это не очень удобно, но все-таки лучше чем получить DOS как результат внешних, не зависящих от пользователя факторов. Если уже начинать строить все по правильному - то тогда REST + XML. Это для взаимодействия между сервером, и устройствами. Ролевой доступ (l/p) обязателен. Сервер поднять проблема небольшая. Проблема в том, чтобы унифицировать зоопарк возможных параметров, и правильно построить протоколы обмена, чтобы значит при добавлении нового устрорйства с неизвестными на данный момент параметрами, не пришлось перешивать уже установленные контроллеры. Если "разливать" конфиги устройств с сервера, то обязательно нужно писать некий свой логический анализатор. На эту швабру я уже наступил уже при 11 устройствах. Прописал не тот канал на одном из устройств, и вместе со светом на кухне, выключался свет на 3м этаже Это была знатная прогулка по швабрам, после которой я добавил в интерфейс каждого из устройств опции, которые позволяют не слать команды другим устройствам или не принимать команды от других устройств. С клиентом под мобильный, ситуация аналогичная. Предположим что вы напишите своего клиента, с красивым интерфейсом под текущую версию Android/IOS. А потом выйдет новая версия, которая не заработает с вашим клиентом. И ? Фиксим и переписываем ? А куда собсно должен "стучаться" мобильный клиент ? На оконечное устройство ? На сервер ? "и туда, и туда" с возможностью выбора ? В общем-то тоже проблем нет, кроме usability. Через год даже разработчик забудет все эту хитроизвернутую логику. А вообще, в принципе, какая стоит задача ? Управлять всем домом из единого графического интерфейса ? Локально ? Или точечная автоматизация ?