ТЕМА: Громадське користування кондиціонером, з захистом від "безглуздого" використання.

За характеристиками від виробника він може підтримувати температуру в кімнаті від 16 до 30 (максимальні значення), і це нормально, до будь-яких ситуацій.
Моя ситуація. це його використання в житловому приміщенні.
Особисто мені досить влітку 20-22, взимку 23-25 (це я маю на увазі, тривалу роботу, добу!).
Таку температуру я для себе і виставляю. Однак бувають гостюють родичі, у деяких з них фішка влітку тільки 16, що особисто для мене це не зовсім прийнятно.
А днями зіткнувся з тим, що і взимку у них є фішка підтримувати добову температуру 30.
Я і не проти, якщо вони у себе так і живуть (ну і нехай, я ж їм не фашист:)))), а у мене свої правила, на жаль вони з моєю точкою зору не згодні, і на порожньому місці виникає конфлікт, якого в принципі не повинно і бути.
З цього приводу, виникла як би ідея, а чи не зробити мені на МК, термостат - приставку до кондиціонера, яка незалежно від того яка виставлена температура з пульта, дозволить кондиціонеру працювати тільки в діапазоні 19-25 (наприклад).
Проблеми немає зробити термостат з програмою.
Моя проблема в іншому, ніколи не лазив я в ці кондиціонери, і невідомо чи є там така «нога», управляючи якою можна робити включення вимикання компресора (компресор не інвертор), але при цьому щоб внутрішній блок продовжував обдув.
Якщо простіше, при завданні з пульта 30 градусів, кондиціонер в кімнаті підтримує тільки до 25, а далі внутрішній блок працює на вентиляції (компресор звичайно відключений) ...
Зі зниженою температурою , праця аналогічна ...
Чи продумував, хто не будь такий варіант?

Можливо варіант "транзитного" контролеру? Штатний IR-приймач перемикається на новий контролер, а з нового контролера на штатний вже передається оброблений сигнал. На перший погляд - все просто. Потрібно тільки зчитати протокол передачі даних і команди від ДУ. Таким чином буде мінімальне втручання в алгоритм роботи самого кондиціонера.
Трудність полягає в синхронізації контролерів. Скоріш за все, налаштування температури проводиться кнопками більше/меньше і транзитний контролер повинен знати яка зараз встановлена температура і чи продовжувати передавати нові команди по її зміні. Тут їх обо якось синхронізувати при першому включенні і дальше паралельно зберігати дані, або зчитувати дані зі штатного дисплея.

