TaurosRMK
Пользователи-
Публікації
2 393 -
Зареєстрований
-
Відвідування
Тип публікації
Профілі
Форум
Календар
Усі публікації користувача TaurosRMK
-
Немає такого пристрою. Але мені виробник скидував фото, якщо це щось дасть. Чи маєте на увазі дивитися в той момент, коли вентилятори показують неадекватні показники? Якось так В щитку один блок живлення на 24В (Mean Well MDR-40-24), від нього живиться контролер на ESP (Kincony A2), регулятор 0-10В, контролер Овен ПР200, пара SSR 4-20mA, електромагнітні реле ETI. Ставлю один щуп на GND на виході з блока і прозвонюю всі GND на інших пристроях - всі звоняться.
-
Інвертора/панелей немає. Здається так, всі gnd об'єднані. А як вони можуть бути сплутані з заземленням? Або я просто не розумію про що ви. Для мене заземлення це PN в мережі 220, а GND це в DC мережі. Відповідно всі PE на шині, а всі GND підключені до відповідних клем. --- Є ще такий момент. На схемі підключення дротів від вентилятора, щоб зчитувати оберти, потрібно два дроти - FG і GND. У мене на входи контролера ESP підключені тільки FG, а GND від вентилятора підключені до регулятора обертів 0-10В (окремо від ESP). Але обидва пристрої заживлені від одного блоку на 24В, тобто в них один GND. І наскільки я зрозумів, GND всюди наскрізний, тобто GND який потрібен для зчитування обертів на контролері ESP підключений не прямо, а через інший пристрій. Якщо б воно не працювало, то оберти не зчитувалися би. Схему можу додати пізніше.
-
Не екранував, але всі прилади підключаються трьома проводами, вентилятори а тому числі. То що на вентиляторі, на самому двигуні, є ще окремий отвір під гвинт з позначкою заземлення, туди нічого не під'єднував, бо: 1. Потрібно демонтувати і розбирати вентилятор, що трохи довго. 2. Прозвонював корпус і заземлення на клемній колодці, прозвонюються, значить якось об'єднані. 3. Питав у виробника, здається відповіли що в тому немає необхідності, якщо підключено заземлення до клемної колодки.
-
Для вентиляції використовуються два EC вентилятори, які мають зворотній зв'язок для зчитування обертів (2 імпульси за один оберт). Підключено це до контролера Kincony A2 на ESP32 який успішно зчитував оберти. Деякий час назад помітив що в одного вентилятора при старті, тобто подачі напруги, оберти стрибають до нереальних 30000-50000, при максимальних десь 3150. Потім через декілька хвилин роботи оберти внормовуються. Іноді бувало що при старті показує 0 обертів, але знову через деякий час оберти піднімаються до тих, які мають бути. При цьому вентилятор точно працює. Не сильно звертав на то увагу, тому що це відображається лише в інтерфейсі Home Assistant і ніяк про це не сигналізується, вентилятор працює і добре. Сьогодні помітив що оберти іншого вентилятора при робочому вентиляторі показують 0, а подивився на графік і в один момент там було під 170000. І за майже годину роботи нічого не змінилося, як було 0, так і залишилося. До сьогодні другий вентилятор не мав таких проблем, оберти завжди не перевищували номінальні і ніколи не падали до нуля при працюючому вентиляторі. Не розумію що сталося і в чому може бути проблема. Щось з самими вентиляторами чи з контролером? Або якісь перешкоди можуть на це впливати? Хоча перешкоди напевно впливали би на обидва вентилятори однаково ще раніше, а так спочатку почав один вентилятор показувати якісь неадекватні цифри, а тепер вже інший. При тому що вентилятори працюють нормально, швидкість регулюється, только зі зворотнім зв'язком по обретах щось не то. Нічого в підключенні не мінялося, працює десь від літа. Не можу сказати чи були такі проблеми з самого початку, бо помітив з першим вентилятором десь півтора-два місці назад. І то це відбувається в основому в момент подачі напруги на вентилятори, наприклад коли вимкнули і включили е/е. І то навіть не кожного разу, інколи може бути все ок, оберти показує як треба, а інколи зашкалює. А якщо вентилятори працюють деякий час, то з обертами все в нормі, нічого не стрибає. Схема підключення вентилятора і схема входів контролера, до яких підключені проводи від вентилятора. Графік обертів двох вентиляторів.
-
А підкажіть що корисного можна прив'язати до НА чи серверу в цілому? В якості сервера виступає міні ПК на N100 / RAM 8Gb / SSD M2 256 GB, встановлена HAOS, додані всі наявні розумні пристрої (їх поки що зовсім небагато) і контролер вентиляції на ESP32. Фактично НА використовується лише як інтерфейс для взаємодії з пристроями, декілька простих автоматизацій для освітлення і на тому все.
-
Подивітся параметри тих же raspberry pi, на яких поголовно ставлять НА, вони точно слабші. В мене пробний варіант працював на допотопному ноуті з одноядерним Sempron 3100 (здається), 2 ГБ оперативки і якийсь там HDD 😁 Якісь оновлення і тд проходили досить довго, але якщо не чіпати, то працював більш-менш нормально. Правда там і девайсів/автоматизацій не було багато, тільки для "погратися".
-
Ще один кусок автоматизації - запуск витяжного вентилятора на максимальну швидкість для зливу конденсату з теплообмінника. Перший бінарний сенсор визначає чи працює система не менше 30 хв (поки для прикладу), наступний перевіряє всі умови для запуску автоматизації - приточний вентилятор запущений / заслонка відкрита, аналогічно і витяжний, сезон Зима, на вулиці нижче +10С (для прикладу) і статус системи "В роботі". Потім через інтервал кожні 3 години буде відпрацьовувати автоматизація - вимкнення балансування вентиляторів, витяжний на 100% на 90 сек (для прикладу), повернення витяжного на попередньо швидкість, вмикання балансування. # Запуск витяжного вентилятора на 100% для зливу конденсату binary_sensor: - platform: template name: "System Running 30min" id: system_is_running_30min lambda: |- return id(system_is_running).state; filters: - delayed_on: 30min # 30min - delayed_off: 0s - platform: template name: "Condensation Drain" id: condensation_drain lambda: |- if (id(system_is_running_30min).state && id(do_1).state && id(do_2).state && id(outdoor_temp).state < 10.0 && id(mvhr_status) == "running" && id(season_winter).state) { return true; } else { return false; } interval: - interval: 3h # 3h then: - if: condition: binary_sensor.is_on: condensation_drain then: - switch.turn_off: balancing_on - lambda: |- id(previous_exhaust_speed) = id(exhaust_fan).speed; // Зберегти попередню швидкість auto call = id(exhaust_fan).turn_on(); call.set_speed(100); // Увімкнути на 100% call.perform(); ESP_LOGI("MHRV", "Exhaust Fan set to 100%"); - delay: 90s - lambda: |- auto call = id(exhaust_fan).turn_on(); call.set_speed(id(previous_exhaust_speed)); // Повернути на попередню швидкість call.perform(); ESP_LOGI("MHRV", "Exhaust Fan returned to previous speed: %f", id(previous_exhaust_speed)); - delay: 1min - switch.turn_on: balancing_on
-
В користуванні два зволожувачі, один без декількох днів буде 2 місяці, інший куплено десь на 10 днів пізніше. Працюються 24/7, приблизно тижні два працювали на максимальному режимі вдень і тихому вночі, потім перейшли в тихий режим на постійно. Вологість трималася в діапазоні 45-55%. В мануалі пише що заміна фільтру раз в 3-6 місяців, заміна блока з іонами срібла раз в 6 місяців. В додатку є пункт в якому показаний стан фільтру у відсотках. Як він розраховується без поняття, напевно просто по часу напрацювання. В першому зволожувачі стан фільтру вже 0%, тобто прийшло нагадування що потрібна заміна, в другому десь біля 20%. Не знаю до чого там в інструкції пише раз в 3-6 місяців, якщо тут за неповних 2 вже потрібна заміна фільтру. Чи вони рахують що зволожувачем будуть користуватися раз в 3 дні? Дуже цікаво... З приводу води, звичайна з під крану, без якоїсь супер фільтрації, тільки через вугільний і пом'якшуючий фільтр. Десь до 40% стану фільтру все було ок, раз в 7-10 днів промивали зволожувач разом з фільтром. А от нижче 40% за декілька днів вода у зволожувачі починала жовтіти і з'являвся неприємний запах, схожий на цибулю чи що. Приходилося частіше промивати. Очікував що при заявлених 3-6 місяцях хоча би 3-4 витягнути, а тут в натяжку можна сказати що лише 2 місяці. З приводу фільтру і його терміну, з вигляду схожий на якийсь хепа матеріал, але напевно чимось пропитаний. Не бачу щоб він якось змінився в порівнянні з новим, за виключенням того, що місцями трохи налипло солей, які вже впиталися в матеріал. Теоретично фільтр тут наче має трохи фільтрувати повітря яке через нього проходить, хоча пристрій не зазначено як очисник повітря. Основне ж призначення фільтру бути постійно вологим і тим самим насичувати сухе повітря вологою. Тому питання про якийсь термін служби фільтру трохи незрозуміле, він не розмокнув, не порвався, нічого йому немає. Хіба що втрачає свою ефективність саме фільтрувати повітря, але фільтр все рівно буде вологим, зволожувач буде виконувати свою функцію і все рівно якись пил має затримувати. Нові фільтри ще в дорозі, а покористувавшись пару днів тим що вже "закінчився", якось не помітив різниці.
-
Приточно-витяжна вентиляція з рекуператором
TaurosRMK відповів у розділі Вентиляція та кондиціонування
Update, v 2.1 Метрову трубу поділив по 50 см, врізав дві оновлені трубки навхрест, з однієї сторони відстань 2D (300 мм), з іншої відповідно 200 мм. Буду монтувати перед вентиляторами. Але тепер постало питання, як відкалібрувати трубки і перевірити чи результати співпадають з реальними? Все рівно буду дещо переробляти в схемі повітроводів, тому можу демонтувати частину яка стоїть перед витяжним вентилятором, вийде так - вентилятор, сумарно 1.5 м повітроводу/колін, теплообмінник, знову 1.5 м повітроводу і ковпак на фасаді. Змонтувати перед вентилятором цей кусок з сенсором і робити заміри анемометром на вході, тобто перед сенсором. Але вірити китайському анемометру... Хоча точних лабораторних досліджень не потрібно, немає бажання зараз якісь досліди проводити, просто звірити що показує сенсор і можливо якось вирахувати калібровочний коефіцієнт, якщо буде потрібно. Напевно змонтую це перед вентилятором і буду фіксувати значення з сенсору та анемометру на кожні 0.25-0.5В керуючої напруги, або на кожні 150-200 обертів вентилятора. Вийде приблизно 20 точок на швидкості вентилятора 0-100%. -
Поки що не розібрався чи то так має бути, чи потрібно якось зберігати значення деяких сенсорів. Для прикладу деякі бінарні сенсори які приймають значення True при виконанні деяких умов, а умови можуть мати затримки щоб не спрацьовувати часто. Якщо такий сенсор має затримку 10 хв, а від нього залежить ще якись код, який має свою затримку 5 хв, то при кожному оновленні прошивки все скидається в початковий стан і відповідно треба чекати знову, поки спливуть всі затримки і виконаютсья умови. Наприклад, сезон Зима/Літо, якщо Т вулична нижче 15С протягом 15 хв, то сезон Зима. Система працює протягом дня, визначила що сезон Зима, але прийшлося оновити прошивку і після оновлення знову очікування 15 хв щоб визначився сезон.
-
* Варто напевно виправити, але це температура не вихлопу на вулицю, а температура повітря з будинку (Extract Air), тобто на вході в ТО. На момент написання цього коду визначення сезону ще не було. Хоча там і не дуже складний код, можна було дописати, але вирішив упустити цю перевірку. Частково по датчику повітря витяжки з будинку можна "визначити" сезон зима/літо, бо при вуличній приблизно нижче 15С при довгому простої температури в ПВУ падають, в порівнянні коли ПВУ працює. Відповідно чим нижча температура на вулиці, тим більше остиває ПВУ. Для прикладу, на вулиці 18С і вище - остивання в ПВУ мінімальне або навіть відсутнє, при 15-18С - остивання 1-2 градуси, при 10-15С - 2-4 градуси, при 0-10С - 4-7 градусів, і тд. Тобто якщо в момент запуску по датчику з будинку буде 15С, при типових 20-22С, то остивання на 5-7С може свідчити що на вулиці точно не літо. Поки що час прогрівання і діапазони умов просто фіксовані, щоб перевірити чи код працює і щоб не вдаватися в якісь складніші розрахунки. В цілому і того вистачить, трохи прогріти, якщо ТО холодний. Тривалість і діапазони треба підкоригувати.
-
Спільними зусиллями з AI процес зрушив з місця 😂 Пермикач "Запуск системи", перевірив, наче працює справно. При включенні запускається система. Спочатку відкриваються дві заслінки (час відкриття 75 сек), потім запускається витяжний вентилятор і перевіряються умови чи потрібен прогрів теплообмінника. Оскільки ПВУ на холодному горищі і хоть трохи утеплена, але це все рівно не спасає від остивання температури в ПВУ і повітроводах. Тому при температурі на вулиці близькій до 0С і нижче краще деякий час прогріти ТО витяжним повітрям. Після цього вмикається приточний вентилятор, відмічаєтсья прапорець що система запущена і додатково надсилається повідомлення на мобільний додаток НА. При вимкненні ситуація зворотня, тільки з перевіркою інших умов. Якщо в момент виключення працюють нагрівачі (хоча б один), то приточний вентилятор вимикається з затримкою 2 хв, щоб продути ТЕНи, попередньо PID регулятори вимикаються. Далі нагрівачі обезточуються, заслонки закриваються і надсилаються повідомлення в додаток що система вимкнена. switch: - platform: template name: "Start MVHR" id: start_mvhr optimistic: true #restore_mode: ALWAYS_OFF turn_on_action: - switch.turn_on: do_1 # Приточна заслонка і вентилятор - switch.turn_on: do_2 # Витяжна заслонка і вентилятор - lambda: |- ESP_LOGI("MVHR", "Opening the dampers"); - switch.turn_on: do_3 # Індикатор роботи - delay: 75s # Затримка відкриття заслонок - lambda: |- ESP_LOGI("MVHR", "Dampers are open"); - fan.turn_on: id: exhaust_fan - lambda: |- // Збереження поточної швидкості витяжного вентилятора id(current_exhaust_speed) = id(exhaust_fan).speed; ESP_LOGI("MVHR", "Current exhaust fan speed saved: %f", id(current_exhaust_speed)); - delay: 5s - delay: !lambda |- float exhaust_temp = id(sht30_eta_temp).state; int delay_time = 0; id(exhaust_warmup_speed) = id(current_exhaust_speed); // Початкова швидкість - поточна швидкість if (exhaust_temp < 17.0) { delay_time = 6; // 6 хвилин id(exhaust_warmup_speed) = 60; // Швидкість встановлюється на 60 ESP_LOGI("MVHR", "Exhaust temperature < 17.0°C, delay for 6 minutes, setting speed to 60"); } else if (exhaust_temp >= 17.0 && exhaust_temp <= 19.0) { delay_time = 3; // 3 хвилини id(exhaust_warmup_speed) = 60; // Швидкість встановлюється на 60 ESP_LOGI("MVHR", "Exhaust temperature between 17.0°C and 19.0°C, delay for 3 minutes, setting speed to 60"); } else { ESP_LOGI("MVHR", "Exhaust temperature > 19.0°C, using current speed: %f", id(exhaust_warmup_speed)); } auto call = id(exhaust_fan).turn_on(); call.set_speed(id(exhaust_warmup_speed)); call.perform(); return delay_time * 60000; // Конвертуємо хвилини в мілісекунди - lambda: |- // Повернення швидкості витяжного вентилятора до поточної, якщо була затримка на прогрів if (id(exhaust_warmup_speed) != id(current_exhaust_speed)) { auto call = id(exhaust_fan).turn_on(); call.set_speed(id(current_exhaust_speed)); call.perform(); ESP_LOGI("MVHR", "Exhaust fan speed restored to %f", id(current_exhaust_speed)); } - fan.turn_on: id: supply_fan - lambda: |- // Збереження поточної швидкості приточного вентилятора id(current_supply_speed) = id(supply_fan).speed; ESP_LOGI("MVHR", "Current supply fan speed saved: %f", id(current_supply_speed)); - binary_sensor.template.publish: id: system_is_running state: ON - lambda: |- ESP_LOGI("MVHR", "System is running"); - homeassistant.action: action: notify.mobile_app_xiaomi_14t data: message: "The MVHR system has been started." title: "MVHR System Running" turn_off_action: - fan.turn_off: id: exhaust_fan - delay: !lambda |- bool heater1_active = id(pid_preheater).mode == CLIMATE_MODE_HEAT; bool heater2_active = id(pid_postheater).mode == CLIMATE_MODE_HEAT; int delay_time = 0; if (heater1_active || heater2_active) { delay_time = 2; // 2 хвилини ESP_LOGI("MVHR", "Blowing the heaters for 2 minutes"); } // Встановлення PID регуляторів на OFF auto call_preheater = id(pid_preheater).make_call(); call_preheater.set_mode("OFF"); call_preheater.perform(); auto call_postheater = id(pid_postheater).make_call(); call_postheater.set_mode("OFF"); call_postheater.perform(); return delay_time * 60000; // Конвертуємо хвилини в мілісекунди - delay: 3s - switch.turn_off: id: heater1_relay - switch.turn_off: id: heater2_relay - fan.turn_off: id: supply_fan - lambda: |- ESP_LOGI("MVHR", "Closing the dampers"); - switch.turn_off: do_2 # Витяжна заслонка і вентилятор - switch.turn_off: do_1 # Приточна заслонка і вентилятор - delay: 75s # Затримка закриття заслонок - lambda: |- ESP_LOGI("MVHR", "Dampers are closed"); - switch.turn_off: do_3 # Індикатор роботи - binary_sensor.template.publish: id: system_is_running state: 'OFF' - lambda: |- ESP_LOGI("MVHR", "System is stopped"); - homeassistant.action: action: notify.mobile_app_xiaomi_14t data: message: "The MVHR system has been stopped." title: "MVHR System Stopped" AI генерує трохи не правильний код, але якщо задавати більше уточнюючих питань і правильно формулювати умови, то виходить майже те що треба. Залишається щось підправити під себе і готово.
-
А там якраз насос дренажний, але не сильно потужний, здаєтсья 1.2 кВт 🙂 Але вмикати потрібно всього 1-2 рази на тиждень на 5-10 хв, не більше. Маю таке міні реле Zigbee, пробував, але оскільки розміщення поза будинком (інша будівля) і через декілька цегляних стін, то поганий сигнал, воно то спрацьовує, то ні. Згадав що є якісь Zigbee підсилювачі, але не знаю чи то допоможе, якщо сам пристрій ловить сигнал погано, то чи буде в тому ж місці підсилювач ловити краще. А от Wi-Fi розетка ловить сигнал значно краще. Мені то не потрібно для автоматизацій чи чогось такого, тільки графік налаштувати і забути, можливо інколи вручну запустити, тому підійшло би і Wi-Fi.
-
Чи надійні такі девайси саме в якості АВ? Задача вбити двох зайців, є окремий прилад, на якому стоїть звичайний АВ, а після нього добовий механічний таймер, який запускає прилад. Але зараз немає потреби щоденного запуску, тому треба внести зміни. Ставити тижневий таймер немає місця, там бокс всього на 2 модулі. Хоча можна використати звичайне Wi-Fi реле і отримати те саме. Але ще один такий розумний АВ потрібен для іншого приладу, тому питання про надійність як АВ актуальне.
-
А сенс при такому розході робити заміри, якщо швидкість повітря через ТО буде дуже низька і скоріш за все не зможе виштовхнути конденсат? Той самий калькулятор на сайті виробника для вашого ТО пише що мінімальний розхід 100 кубів, при цьому швидкість повітря через ТО 0.5 мс. Відповідно при 50 кубах швидкість буде ще нижчою і конденсат буде важко виштовхуватися або й взалалі не буде. Тому при малих об'ємах ще більша ймовірність випадання конденсату прямо в ТО.
-
Бажано напевно робити спостереження на певних обертах, щоб були однакові умови. А то ви спостерігаєте сьогодні на 50 кубах, раніше на 200 кубах, до того може ще інший розхід був. Від цього всі показання можуть плавати туда-сюда і легко вийти на дизбаланс. Хіба що ви постійно перемірюєте анемометром 😁 Я б зупинився на якісь одній швидкості, напевно тій, яка має бути розрахункова для будинку, і вже на ній порівнював результати. Бо при 50 кубах може бути одне, а при 200 кубах зовсім інше.
-
Приточно-витяжна вентиляція з рекуператором
TaurosRMK відповів у розділі Вентиляція та кондиціонування
Сьогодні помітив що витяжний сенсор показує +/- 0 Па, подумав що вже пішов на упокій... Поліз дивитися, наче все ок, але в місці приєднання шлангів до зонду помітив що в шланзі утворилася водяна пробка. Проблема вилізла через те, що зонд розміщений горизонтально і витяжне повітря насичене вологою на холодному горищі успішно конденсує в трубці і немає змоги стікати. Тимчасово там утеплено невеликом куском мінвати, але то не спасає. На фото видно слід від води, але воду вже злив. Все ж таки розташування зонду горизонтально в таких умовах не дуже підходяще. Купив нові трубки і повітровід, буду робити по типу як VAV клапан, трубки розміщу навхрест, але не в горизонтальному положенні, щоб не було таких ситуацій. Якщо повітроводи змонтовані в теплому контурі, то це не страшно, а от в умовах холодного горища не підходить горизонтальний монтаж зондів. -
А при таких обертах є баланс? Бо вигладає що скоріш за все перевага витяжки над притоком, відповідно і температура подачі в будинок буде вища, ніж при +/- балансі потоків.
-
Дивно що така сама ПВУ є ще у декількох людей, але показники температур/ефективності точно відрізняються в кращу сторону.
