• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

TLSR8251 + LCD + термометр = LYWSD03MMC XIAOMI Bluetooth термометр

pvvx

Активный участник сообщества
Так что если и слеплю и кину какую ZigBee прошивку для данных термометров - то у них не будет никой записи истории - банально 512 кило flash хватает только на 2 дубля ПО - рабочий код и OTA.
И тут ничего не поделать - большие дядьки выдумали такой стандарт, чтобы он жрал побольше программной памяти и тупил на слабых MCU...
 

pvvx

Активный участник сообщества
ZigBee придумали "большие дядьки" чтобы всем было неповадно. В проект было изначально заложено - занять побольше времени радиоэфира и устроить долгую жручку на передачу и прием на самой низкой возможной скорости при самых длинных заголовках и атрибутах для передачи одного информационного бита... Ну чтобы в сети не было возможности работать с сотней устройств в секунду... Типа с одним связались и на этом хватит. Потом с другим... И кнопки обязательны - без них устройство не найдет своего координатора, "работающего" с никаким резервированием и ... на устройстве с минимальным объемом в 1 ГБайт RAM на паре ядер и обязательно с SSD. (c) HA.
 

shaman1010

Member
Передачу значений пока не делал, т.к. в SDK ZigBee 3.0, а у Xiaomi - в пределе 2.0
Не совсем понятно. Зигби 2 у датчика, которым прикидывается термометр? Есть у сяомистов датчик света, например, с зигби3 ( GZCGQ01LM )
Шлюз у сяомистов с зигби 3 уже год как продается. Прошлую, интересную, вторую версию уже днем с огнем не найти.
 

pvvx

Активный участник сообщества
Не совсем понятно. Зигби 2 у датчика, которым прикидывается термометр? Есть у сяомистов датчик света, например, с зигби3 ( GZCGQ01LM )
Шлюз у сяомистов с зигби 3 уже год как продается. Прошлую, интересную, вторую версию уже днем с огнем не найти.
Да, да - zclVersion 0x00, stackVersion 0x02 и т.д. :) :)
 

pvvx

Активный участник сообщества
В старье копаться не хочу и нету у меня SDK на старьё. Но структуры отличаются, как и ответы-приветы у датчиков. Хорошо что шлюзу пофигу для регистрации в cloud - он работает не с версиями, а с именами и данными от датчиков.
 

pvvx

Активный участник сообщества
shaman1010 - Если вы не первое десятилетие в сфере программирования и электроники, то сможете сравнить ZigBee хотя-бы со спецификацией Web сервера (или другими протоколами) и понять что ZigBee продумывали дети далекие от понятий программирования на малых MCU. Там всё задумано так, чтобы как можно побольше выесть ресурсов у чипа и максимально увеличить сложность в виде кол-ва условий для каждого варианта обработки условий, команд и данных. Т.е. чтобы малый чип с малой Flash не смог работать в ZigBee.

Для сравнения подсчитайте сколько проектов с открытым исходным кодом к SoC для ZigBee существует на github и сравните с другими вариантами протоколов.

ZigBee – это первопроходец с тьмой ново-вводимых глупостей в сфере малопотребляющих датчиков. За ним следует BLE со всякими MESH, но в BLE вводят алгоритмы позже, после анализа как ZigBee нарывается на подводные камни :)
 

pvvx

Активный участник сообщества
И не забывайте главное природное правило – “народ всегда выбирает самое худшее” - от этого и влечение к ZigBee (вымирать то надо и делать это лучше своими руками). А на производителей безделушек для народа действуют другие правила – как сделать дешевле и иметь какие-то перспективы на дальнейшее производство. В итоге в смартах, ноутах и компах нет никакого ZigBee, а есть BLE со своим зоопарком.

Кол-во устройств и поток данных увеличивается, а ZigBee не может обеспечивать взаимосвязь с множеством устройств из-за длительного времени одной транзакции. В BLE для этого уже включили варианты EDR/LE 2Мбит/с... В перспективе ZigBee вымрет как мамонты, не вписавшись в современные условия, если не изменит свои стандарты практически полностью.
 

shaman1010

