volomoto

Якщо він вже є, ви вже наловчились і загалом функціонал достатній, то я б залишав як є. Ну хіба дуже хочеться побавитись з есп32, то тут вас ніхт оне може зупинити

Як резервне джерело тепла, то так, а от економічної вигоди нема. Хороший кондиціонер на нагрів може мати більший сенс, ніж ТП котел. Я правда не знаю яка ціна дров у вас, але якщо вона типова, то не так привабливо. Також котел малої потужності — це мала камера згоряння, тому постійна кочегарка, а без системи підтримки температури зворотньої води — це й частий секс із забитим смерджючим комином.

Окей, я просто не зрозумів що два останні пункти пов'язані. Правда отримати таку модель в неконтрольованих умовах і без відповідних навичок доволі важко, тому я схиляюсь до mass flow сенсорів, які хоч і дорожче, але це заміри, а не розрахнуки.

Але ж це співвідношення змінюється залжено від наявносні інтенсивності конденсації. Можна щось крутити тільки по температурі, але зовсім не факт, що воно зробить щось краще.

А що за контроллер? Якийсь Carel?

Для налагодження алготитму швидкодія сенсора має значення і чим більша — тим краще. інше питання це швидкодія самого алгоритму керування, яка має відповідати динаміці фізичних процесів, тобто мати правильну константу часу. І отримувати значення сенсора із затримкою в 10 с — це не то саме, що робити семплінг кожних 10 секунд. Частота семплінгу може бути дуже малою, але якщо вже йде замір, то краще знати значення в даний момент, а не на якийсь відчутно великий час в минулому.

То складне питання і залежить що за контроллер у вас, але якщо до нього можна підключитись тільки по USB, то це дуже незручно. З ESP32 також не все гладко, бо для таких задач краще писати свою прошивку на плюсах і без своєї плати воно буде виглядати дуже страшненько. Мій досвід показує, що esphome — це багато костилів, якщо потрібно щось трохи складніше, бо нема контролю над control loop контроллера і приходиться писати костилі на лямбдах. Цифрові сенсори простіші в розводці і програмуванні, але програють у швидкодії. Для керування нагрівачем однозначно має бути серсор типу RTD, NTC чи термопари, який заведений на АЦП контроллера. На ESP32 можна зробити багато всього, але гола плата не підходить для серйозних задач, бо потрібно дуже багато інтерфейсних модулів. Там банально нема гальванічної розв'язки по входах. Якщо рухатись в ту сторону, то краще взяти щось типу такого www.aliexpress.com/item/1005004246120574.html?

Залежить де. Є місця з дуже високим рівнем грунтових вод.

Так, в інструкціях там каша, бо отут вже ніякого нахилу самої вентустановки нема:

Збираюсь, але це не пріоритет. В нагрівачі є ТЕН, сенсор і симістор, в мене є PLC – цього більш ніж достатньо, щоб реалізувати будь-який алгоритм. PID на моєму контроллері робиться в три кліки.

Температура почалась змінюватись (рости), і це дало можливість більше зрозуміти алгоритм контролю нагрівачам, зокрема: 1. Температура, яка виставляється на крутилці нагрівача, це температура при якій включається ТЕН. Тобто якщо виставити -2, як на графіку нижче, то температура повітря після нагрівача не буде меншою, ніж -2, але нема точного контролю, до якої температури буде нагріватись повітря. 2. ТЕН включається на 45 секунд в 99.9% випадків. Було кілька випадків що ніби менше часу, але це може бути проблема частоти збору інформації. 3. При тій самій уставці середня температура після нагрівача залежить від температури вхідного повітря. Якщо надворі -15, то після нагрівача буде десь -2. Якщо ж надворі трохи нижче -2, то на виході нагрівача буде 0 або навіть +1. Замерзнути ТО цей нагрівач не дасть, але трохи перегрівати вхідне повітря може, що негативно впливає на ККД. Нагрівач не керується сенсором, дані з якого є на графіки, а має свій вбудований, який стоїть після ТЕНа. Там, де курсос на графіку, так вийшло, що ТЕН заміри всіх сернсорів співпали, а переважно нагрівач бачить те, що показує голубий графік.

