Майстерня Мольфара

Чудова погода дістати радейку і провести кілька зв'язків. Хоч насправді, гуляючи, побачив що кабелі на даху зірвало і вони сильно провисли. От і поліз все монтувати назад. Можна записати - термін життя пластикової стяжки під ультрафіолетом - 4 роки.

Прислали мені ось таку фотографію - все працює на ура, температура стабільна, проблем як з китайським регулятором не спостерігалось.

Було - стало. Оцей корпус з дуже твердого і ламкого пластику - свердили новими свердлами з мітчиком не помогло - свердло з'їжало, а пластик тріскав. Корпус на 3D принтері був би цікавіший як і розведена плата, але прототип є прототип.

Попросили мене глянути до інкубатора для курячих яєць. Його використовують як проект на уроках біології в школі і минулого року у ньому почались проблеми - він то перегрівав, то зависав, то виключився. На таке діло звичайний контролер температури за 200 грн підходить на ура, але це шкільний проект, куди цікавіше коли можна додати динаміки, інтерактиву, звітності там якоїсь. Але з іншого боку, бюджет трохи обмежений. Тому поки вирішили програму мінімум - замінити контролер на більш точний, бажано з запобіжником від перегріву. Я ж надумав закласти якусь базу, яку б можна було масштабувати, якщо все буде добре. Отож, в основі найдешевша ESP32 плата, яку знайшов - LuaNode32 (38 pin). Багато негативних відгуків через те, що треба тримати кнопку BOOT для програмування, але вона своє робить. Нагрів від ламп-жарівок. Для їх контролю спершу хотів твердотілі реле, але низькопотужні лампи-жарівки світять з чверть сили вже від струмів витоку. Тому звичайний модуль реле. Був у запасах. Контроль температури двома DS18B20. Висока точність, робота до 125 градусів. Один датчик зразу біля ламп (аварійний), другий буде кластись на самі яйця. Температурний режим для яєць бажано мати стабільний - 37,5 градусів на поверхні яйця. Максимальну точність наявними інструментами можна отримати враховуючи гістерезис та інерцію системи нагріву. Для цього є два типи термостатів - термостат за однією температурою з показником дельти і bang-bang термостат. Другий дає більш точний контроль, бо задається два пороги - один для відключення нагріву, а інший - для включення. Логіка така - при досягненні вищого порогу нагрів вимикається повністю (bang!), далі нагрів включиться лише за умови опускання нижчого порогу (bang!). Жодної дельти, два окремих пороги. Прошивка на ESPHome тут підійшла на ура. В режимі точки доступу і локального веб-сервера отримуємо показники в реальному стані на смартфоні чи комп'ютері, підключеному до точки доступу. Плюс - зручне керування. Загалом, за кілька годин пішло щоб зібрати та запрограмувати прототип. Тестування показало гарну красиву температуру між 37,2 і 37,8 при доволі нечастому перемиканні реле. Далі, якщо все буде добре, можна масштабувати систему: 1. Датчик вібрації чи датчик руху для фіксації часу вилуплення із яєць. 2. ESPCam для фото вилуплення 3. Дашборд десь, щоб учні з дому бачили температуру і рух. 4. Дослідження впливу температури на стать курей, дослідження часу інкубації. 5. Додати датчик вологості для визначення важливості вологості і впливу на процес 6. Ще можна замінити реле на модульовану потужність для більш плавного нагріву. Ну і звичайно, тут було б доцільно послухати дітей, що буде їм цікаво ще в такому проекті. На звершення - старий контролер погано працював через неприпаяний конденсатор по живленню - коли ніжки торкались доріжок він працював, коли не торкались - не працював.

Привіт, друже ламповий тестер, 56 років, а ти і далі добре так працюєш.

