최근에 Smartthings의 방향성과 안정성에 대해 의구심이 커지고 있던 참에, Hubitat Elevation으로 이전을 하였다. 참고로 해외에서는 HE라고 줄여쓴다. (ST 처럼...)

Hubitat은 Smartthings의 기능들이 유사한 구조로 사용할 수 있게 되어있다. 이것저것 작업해야 할 것이 많다는 점에서 ST에 비해 사용은 어려운 부분들이 있다. Driver(ST의 DTH)와 App 코드를 조금씩 손봐야할 부분들이 꽤 된다.

ST ⇨ HE로 이전하는데에는 일주일 정도 걸린 것 같다. Device가 얼마 없기 때문에 실제 device 이전은 1~2일정도 걸린 것 같고, App의 이동을 위해 App 코드 수정을 할 시간이 되는 주말까지 기다리느라 일주일 정도 여유를 잡고 진행하였다.

그림 하나 없는 경험기가 되겠다.

HE의 외형이나 가격 등을 간단히 얘기하겠다.
구매가는 US용으로 99달러이다. [최근 할인을 해서 80달러 대에서 구매가 가능한 것 같다.] WiFi 기능이 없는 ST Hub 2세대는 60달러 아래 정도로 구입이 가능한 것에 비해 비싸긴하다. 기기의 스펙 차이는 정확히 모르겠다. 다만 Z-wave는 외부 스틱으로 지원되기 때문에 HE 본체기기는 전세계 호환이다.
크기는 ST Hub 2세대보다는 1/2이상 작다. 나중에 한국용 Z-wave 스틱이 나온다면 교체해서 한국 Z-wave 기기를 연결할 수도 있을 것이다. 여러 스틱을 동시에 사용가능 할지는 모르겠다. (아마 안되겠지..) USB 포트는 두 개가 있다. 스틱을 꽂아야하니 최종적인 허브의 모양이 애매하다. 전원/LAN 케이블이 연결되는 후면 쪽으로 스틱을 연결하는 것이 아니라 다른 방향으로 부채 손잡이처럼 튀어나와있다. 나중에 90도 꺾임 커넥터를 이용해서 위쪽으로 스틱을 세우는게 좋을 것 같다.
그리고 전원 LED는 싸구려 티가 많이 난다. ST Hub는 작은 점같은 초록색 LED이었는데 밤에도 공해가 되지 않을 정도로 적당했다. HE는 파란 빛으로 불빛도 강해 불편하다. 그래서 지금은 박스같은 것으로 덮어두었다. 케이스가 투명해서 LED 앞쪽으로만 가린다고 해서 완전히 가려지지 않는다. 깊숙히 숨겨놓는게 좋을 듯 싶다.

외적인 것은 이 정도로 마무리 하고, 전환하는 부분에서 정리해보겠다.

내가 ST에서 사용했었던 것은,

  • xiaomi zigbee devices - 직접연결
  • mi-connector - 일부 센서들은 샤오미 게이트웨이를 통해 연결 중이었다
  • kuku meter
  • kuku harmony
  • ST 센서/플러그
  • remotec Z-wave 릴레이 - kuku lock DTH를 사용 중이었다.
  • neo Z-wave 모션 센서
  • EZEX zigbee 스위치
  • Hue Bridge - Bulb만 연결되어 있었고, webcore의 자동화 때문에 연결해두었다.
  • Nest Thermostat - NST Manager로 연결했다.
  • dw-connector - 다원 Wifi 플러그
  • Beacon - 가상센서를 만들어두고 WebHook으로 센서를 트리거링 했다.
  • webcore
  • homebridge (pdlove) - ST 카페의 신짱님께서 수정한 일부 코드를 추가해서 사용 중이었다.

이정도이다.

