Именно поэтому во всякие BananaPi не ввязываюсь, после оказывается что хоть оно и стоит дешевле и попугаев у проца больше, но производитель предпочитает клепать новые варианты плат, а дрова для кернела случились давным-давно и нагуглить не особо что получается, т.к. большинство купивших купились на цену и попугаев.
-
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
TLSR8251 + LCD + термометр = LYWSD03MMC XIAOMI Bluetooth термометр
- Автор темы pvvx
- Дата начала
Да я особо и не спешу, у вас же без штробления, можно в любой момент прилепить к стенке и показать разницу с проводным бошемЧитайте внимательнее - писал, что пока не переписано полностью нет смысла кидаться в паблик. Изменения в самом так сказать ядре этого пакета и необходимо переписывать все интеграции, а пока полностью переписаны и отлажены только две из четырех. Я это делаю когда голова уже устала от решения более сложных задач с учетом "погоды" и прочих факторов
)
pvvx
Активный участник сообщества
Вот какая-то позапрошлая версия, вроде работала... В новой пока кишмиш..
DHT22 опять перестал выдавать данные после вкл-выкл кондея, пришлось как обычно ему питание передернуть...
pvvx
Активный участник сообщества
Вы опять что-то путаете. При чем тут "кернела"?
Не ставится пакет для Питона - cryptography. И причины его авторам давно известны, ещё со старых прошлогодних версий.
Всё остальное - это ваши недопонимания.
pvvx
Активный участник сообщества
А DHT22 тут при чем?
pvvx
Активный участник сообщества
Основная причина не "во всякие BananaPi", а в том что "HA" продает свою коробочку и свой платный "Cloud" и без каких либо гарантий - т.е. для окучивания лохов.
Всё в нем делается чтобы на сторонних платах он не работал. HA - это обычная жадность и откатка своего софта на вас, с вашей RPi4.
Ровно при том же что и ваша криптография к HA, сильно уже не вникаю что пишете, есть на что потратить время с большей пользой. Если вдруг допилите элементарную секретность кастомного режима, то будет смысл поиграться с термометрами еще, а принимаемый без проблем мобилкой ксяомиевский режим в этой интеграции для чего дорабатывать одному вам известно... Дыра от этого куда-то делася?
pvvx
Активный участник сообщества
Как я понял у вас что-то с головой не так. Какие-то дыры, что-то другое видится...
Соединение с custom прошивкой защищены pin кодом, а сообщения рекламы зашифрованы AES ССМ со 128 бит ключом.
У кого что болит, тот о том и говорит. каждый - о своем.
Я приветствую Ваши поделки,
но перестаньте думать, что кто-то с вами соревнуется .
Я делаю то, что интересно мне.
--------------------------
Теперь я изложу свое мнение по данной теме.
-----------------------
Никто с Вам не спорит об очевидном:
Энергопотребление меньше, если использовать чипы более новых разработок (TLSR новее, чем ESP),
но при этом у них для связи используются менее мощные передатчики (у TLSR передатчик в 10-100 раз менее мощный).
Поэтому потери в дальности - будет недостатком данных чипов, при одинаковых частотах.
Есть новые чипы с такой же мощностью как ESP и с кпд в 3 раза выше, но и цена их выше и софт для них доступен для бизнес разработок а не для любителей.
------------------
Ваше стремление использовать CR2032 похвально, еще интереснее вообще без батарейки.
------------------------------------
Но практически размер батарейки важен, если Вы это устройство наденете на человека или повесите на стенку и при этом оно будет либо больших размеров либо тяжелым.
----------------------------
Если Вы устройство воткнете в землю на поле ,то какая разница будет батарейка круглой или формата AA?
-------------------------------
Относительно кучи деталек ,
которые якобы нужны в одном случае и не нужны в другом - это спорно.
Это Вы так сконструировали, что у вас куча чего-то, но возможны и другие конструктивные решения.
--------------------
Вопрос стоимости батарейки вообще не стоит,
так как любое устройство на рассматриваемых чипах будет работать месяцами и годами при цене батарейки в 1 доллар.
------------------------
Ваше зацикливание на измерении температуры на основе зверинца сенсоров - вообще не имеет никакого практического смысла.
У дилетантов вообще крыша поедет, а профи это нафиг не надо.
Разве что Вы так тешите свое самолюбие. Но нарциссизм - это диагноз.
==============
Полагаю, что устройства измерения температуры и влажности воздуха
с индикатором и передачей по эфиру показаний на смартфон,
является извращением и бессмыслицей.
Если у Вас есть смартфон - то нахрена индикатор на устройстве?
А если смартфона нет, то нахрена передавать данные?
Наличие одного делает бессмысленным и избыточным другое.
Более того , бессмысленно накапливать и передавать показания каждую секунду и даче каждые 10 секунд.
-------------------
Т е Вы решаете практически бесполезную задачу минимизации питания бессмысленной передачи ненужных данных с одновременным созерцанием их на индикаторе.
При этом, считая экономию энергии, Вы забываете добавить потребление смартфона к Вашим мкА.
-----------------------
Понимаю - вам интересно это, а мне, не поверите, ну абсолютно не интересно на это тратить свое время.
------------------------
Далее..
Если поставить задачу :
измерять что-то далеко в чистом поле ,
то одна батарейка может быть хорошо, а возможно и ничего и не решает.
====================
Ранее я уже писал, что погоня за мкА на измерениях, которые нужны лишь для созерцания не имеет практического значения.
Такие измерения нужны для игры воображения наблюдателя или бессмысленного хвастовства такими "достижениями".
------------------------------
Если Вы задумаетесь о применении этих данных для автоматического управления исполнительными механизмами,
то величие решаемой Вам задачи по экономии микроампер сразу сдуется.
-----------------------------
Во-первых, любой исполнительный механизм скушает столько тысяч мкА,
что ваша экономия просто будет незаметна.
Во-вторых, если датчик из тупого станет умным, то он сам будет принимать решения по управлению
и не будет забивать эфир десятками тысяч сообщений .
=====================
Меня интересуют идеи, методы решения практических задач,
т .е минимизации потребления не столько датчиков, сколько всей автоматической системы управления или измерительными приборами.
Вот неполный перечень таких систем:
1) управление климатом в жил.сел.помещениях, инкубаторах
2) утилизация мусора
3) очистка питьевой воды
5) ректификационная колонна, самогонный аппарат, пивоваренный аппарат
6) система полива теплиц
7) приборы измерения параметров биологических объектов
8) контроль качества продуктов и напитков
9) интеллектуальные (умные) приборы
---------------------
В перечисленных задачах Важным является не созерцание индикаторов или пересылка бесполезных данных по эфиру,
а методы и алгоритмы управления процессом для достижения полезной цели.
-----------------------------------
На разработку методов и решений подобных систем я и трачу свое свободное время, мне это интересно.
Но выкладывать что-либо для хвастовства не собираюсь, как бы халявщики не возмущались.
-----------------------------
Публикуемые Вами решения уменьшения тока потребления с 15 мкА до 10 мкА смотрю,
как некий мультфильм, когда нечего делать, не более того.
Дайте угадаю, AES вы добавили в той версии, которой ещё нет в паблике и описания нет и не предвидится ибо опять же вот тот ble_monitor без задания чего либо пишет в логи принятые значения. Вы совершенно не оригинальны в способах сокрытия разгильдяйства )))
pvvx
Активный участник сообщества
Это всё добавлено несколько версий назад.
В ble_monitor надо вводить bindkey. Но народу нравится без шифрации и поэтому по умолчанию всё передается в открытом формате, пока не переключите на зашифрованную рекламу и не введете pin код
pvvx
Активный участник сообщества
О - фантазер написал простыню. Очередные фантазии о каких-то "разработках", если сказать мягко...
Всё его интересует, но бестолку - реальность то совсем другая.
pvvx
Активный участник сообщества
Понятно, что для вас и для ваших решений это мультфильм. Вам же не вылезти за десятки мА с вашими ESP и вы не знаете схемотехнику Xiaomi LYWSD03MMC.
А в нем стоит контроллер LCD, чип с BLE и прочие деталюшки потребляющие в режиме sleep с поддержкой регенерации LCD от 6 мкА.
Конечно вам в невдомек, что большинство сценариев поддержки простой влажности или температуры требуют получать показания от датчиков с шагом чаще пары секунд. Особенно для алгоритмов ПИД регулирования.
Ведь вам же не рассчитать все коэффициенты с учетом шумов датчика, скоростей отклика и прочих параметров к оптимальному требуемому минимальному шагу передачи показаний, т.к. и в этом вопросе у вас нет ни знаний ни практики.
По тому и слушайте что вам говорит специалист, а не гоните свои фантазии
Вот с учетом "и вашим и нашим" в среднем и выходит что требуется порядка 4 мкА для покрытия большинства вариантов. Остальные 6 мкА - это издержки, которые не изменить не меняя аппаратную платформу. А тема тут про термометры от Xiaomi, а не о ваших фантазиях.
pvvx
Активный участник сообщества
Для ваших фантазийных вариантов с одной передачей и обновлением LCD раз в час, не меняя ничего в Xiaomi LYWSD03MMC выйдет среднее общее потребление порядка 4..5 мкА, т.к. TLSR8251 будет сидеть в deep-sleep, не помня ничего кроме шага времени до просыпания. Вот только такое поведение данного датчика никому не нужно, ну кроме вашей фантазии.
А тем временем всё довольно просто и наглядно.
Смотрим разницу в кол-ве и качестве передаваемых показаний у custom варианта и у Cleargrass (qingping) CGG1 аналогичного датчика на nRF52:
При этом CGG1 на nRF52 и жрет больше, TX-RF на 6 дБ меньше, и чаще гонит рекламу...
А тем временем всё довольно просто и наглядно.
Смотрим разницу в кол-ве и качестве передаваемых показаний у custom варианта и у Cleargrass (qingping) CGG1 аналогичного датчика на nRF52:
При этом CGG1 на nRF52 и жрет больше, TX-RF на 6 дБ меньше, и чаще гонит рекламу...
pvvx
Активный участник сообщества
Аналогичная история со всеми BLE и ZigBee датчиками температуры и влажности от Xiaomi, Туя и прочих "брендов" - жрут больше и дают кривые точки раз в 10 минут, а пишут на Cloud одну точку в час.
Т.е. совершенно ограничены для разнообразного применения - только как "показометр" для лоха, а не для автоматизации.
Т.е. совершенно ограничены для разнообразного применения - только как "показометр" для лоха, а не для автоматизации.
pvvx
Активный участник сообщества
Текущие актуальные и ещё не решенные вопросы находятся не в области самого BLE датчика-устройства, а в кривизне ПО от “сообществ”.
Вот такие простыни о ошибках в скриптах библиотек Питона для BLE на совершенно разных платформах:
И совершенно без разницы какой адаптер BT или платформа – хоть на USB, хоть встроенный по UART, …
Из-за этих ошибок постоянно перезагружаются скрипты интеграции в Home-Assistant и дырявится накопитель этими простынями логов с RuntimeError.
Если откинуть все эти либы и скрипты в HA, то все адаптеры работают без ошибок на кое-как писанном отсебятинном ПО.
Т.е. “сообщество” ещё не созрело на работу с BLE и создает какие-то детсадовские карякули, которые необходимо все переписывать с нуля. А уж разговор о MESH вообще не стоит, хотя он полностью вытесняет устаревший ZigBee.
Вот такие простыни о ошибках в скриптах библиотек Питона для BLE на совершенно разных платформах:
И совершенно без разницы какой адаптер BT или платформа – хоть на USB, хоть встроенный по UART, …
Из-за этих ошибок постоянно перезагружаются скрипты интеграции в Home-Assistant и дырявится накопитель этими простынями логов с RuntimeError.
Если откинуть все эти либы и скрипты в HA, то все адаптеры работают без ошибок на кое-как писанном отсебятинном ПО.
Т.е. “сообщество” ещё не созрело на работу с BLE и создает какие-то детсадовские карякули, которые необходимо все переписывать с нуля. А уж разговор о MESH вообще не стоит, хотя он полностью вытесняет устаревший ZigBee.
pvvx
Активный участник сообщества
Вы совсем зафантазировались - в моих системах датчик и приемник-исполнитель на одинаковых платформах. Но исполнитель не от батарейки CR2032, т.к. он что-то делает и должен быть готов каждую микросекунду для исполнения задачи и соответственно кушает само исполнительное устройство. Смартфон не является исполнителем - он может служить только для настройки системы и нет смысла приписывать его потребление к датчику и исполнителю. Вместо смартфона может быть и комп с кило-ватным потреблением. Вы туда ещё припишите всё потребление связанное с инет на шарике, включая майнинг
Потребление огородо-контроллера, обслуживающего десятки датчиков в окружении до 200 метров уже описывал - порядок 20 мА по 3.3 В -> 66 милли Вт.
pvvx
Активный участник сообщества
Сейчас надо как-то порешать, как вырезать этот безнадежный кривой софт от “вундеркиндов” не умеющий работать с HCI BT чипов (адаптеров BT)...
Вторая большая беда IoT и всех текущих “вумный дом” в базах данных, бесполезно дырявящих накопители.
Пересобрал для них openssl на версию 1.1.1k и для некоторых ещё пару пакетов.
Прошлые картинки - это уже с них...
Так что rPi4+SSD в пролете со своей никчемностью и нынешней ценой.
Проблемы с ошибками в скриптах либ Питона очень близки к ESP32 - возникают из-за неумения настроить параметры сканирования через HCI адаптеру + неправильной буферизации и разбора потока...
Вторая большая беда IoT и всех текущих “вумный дом” в базах данных, бесполезно дырявящих накопители.
Всё решилось - запустил на всех имеющихся платформах.
Пересобрал для них openssl на версию 1.1.1k и для некоторых ещё пару пакетов.
Прошлые картинки - это уже с них...
Так что rPi4+SSD в пролете со своей никчемностью и нынешней ценой.
Проблемы с ошибками в скриптах либ Питона очень близки к ESP32 - возникают из-за неумения настроить параметры сканирования через HCI адаптеру + неправильной буферизации и разбора потока...