Нема нічого більш вічного ніж тимчасове. Як тоді у січні поставив замість несправного SSD диску в домашньому сервері старий зношений диск, так і не ліз його міняти весь місяць. Поки ось не купив за 3х від попередньої ціни такий же SSD і розгорнув Home Assistant заново. Гляну як попрацює, надіюсь довше ніж попередній. Так, оці старі міні-ПК з підтримкою тільки m.2 SATA та без підтримки NVME чи старого-доброго SATA мають суттєвий недолік у відсутності хороших m.2 SATA на ринку. Це найбільший мінус платформи Dell Wyse 5070 під домашній сервер. По-ідеї можна купити адаптер m.2 - SATA і використати SATA диск, але потрібно буде придумати де його змонтувати в маленькому корпусі. І про білий світлодіод стану системи. Dell мають свій конектор під Wyse та Optiplex на 5 пінів, де 2 піни це зворотньо-підключені два LED - бурштиновий та білий. Система подає напругу з відповідною полярністю і, відповідно, маємо білу (робочий режим) або бурштинову (сервісний режим) індикацію. Відсутність білого трохи дратує тим, що невідомий стан системи. Спершу думав знайти замінник, але ціна на такі двійні спарені світлодіоди нерезонна. Виникла думка - мені сервісний режим то нецікавий як такий, чому просто не змінити підключення. Так і зробив, тепер включена система світить приємним бурштиновим кольором. Надіюсь ще трохи в такому режимі і попрацює.

Я не задавав ні формату інтерфейсу, ні розміщення засобів управління, нічого. Просто вказав ключові потреби і отримав оце. Досить і досить непогано, я б навіть сказав - буквально те, що мені було потрібно.

В цікаві часи живемо. Машина мені ще створила пригод, але там більшість проблем ремонтує СТО, то і розказати мало що. Але сьогоднішня історія про сучасні можливості при діагностиці таких старих систем. Придбав давніше GM MDI - це сервісний пристрій для діагностики авто концерну GM. Для чого - бо аматорський op-com дуже дивно виконує (хоч і виконує) сервісні процедури по коробці-робот в моїй машині. Заодно кількість даних і пояснення більш змістовніші, ніж в op-com. GM MDI для Opel до 2014 року вимагає ПЗ Tech2Win - емулятор сервісного діагностичного інструменту. Тобто це офіційна програма від виробника, яка дозволяє емулювати офіційний прилад. Повна офіційність, так сказати. Ця програма повністю сумісна з GM MDI і нею можна програмувати, зчитувати і стирати помилки, змінювати налаштування і коди, а також збирати дані, навіть записувати графіки. Але знову таки - це емулятор приладу з чорно-білим екраном, слабким процесором і малою кількість пам'яті - графіки там такі собі. Що таки зручно - це те, що ці ж дані можна записати на комп'ютер. Але ні, не в JSON, не в Excel і навіть не в CSV. А в HTML таблицю. Так от, після чергових відвідин СТО, в мене почав з'являтись Check Engine з помилкою P0136-04 - втрата зв'язку з другим лямбда зондом. Воно на роботу не впливає, але помилка мені муляла очі, тому вирішив її скидати і моніторити ситуацію. Але ситуація повторювалась, то сьогодні вирішив зробити запис поїздки, поки не вилізе чек. І він виліз. А поки я катався, назбирав HTML файл на 268 Мб. Як же його нормально подивитись? Спершу подумав написати щось самому - простенький парсер. Але потім задумався, що може ШІ мені допоможе, якраз маю Claude Code з тарифом Pro. Написав промт, почекав поки Opus 4.6 переварить формат файлу (12 хвилин), ще 6 хвилин Claude Code щось там робив з кодом, коли на 18 хвилині, використавши 45% ліміту по 5-годинному вікні, я отримав готову тулзу для переглядів звітів з Tech2Win. 18(!) хвилин на роботу, на яку мені б пішло добрий вечір, якщо не більше. І все працює - без помилок. Ще двома промтами покращив відображення графіків і вуаля - готовий інструмент. Мене не так здивувало те, що запис по лямда-зондах добрий (а значить проблема десь в проводці), як те, які зараз можливості в написанні коду швидко і отриманні бажаного результату, швидко. Так, ціна тому вартість оперативної пам'яті. З іншого боку, програмістам вже не треба буде та оперативна пам'ять, бо роботи буде куди менше....

