конечно можно сделать кондовые контуры на норм оборудовании (отдельно котёл, отдельно сигнализация), а с них уже снимать информацию в какую-нибудь погремушку типа rpi, но в такой схеме это всё должно работать без rpi само по себе

Но я же не говорю о надежности как у техники NASA) отказ всей схемы обычно тесно зависит от отказа разных её частей, еще в тервере даже задачки есть, мол, рассчитайте вероятность отказа, если для двух параллельных узлов вероятности отказов по 0.5 и т.п.). ограничивающий резистор это уже вопрос допуска, насколько отклонение может быть большим, чтобы светодиод, крайне чувствительный к току все это выдержал в норме и на предельных нагрузках, какой ток может выдать узел перед ним. Конечно, для светодиода в общем случае не будут ставить военные допуски, но для каких-нибудь усилителей, обратных связей, шунтов и чего-то там такого непредсказуемый и шумный резистор может подкинуть проблем. Ну а в части температуры, то если окружающее оборудование держит 60, то в игру вступает внутренний разогрев компонентов самих по себе, друг от друга, от плохой вентиляции корпуса, так что вполне может быть неравномерная температура в разных местах. Те же микрухи\транзисторы склонны адово все вокруг нагревать при выходе из строя, при плотном монтаже это прямое влияние на компоненты рядом.

ну и по итогу даже эти задачки на отказ системы, а не узла, по итогу нужно смотреть как сделано всё целиком (питание, охлаждение и тд), а не насколько качественные компоненты стоят

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

ну, кстати, вот автор LWDR выдал новую версию https://forum.dlang.org/thread/zlnplbmdlcazkokccbxx@forum.dlang.org

пока у меня время на электронику появится, он это все допилит, буду на ди писать).

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

ну ... приложение, управляющее входом - с логином-паролем, да (:

устраняли подбором сопротивления в цепи, связанной с микрофоном.

Кто-нибудь знает этого господина? Он похоже русскоговорящий:
https://www.youtube.com/playlist?list=PLgM-lc_kSqFQPF0UXgmFZpZalqcrSofe-

Вроде нет

Не знаю зачем вам но это было на первой странице в гугла
https://lhs-blog.info/programming/dlang/formula-tappera-v-d-posredstvom-dlib/

вот кстати от сегфолта из-за null неплохо помогают контракты, особенно out. Но из-за них мне как-то боязно собирать в release, насколько я в курсе контракты, boundscheck и ассерты удаляются и это выглядит такой себе затеей. Получается, что отключаются проверки в либах, у того же xml миллиарды миллионов невалидных состояний, а я смотрю в dxml https://github.com/jmdavis/dxml/blob/ebee7c6e35db270d981d1f2584eea97c9eb54625/source/dxml/parser.d#L1057 стоят assert-ы. Ситуация выходит такой: потестили в дебаге, все работает, но потом прилетает невалидный xml, содержимое которого предсказать в общем случае невозможно... кгм...

>а потом прилетает невалидный xml
напиши тест на невалидный xml ¯\_(ツ)_/¯

эм... в общем случае я не могу предвидеть ситуаций, когда что-то пойдет не по плану, ну и трата времени на тестирование уязвимого к ошибкам кода выглядит затеей неблагодарной. Я так понимаю, что жить мне без release вечно, пусть лучше лишний раз упадет, чем ошибку пропустит.

=ну и трата времени на тестирование уязвимого к ошибкам кода выглядит затеей неблагодарной= - тяжело ж потом все эти программистские поделия внедрять, при таком-то подходе (: (это я о наболевшем)

ну там у них скорее выбор между производительностью и надежностью. Если выбрать второе и нашпиговать код проверками, то могут быть претензии, с т.з. автора либы скорее выбор производительности более логичен, учитывая задачи парсинга xml. Если же выигрыш между enforce и assert не столь значителен, то это уже другой вопрос, но им виднее там.

возможно, там тестировали под нагрузками

Я вообще до конца не понял твою цель — стабильность или что? Если стабильность то ты просто берёшь и оборачиваешь все места где можешь получить некорректный xml эксепшенами и ловишь их на уровне выше а потом думаешь что делать

а откуда я знаю, что там вылетит корректный эксепшен, а код не сделает что-нибудь не то? В коде выше если ассерт выпилить, то поток управления пойдет дальше. Да даже если и оставить, то AssertError как невосстанавливаемую ошибку тоже ловить такое себе, как и Error\Throwable. И так и так плохо, но второе выглядит лучше. Если из двух зол выбирать, то я выберу оверхед по производительности.