Слушай, я с просони особо и не посмотрел картинки то. Получается они вплотную друг к другу стоят? Просто в ряд и поэтому линия 2 метра и получается. Тогда просто на последний модуль поставь этот бустер как микросхему за 33 рубля и все. Он тебе всю линию поднимет до уровня. И все нормально будет. Главное шину i2c тащи рядом с землёй, каждую отдельно. Scl с землёй вокруг неё и sda с землёй вокруг нее и подальше от dc 24v. Между платами соединяй короткими проводами, можешь экранированными.
Ну и со скоростью шины стоит поиграть, возможно максимально снизить до 10 килогерц.
Ну и главное - это питание модулей. Просесть может сильно на последнем модуле. Его стоит либо закольцевать, либо поставить dc-dc на платы.
И подключение настолько простое, что даже не интересно. Тупо параллельно линии i2c. Посмотрите datasheet. И никогда не берите такую банальщину в виде модулей.
Да, отчасти можно увеличить емкость до 4нФ, вполне реально, но от помех линия не защищен а, а от помех 24 двигателей, тем более, а линия будет проходить через все 24 модуля.
Это было первое, теперь второе:
А зачем 24 ардуины?
Если у вас энкодер на 6 контактов, управление мотором - 1 пин.
Можно вопрос - это все 6 для формирования сигнала или 2 из них это питание (vcc, gnd)?
Конфигурировать адрес можно при прошивке. Таким образом - одной ардуиной/мегой328 можно управлять 2 блоками цифр, а это 14 пинов. 2 ещё пойдут на i2c.
И в итоге уже в 2 раза меньше ардуин.
Но есть ещё вариант - atmega2560 или Arduino mega. Там 70 доступных пинов, но есть вариант такой:
Поставить расширители на i2c типа mcp23017, а они по 16 пинов добавляют (их можно до 8 штук на шину поставить) и расширить до 128 пинов.
6 * 24 = 144 пина. + 24 пина для контроля энкодера.
Пинов останется на индикацию победы любимой команды, ну или что там будет на табло...
Но линия i2c будет занята и придется 2 трансивера rs-485. Там хоть от стадиона до дома тащи линию.
Представляешь разницу в цене на 24 распаянных платы и 1 плату. Да, одна большая будет дороже одной маленькой, но сильно дешевле 24 маленьких. Одну можно и самому спаять (если заказывать на jlcpcb, то они шлют 5 минимум)
И если на плате все красиво развести, то получишь ряд разъемов по 8 пинов на один блок.
В меге2560 и памяти больше и побыстрее она будет. А если взять китайскую копию типа мини, то её можно будет на плату модулем воткнуть.
Это моё мнение и видение, поэтому можно прислушаться, но сделаете все равно по своему. И это будет правильно.
Просмотрел все части и честно, не понимаю, а зачем? Может стоит такие знания в действительно что-то более ценное погрузить. Сейчас столько всего можно сделать, в том числе и на FPGA. А тут калькулятор. Блин, зачем?! Ещё и в 9 частях!
Я не осуждаю, просто не могу понять целесообразность таких действий, столько потраченного времени, сил и ресурсов!
Ну так master-slave никто не отменял. По i2c работает, просто, есть главный и он опрашивает, также как и по RS-485 и по чистом uart. Там на i2c нужен адрес того, кто должен ответить, а тут по uart сделай виртуальные ID и тоже в виде запроса, получают все, отзывается один.
Ибо может приехать дохлое, бракованное, перемаркированное или даже классика - поддельные ft232 собранные на микроконтроллере Последний раз покупал 10 ch340 - только 4я заработала. И это особенно печально, когда делаешь прототип, то не сразу понятно, проблема в микросхемах или что-то накосячил в плате или схеме.
Да, понимаю Вас, алиэкспресс нифига не эталон качества продукции но отмечу, что за последние 3-4 года он стал куда лучше. У нас в Алматы, есть магазин DeltaChip, это по сути Chip&Dip Российский и позиционируется он как магазин качественных радиодеталей. Так вот, я первое время брал там, считая что там качественные радиокомпоненты, но когда мне 4 раза поменяли atmega328, который будучи в оригинальном корпусе, оказался битым. Я перешёл на AliExpress. И оттуда я ни разу не купил ни одну убитую или кривую микросхему. Все, что я брал - работает. Учитывая что это цифра, оно работает прекрасно. Да, резисторы плывут по номиналу, но это не влияет на макет, если я не делаю что-то на операционике или на компараторе. Кстати, прецизионные радиокомпоненты там-же беру, и они реально качественные. Датчики тока делал и на 120Ом брал резисторы,так там идеальные 120,003 Ом, я аж охренел от такого.
Сделай CAN шину, esp32 имеют can протокол на аппаратном уровне, только трансиверы поставить. Ну для ардуины придётся ставить преобразователь с spi. А там хоть 2, хоть 22 метра и на скоростях в разы выше. Суммарно купить 100 трансиверов - дешевле чем один усилитель i2c.
Кстати, попробуй uart подключить к трансиверам can. Can в чистом виде не получишь, а вот передачу сделаешь. У меня работало прекрасно. Просто uart гонялся на уровнях can шины. И расстояния приличные.
Попытки усилить и удлинить i2c приведут к тому, что не 400 и не 100 килогерц будет шина, а 10. Тогда будет удобнее rs-485 поставить.
А ещё, когда его дооснастить датчиками, считывающими местоположение хозяина в каждой комнате, с точностью до 10 сантиметров, то можно сделать очень классную логику. А когда дом будет знать, кто перед ним и у него будет файл этого человека (предпочтения, вкусы, цвет глаз, рост и так далее) то он сможет ещё и создавать и предугадывать его действия. Он будет работать по нейроалгоритмам, а не по сценарию.
Я делал такой прикол с обычной LLM Нейросетью, дал ей просто все датчики, лампочки, нагреватель (понятно что виртуально) и потом отправлял пачки состояний (сам генерил) и она мне формировала ряд действий в виде закодированной строки, которую парсим и она работает. Можно добавить датчики, дообучить, и так далее, прикольный опыт. И это уже было похоже на +/- умную систему.
Я не то что бы предвзято, это как красная тряпка, много читаю статей про умный дом, и там почти везде 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. Если это вам о чем-то говорит.
Слушай, я с просони особо и не посмотрел картинки то. Получается они вплотную друг к другу стоят? Просто в ряд и поэтому линия 2 метра и получается. Тогда просто на последний модуль поставь этот бустер как микросхему за 33 рубля и все. Он тебе всю линию поднимет до уровня. И все нормально будет. Главное шину i2c тащи рядом с землёй, каждую отдельно. Scl с землёй вокруг неё и sda с землёй вокруг нее и подальше от dc 24v. Между платами соединяй короткими проводами, можешь экранированными.
Ну и со скоростью шины стоит поиграть, возможно максимально снизить до 10 килогерц.
Ну и главное - это питание модулей. Просесть может сильно на последнем модуле. Его стоит либо закольцевать, либо поставить dc-dc на платы.
Да, понимаю, хочется сделать максимально просто, только всегда есть много НО.
И так, давай отталкиваться от реальностей:
1 - усилитель построен на микросхеме LTC4311, а это - бустер, который отслеживает фронты импульсов и автоматически подтягивает их к логическое единице. И самое прикольное, что её цена - 33 рубля за штуку. https://tellur-el.ru/catalog/integralnye_mikroskhemy_1/interfeysy_1/bufery_i_povtoriteli_1/29592/
И подключение настолько простое, что даже не интересно. Тупо параллельно линии i2c. Посмотрите datasheet. И никогда не берите такую банальщину в виде модулей.
Да, отчасти можно увеличить емкость до 4нФ, вполне реально, но от помех линия не защищен а, а от помех 24 двигателей, тем более, а линия будет проходить через все 24 модуля.
Это было первое, теперь второе:
А зачем 24 ардуины?
Если у вас энкодер на 6 контактов, управление мотором - 1 пин.
Можно вопрос - это все 6 для формирования сигнала или 2 из них это питание (vcc, gnd)?
Конфигурировать адрес можно при прошивке. Таким образом - одной ардуиной/мегой328 можно управлять 2 блоками цифр, а это 14 пинов. 2 ещё пойдут на i2c.
И в итоге уже в 2 раза меньше ардуин.
Но есть ещё вариант - atmega2560 или Arduino mega. Там 70 доступных пинов, но есть вариант такой:
Поставить расширители на i2c типа mcp23017, а они по 16 пинов добавляют (их можно до 8 штук на шину поставить) и расширить до 128 пинов.
6 * 24 = 144 пина. + 24 пина для контроля энкодера.
Пинов останется на индикацию победы любимой команды, ну или что там будет на табло...
Но линия i2c будет занята и придется 2 трансивера rs-485. Там хоть от стадиона до дома тащи линию.
Представляешь разницу в цене на 24 распаянных платы и 1 плату. Да, одна большая будет дороже одной маленькой, но сильно дешевле 24 маленьких. Одну можно и самому спаять (если заказывать на jlcpcb, то они шлют 5 минимум)
И если на плате все красиво развести, то получишь ряд разъемов по 8 пинов на один блок.
В меге2560 и памяти больше и побыстрее она будет. А если взять китайскую копию типа мини, то её можно будет на плату модулем воткнуть.
Это моё мнение и видение, поэтому можно прислушаться, но сделаете все равно по своему. И это будет правильно.
Удачи в проектах!
Просмотрел все части и честно, не понимаю, а зачем? Может стоит такие знания в действительно что-то более ценное погрузить. Сейчас столько всего можно сделать, в том числе и на FPGA. А тут калькулятор. Блин, зачем?! Ещё и в 9 частях!
Я не осуждаю, просто не могу понять целесообразность таких действий, столько потраченного времени, сил и ресурсов!
Ну так master-slave никто не отменял. По i2c работает, просто, есть главный и он опрашивает, также как и по RS-485 и по чистом uart. Там на i2c нужен адрес того, кто должен ответить, а тут по uart сделай виртуальные ID и тоже в виде запроса, получают все, отзывается один.
Да, понимаю Вас, алиэкспресс нифига не эталон качества продукции но отмечу, что за последние 3-4 года он стал куда лучше. У нас в Алматы, есть магазин DeltaChip, это по сути Chip&Dip Российский и позиционируется он как магазин качественных радиодеталей. Так вот, я первое время брал там, считая что там качественные радиокомпоненты, но когда мне 4 раза поменяли atmega328, который будучи в оригинальном корпусе, оказался битым. Я перешёл на AliExpress. И оттуда я ни разу не купил ни одну убитую или кривую микросхему. Все, что я брал - работает. Учитывая что это цифра, оно работает прекрасно. Да, резисторы плывут по номиналу, но это не влияет на макет, если я не делаю что-то на операционике или на компараторе. Кстати, прецизионные радиокомпоненты там-же беру, и они реально качественные. Датчики тока делал и на 120Ом брал резисторы,так там идеальные 120,003 Ом, я аж охренел от такого.
Сделай CAN шину, esp32 имеют can протокол на аппаратном уровне, только трансиверы поставить. Ну для ардуины придётся ставить преобразователь с spi. А там хоть 2, хоть 22 метра и на скоростях в разы выше. Суммарно купить 100 трансиверов - дешевле чем один усилитель i2c.
Кстати, попробуй uart подключить к трансиверам can. Can в чистом виде не получишь, а вот передачу сделаешь. У меня работало прекрасно. Просто uart гонялся на уровнях can шины. И расстояния приличные.
Попытки усилить и удлинить i2c приведут к тому, что не 400 и не 100 килогерц будет шина, а 10. Тогда будет удобнее rs-485 поставить.
А ещё, когда его дооснастить датчиками, считывающими местоположение хозяина в каждой комнате, с точностью до 10 сантиметров, то можно сделать очень классную логику. А когда дом будет знать, кто перед ним и у него будет файл этого человека (предпочтения, вкусы, цвет глаз, рост и так далее) то он сможет ещё и создавать и предугадывать его действия. Он будет работать по нейроалгоритмам, а не по сценарию.
Я делал такой прикол с обычной LLM Нейросетью, дал ей просто все датчики, лампочки, нагреватель (понятно что виртуально) и потом отправлял пачки состояний (сам генерил) и она мне формировала ряд действий в виде закодированной строки, которую парсим и она работает. Можно добавить датчики, дообучить, и так далее, прикольный опыт. И это уже было похоже на +/- умную систему.
Я не то что бы предвзято, это как красная тряпка, много читаю статей про умный дом, и там почти везде 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. Если это вам о чем-то говорит.