Давно у мене не було таких невдач. Запустив дома Must з поста вище від регульованого блоку живлення з параметрами 24 В 2А. Не запускався. Виставив 21В - запустився. О, цікаво-цікаво. На екрані помилка 04 - низька напруга, нехай. Виключив, підняв напругу до 24 В знову - не запустився. Кілька раз включив-виключив - опа, запустився. Явно щось не то. Розібрав. Жодного пошкодженого елементу, всі мосфети без КЗ, конденсатори цілі, слідів прогару нема - все супер. Запустив, опорні напруги присутні, 230 В є, синусоїда чиста. Виключив і зібрав назад, запустив при 24 В - запустився. Підняв до 27,4 В - працює. Включив, виключив - працює. Кілька раз запускав і виключав з розряджанням конденсаторів - все працює. Дзвоню власнику, мол, давай пробувати. Прийшов до нього, підключив до літієвих акумуляторів, включаю - чую писк, бачу версію ПЗ, бачу напруги, бачу починається генерація 230 В, тут писк, тріск, дим з вентиляторів і екран починає блимати. Швидко від'єдную акумулятор. Приїхали! Там же розібрав - прогар на мосфеті по низькій напрузі. На мосфеті не було КЗ, не було слідів прогару до цього, не було нічого. Напруга на підключених акумуляторах - 27,5 В. Як так сталось - взагалі не розумію. Чому за 30 хв запущеного стану у мене все було нормально, а там він згорів моментально? Хіба 27,4 В при тестуванні у мене і 27,5 В на акумуляторах могли бути аж так критичними. І що важливо - як цей інвертор працював роки з AGM акумуляторами і почав оце глючити з LFP. Більше питань, ніж відповідей. Цього разу точно не огляд і контроль напруг треба робити, а розтин.

Якось попросили мене глянути, чому не працює логер в інверторі. Там логер не з'єднувався з WiFi, відповідно не передавав дані, все ніби просто. Але цікавіше далі - помітив, що 6кВт інвертор підключений до LiFePO4 48 В батареї з набором перемичок які були під рукою в електрика - одна 25мм2, інша 35мм2, ще інша - пара з двох 10мм2. Порадив цей зоопарк зробити нормально, що попросили зробити мене. Цікаво, що там два інвертори (один Must 3 кВт 24В, інший Anenji 6кВт 48в), і той що слабший був підключений добре - кабелем КГ 35мм2. Важливий нюанс - тут батареї із 12 вольтових LiFePO4 акумуляторів, із простою BMS, підключені як послідовно для отримання необхідної напруги. Так от, замінюючи кабель на 35мм2, помітив дивну річ - обидва інвертори при включені мережі дуже довго синхронізуються. Anenji просто показує на екрані факт наявності міської мережі, але синхронізація і підключення відбувається десь через 1-2 хв. Must показує помилку 43 (невірна частота) і синхронізація відбувається десь за 1 хв, трохи скорше за Anenji. При цьому, Anenji показує стабільну напругу (220 В) і стабільну частоту (49-50 Гц), а Must показує 170-240В і 37-55 Гц. Далі, якщо Anenji синхронізувався, то він починає заряджати в повну потужність, а Must не включає заряд - немає індикації і струм заряду не протікає. Десь за 10 хв заряд включається, але все зупиняться у випадковий момент - обидва інвертори переходять на режим роботи від батареї, показуючи, що вхідна мережа нестабільна. І так майже циклічно. Спостерігав біля 30 хв і помітив, що втрата мережі відбувається у момент, коли стабілізатор різко міняє напругу через різку зміну у міській мережі. Нехай, подумав я, стабілізатор потенційно впливає на роботу інверторів, але заряд відбувається. Порадив спробувати перепідключити вхід, так щоб інвертори були підключені перед стабілізатором. І все працювало два дні, поки мені не подзвонили і не сказали, що Must взагалі завис, пищить і мигає. Скинули відео і бачу, що батарея розряджена - 21,1 В на акумуляторі. Прийшов на діагностику, помітив наступне: 1. Один з двох акумуляторів підключених до Must пішов в блокування. 2. Must пищить і мигає через те, що не бачить батареї. Наклалось це на посилення відключень, то думаю, що Must в тому режимі з постійними втратами вхідної мережі не встигав зарядити акумулятори. Поміряв напруги і виявилось, що на одному акумуляторі 12,2 В, а на іншому (після зняття блокування через режим заряду NiCd на iMax B6, який дозволяє заряджати струмом без контролю напруги) - 11,7В. Акумулятори пішли в розбаланс. Вирішили, що треба зробити топ-балансування - зарядити обидва акумулятори до 100%. Поки буде таке балансування - ставимо старі гелеві акумулятори, заряджені на 100%, які стояли сховані на чорний день. Так от, підключив батарею, на обох акумуляторах 13,3 В, на батареї ідеальні 26,6 В. Включаю Must - а він не включається. У момент натиску кнопки на долю секунди світиться екран і світлодіоди і тут же гаснуть, пищалка не спрацьовує. Напруга при цьому не просідає - точно не проблема у акумуляторах. Струм з батареї 0,2 А, мало. Якщо відключити батарею і включити живлення, то інвертор запускається і зразу виключається. Таке відчуття, ніби напруга 26,6 В йому зависока і він не включається. До слова, на LiFePO4 акумуляторах, які розрядив Must, було по 12,9 В в той час, коли інвертор включався. Маю думку, що інвертор має проблему із детекцією напруги акумулятора. Це пояснює затримку у запуску заряджання навіть коли синхронізація з мережею відбувалось - забрав його до себе "на розтин". Але сама проблема із тривалою синхронізацією потребує вирішення теж, поки не знаю як, бо не вивчав щитову і можливості перепідключення. Цікаво, що така ситуація взагалі сталась, це ж мало бути краще, що вхідна напруга стабільніша від стабілізатора. Але щось вони не подружились.

