polling → event driven 처리 방식 변경

실시간 확인 필요 정보

• 엔진의 커버 상태(열림, 닫힘)

• 현재 냉장 온도

• 슬롯별 보틀 실시간 탈장착 정보

기존 방식 polling

• 일정시간 주기를 정해놓고, 디바이스앱에서 펌웨어로 항상 먼저 물어보는 방식

• 펌웨어는 항상 물어볼 때만 값을 조회해서 반환해주는 로직이었다.

이슈

• 실시간 동기화를 위해 polling 주기를 극단적으로 줄이면,
• 이벤트가 발생하지 않을 때는 너무 많은 불필요한 통신을 하게 됨.

• polling 주기를 5초 정도로 두면
• 완전히 실시간으로 싱크가 맞지 않으니까, 어색한 상황이 종종 목격됨.
• (특히 커버 상태)

1차 개선 (긴급)

• 인터럽트와 이벤트 방식으로의 개선은 이미 생각하고 있었지만 빠르게 반영할 수 있는 상황이 아니었다.
• 펌웨어의 수정 필요,
• 배포된 엔진의 펌웨어 업데이트 필요
• 디바이스앱 로직 개발 필요

• 따라서 POC 도중에 이미 사용자들이 불편을 겪고 있던 상황이었으므로, 폴링 주기를 당겨서 부자연스러움을 임시로 해결하였다.
• 하지만 이는 불필요한 통신을 수시로 하고 있는 것이기 때문에 정말 임시 방편이다.

2차) 개선 방식 event driven(디바이스앱) + interrupt(펌웨어)

• 보틀의 장착 정보, 커버 상태 정보, 냉장온도 변화 등

• 엔진에 붙어있는 물리적인 요소들의 변화는 펌웨어가 가장 빠르고 정확하게 알 수 있는 내용

• 디바이스앱이 먼저 이러한 변화를 먼저 알아챌 수는 없음.

• 펌웨어와 엔진 요소들은 인터럽트 방식으로 구현하여, 변화가 생겼을 때 즉각적으로 펌웨어로 알려줄 수 있도록 수정

• 펌웨어 프로토콜을 구독 명령으로 프로토콜 변경 합의
• 디바이스앱이 켜지고, 초기화 과정에서 구독 명령을 펌웨어로 전송한다.
• 펌웨어는 구독명령이 수신된 이후로는, 인터럽트가 발생할 때마다 디바이스앱에게 먼저 변화를 알려준다.
• 디바이스앱에선 리스너가 대기하고 있다가, 이벤트 수신 시 즉각적인 처리를 한다.

결과

• 불필요한 통신 제거됨.

• 이벤트 발생에 따른 즉각적인 대응
• 사용자 UI 변화
• 값 변경에 따라 필요한 추가 처리 로직, 가공 로직들이 즉각적으로 대응됨