이 방식의 핵심은 time.ticks_us()와 time.ticks_diff()를 이용해 상태가 변한 시점 간의 마이크로초 단위 시간차를 구하는 것입니다.
출력된 durations 배열을 확인해보면, 대략 9000, 4500, 560, 1690, 560, 560... 과 같은 숫자들의 나열을 볼 수 있습니다. 이 숫자들을 if/else 문으로 0과 1로 치환한 뒤 비트 연산을 해주면, 라이브러리 없이도 완벽한 나만의 IR 디코더를 만들 수 있습니다.
단순한 제어가 필요할 때 무거운 라이브러리를 통째로 올리는 대신, 이처럼 펄스 폭을 직접 측정하는 방식을 사용해보시면 임베디드 하드웨어의 통신 원리를 이해하는 데 큰 도움이 될 것입니다.
응용 예제 코드: 리모콘으로 LED 램프를 토글식으로 켜고 타이머로 30초만 켜짐. 자동 모드로 랜덤으로 깜빡이는 촛불 모드로 5초 켜기
import network
import time
# Wi-Fi 스테이션 모드 활성화
wlan = network.WLAN(network.STA_IF)
wlan.active(True)
# Wi-Fi가 연결될 때까지 대기 (실제 코드에서는 공유기 접속 코드가 필요합니다)
while not wlan.isconnected():
print("연결 대기 중...")
time.sleep(1)
print("연결 완료!")
# 1초마다 RSSI(신호 강도) 측정하기
while True:
if wlan.isconnected():
# RSSI 값 가져오기 (단위: dBm)
rssi = wlan.status('rssi')
print(f"현재 Wi-Fi 신호 강도 (RSSI): {rssi} dBm")
else:
print("Wi-Fi 연결이 끊어졌습니다.")
time.sleep(1)
2. 주변 Wi-Fi를 스캔하면서 RSSI 측정하기
공유기에 접속하지 않고, 주변에 있는 모든 Wi-Fi 채널을 검색(Scan)하여 각각의 RSSI를 확인하고 싶을 때는 wlan.scan()을 사용합니다.
제어 공학에서 오랜 기간 왕좌를 지켜온 PID(Proportional-Integral-Derivative) 제어와 차세대 제어 알고리즘으로 주목받는 ADRC(Active Disturbance Rejection Control, 능동 장해 거부 제어)는 각각의 뚜렷한 철학과 장단점을 가지고 있습니다.
두 제어 방식의 핵심 개념, 성능 비교, 그리고 앞으로의 제어 트렌드를 상세히 정리해 드립니다.
1. PID vs ADRC 핵심 개념 이해
PID 제어: “과거와 현재의 오차만 보고 달린다”
PID는 시스템의 수학적 모델 없이도, 제어 대상의 ‘출력 값’과 ‘목표 값’의 오차(Error)만을 바탕으로 제어 입력을 생성합니다.
P (비례): 현재 오차에 비례해 제어 (속도 결정)
I (적분): 누적된 과거 오차를 제거 (정상상태 오차 제거)
D (미분): 오차의 변화 추세를 보고 미래를 예측 (오버슈트 억제)
💡 한계: 시스템 내부에 급격한 외란(Disturbance)이 발생하거나, 모터의 부하가 갑자기 바뀌는 등 ‘동적 특성 변화’가 생기면 PID는 이에 즉각 대응하지 못하고 오차가 커진 후에야 사후 약방문식으로 제어를 시작합니다. 또한 미분(D) 성분은 센서 노이즈를 증폭시키는 고질적인 문제가 있습니다.
ADRC 제어: “외란을 실시간으로 감시하고 즉시 상쇄한다”
중국과학원 한징칭(Han Jingqing) 교수가 제안한 ADRC는 “모델의 불확실성과 외부 외란을 실시간으로 추정하여 제어 신호에서 빼버리면, 시스템은 단순한 적분기 형태로 변한다”는 철학에서 출발합니다. 핵심은 ESO(Extended State Observer, 확장 상태 관측기)입니다.
확장 상태 관측기 (ESO): 시스템의 내부 상태뿐만 아니라, ‘수학적 모델의 오류’와 ‘외부 외란’을 하나의 ‘총체적 외란(Total Disturbance)’이라는 새로운 상태 변수로 정의하고 실시간 추정합니다.
결론부터 말씀드리면 “제어 성능과 강인성(Robustness) 측면에서는 ADRC가 압도적으로 우세하지만, 구현의 단순함과 범용성 측면에서는 여전히 PID가 우세하다”고 볼 수 있습니다.
비교 항목
PID 제어
ADRC 제어
우세 승자
외란 대응 능력
오차가 발생한 후 제어 (느림)
ESO를 통해 외란을 실시간 상쇄 (매우 빠름)
ADRC
모델 의존도
없음 (완전 블랙박스 가능)
대략적인 시스템 차수만 알면 됨
무승부
매개변수 튜닝
3개 (Kp,Ki,Kd) / 직관적임
ESO 대역폭, 제어기 대역폭 등 2~3개 (대역폭 기반 튜닝으로 발전하여 생각보다 쉬움)
무승부 (최신 LADRC 기준)
센서 노이즈 영향
미분(D) 항이 노이즈를 증폭시킴
ESO가 필터 역할을 하여 노이즈에 강함
ADRC
연산 복잡도
매우 낮음 (MCU 자원 거의 안 먹음)
관측기(ESO) 상태 방정식을 풀어야 하므로 연산량 많음
PID
산업계 범용성
전 세계 산업계의 90% 이상 사용
고성능 임베디드 장비를 중심으로 급격히 확산 중
PID
왜 ADRC가 우세한가? (예시)
모터 제어를 예로 들면, 로봇 팔이 물건을 집어서 갑자기 무게(부하)가 늘어나는 상황이 발생했을 때:
PID: 속도가 떨어지고 나서야 Ki 항이 서서히 차올라 모터 출력을 높입니다. (응답 지연, 오버슈트 발생 가능)
ADRC: 부하가 걸리는 순간 ESO가 이를 ‘외란’으로 즉시 감지하여 한두 스텝 만에 모터 전류를 올려버립니다. 속도 저하가 거의 발생하지 않습니다.
3. 앞으로의 제어 방식은 어디로 가는가?
앞으로의 제어 패러다임은 “PID의 점진적 세대교체”와 “지능형 제어의 융합”으로 요약할 수 있습니다.
① 하드웨어 성능 향상으로 ADRC의 급부상
과거에는 ADRC의 복잡한 행렬 연산과 관측기 루프를 저가형 MCU(마이크로컨트롤러)에서 돌리기 부담스러웠습니다. 하지만 최근 하드웨어(Cortex-M 시리즈, ESP32, RP2040 등)의 성능이 비약적으로 상승하면서 ADRC를 탑재하기 매우 유리해졌습니다.
텍사스 인스트루먼트(TI) 사의 모터 제어 칩셋에는 이미 InstaSPIN-MOTION이라는 이름으로 ADRC 기술이 내장되어 상용화되었습니다.
드론(Betaflight 등 프레임워크), 정밀 CNC, 서보 드라이브, 스마트 가전(인버터 컴프레서) 등 외란이 많고 정밀 제어가 필요한 영역에서 PID를 빠르게 대체하고 있습니다.
② 데이터 기반 및 AI와의 융합
전통적인 제어 이론에 딥러닝이나 강화학습(Reinforcement Learning)을 융합하는 시도가 활발합니다.
AI 기반 자동 튜닝: PID나 ADRC의 파라미터를 사람이 맞추는 것이 아니라, AI가 시스템의 거동을 보고 실시간으로 최적의 파라미터(Gain)를 찾아주는 방식입니다.
신경망 외란 관측기: ADRC의 핵심인 ESO 자리에 딥러닝 모델을 넣어 복잡한 비선형 외란을 예측하는 연구가 진행 중입니다.
③ 현실적인 공존: PID는 죽지 않는다
ADRC가 아무리 좋아도 밸브 제어, 단순 온조기, 유량 제어처럼 빠른 응답이 필요 없고 정밀도가 적당해도 되는 수많은 산업 현장에서는 여전히 PID가 굳건히 자리를 지킬 것입니다. 싸고, 직관적이며, 유지보수가 편하기 때문입니다.
요약
현재: 단순하고 범용적인 제어는 여전히 PID가 지배하고 있지만, 고성능·강인 제어가 필요한 곳에서는 한계에 부딪히고 있습니다.
미래: 시스템의 성능을 극대화해야 하는 정밀 제어 분야(로봇, 드론, 전기차 모터 등)에서는 외란 저항성이 압도적인 ADRC가 사실상의 표준(Standard)으로 자리 잡아가고 있습니다.
💡 여기서 잠깐! 실무 엔지니어링 팁
앞서 PID와 ADRC의 이론적인 개념을 비교해 보았는데요. 이번에는 실제 임베디드 현업이나 DIY 프로젝트에 적용할 때 꼭 알아야 할 현실적인 실무 포인트 4가지를 짚고 넘어가겠습니다.
1. ADRC는 쓰기 어렵다? 편견을 깨버린 ‘LADRC’의 등장
“관측기(ESO)에 행렬식에… 수식이 너무 복잡해서 현업에서 못 쓰겠다” 하시는 분들이 많습니다. 실제로 한징칭 교수가 처음 제안한 초창기 ADRC는 비선형 수식이 많아 튜닝해야 할 파라미터가 10개가 넘어 다들 고개를 저었죠.
하지만 가오(Gao) 교수가 이를 선형화한 LADRC(Linear ADRC)를 발표하면서 판도가 완전히 바뀌었습니다.
복잡한 파라미터를 단 2개로 압축: 최신 LADRC는 관측기 대역폭(ωo)과 제어기 대역폭(ωc)이라는 딱 두 가지만 조절하면 튜닝이 끝납니다.
직관적인 튜닝: 시스템의 주파수 대역폭만 슥슥 조절하면 되기 때문에, 어설프게 Kp,Ki,Kd 세 개를 붙잡고 수십 번 밤새워 튜닝하는 PID보다 오히려 셋팅이 훨씬 직관적이고 빠릅니다.
2. 하드웨어 리소스, 내 칩(MCU)에서 돌아갈까?
제어 알고리즘을 고를 때 가장 중요한 건 결국 “내가 가진 하드웨어 성능으로 커버가 되느냐”입니다.
PID 제어: 코드 몇 줄이면 끝납니다. 이산화(Discretization) 과정도 매우 간단해서 아주 저렴한 8비트 아두이노(AVR 계열) 칩에서도 넘치도록 가볍게 돌아갑니다.
ADRC 제어: 매 루프마다 내부 상태 방정식 오차를 계산하고 예측하는 연산(오일러 적분 등)이 포함되기 때문에 소수점(Floating Point) 연산이 끊임없이 일어납니다.
🛠️ 실무 팁: 따라서 연산 성능이 떨어지는 8비트 MCU보다는, 하드웨어 **FPU(부동소수점 연산 장치)**가 탑재된 32비트 MCU(예: Cortex-M4 시리즈, ESP32, RP2040 등) 환경에서 구현하는 것을 적극 권장합니다. 최근에는 워낙 고성능 MCU가 저렴하게 잘 나와서 하드웨어 제약은 거의 사라진 편입니다.
3. 직관적인 비유로 이해하는 두 방식의 차이
이해를 돕기 위해 우리가 매일 타는 ‘자동차 운전’으로 두 제어 방식을 비유해 보겠습니다.
PID 제어는 ‘운전면허 시험장 코스’를 도는 것과 같습니다. 바람도 안 불고 노면도 고른 완벽한 통제 환경이라면, 엑셀과 브레이크만 적당히 밟아도 자율주행 차가 선을 넘지 않고 완벽하게 목적지까지 달립니다.
ADRC 제어는 ‘돌풍이 몰아치는 대관령 고갯길’을 달리는 것과 같습니다. 차가 코너를 돌 때 갑자기 측면에서 강한 돌풍이 불면, 차가 차선 밖으로 밀려나기 전에 운전자가 본능적으로 핸들을 반대 방향으로 확 꺾어 버리죠(외란 상쇄). 외란이 발생해도 차체는 거의 흔들리지 않고 중심을 유지하며 안정적으로 주행하게 됩니다.
4. 이미 구축된 오픈소스 생태계와 상용화 트렌드
“이 좋은 걸 나 혼자 맨땅에 헤딩하며 코딩해야 하나?” 걱정하실 필요 없습니다.
이미 GitHub 등에 Alternative PID, Arduino ADRC, LADRC C++ 같은 키워드로 검색해 보면 잘 짜여진 오픈소스 라이브러리를 쉽게 찾을 수 있습니다. 또한, 오픈소스 드론 플라이트 콘트롤러(PX4, Betaflight)나 로봇 운영체제(ROS) 진영에서도 이미 외란에 강한 ADRC 알고리즘이 메인 제어기로 녹아들고 있는 추세입니다.
칩 제조사들도 발 빠르게 움직이고 있습니다. 모터 제어 칩의 명가인 텍사스 인스트루먼트(TI) 사의 모터 제어 IC 라인업에는 이미 InstaSPIN-MOTION이라는 이름으로 ADRC 기술이 칩 내부에 하드웨어적으로 탑재되어 상용화되어 있습니다.
🏁 결론: 나의 프로젝트에는 무엇을 골라야 할까?
과거에는 연산량 부담 때문에 그림의 떡이었던 ADRC였지만, 이제는 32비트 고성능 MCU를 누구나 수천 원에 구하는 시대가 되었습니다.
내가 만드는 자동화 장비나 IoT 기기가 ‘갑작스러운 부하 변동이 많고, 외부 노이즈나 바람 같은 환경 변수에 민감한 영역(드론, 정밀 서보 모터, 로봇 팔 등)’에 속한다면, 이제 익숙했던 PID를 잠시 내려놓고 차세대 표준으로 자리 잡고 있는 ADRC(LADRC)를 적용해 보시는 건 어떨까요? 여러분의 장비가 한 차원 더 스마트해지는 것을 경험하실 수 있을 것입니다.
안녕하세요! 디바이스를 설계하고 IoT 프로젝트를 진행하다 보면 누구나 한 번쯤 “더 정확하고, 더 최신인 센서”를 찾게 마련입니다.
저 역시 최근 프로젝트를 진행하면서 기존에 흔히 쓰던 DHT11이나 DHT22 대신, 비교적 최신 칩셋이면서 정밀도가 높은 AHT20이나 기압까지 측정되는 BMP280을 적극적으로 도입했습니다. 당연히 스펙이 더 좋으니 결과물도 완벽할 줄 알았죠.
하지만 실전 배치 단계에서 예상치 못한 복병을 만났습니다. 바로 ‘전선 연장 거리(통신 거리)’ 문제였습니다.
오늘은 실전에서 직접 삽질하며 깨달은 AHT20/BMP280(I2C 방식)과 DHT11/DHT22(1-Wire 방식)의 통신 거리 제약과 그 이유에 대해 생생하게 공유해 보려고 합니다.
1. 발목을 잡은 주범, I2C 통신 (AHT20, BMP280)
AHT20과 BMP280은 성능이 정말 뛰어납니다. 반응도 빠르고 소수점 아래 단위까지 기가 막히게 잡아내죠. 하지만 이 녀석들은 I2C(아이스퀘어드씨) 통신 방식을 사용합니다.
I2C는 원래 하나의 회로 기판(PCB) 위에서 아주 가까이 있는 칩들끼리 데이터를 주고받으라고 만든 규격입니다. 즉, ‘태생적으로 장거리용이 아니다’라는 뜻입니다.
실전 한계 거리: 별도 조치 없이 일반 전선(점퍼선)으로 연결할 때 안정적인 거리는 30cm ~ 50cm 내외입니다.
1m 넘게 늘리면 어떻게 될까? 선 길이가 1~2m를 넘어가는 순간, 전선 자체의 정전용량(Capacitance)과 주변 노이즈 때문에 데이터가 심하게 왜곡됩니다. 센서 값이 멈춰버리거나 통신 에러가 나면서 MCU가 먹통이 되는 현상을 목격하게 됩니다.
💡 I2C 센서로 거리를 늘려야만 한다면? 꼭 이 센서들을 멀리 떨어뜨려야 한다면, 통신 속도(Clock Speed)를 기본 400kHz에서 100kHz 이하로 대폭 낮추고, 풀업 저항(2.2kΩ~4.7kΩ)을 보강해야 합니다. 5미터 이상이라면 P82B715 같은 전용 I2C 버스 확장 IC를 추가하는 번거로운 하드웨어 작업이 수반됩니다.
2. 느리지만 멀리 간다! 1-Wire 통신 (DHT11, DHT22)
반면, 초보자용으로 분류되거나 구형 취급을 받기도 하는 DHT11과 DHT22는 어떨까요? 이 녀석들은 독자적인 1선(Single-Bus) 디지털 통신 방식을 씁니다.
데이터 선 딱 하나로 통신을 주고받는데, 데이터 갱신 속도는 1~2초 주기로 다소 느리지만 거리 면에서는 엄청난 깡패입니다.
실전 한계 거리: 기본적으로 5m ~ 10m는 선을 그냥 늘려도 아무 문제 없이 짱짱하게 돌아갑니다.
조건만 맞추면 20m~30m도 거뜬: 전원을 3.3V 대신 5V로 인가해 전압 강하를 막아주고, 데이터 선에 달리는 풀업 저항 값을 4.7kΩ 수준으로 낮춰주면 랜선(UTP)이나 실드선을 타고 수십 미터 밖에서도 온습도 데이터를 안정적으로 쏘아 보내줍니다.
📊 한눈에 보는 센서별 통신 거리 사양
센서 명
통신 방식
정밀도 체감
기본 권장 거리
한계 극복 방법
AHT20 / BMP280
I2C
훌륭함 (0.1∘C 단위)
50cm 이내
통신 속도 다운, 풀업 저항 매칭, 확장 IC 필수
DHT11
1-Wire
아쉬움 (1∘C 단위)
5m 이내
5V 전원 사용, 풀업 저항 조절
DHT22
1-Wire
준수함 (0.1∘C 단위)
5m ~ 10m
5V 전원 사용, 풀업 저항 조절, 실드선 활용
💡 실전에서 얻은 결론: 맹신은 금물, 환경이 우선이다
부화기 내부나 스마트팜 챔버처럼 제어 장치(MCU)와 센서의 거리가 수 미터 이상 떨어져야 하는 환경이라면, 아무리 최신형 AHT20이나 BMP280이 정밀하다고 해도 배선 작업과 회로 보완 때문에 배보다 배꼽이 더 커질 수 있습니다.
반면 DHT22는 적당한 정밀도(±0.5∘C)를 보장하면서도, 풀업 저항 하나만 손보면 긴 선을 빼서 원거리 환경을 제어하기에 압도적으로 편리합니다.
MCU와 센서가 같은 케이스나 기판에 붙어있다? ➡️ 무조건 AHT20, BMP280 추천 (고정밀, 고속)
수 미터 밖의 먼 곳의 온습도를 끌어와야 한다? ➡️ 뒤도 돌아보지 말고 DHT22 추천 (원거리 안정성)
기술 스펙 시트에 적힌 정밀도 수치에만 현혹되지 말고, 내가 만들 장치의 ‘물리적 거리와 배선 환경’을 먼저 고려하는 것이 실패 없는 메이킹의 지름길이라는 것을 이번에 배웠네요.
안녕하세요! 여름철 무더위를 피해 에어컨을 켰는데, 온도는 분명 22~24도로 시원해졌음에도 불구하고 오히려 몸이 끈적거리고 습도가 치솟는 경험 해보신 적 있으신가요?
“어? 에어컨 켜면 제습도 같이 되는 거 아니었나?” “혹시 에어컨 물이 안 빠져서(배수 불량) 그런가?”
하고 걱정하시는 분들을 위해, 오늘은 에어컨 가동 시 습도가 높아지는 진짜 이유와 해결법을 시원하게 정리해 드리겠습니다!
1. 배수가 안 돼서 그런 걸까요?
많은 분들이 가장 먼저 의심하시는 게 바로 ‘배수관 막힘’입니다.
결론부터 말씀드리면, 물이 방바닥으로 넘쳐흐르지 않는다면 배수관이 완전히 막힌 것은 아닙니다. 다만, 완전히 막히지 않았더라도 실내기 내부 물받이(드레인 팬)에 물이 원활하게 흐르지 않고 고여 있다면 습도 상승에 일부 영향을 줄 수는 있습니다.
하지만 진짜 주범은 배수가 아니라 ‘에어컨의 운전 원리’에 있습니다.
2. 온도는 내려가는데 습도는 왜 오를까? (진짜 이유 2가지)
① 실외기가 멈추면서 일어나는 ‘역증발 현상’
에어컨이 제습을 하는 원리는 찬물이 담긴 컵 표면에 물방울이 맺히는 것과 같습니다. 에어컨 내부의 냉각판이 차가워지면서 공기 중의 수분을 머금고, 이 물이 배수관을 통해 밖으로 빠져나가는 것이죠.
문제는 방 온도가 내가 설정한 온도(예: 23도)에 도달했을 때 발생합니다. 목표 온도에 도달하면 에어컨은 찬 바람을 만드는 실외기(컴프레셔) 가동을 멈추거나 최소화하고 ‘송풍’ 상태로 바뀝니다. 이때, 냉각판에 맺혀 있던 축축한 수분들이 바람을 타고 다시 방 안으로 증발(역증발)해 버립니다. 온도는 낮은데 수분이 대량으로 공급되니 습도가 80~90%까지 순식간에 올라가게 됩니다.
② 방 크기에 비해 에어컨 용량이 너무 큰 경우
방은 작은데 에어컨이 너무 강력하면, 켜자마자 순식간에 목표 온도에 도달합니다. 에어컨이 충분한 시간 동안 실외기를 돌리며 공기 중의 수분을 짜내야 하는데, 너무 일찍 일을 끝내고 실외기를 꺼버리기 때문에 온지만 낮고 습한 상태가 유지되는 것입니다.
💡 끈적함 탈출! 쾌적하게 에어컨 쓰는 꿀팁
첫째, 설정 온도를 1~2도만 더 낮춰보세요 이미 온도가 낮아서 춥다면 바람 세기를 ‘약풍’이나 ‘미풍’으로 줄이더라도, 실외기가 멈추지 않고 계속 돌아갈 수 있도록 설정 온도를 조금 더 낮추는 것이 좋습니다. 실외기가 돌아야 수분이 밖으로 계속 배출됩니다.
둘째, ‘제습 모드’도 설정 온도를 낮게 잡으세요 많은 분들이 오해하시는데, 인버터 에어컨의 제습 모드 역시 설정 온도에 도달하면 송풍으로 바뀌며 습도가 다시 올라갑니다. 제습 모드를 쓰실 때도 희망 온도를 현재 온도보다 2~3도 낮게 설정해야 제습 효과를 제대로 볼 수 있습니다.
셋째, 끄기 전 ‘송풍’ 또는 ‘자동 건조’는 필수! 에어컨 내부 물받이에 물이 오래 고여 있거나 먼지가 많으면 수분을 더 많이 머금게 됩니다. 에어컨을 끄기 전에는 반드시 ‘자동 건조’ 기능을 켜두시거나, ‘송풍 모드’로 20~30분간 내부를 바짝 말려주셔야 다음 가동 때 습기와 꿉꿉한 냄새를 줄일 수 있습니다.
에어컨을 켰는데도 끈적거렸던 이유, 이제 궁금증이 풀리셨나요? 실외기가 멈추지 않도록 온도 설정을 지혜롭게 조절하셔서, 올여름은 온도와 습도 둘 다 잡는 쾌적한 여름 보내시길 바랍니다!
안녕하세요! 스마트홈 구축의 끝은 결국 ‘UX/UI’와 ‘시각적 만족’이 아닐까 싶습니다. 기존에 사용하던 온습도 모니터링과 에어컨/TV 등 가전 제어용 IR 리모콘 페이지가 슬슬 지겨워지기 시작하더군요. 그래서 이번에 큰맘 먹고 여러 가지 버전의 디자인으로 리모델링을 진행했습니다!
기존 UI의 문제점: 기능은 잘 작동하지만, 한눈에 들어오지 않거나 인테리어와 어울리지 않음.
변화된 핵심 기능: 온습도 데이터 시각화 개선 + IR 리모콘 버튼의 직관적 배치.
여러 가지 디자인 테마 소개:
Type A. 모던 다크 모드: 밤에 봐도 눈이 편안하고 테크니컬한 감성.
Type B. 미니멀 화이트: 깔끔한 화이트 인테리어에 녹아드는 감성 UI.
Type C. 대화면 대시보드형: 거실 월패드나 태블릿에 띄워두기 좋은 한눈에 보기 테마.
색상 테마 5~6개 정도를 선택할 수 있도록 기능 추가
온습도 수치 테이블과 그래프와 온습도를 보고 바로 에어컨 조절을 한페이지에서 할 수 있도록 통합
최근 2시간동안 1분 온습도 추이 기능 추가. 에어컨 온도 조작시 몇분내로 온습도 추이를 볼 수 있다.
기존에 1시간 마다의 온습도 기록은 유지하고 2년 이상의 전체 데이타를 그래프화 해서 볼 수 있다.
마무리 디자인을 여러 개로 바꿔가며 적용해 보니, 계절이나 기분에 따라 스마트홈 분위기를 바꿀 수 있어 만족도가 200%입니다.