З листопада 2016-го користувався одним набором біт для ремонту дрібної техніки - приблизно таким набором 53 в 1, ідентичного до старого не знайшов. Попри малу вартість, хороший матеріал біт і загальна якість викрутки. Але воно вже за цих десять років майже доламалось і от задумався про заміну. Що порадите, чим користуєтесь?

Зробив ревізію своєї радіоаматорської антени на діапазони СіБі (27 МГц) та 10 м (28-29 МГц), на якій і виборов диплом DXCC. За кілька років КСХ стабільно 1:1,2 на 27,5 МГц, частина противаг покрилась іржею, але поліетиленова дощечка з Метро витримала і прямі сонячні промені, і морози. Шикарна річ для DIY.

Я не знаю як ця магія працює, але з травня 2024 року у додатку Starlink висіло повідомлення про неможливість визначити локацію (хардварна помилка 16), але після реєстрації в білому списку помилка зникла, локація стала правильна (навіть за дії РЕБ - в Перу), і запуск триває декілька секунд. 🤔

За менш як 36 годин від реєстрації Starlink знову у мережі. Оце от швидкості на Standby - на відеодзвінок по роботі буде достатньо.

Досвід використання Starlink у межах багатоквартирного будинку із сусідами та досвід останніх змін. Так от, маючи нульовий досвід прокладання зовнішніх ліній витої пари, організували із сусідами локальну мережу із Starlink у ролі WAN-шлюзу, ще у 2022-2023 рр. З цього вилізло декілька нюансів. - Розміщувати шафу із обладнанням краще не на верхніх поверхах, а на нижніх. Гаряче повітря піднімається вгору, то літом без активного обдуву обладнання може вийти з ладу. Так і сталось (згорів додатковий роутер) - Прокладати виту лінію між під'їздами краще не в повітрі, а по даху чи через підвал. В іншому випадку у сезон гроз буде стабільно горіти по порту на комутаторах, навіть із використанням розрядників. Останні суттєво покращили ситуацію, але не виправили зовсім. - Смішні потужності у контексті квартири по іншому відчуваються за час - за рік отакого пасивного споживання набігає більше 500 кВт-год. - Якщо в укритті організувати свою WiFi точку, то вона у час тривоги не проб'ється через РЕБ всі активні пристрої сусідів, навіть якщо останні не працюють, а просто намагаються пробитись на WiFi роутер від провайдера. - Starlink з активною GPS антеною має проблему із цією антеною під час грози - вона вигорає. Знайшов що це типова проблема. Тепер тарілка не проходить self-test, підключення триває набагато довше, але працює. - Оскільки цей резервний канал зараз майже не використовується, то єдиний варіант це тримати його включеним на тарифі Standby за $6 на місяць. На кількох сусідів швидкості не поділиш, але на одну квартиру достатньо. - Передвчора вечером перестало працювати з'єднання з інтернетом, на пошту прийшло сповіщення про блокування. Зареєстрував в ЦНАПі за 20 хв, включаючи чергу. Пораджу - випишіть собі номер облікового запису (починається з ACC), KIT номер, серійний номер (він же номер терміналу) і номер UTID. У ЦНАПі плутають, сказали що не могли розібратись і реєстрували людей, вписуючи номер підписки (починається з AST) замість номера облікового запису (починається з ACC). Мене ніби внесли правильно. Після реєстрації чекати мінімум 48 годин на активацію. Загалом, як канал резервного зв'язку - зійде. Якщо ще ділити на сусідів - теж. А в мене трохи додалось досвіду у зовнішньому монтажі витої пари і обладнання.