Soir пише: Несподівано так, цікава ідея, мені подобається.
Дійсно вийде мінімальне втручання, а також не доведеться «прикручувати» в потрібне місце DS18b20.
Мінус тільки один, «настроювач» який бажає побачити на дисплеї кондиціонера +30 градусів, так її і не побачить :(((
Soir пише: Я кілька далекий від цих всіх протоколів,
Тому, на мою думку, починаючи від включення кондиціонера, і закінчуючи його виключенням, пульт дистанційного керування в одній довгій посилці передає відразу всю інформацію з настройками,
і так кожен раз,
потрібно в ній тільки знайти байти в яких міститься температура, і зробити їм діапазон з контролем.
Решта, так - транзитом.

Oto пише: Можна ж сказати, що то такі параметри кондиціонера - ні більше, ні меньше. Або щось зламалося...

Oto пише: Цілком можливо. Це не складно перевірити. Десь в іншій кімнаті, накрутити пульт, а потім піднести до кондиціонера і щось натиснути на пульті. Якщо налаштування перескочать на нові - тоді так. А якщо виконається тільки один крок - ні.
Якщо так, тоді все набагато спрощується. Розібратися з протоколом не так вже й складно. Особливо, якщо є аналізатор, осцилограф... та й можна простий грабер на колінці зібрати.
Далі вже підставляти свої байти і дивитись що з цього виходить.

Добрався до монтажної плати,



Приймач там HS0038



незрозуміло тільки, A4 там щось значить чи ні.

Дані протоколу прочту лог.аналізатором трохи згодом.

Мікроконтролер десь на іншій платі?

Основна плата управління упакована у чорну платмасову коробочку



До ІЧ датчика дістатися простіше,

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

Аналізатором прочитав дані,
порядок такої, один натиск кнопки
25 градусів - 26 ... - 27 .. - 28 ..- 29 .. - і двічі 30 градусів.
Погляньте, читаеми вони для вас, чи ні.

---

Для налагодження схему буду збирати на макетної платі ATtiny2313.
Потім постійну схему буду робити на ATtiny 24 з кварцом 8МГц.
Нижній поріг обмеження виставляти від 17 до 22, верхній поріг від 24 до 29.
І ще така ідея, як би зробити ...
так щоб передбачити якусь комбінацію умов за допомогою кнопок,
щоб температурні пороги прописувати ні через .еер, а за допомогою комбінації кнопок на пульті.
Поки у мене є такий варіант, на пульті є кнопки таймер ON і таймер OFF.



Якщо встановити на таймері ON число 10, а на таймері OFF число 11
І потім натиснути кнопку SLEEP, тоді дані з «кеша» температури пропишуться в нижній поріг.
Якщо комбінація - на таймері ON число 11, а на таймері OFF число 10.
І потім натиснути кнопку SLEEP, тоді дані з «кеша» температури пропишуться в верхній поріг.
Я поки не наполягаю на цьому варіанті, можливо це я зараз на мудрував,
Але якщо в цьому є сенс, тоді скажіть з якою черговістю зробити натискання кнопок на пульті, щоб аналізатор зафіксував ці коди.

Про алгоритм управління поки що рано говорити, спочатку розібратись з протоколом передачі даних. А тоді уже можна буде все.
Не підібрав я ні один з поширених протоколів під дані аналізатора. Але це не дуже важливо. В цілому він зрозумілий. В кожній посилці два однакових пакети. В кожному пакеті по 6 байт.
Спочатку йде адрес (напевно, так майже завжди). Тут адрес 0xB2. Другий байт - інверсний байт адресу (0x4D).
Далі байт 0xBF теж повторюється у всіх посилках. Не знаю, що він означає, можливо адрес команди. Наприклад дає контролеру зрозуміти, що зараз буде передаватись температура, або таймер... За ним його інверсія 0x40.
Наступний байт можливо величина. Тут в кожній посилці вже різні дані (крім двох останніх - вони повторюються). 204, 220, 156, 140, 172, 188... Ну і його інверсія. Числа мені малозрозумілі, треба їх розглядати в контексті що натискалось на пульті і як реагував кондиціонер.

Щоб спробувати повністю розібратись в протоколі, потрібно більше даних з прив'язкою до конкретних команд.
Але насправді, потрібні не всі команди. Головне зрозуміти принцип і виділити ті, які потрібно підміняти. Решту можно просто ретранслювати в основний контролер, не задумуючись що це таке.
Звичайно, якщо будуть потрібні якісь додаткові команди, тоді потрібно розбиратись з відповідними кнопками пульта.

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

Понатискав різні кнопки, і коротко підписав всі файли, все склав в архів.
Є там натискання кнопки вкл. - вимкнути.
Температура, по всьому діапазону від 17 до 30 градусів.
Перемикач MODE, (4 режими)
Кнопка TIMER-ON і TIMER-OFF по цих кнопкам установки змінюються з кроком 0.5 (але з аналізатора, там трохи не вийшло поспіль записати значення)
Кнопка SLEEP є файл, і FAN
Виявляється і кнопка LED, щось передає, хоча візуально від неї вмикається тільки підсвічування пульта, кондиціонер начебто ніяк не реагує.

Чомусь нові дані відрізняються від попередніх. Не знайшов серед нових тих, що були раніше.
Крім того, дещо змінився і формат. Байти йшли так: Перший байт, інверсія, другий байт, інверсія, третій байт, інверсія. Для деяких команд це збереглося, а для температури (ще для деяких) після третього байта йде вже інший байт. Можливо пожертвували інверсією щоб більше передати інформації.

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

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

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

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

P.S. Якщо застосувати ATtiny24, для приймача вхід РА5 можна буде застосувати?

Oto пише: Потрібно одну і ту ж команду повторити декілька разів. Найбільш важлива температура, яку потрібно буде заблокувати. Наприклад, 18 градусів. Збільшити її до 19, потім зменшити до 18, потім зменшити до 17. Зробити це для різних режимів - зима, літо... які там ще є.

Oto пише: Так. Можна будь-який, у якого є переривання по зовнішньому сигналу.

P.S.
А чому все-таки різнять дані першого файлу і наступних? В яких умовах вони знімалися? Аналізатор не може ж помилятись.

У порівнянні з першим, думаю відрізняються тому що було багато змін умов крім температури були так само зміни -режим- вентилятор і ще можливо таймер.

Зараз спробував зробити натискання кнопок під відео зйомку.

---

попередньо намалював монтаж друкованої плати,
буде він ось такий

Oto пише: Ні, так не піде. У мене і так вже в очах рябить видивлятись ці імпульси, а тут їх сотня, і де що, ще потрібно вираховувати.
Тому прошу буквально дві-три команди, як я писав вище. І ті, які потрібні для роботи а не всі підряд.

Oto пише: Зазвичай ставлять ще зовнішній підтягуючий резистор (4,7-10 кОм) на вихід IR-приймача.

Перший архів, дані включення/відключення зняті при таких умовах.
1) вкл/відкл - режим "нагрів", температура 25°С
2) вкл/відкл - режим "охолодження", температура 20°С
3) вкл/відкл - режим "авто", температура 23°С



Другий архів
режим "авто ", разове натискання кнопками змінюю температуру, починаючи від 20°С, до 23°С, і зворотній порядок до 19°С