Member
401-й термометр. Уменьшил дельту до "-20000" - за сутки убежали ВПЕРЕД на 4 минуты. (при +-2000 было плюс две минуты).
В логах Device StepTimeSec: 998750.000 us
Т.е в логах вертится в нужную сторону, но по факту корректировка всегда идет на увеличение скорости.
Эти висят на батарейке рядом с дешманскими, которые на БП и за трое суток с корректировкой "1000" в минутах не уплыли никуда.
Сейчас поставил "800", в логах - 1000050.000 - предполагаю, должны плюс-минус приблизиться к норме.
 

esnet

New member
восстановить их, а затем можно вернуть оригинальную прошивку и она будет дальше работать в Mi Home.
работает, несколько часов. потом данные в михом поступать перестают. Ни через шлюзы ни через телефон данных нет. А в брокере через шлюз на openwrt все красиво и стабильно. На облака не грешу ибо при переключении режимов данные снова начинают фиксироватся, но так-же недолго. Кто-то палит контору ? От чего так или есть ли возможность вылечить?
 

esnet

New member
перечитал еще раз - чую мысль нет та: я привязываю в михоме на оригинальной прошивке датчик, считываю из облака токен и ключ, прошиваю custom 2.9, прописывыю теже токен и ключ. работает с михоме , но не долго. час, два максимум видел пять. при этом в HA данные поступают нормально
 

pvvx

Активный участник сообщества
работает, несколько часов. потом данные в михом поступать перестают. Ни через шлюзы ни через телефон данных нет. А в брокере через шлюз на openwrt все красиво и стабильно. На облака не грешу ибо при переключении режимов данные снова начинают фиксироватся, но так-же недолго. Кто-то палит контору ? От чего так или есть ли возможность вылечить?
Причина в счетчике - он идет не по правилам mijia. Custom прошивка дает замеры чаще, а шлюз приучен получать данные от оригинала не быстрее раз в 10 минут, а cloud - вообще 1 раз в час.
Через какое-то время требуется соединение со смартом для проверки ключей регистрации... Каждое включение просмотра в смарте лезет в термометр и проверяет регистрацию, заодно считывает историю замеров и всё это отправляет в cloud. А использование cloud со сторонними датчиками в Mi-Home запрещено. Когда вы регистрируете датчик, то вылазит сообщение о пользовательском соглашении. В нем запрещено всё, даже смотреть на прошивку или на плату устройства, лезть в cloud со своими данными, глазеть на любые коды и любой реверс-инженеринг...
 

pvvx

Активный участник сообщества
По этой причине вы можете использовать устройство только как груду деталек и в своем ПО. А все данные что там творится получать из открытых публичных источников, не производя никакого реверс-инженеринга. Что и произведено :) Остальное пока никто не опубликовал и я не могу встроить, т.к. пользуюсь Mi-Home c оригинальными прошивками :p
 

esnet

New member
По этой причине вы можете использовать устройство только как груду деталек и в своем ПО. А все данные что там творится получать из открытых публичных источников, не производя никакого реверс-инженеринга. Что и произведено :) Остальное пока никто не опубликовал и я не могу встроить, т.к. пользуюсь Mi-Home c оригинальными прошивками :p
понятно, просто наличие режима mi и галочки с кодированием от чего-то приводит к мысли что это возможно :) но и тут братья по разуму нам запрещают ковыряться в носу. А от чего могут быть такие странные пилы на графике влажности ( красном, от LYWSD03MM со стоковой прошивкой) синий график - датчик влажностивстроенный в увлажнитель. т.е. в целом картина сходится, но плавное нарастание по ступенькам данных от градусника и потом обрыв до каких то (реальных?) значений значительно меньше предыдущих - это от чего такие пилы?
 

Вложения

pvvx