HE에서 기본으로 지원하는 3rd party driver도 많이 있다. Neo, ST, remotec 릴레이 모두 기본 driver로 사용할 수 있다.
driver가 없다면 HE 커뮤니티에 찾아보거나, ST의 DTH를 수정해서 사용할 수 있다. 커뮤니티에 올라온 대부분들도 DTH를 수정해서 올라온 것들이다.
DTH의 physicalgraph부분을 hubitat으로 교체하는 정도만 작업하면 사용 가능한 경우가 많다.

kuku lock DTH를 쓰던 것은 driver 코드를 추가한 뒤에 driver 변경해주면 문제 없다.
ST 플러그는 Generic Outlet 으로 잡히는데, 설정으로 전력 리포팅 옵션도 지정할 수 있다. 리포팅하도록 하면 전력이 실시간으로 업데이트가 잘 된다. 다만 스위치 상태 업데이트가 제대로 안될 때가 몇 번 있었다. 전력이 10 watt 등등 로그가 올라오는데 상태는 그대로 off였다. 기본 driver라 driver 코드가 없어, 이 부분은 webcore를 통해 전력이 report 될 때 상태를 refresh 하도록 해두었다. 몇 차례 허브가 업데이트되긴 했는데 드라이버가 개선되었는지 잘 모르겠다.

webcore는 HE용으로 포팅해둔 것이 있다. ST에서 지원되는 버전으로 최신버전은 아니지만 사용하는데는 문제가 없다. ST의 webcore에서 백업해와서 HE에서 복원하면 webcore 피스톤들은 그대로 옮겨 올 수 있다. 다만 기기들의 id들은 바뀌니 그것들은 다 다시 지정해줘야 한다. 이번에 ST에서 중구난방으로 짜두었던 피스톤들을 정리하는 김에 복원을 골라 하면서 불필요한 부분들은 삭제 했다.

그리고 ST에서 연결이 안 끊어지고 잘 사용하던 직연결된 샤오미 디바이스들도 이번엔 샤오미 게이트웨이를 통해 연결하기로 했다. 도어 센서/모션 센서/누수 센서/온습도 센서/아카라 원버튼들이다.
미커넥터의 아버지 아기나무집님이 HE용 mi-connector와 HE 드라이버를 올려두셨다. HE에서는 GitHub연동이 안되니... 일일이 다 옮기기엔 너무 많아 내가 사용할 도어/모션/누수/온습도/버튼 driver코드만 옮겨왔다.
도어/누수 센서는 올려 주신 그대로 사용해도 문제가 없었다. 온습도 센서도 큰 문제는 없다. 모션 센서는 개조 슈퍼센서와 일반센서를 같이 사용 중인데, 이슈가 좀 있었다.
mi-connector에서 올려주는 inactive 신호를 무시하고, active가 된 후 얼마 후 자동으로 inactive되도록 변경했다. (mi-connector에서는 4900ms후에 inactive하도록 신호를 올려주는데, 일반 센서도 이 시간 이후에 inactive시켜버려서 일반센서를 사용할 수 없는 상황이었다.)
그리고 버튼 driver도 정상작동하지 않아 수정해서 사용했다. 지금은 아기나무집님이 수정하셔서 GitHub에 올라가 있는 버전을 사용하면 될 것 같다.