Єдиної системи немає.
Дані однієї діаграми не співпадають з іншими. Те що було вчора - сьогодні вже інше... Чому так - не зрозуміло. Тільки здається вловив суть і тут же облом.
Для прикладу. Байт, у якому на мою думку записана температура 23 градусів у файлі "4 MHz_avto_20c_21c_22c_23c_21c_20c_19c.logicdata" співпадає з файлом "4 MHz_avto_23c_vkl_vukl.logicdata". Але коли взяти аналогічні дані для 20 градусів - уже ні.
Діаграми все рівно в різнобій і важко співставити, тільки окремі перетинаються. І якісь висновки зробити важко.
В останніх діаграмах знову третій байт передається в прямому та інверсному виді. Хоча вчора - ні.

Ще раз запитаю. Аналізатор може помилятися? Можливо у нього є якісь налаштування і він не завжди одинаково визначає імпульси? Можливо одну і ту ж команду зчитати аналізатором і осцилографом, щоб можна було зрівняти?
З іншого боку, адреса (перший байт) завжди одинакова... І інверсія підтверджує попередній байт.
Поки що не розумію, чому так різняться дані.

Та ні помилка аналізатора це навряд чи.

Напевно ви там бачите різницю, тому що різні режими
Ось в цьому випадку
4MHz_avto_20c_21c_22c_23c_21c_20c_19c.logicdata і 4MHz_avto_23c_vkl_vukl.logicdata
Збігається бо, зроблено в одному режимі

Якщо порівнювати
4MHz_avto_20c_21c_22c_23c_21c_20c_19c.logicdata і 4MHz_cool_20c_vkl_vukl.logicdata
Тут температура та ж, але режими різні (виділив кольором) .

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

В помилку аналізатора я й сам не вірю, але це було б найкраще пояснення.
Можливо мої порівняння і не зовсім коректні, але нічого іншого для порівняння не знайшов.
Зробіть діаграми аналогічні 4 MHz_avto_23c_vkl_vukl.logicdata, але для якоїсь однієї температури. Хай це буде 23 градуси. З різними режимами auto/cool/heat. Достатньо тільки вкл., викл. для всіх виглядає одинаково.

Зробив перемикання тільки режимів, завдання 23°С градуси
черговість
1) avto т.23°С (швидкість обдува автоматичн. (Вентилятор вручну не регулюється))
2) coll т.23°С (швидкість вентилятора можна регулювати вручну)
3) dry т.23°С режим осушення (швидкість вентилятора виставляється вручну)
4) heat т.23°С (швидкість вентилятора можна регулювати вручну)
5) fan тільки вентилятор (температура на екрані д/к відсутня)

Безрезультатно. Розшифрувати в чистому вигляді не вдається. Можливо для кожного режиму прийдеться складати таблицю заборонених байт (річ поки що про третій байт), які не передавати штатному контролеру. Якщо весь діапазон температур від 16 до 30, то такий перелік буде не більше 15 байт. Для кожного з режиму, який потрібно контролювати. Можливо це буде навіть економніше, ніж все-таки вдасться вивести формулу.
Або, щоб не вигадувати ще з режимом (там теж не все прозоро), то ще і другий байт. Тоді взагалі все стає простим: программа перевіряє чи є така комбінація байтів в таблиці і вирішує, що з ними робити.

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

Погано що не виявилася системність,
Soir пише:
Може спробувати варіант грабера, для дослідження цього протоколу.
На макетке зібрати таку схему, якщо це в програмної реалізації реально.

---

Спробував половинку коду розмалювати на біти, виходить що в посилці 48 біт або 6 байт.
10110010 01001101 10011111 01100000 11011100 00100011
Однак в ручном режимі перерахувати і систематизувати, це каторга однако :)
Треба, це все перекласти на "плечи автоматики"

Oto пише: Аналізатор і є грабер.
Oto пише: Я цим і займаюсь, про 6 байт писав з самого початку і про їх призначення. Вони вже всі перераховані, але систематизувати поки що не вдалося. Якраз проблема в цьому.
Ось наприклад, як виглядає файл 4 MHz,ALL_mode_23c.logicdata

Ось ще, де мінялась тільки температура 4 MHz_avto_20c_21c_22c_23c_21c_20c_19c.logicdata

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

Так це ви там в аналізаторі вручну перераховуєте біти?
Чи аналізатор обробляє сам, тільки потрібно налаштувати якийсь із протоколів?


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

Тут хочу зауважити, що протокол пульта який ми розглядаємо, це наврядчи якийсь індивідуальний протокол. У мене є три різних «китайські бренди» кондиціонерiв, пульти у них аналогічні цьому і взаємозамінні.

Якщо аналізувати більше команд.
Потрібно щоб, я як то сам міг перерахувати масиви команд.
Може зробити програму - приймач, яка через ТХ UART буде все виводити в термінал в .нех форматі.
Тоді буде можливість все це підписати, і візуально аналізувати?