Підключав інвертор на 2,5 кВт / 3,6 кВА і задумався над оптимізацією підключення. Зазвичай даю найтовстіший провід для входу і виходу, виходячи із підключеного навантаження всього одночасно. Це у більшості випадків 3 х 4 мм2. Але сьогодні ситуація вимагала використати максимум кабель 3 х 2,5 мм2. Так от, питання. Якщо реле інвертора на 40 А (9,2 кВт), але інвертор має режим захисту від перевантаження своєї номінальної потужності, то він відключить навантаження при > 2,5кВт більше 5 хвилин, навіть якщо він працює в режимі байпасу. Тобто, навіть якщо підключити частину будинку, де в нас споживання буде > 2,5 кВт, проте на момент відключень є потреба у тих розетках з дотриманням контролю навантаження, то через інвертор струм більше 10А не буде йти більше, ніж 5 хв. Чи є сенс закладати кабель як на максимальне навантаження групи (4 мм2), чи як на вузьке місце у підключенні (2,5 мм2)? Примітка, 2,5 мм2 має номінальний струм 20-27А, то і він із запасом. Очевидно, що на виході з інвертора ставиться І-0-ІІ, який дозволяє навантаження перевести у живлення від міської мережі поза інвертор, і воно підключається правильним перетином. А от щодо самого інвертора - задумався. 1 метр 3 х 2,5 мм2 коштує в районі 48 грн/м, а 3 х 4,0 мм2 - 155 грн/м. Так при підключенні на відстані 5 метрів від щитка маємо 480 грн проти 1550 грн - різниця відчутна, враховуючи що ставиться не інвертор на 2,5 кВт.

Сьогодні вперше монтував отаку мідно-алюмінієву гільзу, для з'єднання мідної та алюмінієвої проводки. В даному випадку це GTL-10, для з'єднання кабелів перетином 10 мм2. Обтискав гідравлічним пресом YQK-70 з матрицею на перетин 16мм2. Попри те, що кабель не заходив щільно в гільзу, обтиск вийшов хороший. Непогане рішення для старої проводки.

Якщо не працює зв'язок між JK-BMS та ESPHome на основі https://github.com/syssi/esphome-jk-bms , то потенційно вибраний не той протокол UART1. Вибір варіанту 000. 4G-GPS Remote module вирішує цю проблему. Сьогодні мав таку проблему - BMS просто не відповідала на команди, хоча сигнал від і до BMS був. А проблема була у протоколі.