Driver를 수정하다보니 ST와 HE의 차이를 찾을 수 있었다. capability에 맞춰 구성하지 않으면 기기의 기능을 제대로 사용하지 못한다.
또 ST 앱에서 device 상세화면에서 보여주던 tile 정의들이 HE에서는 무용지물이다. 코드상으로는 지원하고 있지만 이 내용이 HE web에서는 보이지 않는다. ST에서는 capability가 어떻게 되던 command와 tile을 잘 구성해두면 문제 없었다. 하지만 HE에서는 capability가 중요하다. capability의 기준으로 device의 화면에서 버튼들이 보이게 되고 추가로 command로 지정한 버튼들이 보인다.
그래서 Switch capability가 있는 기기의 경우 항상 on/off버튼이 보인다. 커튼의 경우엔 Window Shade capability가 있다. 이 capability는 on/off 대신 open/close 기능이 있다. 커튼 켜줘/꺼줘가 아닌 커튼 열어줘/닫아줘이니까.
커튼에 Switch capability를 추가해두면 on/off와 open/close버튼이 모두 보이게 된다. 열림의 정도를 조절할 수 있는 비슷한 capability가 Switch Level이 있는데 이것은 level 값으로 열림 정도를 조절하게되고, Window Shade는 position으로 조절하게 된다. 어떤 것으로 조절이 되어도 잘 되도록 driver를 구성할 수는 있다. 다만 연동되는 앱들에서 특정 capability와 연동만 되도록 구성되어 있다면 호환이 잘 되지 않을 수 있다.
(뒤에 나올 homebridge tonesto7 플러그인이 그런 이슈가 좀 있었다.)

Ezex 스위치 드라이버를 구성하면서 capability에 대해서 좀더 이해하기도 했었다. 그리고 Parent-Child 간의 연동방식도 알게 된 것 같다. Child는 실제적으로 기기로 명령을 전달할 수 없는 것 같고 Parent를 통해서만 통신이 가능한 것이다. Child는 가상의 디바이스 같은 느낌이다. 그래서 실제 기기와는 Parent와 통신이 가능한 것이다. 처음엔 Child에서 각 버튼으로 명령을 날리려고 했더니 안되어서 고생했었다.
그리고 HE가 재부팅될 때(?) Ezex의 Device network ID가 변경된다. ST에서도 그랬던 것인지는 지금으로선 확인할 수 없지만 HE 재부팅 후에 Child device가 작동하지 않길래 왜 그런가 봤더니 Parent의 DNI가 바뀌어서 Parent DNI로 연결되는 Child가 없어서 작동하지 않았던 것이다.

Beacon기기 연동은 webCore를 이용해 외부 호출이 되는 url를 따서 Webhook과 연동하였다.
Nest는 HE에서 내장 App으로 지원하고 있다. 다만 Nest 개발자 앱을 만들어 Client id와 secret을 생성해야한다. 이건 기존의 NST Manager를 사용하고 있었기 때문에 그때 사용했던 client id와 secret을 사용했다.

homebridge는 HE용으로 homebridge-hubitat-tonesto7 플러그인이 있다. ST에도 tonesto7이 구성한 플러그인이 있지만 사용하지 않았었다. pdlove보다 최근까지 유지보수된 플러그인이라 보다 더 다양한 기기들을 지원하도록 되어있다.

그리고 kuku meter/kuku harmony이다.
kuku harmony는 Parent/Child App 형태로 구성되어 있었는데, ST의 App 코드는 하나로 하여 코드 내부에서 Parent와 Child를 구분할 수 있었다. 하지만 HE에서는 불가능한 것 같다. 코드에서 정의된 App의 이름을 기준으로 찾는 것 같아서, Child를 코드 내부에서 분기하는 방식으론 Child의 이름을 찾을 수 없었다. 나머지는 큰 수정없이 사용했었던 것 같다.
kuku meter가 큰 산이었다. enertalk의 API를 직접적으로 연동하고 있어 oauth 연동을 해결했어야 한다. 이 부분은 이미 구현되어있는 Netatmo의 App을 참고하여 수정하였다. 다만 oauth callback url이 enertalk에서 일방적으로 parameter에 token을 붙여주는 방식으로 callback이 이뤄지고 있어서 중간에 중계해주는 서버를 추가했다. url주소에 parameter가 붙으면 5mango.com?access_token=abcde 이렇게 붙는다. 그 다음 parameter는 5mango.com?access_token=abcde&code=ghijk 이런식으로 이어져야 서버가 인식을 access_token과 code를 인식 할 수 있다. HE는 App으로 접근할 수 있는 방법은 반드시 access_token이 붙어야 한다. 이 방법 외에는 모두 실패이다. 그래서 기본 callback 주소가 192.168.1.1/apps/api/1?access_token=1234abcd 이런식이다. 여기에서 enertalk 인증이 성공하면 그냥 192.168.1.1/apps/api/1?access_token=1234abcd?code=token 이런식으로 callback을 요청한다. 그래서 HE에서는 access_token이 1234abcd?code=token로 인식하고 App접근을 실패하게 된다. 이 부분을 1234abcd&code=token로 되게끔해주는 간단한 코드로 중계서버를 띄워두고 연동시켰다. 나머지 부분은 수정한 부분은 크게 없다. ST앱에서 하단에 보여주던 enertalk 그래프 부분 Html tile은 삭제하였다. HE에서 미지원이다. 그리고 데이터를 polling 하는 주기를 분 단위에서 초 단위로 바꿨다.

