TOHO TTM006W 온도컨트롤러 원격제어, EASY LOGGER 납품사례
보일러 온도를 현장에서만 확인해야 한다면 담당자가 설비 앞에 있어야 하는 시간이 길어져요. 이번 납품 사례는 기존 비통신형 TOHO TTM006을 TTM-000W 시리즈의 TTM006W로 적용하고, Modbus RTU로 읽은 PV·SV 값을 EASY LOGGER에 연결한 구성입니다. MQTT로 원격 제어 명령을 전달하고 MySQL에 온도 이력을 남겨 현재값과 추세를 확인하도록 정리했어요.
아래 내용은 제공된 화면과 동영상을 기준으로 하며, 모델별 레지스터 주소와 값의 배율은 실제 TOHO 매뉴얼·현장 주소 맵과 대조해 확정해야 해요.
먼저 결론부터 볼게요
이번 구성의 핵심은 데이터가 끝까지 이어지는지 확인하는 데 있어요. TTM006W의 PV는 현재 온도, SV는 목표 온도로 보고, TTM006B/BOILER_PV, TTM006B/BOILER_SV, TTM006R/RETURN_PV, TTM006R/RETURN_SV처럼 장비명과 설정명을 나누면 보일러와 리턴 계통을 구분하기 쉬워져요.
EASY LOGGER는 수집 주기·저장 이력·전달 상태·대시보드를 운영하고, MQTT는 실시간 READ·WRITE, MySQL은 외부 이력 검색을 맡겨 역할을 나눴어요. 장비 한 대의 필드만 연결하면 EASY-LINK 중심으로 시작할 수 있지만 PV·SV 화면과 장기 이력, 원격 제어 권한까지 함께 관리할 때는 EASY LOGGER가 더 잘 맞아요.
비통신형 TTM006에서 TTM006W로 바꾼 이유
기존 비통신형 TTM006은 표시창과 현장 조작이 중심이어서 원격지에서 현재 온도와 설정값을 같은 화면으로 확인하기 어려웠어요. TTM006W 적용 사례에서는 컨트롤러를 Modbus RTU 장치로 등록하고, Unit ID와 시리얼 조건을 맞춘 뒤 읽기 필드와 쓰기 대상을 분리했어요.
온도센서와 PV를 확인하고, PV는 실제로 읽는 현재값이고 SV는 운전 조건에 영향을 주는 설정값이에요. MQTT WRITE와 대시보드의 SEND 입력은 승인된 SV 주소에만 연결하고 PLC 또는 컨트롤러의 인터록과 수동 조작 절차를 함께 확인해야 해요.
TOHO TTM-000W 시리즈와 현장 설정
제공된 연결 화면에는 TTM006B, Unit ID 1, /dev/ttyUSB0, 9600 baud, Odd parity, 8 data bit, 1 stop bit가 표시돼요. 이 값은 사례 설정값이며 모든 TTM-000W 시리즈의 기본값이라고 단정하지 않고, 매뉴얼과 배선표를 기준으로 확정해야 해요.
TTM006B, Unit ID 1, /dev/ttyUSB0, 9600 baud, Odd parity, 8 data bit, 1 stop bit가 표시된 설정 화면이에요.
목록에는 TTM006B와 TTM006R이 같은 /dev/ttyUSB0에서 Modbus RTU로 동작하고 Unit ID 1과 2를 사용하도록 보입니다. 수집 설정은 BOILER_PV·BOILER_SV, RETURN_PV·RETURN_SV로 나뉘며 500MS Timer, INT32, 주소 0과 2가 표시돼요.
두 컨트롤러의 Unit ID와 BOILER·RETURN PV·SV 설정, 500MS·INT32·주소 항목을 한 화면에서 확인하는 사례예요.
주소 0과 2가 레지스터 번호인지 오프셋인지는 이 화면만으로 확정할 수 없어요. 인수 전에는 표시값·원시값·변환값을 같은 시각에 비교하고 INT32의 부호·배율·바이트 순서를 주소 맵에 기록해요.
EASY LOGGER MQTT 예제
공식 MQTT 형식은 Modbus 수집 설정의 이름을 기준으로 READ·WRITE Topic을 만들어요. 이번 화면의 설정명을 적용한 예시는 아래와 같고, Topic은 Automatic Topic Preview에서 다시 확인해야 해요.
READ TOPIC: TTM006B/BOILER_PV/READ
WRITE TOPIC: TTM006B/BOILER_SV/WRITE
BOILER_PV는 읽기 대상이고 BOILER_SV는 쓰기 대상이에요. 화면에서 BOILER_SV 주소가 2로 표시되므로 payload의 values에 주소 2를 넣었지만, 30이라는 값의 배율은 예시이므로 주소 맵과 컨트롤러 설정을 대조해야 해요.
{
"plc_name": "TTM006B",
"config_name": "BOILER_SV",
"data_type": "int32",
"values": {"2": 30}
}
Automatic Topic Preview에서 Topic을 확인하고 Runtime Status에서 Broker 연결·마지막 수신을 봐요. Payload Log에서는 WRITE 기록과 처리 결과를 확인하고, 외부 시스템은 Subscribe to the WRITE Topic. 동작과 READ·WRITE 권한을 분리해요.
- Subscribe to the WRITE Topic.
- 테스트 주소만 사용합니다.
- 최소 권한만 부여합니다.
- 허용 주소 범위를 제한합니다.
- PLC 인터록을 확인합니다.
- 수동 복구 절차를 준비합니다.
MQTT는 이번 구성의 주 전달 대상이고, 현재값을 여러 클라이언트에 나누는 데 적합해요. 기간별 검색과 보존이 중심이면 다음 MySQL 흐름을 함께 확인하면 돼요.
EASY LOGGER MySQL 예제
MySQL 데이터베이스 설계와 이력은 EASY LOGGER 내부 테이블을 추정하지 않고 운영팀이 관리하는 외부 데이터베이스의 스키마와 기록 규칙으로 설계해요. 아래 테이블은 외부 저장소 예시이며 실제 컬럼명과 보존 정책은 현장 DB 문서에 맞춰야 해요.
CREATE TABLE boiler_temperature_history (
controller_name VARCHAR(32) NOT NULL,
config_name VARCHAR(32) NOT NULL,
pv DECIMAL(10,2) NOT NULL,
sv DECIMAL(10,2) NOT NULL,
measured_at DATETIME(3) NOT NULL,
received_at DATETIME(3) NOT NULL,
PRIMARY KEY (controller_name, config_name, measured_at)
);
TTM006B의 BOILER_PV·BOILER_SV를 기록한다면 measured_at은 컨트롤러 값이 만들어진 시각, received_at은 EASY LOGGER가 받은 시각으로 구분해요. DB History Logs에서 저장 성공·오류를 확인하고 외부 DB 기록을 검색할 때는 장비명·설정명·기간을 조건으로 사용해요.
SELECT controller_name, config_name, pv, sv, measured_at, received_at
FROM boiler_temperature_history
WHERE controller_name = 'TTM006B'
AND measured_at >= '2026-08-21 00:00:00'
ORDER BY measured_at DESC;
이력 보존 기간(retention)과 검색 인덱스는 MySQL 운영 정책으로 정해요. DB History의 오류 시각과 MQTT Payload Log의 수신 시각을 맞추면 저장 실패와 통신 실패를 구분할 수 있어요.
보일러 PV·SV 화면과 동영상으로 확인하기
대시보드에는 보일러 PV 24.6℃, SV 30℃, 리턴 PV 25.9℃와 리턴 SV 2℃, PV 추세 그래프가 표시돼요. 숫자뿐 아니라 PV·SV 이름, 마지막 수신 시각, 전송 상태, 설정 권한을 함께 표시해야 원격 제어 화면을 운영할 수 있어요.
보일러와 리턴의 PV·SV, SV 입력·SEND 버튼, PV 온도 추세가 함께 보이는 원격제어 화면이에요.
리턴 영역의 UNDEFINED는 납품 전 위젯명이나 데이터 연결을 최종 점검해야 한다는 신호예요. 대시보드가 보인다는 이유만으로 WRITE가 안전하게 끝났다고 판단하지 말고, 테스트 주소와 승인된 SV 범위에서 컨트롤러 표시값·MQTT Payload Log·MySQL 기록을 대조해야 해요.
실제 동작 흐름은
스마트양식장·스마트수영장으로 확장할 때
이번 납품 사례는 보일러와 리턴 온도 제어예요. 같은 PV·SV 구조를 스마트팜·스마트양식장의 수온 순환·가열 설비나 스마트수영장의 수온 유지 설비에 적용할 수는 있지만, 해당 현장의 납품이나 수질 결과를 증명하는 내용은 아니에요. 수위·유량·pH·잔류염소 필드와 펌프·히터 인터록은 시설별로 따로 검토해야 해요.
스마트팩토리에서는 Modbus RTU 수집과 MQTT 원격 제어를 설비 단위로 시작하고, MySQL 이력에서 PV·SV 편차와 설정 변경 기록을 검색하는 흐름이 현실적인 출발점이에요. MES·CIM은 확인된 MQTT, HTTP API 또는 DB 인터페이스로 필드 계약을 협의하고, 전용 커넥터나 무설정 직접 연계를 전제로 하지 않는 게 좋아요.
납품 후 확인 순서와 현장 연결 가능 여부
인수 전에는 다음 순서로 확인하면 돼요.
- TTM006B·TTM006R의 Unit ID가 겹치지 않는지 확인해요.
- baudrate, parity, data bit, stop bit와 RS-485 배선을 대조해요.
- PV·SV 주소, INT32 타입, 배율과 부호를 현장 주소 맵에 기록해요.
- PV 읽기와 SV 쓰기를 테스트 주소에서 각각 확인해요.
- PLC 인터록과 수동 복구 절차, 원격 WRITE 권한을 문서화해요.
- MQTT Payload Log와 MySQL DB History의 시각·값·설정명을 비교해요.
한 대의 컨트롤러와 한 공정에서 정상값·경계값·통신 재연결을 확인한 뒤 범위를 넓히는 편이 좋아요. EASY-LINK의 역할은 현장 Modbus RTU 필드를 수집해 목적지로 보내는 연결 계층이고, EASY LOGGER의 역할은 수집 주기·저장 이력·전달 상태·대시보드를 통합 관리하는 운영 계층이에요.
현장 연결 가능 여부를 확인하고 싶다면 컨트롤러 모델, RS-485 설정, Unit ID 목록, PV·SV 주소 맵, MQTT Broker 권한과 외부 MySQL 컬럼을 준비해 문의해 주세요. 적용 범위를 작게 잡고 화면·명령·이력의 세 결과가 같은 사건을 가리키는지부터 확인하면 원격 제어를 운영 절차 안에 넣을 수 있어요.