작업 중인 enertalk 연동과 InfluxDB 로깅을 작업하면서 생긴 궁금증을 정리해보려고 한다.

enertalk api를 사용하여 조회한 소비전력/소비전력량/요금을 HC3에 업데이트하려고 QD를 통하여 업데이트하고 있다. 아직 테스트 과정이라 5초마다 3가지를 업데이트하고 있다.
QD가 3개이고 이 값에대해서 scene을 트리거링하여 InfluxDB에 로깅하도록 하고 있다.
scene에서는 HTTPClient가 없어진 것 같고, trigger정보를 QD에 액션으로 넘겨 QD에서 처리하도록 하였다.

그러면서 몇 가지 의문점이 생겼는데, 관련 정보가 너무 부족하다.

HC2 scene에서 중복으로 트리거링되고, scene의 cycle이 생기면서 해외의 고수 jgab이 싱글 인스턴스 형태의 새로운 룰 Syntax를 이용하여 작성한 자동화인 EventRunner라는 것이 있다. 이것의 HC3용 알파버전을 간단히 살펴보면 1000ms 간격으로 디바이스 property/global variables/event의 변경을 조회해서 동작하는 것으로 확인된다. (아직 alpha 버전이라 1초간격으로 polling으로 되어있다고 한다.)
jgab과 직접적으로 얘기한 것이 아니라서 왜 QD로 구성하였고 이렇게 구성해도 실시간으로 동작할 수 있느냐 의문이 있다.

여기에 더불어 내가 작업하면서 몇 가지 추가 의문이 있는데,
앞서 enertalk 연동시 3가지 QD를 동시에 업데이트하고 이를 scene에서 트리거링해서 Influx로 로깅하는 QD를 호출하게 된다.
그 과정에서 디버깅 로그를 봤는데, ERROR가 계속 발생되고 있었다. 코드는 단순하기 때문에 에러가 발생할만한 부분이 없다고 생각된다.

local debug = 5

local function log(level, str)
  if level <= debug then
    fibaro.debug("d", str);
  end
end

log(5, json.encode(sourceTrigger))
fibaro.call(32, "sendInflux", json.encode(trigger))

위와 같이 단순한데, 실제로 디버깅 이미지와 같이 ERROR가 발생된다. 추측컨데 동시에 실행될 경우 기존 scene이 중단되면서 ERROR가 발생되는 것이 아닐까 싶다. HC3에서 lua 동작메커니즘이 동시 실행이 불가능하도록 바뀐 것인지 에러의 원인도 확인할 수 없다.
scene에서 오류가 발생해서 QD로 트리거가 넘어가지 못해 InfluxDB에 데이터가 누락이 있었는지는 정확하게 파악하기 어렵다. 동일시간대에 데이터가 없는 것은 확인되었지만 지연되어서 요청되었는지 누락이 있었는지는 확인하기 어려웠다.

또한, enertalk과 연동하는 QD를 5개로 늘리고 개인서버에서 1초마다 enertalk api를 조회해서 PUT /api/devices/{ID}로 value, energy, power, ui 등을 업데이트했더니 HC3이 응답을 못하는 경우가 생긴다.

연동하는 서버를 실행시키자마자, CPU는 바로 100% 가까이 사용되면서 몇 분 후 서버 응답불가로 나타난다. 물론 실제로 HC3이 서비스 불가능한 상태가 되는 것은 아니고 또다시 응답을 한다. (내부 시스템 일부가 과부하되면서 응답을 하지 않는 형태로 나타나는 것 같다. 저럴 때 웹 브라우저에는 문제가 있으니 리스타트 하라는 경고창이 뜨기도 한다.)
enertalk api응답은 1초내로 오기 때문에 거의 매 1초마다 HC3에 업데이트가 되고 있는 것이고 HC3에 정보를 업데이트하면 scene이 동작하고 QD에서 로깅에 남길 디바이스의 Room, Section 정보들을 추가 수집해서 InfluxDB로 5회 http call을 한다.

주기를 5초로하여 서버를 실행하였다.

역시 스파이크 치는 주기는 5초였다. Influx 로 로깅할 때 로직이 약간 있기 때문에 이 때문인가 싶어 scene을 비활성화시켜도 동일하게 CPU는 90% 대를 유지하였다.

이제는 Rest API를 통해 device 정보를 업데이트하는 것이 무거운 작업인 것인지 확인할 길이 남았다.

  1. 5개 QD에 POST /api/devices/{ID}/action/{actionName} 으로 데이터를 업데이트 했을 때 CPU Util 확인
  2. 1개 메인 QD에 POST /api/devices/{ID}/action/{actionName} 으로 데이터를 업데이트하고, 나머지 4개에 QD내의 lua 코드로 업데이트 했을 때 CPU Util 확인

이렇게 추가 진행해볼 필요가 있을 것 같다.

어줍잖은 추측을 해본다면 PUT /api/devices/{ID} 이 API는 실제로 device의 정보를 업데이트하는 것이기 때문에 변경된 정보를 저장하는데 작업(DB I/O?)이 소모될 것이고, POST /api/devices/{ID}/action/{actionName} 는 QD의 메소드를 실행시키는 API이기 때문에 가벼운 작업일 수도 있을 것 같다.