Я не то что бы предвзято, это как красная тряпка, много читаю статей про умный дом, и там почти везде WirenBoard, я его детально разобрал и был в шоке, если честно. Они его называют промышленным решением, а модули по i2c подключены, и масса ограничений, свойственных этой шине. Ну не тянет он на промышленный, как не крути. Потом - используют rs-485, отлично, хорошее решение, только эти модули ставят в том-же шкафу! И к ним тянут километры проводов! И вот это от проекта к проекту, один в один. От каждого выключателя до модуля дискретного ввода, от каждой лампочки, к модулю дискретного вывода, ну и так далее. Никакой распределенности, всегда тупо один контроллер и обвес внутри шкафа.
Хотя, у них есть классные компактные модули на rs485, которые можно поставить под выключатель (даже если модуль сдохнет, можно заменить на выключатель обычный, с фиксацией).
Но этого не делают. Я задавал много вопросов, и мне отвечают - это классическое решение. Километры проводов, под потолком (или на полу), в однушке, в щит на пол стены. Особенно улыбнули проекты, на 500 - 600 м2, в которых из гаража и из бассейна тащили освещение и управление в центральный щит! Блин, извините, но в 2025-2026 это можно сделать немного лучше. Мы так даже на производстве не делали 20 лет назад. Распределеные системы предполагают наличие нескольких шкафов с ПЛК, узлов, где можно грамотно распределить и нагрузки и управление и в конце концов обезопасить участки. Если один ПЛК тупо дохнет, остальные работают.
А так получается, я могу такую-же как wirenboard систему собрать и на esp32, подрубить по i2c или на spi модули расширения Mcp23017 (их кстати и используют модули DI/DO от Wirenboard) /mcp23s17 и сделать похожее решение. У меня 128 портов ввода вывода будет.
А самое интересное, что логика то будет максимально примитивной и обработается как if - else, ну или case. И ещё, самое главное, мне это все нейронка напишет быстрее, чем я через Web запрограммирую.
Это было во первых, а во вторых, они программируют его просто событиями, сценариями через Web интерфейс. И ни разу я не увидел адекватный код программы (хотя бы FBD на IEC) и понимаю, почему они не ставят несколько ПЛК, почему не связывают между собой, потому что в сценариях, они просто не свяжутся, и придётся городить MQTT брокера и гонять между ним данные.
Он ещё сыроватый и больше напоминает симбиоз между esp32 и Малинкой, в который постарались затолкать все то, что ему пока не нужно. И самое неприятное, что он зависит от Debian, на нем все крутится. Это сильно и отличает Wirenboard от промышленных контроллеров и даже микроконтроллеров. В них есть понятие тактирования, цикла а здесь нет, здесь программа крутится во внешней операционке. Это как Rp2040, когда они дали возможность писать на micro Python и все это подхватили, только код выполнялся медленнее чем на Arduino Nano, дольше и пробематичнее.
Я не говорю что он плохой, нет. Он просто мне не подходит. За много лет (более 30) я видел столько и очень разных и ПЛК и микроконтроллеров и ПЛИС и разных распределены и локальных систем, что wirenboard для меня - это нечто примитивное, медленное, простое, не надёжное и сырое.
А вам какие контроллеры и микроконтроллеры по душе?
Я сейчас немного отойду в другую сторону от домашней автоматизации, не поймите меня неправильно, но я думаю что это стоит сделать небольшое отступление в сторону пояснений:
Вы знаете, а ведь в языках IEC ничего плохого нет и это как основа автоматизации производства без программного кода. Научить можно кого угодно, это не с языком С и С++ разбираться, да и не каждому это дано. И если промышленность сделала унификацию и включила туда IEC то это не просто так. Представьте так картину, как это происходит сейчас в ИТ: десятки языков, сотни фреймворков, каждый привык писать в том, в чем умеет и хочет. А теперь перенесите это на производство и получим хаос. Нет четкости, везде куча "подпорок" и "костылей", нет чёткой логики и организации процесса управления. И самое печальное что нужна куча разных специалистов/программистов.
И с домашней автоматизацией сейчас происходит та-же картина, куча брендов, у каждого своя архитектура, свое облако (не у всех) и их начинают объединять по разным протоколам, на какой-нибудь Home Assistant. А есть такие, которые не работают напрямую датчиками с HA, поэтому для них ставится свой докер, свой софт, потом интегрируется с HA. Слишком много порой действий, логика вся переносится на программный уровень и работает по правилам Home Assistant. А когда SD карта на малине накрывается, то вся система падает. И ей синяя изолента не поможет, если только отметить что сдохла))) тогда лучше красную.
А что касается применения промышленных ПЛК, так вы посмотрите на Wirenboard (я его не особо уважаю, но как пример - прекрасно). Там все на проводах, классическая структура подключения входов и выходов, достаточно много модулей для различных нужд, но при этом есть и скриптовая логика и поддержка языков IEC и Scada система и многое другое. Это как пример хорошего симбиоза классических промышленных решений и современной инфраструктуры и программного обеспечения.
А что касается малинки, так это совсем не эталон качества и производительности.
И вы правы, есть люди, которые думают что только провода и старые технологии имеют место быть, но имейте ввиду что есть и те, которые считают что только беспроводные технологии, докеры, интеграторы и MQTT могут быть в нашей реальности. Это как вечный спор между стариком и молодым, а истина всегда где-то между. Все зависит от того, что хотим получить, с какой скоростью, с каких объёмах и с каким уровнем опасности/безопасности.
PS: я никогда не доверю перекрытие воды при протечек, системе Home Assistant и беспроводным технологиям, потому что этот процесс при протечке должен быть максимально контролируемым и управляемым на низком уровне. И здесь я доверюсь исключительно проводным решениям и промышленному PLC. Но это моё мнение и я его никому не навязываю, просто делюсь своим опытом.
Прекрасная статья, я как будто вернулся в 2000-е, сам с 90-х занимаюсь промышленной автоматизацией и было приятно видеть, что автор сделал на промышленное ПЛК систему автоматизации дома (я не называю такие системы "умный дом", потому как там простые сценарии, банальная логика и дистанционное управление и для меня это не умная система).
Да, решение на момент 2011 года было несомненно отличным (хотя и сейчас я тоже сделаю так-же на проводах, единственное, сделаю систему распределенной, не люблю километры проводов, поэтому буду использовать надёжный промышленный RS-485 для управления и контроля). И сейчас промышленное решение типа PLC - кажется максимально надёжным и удобным (опять же, это мышление нашего поколения, потому как мы видели становление беспроводных технологий, видели их костыли и палки, поэтому доверяем им меньше).
Хотя, если посмотреть на современные решения для "умных домов", то там мало отличий от решений прошлых десятилетий и они очень похожи на промышленные решения (отчасти). Аналогичные модули ввода-вывода, использование Modbus на rs-485, но используется Linux и программное обеспечение.
Согласен с одним из выводов в комментариях, о том, что если старая система выйдет из строя, то все нужно будет переписывать и это создаёт проблемы. Да, несомненно, отказ системы - это проблема, но там и логика как правило описана простая. Там нет PID регуляторов, нет управления динамически процессом и автор сделал все, для того, что бы отказ системы прошел максимально безболезненно. Хотя я считаю что эти PLC, ещё 30 лет отработают без напряга. Единственное, что для расширения количества каналов управления и модулей DI необходимо иметь в наличии дополнительные модули. Ну или при их отсутствии городить новые методы управления и контроля, добавляя новую подсистему.
Ничего не имею против современных решений, протоколов и модулей, сам их использую и они несомненно имеют место быть и будут всегда развиваться, но ничто не сделает систему максимально надёжной, чем датчики и исполнительные устройства на проводах.
Сейчас как раз разрабатываю такую систему которая сочетает в себе возможности шинной, распределенной и в основном проводной топологии (беспроводные решения, IoT, zeegbee и пр. тоже будут, а так-же модули, которые смогут охватить максимум необходимых задач, как для промышленных решений, так и для дома. И естественно, в основе - классика автоматизации - DI, DO, AI, AO, RS-485 (MODBUS). Посмотрим, что из этого получится, но пока все отлично!
Автору спасибо за классную статью, хотелось бы ещё увидеть логику, схемы и прочие решения вашей системы управления домом.
А с сетевым трафиком I2S не приходилось работать? С широковещательным пакетом, в полном дуплексе и просто передача звука по tcp ip? От 1 к 1 и от 1 к многим.
Сначала вы предлагаете использовать military grade микросхему, где она не нужна по факту, а потом кидаете ссылки на АлиЭкспресс где они стоят в 10 раз дешевле, чем в нормальных магазинах, и говорите про супер-пупер надёжность решения? Логика из чата вышла
А как вы считаете, микросхема 1-я, которая была предложена и последующие с AliExpress, чем они отличаются? Так вот, скажу вам, только объёмом памяти. Потому что работают они все одинаково хорошо.
Я лично в Китае, был на заводе, где делают модули ввода-вывода Siemens, так вот туда ставят китайского производства микросхемы, оптопары, диоды и всп остальное барахло, а все что лежит в "нормальных" магазинах куплено у тех-же китайцев, просто было проверено ОТК от заказчика и отбраковано порядка 40%. Просто не прошло по одному из параметров, известных только ОТК от Siemens.
Логика никуда не выходила, и сколько я беру на АлиЭкспрессе, всего один раз был брак и тот на китайском микроконтроллере Ch32v003j4M6.
Если не делать так как автор - open/append, write, close, то fatfs кеширует данные до переполнения буфера или f_close/f_flush.
А как вы предлагаете делать? Держать файл открытым? Так в этом и проблема, что автор переживает за то, что при потере питания, он потеряет данные.
Даже если делать как в статье - то запись раз минуту должна убить сектора фат-таблицы за полгода-5 лет
Все будет зависеть от объёма записи, если по 30 байт, то возможно, а если по 300,то быстрее, и sd не скажет об этом, но если помрёт один сектор, то и файл можно будет похоронить. Ну или каждый день делать новый файл, что бы не потерять все.
P.s. лет 20 назад,коллега как-то пытался "убить" eeprom на avr. Работало оно месяц без перерыва, значения из даташита превзошло на порядок. Он не победил
Я в 2003 такое делал с atmega8 и её победил, она сдохла за 2 суток. При постоянной перезаписи своих несчастных 512 байт, а в прошлом году из партии китайцев eeprom взял 3 штуки и убивал их. Да, циклов они выдержали больше заявленного, раза в 4, но сдохли!
FRAM висит уже месяцев 8, жив, здоров и не чихает.
Все куплены на AliExpress.
Нужно будет ради прикола nano и pro mini поставить на тесты.
Я fram использую очень давно. С ним нет никаких проблем.
Я расписывал здесь, как даталоггер может хранить 3 месяца в fram памяти. С вот с оперативной - это проблемы. В fram закинул байт, потом ещё, потом ещё и максимум, потерять можно байт, или последнюю запись. С оперативкой сложнее, там нужно выделять память и в этих рамках только оперировать. И потом, куда скидывать из оперативки? На SD карту, тогда постоянно это делать нужно, если не скидывать и ждать наполнения, то есть риск потерять всю оперативку. Много нюансов. И с eeprom (которая адресуется как fram) есть много проблем. Она не любит много циклов перезаписи. Если брать flash, то туда писать можно только блоками, значит эти блоки нужно собрать сначала.
SD - тоже писать секторами, значит наполнение взять нужно, но пишет долго. Есть риск потерять весь файл.
В итоге, оптимально - это fram, с бесконечной перезаписью, побайтной записью и примитивной i2c.
Попробуйте, потом скажете свое мнение. Можно начать с внешней eeprom на i2c, разобраться, как она пишет, а потом воткнуть fram.
Я вас очень понимаю и сам часто визуализирую данные в виде графиков, особенно если система динамичная. А уж все АСУ ТП системы, так там любая информация - это графики. Как менялась температура, давление, расход и многое другое (PiSystem от Osi Soft, один из представителей подобного рода систем)
Здесь же, автор говорил именно про логгирование. Не хочу быть душным, но это немного другое:
Логгирование информации (журналирование) — это автоматическая текстовая запись хронологии событий, происходящих в компьютерной системе, программе или оборудовании.
Сам по себе лог — это строго текст или структурированные данные.
Ну а графическом представление, которое более информативное - это визуализация данных.
И то и другое имеет место быть и они имеют разное назначение.
Ram - это оперативка и в ней хранить как то не безопасно. Суть логгера сохранить данные, ну и забивать эту память в динамике - можно просто повешать МК при переполнении.
Использование внутренней флеш-памяти ESP32 для постоянного побайтового или построчного логирования приведет к быстрому выходу устройств из строя на реальных объектах.
Встроенная память рассчитана на 100 000 циклов записи и не факт что она их отработает. Если много логов, то спустя год - полтора могут начаться проблемы с записью и чтением. А если циклически записывать данные в одну и ту же ячейку (например, каждую секунду в цикле loop), память выйдет из строя всего за ~27 часов.
Поэтому контроллер лучше использовать как управление, а данные гонять грамотно и оптимизировано, учитывая возможности модулей и компонентов.
Они меньший ресурс имеют чем FRAM, но думаю что при нечастой записи их на век хватит.
Я так понял, SD карта требуется в случаях когда логгер куда-то жестко вмонтирован, и есть ситуация когда пропадает связь а данные требуется считать.
По сути да, и логгер всегда стоит в параллель с потоком данных и сам не занимается считыванием, иначе он становится основным датчиком с накоплением, а не логгером.
А самый оптимальный вариант - это накопление данных в EEPROM или FRAM, а потом, при заполнении переписать на SD. В новый файл, не трогая предыдущий, для сохранения. Затем проверить записались ли данные и сравнить их с тем, что лежит в EEPROM или FRAM и если все ок, то очистить EEPROM или FRAM и приготовиться писать туда опять.
Ну вам видимо нужно много попкорна, а мы так обогатительные фабрики автоматизировали и рудники, не говоря уже про банальные комнаты. Вы вообще понимаете, о чем иднт речь или так просто написать решили? Я же написал про шину rs485, а это немного промышленный стандарт, который легко поднимается где угодно, ну а питание для примитивных датчиков в пару миллиампер - не проблема, в том же кабеле вместе с rs485. Если это вам о чем-то говорит.
А где лог? Я вижу только график и он без пояснений, а лог - это обычно текст, с отметкой времени и данными. Возможно с пояснения и, заметками, отметками. Формат любой по желанию. И лог не предназначен для вывода в виде графика, в виде данных и так далее, лог нужен для того, что бы восстановить пропущенные данные в базах, увидеть и понять какие либо ошибки, а график, который представлен здесь нужен для понимания работы процесса, датчика и так далее, для поиска зависимостей, и всего того, что душа пожелает.
Эта версия, да, стоит дорого, но есть дешевле, объёмом немного меньше.
FM24V10-G на 1 мегабит, или MB85RC256V на 256 килобит. Эти стоят менее 100 рублей, но они вечные, ни одна SD карта столько не отработает и запись на них простая, я выше писал преимущества.
Так там же емкостный датчик влажности применяется, он не имеет контакта открытой меди с грунтом, соответственно окисления нет. Его ещё отдельно лаком заливают, что бы герметичность была лучше.
Очень странно, я же спросил автора, а не критиковал, а мне за вопрос кинули - 1, для меня это действительно интересно, потому что хочу сделать просто как на плате у автора, но мне ещё важна безопасность при эксплуатации.
Серьёзно? А вы в норме? Людей оскорбляете, себя ставите выше всех присутствующих, ноги о мнение других вытираете, а не адекватный здесь я?
А рот вам нужно помыть, что бы больше не говорить такой бред! И совет на будущее: если думаете что что-то знаете, перепроверьте и потом уже доказывайте, есть вероятность ошибиться и потом выглядеть по идиотски.
А самое неприятное, вы ни разу не признали ни один факт того, что ошиблись и продолжаете стоять на своём, это признак нарциссизма, эгоцентризма, и догматичности.
Это по вашему адекватность?
Прощайте и удачи вам.
Нет желания более общаться, тем более это и общением то назвать нельзя. Есть вы, есть ваше мнение и есть другое-неправильное.
А зачем такие непонятные действия делать? И потом коммутировать перед началом записи? Типа дополнительная емкость, ну тогда нужно перед ними, на линии питания диод ставить, что бы разряд шёл только с схему, а не на другие конденсаторы и стабилизаторы (если они там будут).
Я что-то похожее делал для бистабильно го реле, что бы отключать его, если пропало питание. Они же без тока не переключаться обратно, поэтому дополнительное микрореле ставил и коммутировать его так, что бы заряженные конденсаторы отрабатывали на отключающие катушки. Вам можно сделать аналогично. Коммутация конденсатора в момент отключения питания. Реле подключено на самом входе без конденсатор в, потом диод, что бы конденсаторы не удерживали катушку реле, за диодом конденсатор базовый и следом подключаемый.
Я не то что бы предвзято, это как красная тряпка, много читаю статей про умный дом, и там почти везде WirenBoard, я его детально разобрал и был в шоке, если честно. Они его называют промышленным решением, а модули по i2c подключены, и масса ограничений, свойственных этой шине. Ну не тянет он на промышленный, как не крути. Потом - используют rs-485, отлично, хорошее решение, только эти модули ставят в том-же шкафу! И к ним тянут километры проводов! И вот это от проекта к проекту, один в один. От каждого выключателя до модуля дискретного ввода, от каждой лампочки, к модулю дискретного вывода, ну и так далее. Никакой распределенности, всегда тупо один контроллер и обвес внутри шкафа.
Хотя, у них есть классные компактные модули на rs485, которые можно поставить под выключатель (даже если модуль сдохнет, можно заменить на выключатель обычный, с фиксацией).
Но этого не делают. Я задавал много вопросов, и мне отвечают - это классическое решение. Километры проводов, под потолком (или на полу), в однушке, в щит на пол стены. Особенно улыбнули проекты, на 500 - 600 м2, в которых из гаража и из бассейна тащили освещение и управление в центральный щит! Блин, извините, но в 2025-2026 это можно сделать немного лучше. Мы так даже на производстве не делали 20 лет назад. Распределеные системы предполагают наличие нескольких шкафов с ПЛК, узлов, где можно грамотно распределить и нагрузки и управление и в конце концов обезопасить участки. Если один ПЛК тупо дохнет, остальные работают.
А так получается, я могу такую-же как wirenboard систему собрать и на esp32, подрубить по i2c или на spi модули расширения Mcp23017 (их кстати и используют модули DI/DO от Wirenboard) /mcp23s17 и сделать похожее решение. У меня 128 портов ввода вывода будет.
А самое интересное, что логика то будет максимально примитивной и обработается как if - else, ну или case. И ещё, самое главное, мне это все нейронка напишет быстрее, чем я через Web запрограммирую.
Это было во первых, а во вторых, они программируют его просто событиями, сценариями через Web интерфейс. И ни разу я не увидел адекватный код программы (хотя бы FBD на IEC) и понимаю, почему они не ставят несколько ПЛК, почему не связывают между собой, потому что в сценариях, они просто не свяжутся, и придётся городить MQTT брокера и гонять между ним данные.
Он ещё сыроватый и больше напоминает симбиоз между esp32 и Малинкой, в который постарались затолкать все то, что ему пока не нужно. И самое неприятное, что он зависит от Debian, на нем все крутится. Это сильно и отличает Wirenboard от промышленных контроллеров и даже микроконтроллеров. В них есть понятие тактирования, цикла а здесь нет, здесь программа крутится во внешней операционке. Это как Rp2040, когда они дали возможность писать на micro Python и все это подхватили, только код выполнялся медленнее чем на Arduino Nano, дольше и пробематичнее.
Я не говорю что он плохой, нет. Он просто мне не подходит. За много лет (более 30) я видел столько и очень разных и ПЛК и микроконтроллеров и ПЛИС и разных распределены и локальных систем, что wirenboard для меня - это нечто примитивное, медленное, простое, не надёжное и сырое.
А вам какие контроллеры и микроконтроллеры по душе?
Я сейчас немного отойду в другую сторону от домашней автоматизации, не поймите меня неправильно, но я думаю что это стоит сделать небольшое отступление в сторону пояснений:
Вы знаете, а ведь в языках IEC ничего плохого нет и это как основа автоматизации производства без программного кода. Научить можно кого угодно, это не с языком С и С++ разбираться, да и не каждому это дано. И если промышленность сделала унификацию и включила туда IEC то это не просто так. Представьте так картину, как это происходит сейчас в ИТ: десятки языков, сотни фреймворков, каждый привык писать в том, в чем умеет и хочет. А теперь перенесите это на производство и получим хаос. Нет четкости, везде куча "подпорок" и "костылей", нет чёткой логики и организации процесса управления. И самое печальное что нужна куча разных специалистов/программистов.
И с домашней автоматизацией сейчас происходит та-же картина, куча брендов, у каждого своя архитектура, свое облако (не у всех) и их начинают объединять по разным протоколам, на какой-нибудь Home Assistant. А есть такие, которые не работают напрямую датчиками с HA, поэтому для них ставится свой докер, свой софт, потом интегрируется с HA. Слишком много порой действий, логика вся переносится на программный уровень и работает по правилам Home Assistant. А когда SD карта на малине накрывается, то вся система падает. И ей синяя изолента не поможет, если только отметить что сдохла))) тогда лучше красную.
А что касается применения промышленных ПЛК, так вы посмотрите на Wirenboard (я его не особо уважаю, но как пример - прекрасно). Там все на проводах, классическая структура подключения входов и выходов, достаточно много модулей для различных нужд, но при этом есть и скриптовая логика и поддержка языков IEC и Scada система и многое другое. Это как пример хорошего симбиоза классических промышленных решений и современной инфраструктуры и программного обеспечения.
А что касается малинки, так это совсем не эталон качества и производительности.
И вы правы, есть люди, которые думают что только провода и старые технологии имеют место быть, но имейте ввиду что есть и те, которые считают что только беспроводные технологии, докеры, интеграторы и MQTT могут быть в нашей реальности. Это как вечный спор между стариком и молодым, а истина всегда где-то между. Все зависит от того, что хотим получить, с какой скоростью, с каких объёмах и с каким уровнем опасности/безопасности.
PS: я никогда не доверю перекрытие воды при протечек, системе Home Assistant и беспроводным технологиям, потому что этот процесс при протечке должен быть максимально контролируемым и управляемым на низком уровне. И здесь я доверюсь исключительно проводным решениям и промышленному PLC. Но это моё мнение и я его никому не навязываю, просто делюсь своим опытом.
Прекрасная статья, я как будто вернулся в 2000-е, сам с 90-х занимаюсь промышленной автоматизацией и было приятно видеть, что автор сделал на промышленное ПЛК систему автоматизации дома (я не называю такие системы "умный дом", потому как там простые сценарии, банальная логика и дистанционное управление и для меня это не умная система).
Да, решение на момент 2011 года было несомненно отличным (хотя и сейчас я тоже сделаю так-же на проводах, единственное, сделаю систему распределенной, не люблю километры проводов, поэтому буду использовать надёжный промышленный RS-485 для управления и контроля). И сейчас промышленное решение типа PLC - кажется максимально надёжным и удобным (опять же, это мышление нашего поколения, потому как мы видели становление беспроводных технологий, видели их костыли и палки, поэтому доверяем им меньше).
Хотя, если посмотреть на современные решения для "умных домов", то там мало отличий от решений прошлых десятилетий и они очень похожи на промышленные решения (отчасти). Аналогичные модули ввода-вывода, использование Modbus на rs-485, но используется Linux и программное обеспечение.
Согласен с одним из выводов в комментариях, о том, что если старая система выйдет из строя, то все нужно будет переписывать и это создаёт проблемы. Да, несомненно, отказ системы - это проблема, но там и логика как правило описана простая. Там нет PID регуляторов, нет управления динамически процессом и автор сделал все, для того, что бы отказ системы прошел максимально безболезненно. Хотя я считаю что эти PLC, ещё 30 лет отработают без напряга. Единственное, что для расширения количества каналов управления и модулей DI необходимо иметь в наличии дополнительные модули. Ну или при их отсутствии городить новые методы управления и контроля, добавляя новую подсистему.
Ничего не имею против современных решений, протоколов и модулей, сам их использую и они несомненно имеют место быть и будут всегда развиваться, но ничто не сделает систему максимально надёжной, чем датчики и исполнительные устройства на проводах.
Сейчас как раз разрабатываю такую систему которая сочетает в себе возможности шинной, распределенной и в основном проводной топологии (беспроводные решения, IoT, zeegbee и пр. тоже будут, а так-же модули, которые смогут охватить максимум необходимых задач, как для промышленных решений, так и для дома. И естественно, в основе - классика автоматизации - DI, DO, AI, AO, RS-485 (MODBUS). Посмотрим, что из этого получится, но пока все отлично!
Автору спасибо за классную статью, хотелось бы ещё увидеть логику, схемы и прочие решения вашей системы управления домом.
Очень интересное решение!
А с сетевым трафиком I2S не приходилось работать? С широковещательным пакетом, в полном дуплексе и просто передача звука по tcp ip? От 1 к 1 и от 1 к многим.
А как вы считаете, микросхема 1-я, которая была предложена и последующие с AliExpress, чем они отличаются? Так вот, скажу вам, только объёмом памяти. Потому что работают они все одинаково хорошо.
Я лично в Китае, был на заводе, где делают модули ввода-вывода Siemens, так вот туда ставят китайского производства микросхемы, оптопары, диоды и всп остальное барахло, а все что лежит в "нормальных" магазинах куплено у тех-же китайцев, просто было проверено ОТК от заказчика и отбраковано порядка 40%. Просто не прошло по одному из параметров, известных только ОТК от Siemens.
Логика никуда не выходила, и сколько я беру на АлиЭкспрессе, всего один раз был брак и тот на китайском микроконтроллере Ch32v003j4M6.
А как вы предлагаете делать? Держать файл открытым? Так в этом и проблема, что автор переживает за то, что при потере питания, он потеряет данные.
Все будет зависеть от объёма записи, если по 30 байт, то возможно, а если по 300,то быстрее, и sd не скажет об этом, но если помрёт один сектор, то и файл можно будет похоронить. Ну или каждый день делать новый файл, что бы не потерять все.
Я в 2003 такое делал с atmega8 и её победил, она сдохла за 2 суток. При постоянной перезаписи своих несчастных 512 байт, а в прошлом году из партии китайцев eeprom взял 3 штуки и убивал их. Да, циклов они выдержали больше заявленного, раза в 4, но сдохли!
FRAM висит уже месяцев 8, жив, здоров и не чихает.
Все куплены на AliExpress.
Нужно будет ради прикола nano и pro mini поставить на тесты.
Я fram использую очень давно. С ним нет никаких проблем.
Я расписывал здесь, как даталоггер может хранить 3 месяца в fram памяти. С вот с оперативной - это проблемы. В fram закинул байт, потом ещё, потом ещё и максимум, потерять можно байт, или последнюю запись. С оперативкой сложнее, там нужно выделять память и в этих рамках только оперировать. И потом, куда скидывать из оперативки? На SD карту, тогда постоянно это делать нужно, если не скидывать и ждать наполнения, то есть риск потерять всю оперативку. Много нюансов. И с eeprom (которая адресуется как fram) есть много проблем. Она не любит много циклов перезаписи. Если брать flash, то туда писать можно только блоками, значит эти блоки нужно собрать сначала.
SD - тоже писать секторами, значит наполнение взять нужно, но пишет долго. Есть риск потерять весь файл.
В итоге, оптимально - это fram, с бесконечной перезаписью, побайтной записью и примитивной i2c.
Попробуйте, потом скажете свое мнение. Можно начать с внешней eeprom на i2c, разобраться, как она пишет, а потом воткнуть fram.
Я вас очень понимаю и сам часто визуализирую данные в виде графиков, особенно если система динамичная. А уж все АСУ ТП системы, так там любая информация - это графики. Как менялась температура, давление, расход и многое другое (PiSystem от Osi Soft, один из представителей подобного рода систем)
Здесь же, автор говорил именно про логгирование. Не хочу быть душным, но это немного другое:
Логгирование информации (журналирование) — это автоматическая текстовая запись хронологии событий, происходящих в компьютерной системе, программе или оборудовании.
Сам по себе лог — это строго текст или структурированные данные.
Ну а графическом представление, которое более информативное - это визуализация данных.
И то и другое имеет место быть и они имеют разное назначение.
Ram - это оперативка и в ней хранить как то не безопасно. Суть логгера сохранить данные, ну и забивать эту память в динамике - можно просто повешать МК при переполнении.
Использование внутренней флеш-памяти ESP32 для постоянного побайтового или построчного логирования приведет к быстрому выходу устройств из строя на реальных объектах.
Встроенная память рассчитана на 100 000 циклов записи и не факт что она их отработает. Если много логов, то спустя год - полтора могут начаться проблемы с записью и чтением. А если циклически записывать данные в одну и ту же ячейку (например, каждую секунду в цикле loop), память выйдет из строя всего за ~27 часов.
Поэтому контроллер лучше использовать как управление, а данные гонять грамотно и оптимизировано, учитывая возможности модулей и компонентов.
Да, вполне можно и эти использовать.
Они меньший ресурс имеют чем FRAM, но думаю что при нечастой записи их на век хватит.
По сути да, и логгер всегда стоит в параллель с потоком данных и сам не занимается считыванием, иначе он становится основным датчиком с накоплением, а не логгером.
А самый оптимальный вариант - это накопление данных в EEPROM или FRAM, а потом, при заполнении переписать на SD. В новый файл, не трогая предыдущий, для сохранения. Затем проверить записались ли данные и сравнить их с тем, что лежит в EEPROM или FRAM и если все ок, то очистить EEPROM или FRAM и приготовиться писать туда опять.
Да нет, не белорусских. Я правда в тенге смотрю, потому как из Казахстана. Ну вот, посмотрите сами:
Курс рубля: за 1 рубль 6 тенге. Посчитайте.
Я когда нашёл за такую цену, заказал себе 2 десятка. Есть пара проектов, куда их можно будет применить.
От 500 до 5000 Ампер, для тиристора
До 400-500 Ампер симмисторы справляются.
И это все на запуск, на постоянную работу уже идут контакторы, после запуска, но бывают исключения, когда приходится гонять все только на тиристорах.
Ну и ещё IGBT на таких токах работают, очень неплохо. Но сильно дороже.
Ну вам видимо нужно много попкорна, а мы так обогатительные фабрики автоматизировали и рудники, не говоря уже про банальные комнаты. Вы вообще понимаете, о чем иднт речь или так просто написать решили? Я же написал про шину rs485, а это немного промышленный стандарт, который легко поднимается где угодно, ну а питание для примитивных датчиков в пару миллиампер - не проблема, в том же кабеле вместе с rs485. Если это вам о чем-то говорит.
А где лог? Я вижу только график и он без пояснений, а лог - это обычно текст, с отметкой времени и данными. Возможно с пояснения и, заметками, отметками. Формат любой по желанию. И лог не предназначен для вывода в виде графика, в виде данных и так далее, лог нужен для того, что бы восстановить пропущенные данные в базах, увидеть и понять какие либо ошибки, а график, который представлен здесь нужен для понимания работы процесса, датчика и так далее, для поиска зависимостей, и всего того, что душа пожелает.
Эта версия, да, стоит дорого, но есть дешевле, объёмом немного меньше.
FM24V10-G на 1 мегабит, или MB85RC256V на 256 килобит. Эти стоят менее 100 рублей, но они вечные, ни одна SD карта столько не отработает и запись на них простая, я выше писал преимущества.
Так там же емкостный датчик влажности применяется, он не имеет контакта открытой меди с грунтом, соответственно окисления нет. Его ещё отдельно лаком заливают, что бы герметичность была лучше.
Очень странно, я же спросил автора, а не критиковал, а мне за вопрос кинули - 1, для меня это действительно интересно, потому что хочу сделать просто как на плате у автора, но мне ещё важна безопасность при эксплуатации.
А здесь на входе 220В просто делитель стоит? Я просто не вижу ни диодов ни чего-то ещё. И развязки я так понимаю нет, везде есть высокий потенциал?
Серьёзно? А вы в норме? Людей оскорбляете, себя ставите выше всех присутствующих, ноги о мнение других вытираете, а не адекватный здесь я?
А рот вам нужно помыть, что бы больше не говорить такой бред! И совет на будущее: если думаете что что-то знаете, перепроверьте и потом уже доказывайте, есть вероятность ошибиться и потом выглядеть по идиотски.
А самое неприятное, вы ни разу не признали ни один факт того, что ошиблись и продолжаете стоять на своём, это признак нарциссизма, эгоцентризма, и догматичности.
Это по вашему адекватность?
Прощайте и удачи вам.
Нет желания более общаться, тем более это и общением то назвать нельзя. Есть вы, есть ваше мнение и есть другое-неправильное.
А зачем такие непонятные действия делать? И потом коммутировать перед началом записи? Типа дополнительная емкость, ну тогда нужно перед ними, на линии питания диод ставить, что бы разряд шёл только с схему, а не на другие конденсаторы и стабилизаторы (если они там будут).
Я что-то похожее делал для бистабильно го реле, что бы отключать его, если пропало питание. Они же без тока не переключаться обратно, поэтому дополнительное микрореле ставил и коммутировать его так, что бы заряженные конденсаторы отрабатывали на отключающие катушки. Вам можно сделать аналогично. Коммутация конденсатора в момент отключения питания. Реле подключено на самом входе без конденсатор в, потом диод, что бы конденсаторы не удерживали катушку реле, за диодом конденсатор базовый и следом подключаемый.