Экспериментирую с модулем термостата, мне там надо аж 11 шт., соответственно, гпио расширены с помощью 2-х 74HC595. Проверяю логику работы с реальным датчиком (взял для теста DHT22, будут 18b20) - при переходе значений через установленные пороги - все тип-топ. Но после сброса девайса, состояние выхода(ов) почти всегда "выкл", хотя значение датчика ниже порога включения. Это баг?

добавлю - речь идет о сбросе при подаче питания, выходы через пару секунд могут принять правильное значение на полсекунды, потом сбрасываются. После кнопочного сброса вроде работает штатно.

Не эксперементировал никто в такой ситуации - нужно проверять алгоритмы

Набрал статистику:
1. сбои в логике случаются и после кнопочного сброса, просто реже
2. сбои случаются только с включенным сервером mqtt (с внешним брокером cloudmqtt, со своим, в локальной сети, сбоев пока не наблюдал)
3. правильные значения на выходах девайс устанавливает где-то секунд через 6-7 после сброса. Если девайс получает IP адрес сильно раньше и успевает заранее отправить топики (хоть и с нулевыми значениями) брокеру, до того как значения на выходах установятся как надо, то все ок. А вот если это происходит практически одновременно - то бывает, что значения ставятся и тут же сбрасываются.
По моему мнению происходит следующее: девайс слушает брокер, и реагирует на свои же собственные отправленные топики, а из-за того, что брокер внешний и они приходят с задержкой (по моим прикидкам - около секунды), то схема при сбоях получается такой - он отправляет на брокер нулевые значения выходов -> устанавливает значения выходов как положено по логике термостата -> слышит свои же топики с брокера (нулевые) -> устанавливает значения в соответствии с ними - т.е. в нуль.
Думаю, надо как-то поменять логику отправки значений выходов брокеру. Или хотя бы чаще проверять условия термостата, не только при переходе данных через пороги.
Я бы и сам в конструкторе кода их проверял, да не знаю, где лежат необходимые данные (пороги, включен ли термостат, какой датчик управляет)

mqtt не сразу стартует, он где-то секунд через 15 стартует, за это время датчики хотя бы раз успевают считываться и термостат принимает нужное состояние..

При всем уважении, не-а, не через 15, топики начинают посылаться сразу как IP появляется (у меня динамика). Я специально вывел на tft ip с частотой 1 сек и повесил стороннего клиента mqtt на данные топики. С моим DHCP сервером ip выдается секунды за 3 (обычно.. но не всегда).
А схема именно такая, как я описал...
И в процессе длительной работы наблюдал, что один из выходов, изначально включенный (18b20 говорит ~20 гр., границы 30-31, выход д.б. вкл.) оказывается выключенным. Сам момент выключения я не видел. Может, датчик глюкнул в какой-то момент, выдал повышенное значение. Не знаю. Но факт в том, что при таком сбое логика нарушается, и восстанавливается только при сбросе или при переходе значений датчика через границы. Это в корне неверно. В случае термостата нагреватель просто вырубится и все замерзнет...
Кстати, обратил внимание, что на другом моем девайсе, где просто gpio управляется изнутри кода (в моем случае, от посылки nrf24), после добавления поддержки mqtt, стали появляться похожие сбои, редко правда. Выглядит немного схоже - выход GPIO1 меняет свое состояние (как ему положено в моем коде) и через мгновенье сбрасывается. Или по моему таймеру он же должен отключиться, а не отключается.. Замечено за неделю уже раз 6.., до включения в прошивку mqtt работало пару месяцев без подобных эффектов.