이렇게 기존에 사용하던 모든 Device/App을 HE로 가져왔다.

지금까지 1달 정도 사용하고 있는데, 어차피 최종 연동 포인트가 Apple Home이었고, 가끔씩 사용하던 ST앱의 느린 로딩을 경험하지 않아도 되어서 후련하다. 아예 ST앱은 삭제하였다. (LTE Tracker를 위해 New ST앱은 아직 남아있다.)
로컬 접속에 대해서, 연동 초기에 Homebridge 와의 연동에 약간 문제가 있어서 가끔 밖에서 HE 웹화면을 접근해야할 경우가 생겼었는데, 이 부분은 VPN을 사용하고 있어서 외부에서 VPN 연결 후에 접속하였다. 이제는 굳이 외부에서 HE에 직접 접속할 일이 없다. 그리고 보안을 위해서, 포트 연동의 귀찮음때문에 외부접속을 가능하도록 설정하지는 않았다.
geo펜스 기능도 사용하지 않았다. 그래서 ST App에만 되는 특정한 기능에 대한 미련은 없었다.
webCore의 문자 알림은 사용하지 않았고 (문자 알림을 선호하지 않아서, 문자 발송이 되는지 모르겠다.) App의 Push 기능은 받아보고 있었는데, 이 부분은 HE에서 지원하지 않는다. 사실 자동화가 잘 이뤄졌나에 대한 확인차 Push를 받아보고 있어서 받아보기만 앱을 열어 제대로 확인하지 않았다. 이제는 자동화를 신뢰할 수준이 되어서 없어도 문제 없을 것 같다. 그리고 외부 다른 Push 전용 서비스 앱을 사용하면 가능하다지만, 굳이 Push만을 위해서 새로운 앱을 받는건 별로다. 앞으로 Push 기능이 필요하다면 개발할 텔레그램 봇으로 전달할 예정이다.
로컬 운용에 대한 스피드? 센서 반응도는 체감상 빨라진 것 같지만 정확한 판단은 불가능하다. 아무리 그래도 1초이상 차이 나진 않을 것 같으니... 이제 사용하는 장비 중에 Cloud로 연동되는 건 kuku meter, 다원 플러그, Nest, Beacon Webhook 뿐인 것 같다. 여전히 이 장비들에 대해서는 인터넷 연결에 대해 주의를 하고 있다. 그리고 기존처럼 로컬 네트워크는 항상 연결되어 있어야 하며, Apple HomeKit의 Home Hub는 장비는 항상 외부 네트워크에 연동되어 있어야 한다. 그러므로 ST와 사용할 때와 마찬가지로 네트워크 연결은 항상 필요하다.
그래도 ST의 서버 의존성을 내려놓으니 마음이 한결 편하다. 마음대로 진행하는 펌웨어 업데이트며, 서버점검... 의외로 스트레스였다.

앞으로 장비가 추가되면서 얼마나 편리해지고, 불편해질지는 모르겠다. 하지만 지금까지는 ST보다는 기분좋은 경험이었다.