@hamster, поддерживаю!
только чувствую что сейчас придёт Богер, обидется и предложит вернуть модуль и деньги, попутно уточнив что модуль не их разработка, а невотона и они его просто продают
по сути, как я считаю, opentherm это открытый протокол, а каждый производитель уже интерпретирует его как захочет (к сожалению). поэтому по хорошему, в модуле надо выбирать тип устройства (generic opertherm по дефолту и список реально протежируемых котлов), т.к. с каждым котлом работа чуть-чуть будет отличаться
по чтению - тоже сложилось впечатление что читается заданный список по кругу, хотя логичнее читать то что отдаёт котёл (возврат к модели) или же чуть умнее, если связь есть (наверное контроль вычитки id = 0) и если Х раз не удалось вычитать какой то id, то выкидывать его их цикла до пропадания связи (проблем с чтением id = 0)
так же разумно читать разные параметры с разными весами, т.к. тот же id = 0 читать часто, т.к. там режим работы, а какие нибудь минимумы и максимумы гвс - очень редко, т.к. в принципе они и не меняются (но могут конечно же)
предположу, что имеющие быть проблемы с “нереальными” значениями, которые ведёт модуль и про которые отвечают что это провода неправильные или наводки, могут быть связаны как раз с таймингами… и тут два варианта, или в коде явно ошибка, если код однопоточный, или если многопоточный, то блокировки в другом потоке который приводят к этому… а может просто неправильный выбор базовой железки, которая не может обеспечить в принципе достаточную точность отсчётов времени.
с учётом хотя бы невозможности обновления прошивки нормальными методами из за нехватки места под данный функционал в модуле, логичным выглядит замена на более старшую модель, но этого не будет сделано в текущих реалиях
а прошивка сырая и страдать будем долго ещё…