Активный участник сообщества
понятно, просто наличие режима mi и галочки с кодированием от чего-то приводит к мысли что это возможно :)
Это для любителей шифроваться. Обычно используется совместно pin-code. Тогда данные с датчика "недруг" не увидит и датчик не перепрошьет. А кодировка Mijia с bindkey уже есть во многих "вумных домах" - оно и используется.
А от чего могут быть такие странные пилы на графике влажности ( красном, от LYWSD03MM со стоковой прошивкой) синий график - датчик влажностивстроенный в увлажнитель. т.е. в целом картина сходится, но плавное нарастание по ступенькам данных от градусника и потом обрыв до каких то (реальных?) значений значительно меньше предыдущих - это от чего такие пилы?
Это причуды вашей программы, Xiaomi cloud и передачи данных не чаще раз в 10 минут у оригинала...
Вы не описали кто построил данный график и какие компоненты участвовали в съеме показаний...
 

pvvx

Активный участник сообщества
У меня графики на тестовых вариантах термометров записывающиеся в них самих более причудливые :) К примеру у MHO-C401 часто валяющего около компа и подвергающемуся разным прошивкам, отключениям, тестам:
1617246523098.png
В принципе показывает нагретый воздух из компа :) Типа +2С всегда, когда комп работает и не спит :)
 

pvvx

Активный участник сообщества
И внутренняя запись с оригинального Xiaomi LYWSD03MMC показывающая когда работает 4K Dell монитор, т.к. валяется на полке над монитором:
1617247308102.png
Примерно так-же на +2С греется поток воздуха с монитора, когда он включен :)
 

pvvx

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

shaman1010

Member
Все-таки на 401-х неверно работает корректировка времени, возможно из-за рефреша экрана. Про корректировку +- в одну сторону уже говорил. Сейчас уточнение - корректировка в 0 - часы планомерно начинают отставать. За пол-дня ушли на 5 минут, за сутки прошлый раз отстали на 11. Если поставить корректировку "1" - то часы начинают спешить, как и при 2000 и при 20000, те.е примерно на 2 минуты в день. В логах микросекунды указываются верно, но поведение часов - неверное. Возможно рефреш экрана влияет.
Кстати, насчет рефреша - у сяомистов он был прикольней, Инвертировались и цифры и фон одновременно, т.е. даже в момент рефреша - значения оставались видимыми. В альтернативной прошивке рефреш стандартный, с двойной очисткой всего экрана, т.е. в момент рефреша - информации не видно.
 

shaman1010

Member
А дешманские с корректировкой работают нормально. Явного ухода времени не наблюдается.
 

pvvx

Активный участник сообщества
Все-таки на 401-х неверно работает корректировка времени, возможно из-за рефреша экрана. Про корректировку +- в одну сторону уже говорил. Сейчас уточнение - корректировка в 0 - часы планомерно начинают отставать. За пол-дня ушли на 5 минут, за сутки прошлый раз отстали на 11. Если поставить корректировку "1" - то часы начинают спешить, как и при 2000 и при 20000, те.е примерно на 2 минуты в день. В логах микросекунды указываются верно, но поведение часов - неверное. Возможно рефреш экрана влияет.
Кстати, насчет рефреша - у сяомистов он был прикольней, Инвертировались и цифры и фон одновременно, т.е. даже в момент рефреша - значения оставались видимыми. В альтернативной прошивке рефреш стандартный, с двойной очисткой всего экрана, т.е. в момент рефреша - информации не видно.
На MHO-C401 у меня не снят лог refresh EPD, а использован алгоритм-коды от znanev . Но остальное переписано на мою отсебятину и оптимизировано по самое...
Часы на моих MHO-С401 не уходят на столько, сколько у вас. До десятков секунд в день как макс.
MHO-С401 лепили сяомисты - там нет емкостей по питанию, только позиции для пайки :) В итоге он так-же не тянет RF-TX более 0 Дб и на них постоянно болтается питание - похоже дешман металл у контактов батареи - постоянно отходят.
Единственный где есть емкости по питанию и даже защита от переполюсовки и т.д. - CGG1-M. Другие ни один не содержат ничего подобного - удешевлены до предела из-за дороговизны чипа nRF52 - стоят от 1.5 раза и более дороже из-за применения самых отстойных nRF52810 с доп. внешней SPI-Flash или nRF52832. По спекам от Nordic на них незя даже писать Flash без дополнительных емкостей.
 
Сверху Снизу