Це різні вентустановки

Все правильно, бо калькулятор враховує динамічний тиск, а я сказав тільки про статичну втрату за рахунок тертя, але не врахував динамічну втрату тиску за рахунок турбулентності потоку, яка в мусить бути сильно виражена в ТО, щоб був теплообмін.

Не будуть вони міряти, це утопія. Без каліброваних сенсорів швидкості повітря це все гадання, а не контроль, бо на тиск впливає багато всього і фільтрування показів сенсора тиску стає складною і непотрібною для вирішення задачею. Ні, 25 Па, бо спад тиску залежить квадратично від потоку повітря. При зменшенні потоку в два рази тиск падає в 4, а споживана вентиляторами потужність — у 8 разів.

Відгоряння нуля на підстанції — це якраз те, з чим TN-C-S справляється краще, бо нуль якщо відгоряє, то від лінії, а не від заземлювача ТП. Тобто нейтраль трансформатора залишається заземленою і якщо в вас вдома є також низькоімпедансне заземлення, то нема міжфазної напруги на приладах. Ну і TN-C-S — це заземлення лінії, а не заземлення індивідального споживача. І вся суть у великій кількості повторних заземлень вздовж всієї лінії і навіть якщо відгорить той нуль, то незбалансований струм від споживачів розподілиться через десяток а то і більше заземлювачів та ще й на великій площі. А взагалі відгоряння нуля на підстанції — це не та аварія, від якої має рятувати система заземлення. Є інші аспекти захисту, і в нихTN-C-S показує себе набагато краще, ніж ТТ.

Є протокол який називається Modbus TCP, а є Modbus Serial over TCP — це різні протоколи. Комунікація в обидвох випадках йде через TCP, але пейлоад різний.

Ну тоді це не Modbus TCP. Без моніторингу RS485 шини важко сказати що не так і, можливо, карще відразу купити хороший шлюз. Іони мають вбудований термінальний резистор чи треба ставити зовнішній?

Захист є, якщо використовувати оригінальний корпус, але він великий і призначений для монтажу на повітропровід. Просверлити передню кришку мені шегше, ніж видумувати щось інше.

Це коли пейлоад TCP пакета напряму конвертується в сигнали RS485 шини згідно конфігурації послідовної шини. Відкривається TCP з'єднання із портом шлюза і шлеться туди запит як у випадку модбас RTU. Відповідь слейва прийде по цьому ж з'єднанню і також у форматі RTU. Таке ж можливо по HTTP та MQTT, залежно від шлюза.

У мене цифрові канальні сенсори, які міряють температуру і вологість. Я не можу їх засунути всередину вентустановки, бо там крім сенсора є ще й плата з мікросхемами.

Значить тупить шлюз при трансляції модбас протоколів. Я б попробував пряму роботу через TCP, але тоді прийдеться писати scheduler опитування на стороні опенхабу.

Я мав на увазі матераіли, а не конфігурацію потоків. Тобто використати фанеру як конструкційний метеріал, з якої зробити коробку, в яку вже вклеїти весь утеплювач. Виводи робіть так як вам зручно.

Якась дрібна різниця буде, але загалом один фіг. Просто в SBU вам важко буде створити такий самий хараткер навантаження, як випадку з експортом в мережу. Буде або замало сонця і використовується все що є плюс акум, або забагато і акумулятор вже заряджений, відповідно генерація обрізається до рівня навантаження.

Там 5 см місця, тому ніяк.

Мені подобається корпус @Dmode і я вважаю, що це найоптимальніше для саморобки. Я б правда взяв ламіновану воологостійку фанеру, щоб не переживати за розбухання у випадку намокання.