IoT/API tủ lạnh thông minh: device state, event và integration

Tài liệu này đặt phạm vi trên tủ lạnh kết nối (smart refrigerator) ở mức kiến trúc: cảm biến & cơ cấu chấp hành → MCU/Main PCB → Connectivity module (Wi‑Fi/Zigbee/BLE) → Gateway firmware → Local/Cloud API. Những mô tả về mô hình dữ liệu, giao thức (MQTT/REST) và pattern xác thực có thể áp dụng cho triển khai prototype hoặc tích hợp; không khẳng định có Local API công khai trên mọi model — điều đó cần xác minh theo firmware/model.

Lưu ý an toàn: mọi thao tác gửi lệnh điều khiển liên quan máy nén hoặc xả đá phải có cơ chế giới hạn tần suất để tránh bật/tắt máy nén trong khoảng thời gian ngắn (không khuyến cáo can thiệp dưới 5 phút giữa các lần khởi động máy nén).

Bạn nên tham khảo hướng dẫn chẩn đoán tổng quát thiết bị tại Chẩn đoán tủ lạnh thông minh.

Mô hình khuyến nghị tách rõ: Reported State (thiết bị báo về), Desired State (command mong muốn), Telemetry (dữ liệu đo định kỳ) và Events (sự kiện bất thường). Dùng cấu trúc JSON chuẩn, timestamp theo UTC ISO8601, và giữ kích thước payload nhỏ đủ cho MCU/Gateway.

3.1 Ví dụ Reported Payload JSON (minified mẫu)
json
{
“deviceId”: “fridge-xxxx”,
“timestamp”: “2026-08-01T12:00:00Z”,
“reported”: {
“temperature”: { “fridge”: 4.0, “freezer”: -18.0 },
“door”: { “open”: false },
“compressor”: { “state”: “idle” },
“defrost”: { “active”: false },
“power”: { “w”: 42.5 }
}
}

Chú thích: các giá trị là ví dụ minh họa; luôn kiểm tra dải giới hạn thiết bị trước khi áp dụng lệnh.

3.2 Ví dụ Command Payload JSON (thiết lập nhiệt độ)
json
{
“deviceId”: “fridge-xxxx”,
“command”: “set_temperature”,
“parameters”: {
“target”: { “fridge”: 5.0 }
},
“meta”: { “requestId”: “abc-123” }
}

Vì sao có field meta: theo dõi lifecycle lệnh và mapping response / audit.

Điều kiện an toàn: trước khi gửi command thay đổi nhiệt độ, kiểm tra token hợp lệ và đảm bảo command không vi phạm policy thiết bị (ví dụ không đặt target nằm ngoài dải an toàn).

5.1 MQTT (pattern)

• Topic phân lớp: /telemetry, /state, /command, /event.
• Sử dụng QoS phù hợp: telemetry có thể QoS0; state/command dùng QoS1 khi cần đảm bảo delivery.
• Keep-Alive & LWT: khai báo Last Will cho thông báo offline.
• Cổng chuẩn: 1883 (MQTT), 8883 (MQTTS).

5.2 REST/Webhook

• REST endpoints dùng GET để truy vấn state, POST/PUT cho command/config.
• Webhook: Cloud gửi sự kiện đến hệ thống thứ ba khi event trigger; cần xác thực endpoint và retry logic.

Thiết kế topic và method phải tương thích với cách vendor quản lý retained messages để tránh desynchronization.

Checklist bảo mật:

• Bật TLS cho transport: MQTTS/HTTPS (port 8883/443).
• Sử dụng JWT/OAuth2 hoặc API key với expiration và refresh flow; không hardcode key trong firmware.
• Rate limiting: giới hạn số command/giây trên Gateway để tránh DoS nội bộ.
• Audit/logging: giữ log action thay đổi state với requestId để truy vết.

5.1 Token lifecycle (tóm tắt)

• Kiểm tra: token có thời hạn và refresh token không.
• Vì sao: token expired gây lỗi authorisation; refresh flow phải an toàn.
• Nếu không đạt: block tính năng remote control cho tới khi xác thực được phương pháp làm mới token.

5.2 Bảo vệ phần cứng

• Vì sao: lệnh giả mạo có thể gây hại cho compressor/board.
• Biện pháp: enforce server-side sanity checks (validation limits) trước khi đẩy lệnh xuống thiết bị.