Якщо не працює зв'язок між JK-BMS та ESPHome на основі https://github.com/syssi/esphome-jk-bms , то потенційно вибраний не той протокол UART1. Вибір варіанту 000. 4G-GPS Remote module вирішує цю проблему. Сьогодні мав таку проблему - BMS просто не відповідала на команди, хоча сигнал від і до BMS був. А проблема була у протоколі.

Вечір неділі пішов на спроби перевірити справність диску у домашньому сервері, який почав зависати. Так от, в іншому ПК, із хорошим блоком живлення і точно справним M.2 портом, диск аналогічно завис на спробі зчитати великий файл, в тому ж місці, де раніше. Запустити диск вийшло лише після повного виключення, включно із живленням комп'ютера від мережі. Все вказує на те, що проблема саме у диску і саме із чіпом пам'яті. Спробував ddrescue для окремого розділу диску. Диск зчитувався без жодної помилки аж до 99,7%. Останні 1182 Гб не зчитались і диск завис. Повторний запуск ddrescue не допомагав - диск зависам при спробах зчитати дані на тих самих останніх 1182 Гб. Тобто, виглядає що диск пошкоджений у самому кінці всього об'єму пам'яті. Друга спроба зчитати всі дані з нуля, цього разу не розділу, а всього диску, закінчилось помилкою на 99,6%, або рівно 1200 Гб. Дивно, що збільшився об'єм пошкоджених даних, тому вирішив третю спробу не робити. Що робити з диском - однозначно під заміну. Але поки прийде заміна, подумав, як отримати тимчасово робочий сервер. Вирішив спробувати зменшити розмір диску, щоб останні пошкоджені сегменти не використовувались. Так, спершу видалив великий файл бази даних, щоб отримати мінімально необхідне місце. Вийшло 66 Гб використаного місця. Запустив resize2fs щоб скоротити об'єм диску до 100 Гб. Ресайз пройшов і далі була ідея запустити e4defrag щоб перенести якомога більше вцілілих даних на початок диску. Так, на SSD це потенційно може не спрацювати, бо використанням чіпів пам'яті керує контролер, але інших варіантів у мене немає. Після перезапуску ПК після успішного ресайзу диск перестав зчитуватись взагалі. Система зависає на етапі ініціалізації дисків в UEFI, а далі в диск взагалі ніде не відображається. Ну, неуспішна спроба теж спроба. Як запустити сервер тепер, хоча б для Home Assistant? Порився в донорах і знайшов старий SSD зі 2017-го із 17% зносу та більше 25 Тб записів. По суті, ледь живий загиблик, але живий! Запустив на ньому Arch Linux, розгорнув налаштування всього з бекапу, система жива, можна керувати освітленням і бачити рівень заряду на акумуляторі ДБЖ. А що з образом, збереженим ddrescue, як його зчитати, якщо він не повний? Для цього є хороша утиліта testdisk. Загрузив образ з testdisk, вибирав тип. Далі програма показує результат аналізу образу, зокрема список розділів на диску. Перший, системний EFI, зчитався, інший (основний) був невідомий і пошкоджений. Форсовано задав ext4 та тип Linux filesystem, відкрилось меню доступу до файлів. І доступ таки отримав. Витягнув ще файли, які не подумав забекапити минулого разу і спробував витягнути той великий файл бази даних. Який результат - рівно на 86 Гб програма видає що файл пошкоджено і отримати його цілком не вийде. Підсумую. Диск має брак в частині чіпів пам'яті і починає зависати через спроби зчитати чи записати в ту ділянку. Цей брак в кінці всієї пам'яті, то виліз брак тільки, як контролер туди добрався і почав з ними працювати. Ну що ж, новий SSD прийдеться купляти точно. А старий можна спробувати віддати по гарантії, яка 36 місяців. Тільки от як занулити хоча б частину даних, суто з моєї параноїдальної безпечності, треба ще придумати.