Bạn có thể đọc thêm về an ninh thiết bị tại Bảo mật tủ lạnh thông minh.

Luồng mẫu tích hợp:
Broker connect → Authenticate → Subscribe telemetry/topic → Transform payload → Automation node (rule) → Action (notify / set command)

7.1 Kịch bản: Door Open > 180s → cảnh báo

• Kiểm tra: event door.open true + timestamp.
• Vì sao: cảnh báo kịp thời tránh thất thoát nhiệt.
• Nếu đạt: webhook gửi notification; có thể trigger gentle action (blink light) chứ không bật/tắt compressor.
• Nếu không đạt: log và đẩy recheck qua retained state.

Lưu ý: tránh automation bật/tắt máy nén liên tục; để tránh sốc áp suất, không cho automation gửi command khởi động máy nén nếu compressor mới tắt dưới 5 phút.

Ví dụ YAML (Home Assistant) minh họa xử lý event (cấu trúc mẫu, không phải config hoàn chỉnh):
yaml
trigger:

• platform: mqtt
  topic: “fridge-xxxx/event/door”
  condition:
• condition: template
  valuetemplate: “{{ (astimestamp(now()) – astimestamp(trigger.payloadjson.timestamp)) > 180 }}”
  action:
• service: notify.mobile_app
  data:
  message: “Door open > 180s”

• Sai lầm: tin rằng retained message luôn là nguồn thật của trạng thái hiện tại. Giải thích: retained có thể cũ; cần query trạng thái hiện thời.
• Sai lầm: gửi command thay đổi nhiệt độ liên tục khi không có cơ chế debouncing. Giải thích: tăng nguy cơ bật/tắt máy nén quá tần suất.
• Sai lầm: làm automation chỉ dựa trên Cloud API, bỏ qua latency và rate-limit. Giải thích: automation thời thực cần fallback Local.

• Kiến trúc phân tầng: phần cứng ↔ gateway firmware ↔ transport (MQTT/HTTP) ↔ integration layer.
• Sự khác nhau giữa Telemetry (định kỳ), State (reported/desired) và Event (bất thường).
• Các điểm cần đo/check: availability trên LAN, retained message, token lifecycle, và rate limiting.

• Chẩn đoán tủ lạnh thông minh
• Chẩn đoán lỗi giao tiếp tủ lạnh
• Chẩn đoán firmware phần mềm tủ lạnh

13.1 Có thể điều khiển trực tiếp tốc độ máy nén Inverter qua REST API không?

Trả lời: Không thể khẳng định cho mọi model. Về mặt kiến trúc, một API có thể cung cấp lệnh điều khiển mức hoạt động (ví dụ chế độ Eco/High), nhưng việc điều khiển trực tiếp vòng quay máy nén (throttle) phụ thuộc firmware và policy nhà sản xuất. Trước khi thử, cần xác minh khả năng command trên firmware và tuân thủ giới hạn thời gian khởi động máy nén (không gửi lệnh bật/tắt quá thường xuyên).

13.2 Khác biệt giữa Local API và Cloud API là gì?

Local API: latency thấp, phù hợp cho automation thời thực, nhưng phụ thuộc vào kết nối LAN và khả năng thiết bị mở cổng/advertise service. Cloud API: có authentication tenant, chính sách rate limit, xử lý logging/audit; có ưu điểm truy cập từ xa nhưng có thêm latency và phụ thuộc hạ tầng đám mây của vendor.

13.3 Tại sao các lệnh thay đổi nhiệt độ qua API đôi khi có độ trễ vài phút?

Nguyên nhân có thể là: firmware thực hiện debouncing/validation trước khi áp lệnh vào controller để bảo vệ máy nén; hoặc có queue processing trên gateway/cloud và rate limiting. Phép kiểm tra: xác minh timestamp request/response, kiểm tra logs gateway và policy throttle; không cố gắng giảm thời gian bằng cách gửi nhiều request liên tiếp.

• Khung dữ liệu Device State (Reported/Desired), cách thiết kế payload JSON và topic MQTT cho tủ lạnh kết nối.
• Điểm kiểm tra quan trọng để khắc phục desynchronization và lỗi auth/throughput.
• Giới hạn an toàn khi gửi lệnh liên quan máy nén và xả đá.

Sau khi đọc xong, nếu cần mở rộng sang chẩn đoán phần cứng hoặc điều tra firmware theo model cụ thể, tham khảo các bài liên quan trong phần Học tiếp ở trên.