안녕하세요. 

"생각의 웹"입니다.


지난 AppIN 세미나를 통해 소개했던 Do IoT Yourself 프로젝트를 기반으로 

thermistor 대신 온습도 센서(DHT11)를 달아 며칠 간 안방의 온습도 트랜드를 측정해 보았습니다.


먼저, 검색해 보니 계절 별로 생활하기 적정한 온/습도에 관련 내용이 있더군요.


실내 적정 온도와 습도


 지금과 같이 겨울철에는 적정온도 18~21도, 습도 40% (알레르기 비염환자의 경우 50%)라고 하는군요.



사실, 이 프로젝트를 적극적으로 시작한 계기는 

제 아내와 아이들이 알레르기 비염 증상이 있어 잠자는 도중에 재채기를 심하게 하는 경우가 많아서 입니다.

(가끔 저도 같은 증상을 겪기도 했습니다.)


비염을 예방하기 위해서 가.성.비가 탁월하다는 공기청정기를 구매해 사용하니 

방 안 먼지 때문에 나오는 재채기는 줄어 들었으나 

잠자는 도중 하는 재채기가 줄어들지 않더군요.


따라서 잠자는 도중 하는 재채기의 원인을 온,습도의 변화로 지목하고

제 때 물 갈기가 귀찮아서 사놓고 방치했던 가습기를 켠 상태에서 

방 안의 온, 습도를 모니터링하기로 결정했습니다.


다음은 날짜 별로 온습도 변경 기록 및 요약입니다.




11월 18일



- 시스템 설치 첫 날 오후 2시 경부터 온습도 기록을 시작했습니다. 온도는 23도에서 +- 2도 정도의 변화를 보였습니다. 

   보일러의 목표 온도가 22도로 맞추어져 있기 때문에 추워지면 보일러가 돌아간 것으로 보입니다. 


- 가습기의 목표 습도를 50%로 설정하고 잠자리에 들기 전부터 가동했습니다.


- 가습기를 가동한 저녁부터 습도가 34%에서 37%로 증가했습니다.

  가습기 자체에 습도계가 있어 목표 습도인 50%가 되면 습기량이 줄어들고 

  습도가 다시 낮아지면 습기량이 느는 동작을 반복합니다.


- 다행히도 가습기를 튼 당일부터 잠자는 도중 하던 재채기가 사라졌습니다. 

  적용 첫날부터 효과가 있는 걸로 보아 기침의 원인은 습도였나 봅니다. ^^




11월 19일



- 밤, 새벽 시간 온도는 22도 수준을 유지하다 낮에는 24도 수준으로 올라갔습니다.


- 가습기가 동작하던 오전 9시 경까지 습도가 36~37%를 유지하다 가습기를 끈 낮에는 34% 수준으로 떨어졌습니다.


- 가습기가 동작한 저녁 8시부터 습도가 다시 2% 정도 증가했습니다. (여전히 목표 습도는 50% 입니다.)



11월 20일


- 11월 19일과 유사한 환경에서 오전만 측정했습니다. 

   (오후에는 시스템 개선 작업을 진행하느라 잠시 꺼두었습니다. ^^a )


- 밤 12시에 24도에서 점차 떨어져 새벽 6시 경에는 21도가 되었다가 해가 뜨니 25도까지 올랐습니다.


- 가습기가 동작한 밤에는 습도가 37% 수준에서 유지되다가 아침에 가습기를 끄니 34% 수준으로 떨어졌습니다.



11월 21일


- 온도가 밤부터 새벽 시간에는 23도에서 머무르다 낮이 되니 25도까지 올랐다가 다시 밤에는 23도로 돌아왔습니다.


- 가습기가 동작할때의 습도는 35~37%, 가습기를 끄면 34%까지 내려갑니다. 

  안방의 습도는 34% 수준에서 평형을 유지하는가 봅니다. 



11월 22일


- 온도가 밤부터 아침까지 22도에서 24도로 올랐다가 낮에 25도가 되었습니다.

  그날 따뜻했는지 21일보다 1도 정도가 더 높네요.


- 습도는 가습기가 동작하는 밤에는 37%였다가 가습기를 꺼두어도 35~36% 수준을 유지했습니다.



11월 23일


- 온도가 새벽 2시부터 올라 23도에서 26도까지 올랐습니다. 아침 10시경 외출했더니 낮임에도 불구하고 23도로 내려왔습니다.


- 가습기의 목표 습도를 60%로 설정하고 동작했음에도 습도는 35~6% 수준에서 

  머물러 있습니다. 



마무으리~로 지난 시험의 결과를 요약해 보면


- 방 안의 온도가 겨울철 적정 온도(18~21도)보다 3~5도가 높아서 너무 따뜻하게 지내는 것일 수 있을 듯 합니다.

  난방비를 생각해서 희망 온도를 22도에서 20도로 줄이는 걸 고려해 봐야 겠습니다.     


- 습도는 가습기를 동작시켜도 적정 습도인 40%에는 부족한 37% 수준까지만 올라갑니다. 

  희망 습도를 60%으로 올리더라도 습도 변화에 큰 차이가 없는 걸 보니 가습기의 습도계를 믿어선 안될 듯 싶네요.

  비염 환자를 위한 적정 습도인 50%까지 올리려면 지속적으로 가습기를 켜 두어야 할 것 같습니다.


이 측정을 하기 전에는 

바닥에서 자는 아내가 새벽에 코가 시릴 정도로 춥다고 해서 난방 온도를 올리는 방향으로 결정했으나 

측정 결과, 난방 온도를 올리면 상대적으로 습도가 낮아지고 온도 차에 의한 순환 때문에 외풍이 부는 것처럼 느껴지는게 아닐까 하는 의심이 들었습니다.


따라서, 오늘 밤부터는 난방을 줄이고 가습을 더 하는 방향으로 시험해서 체감 온도를 느껴봐야 겠습니다.


이처럼 단순히 온도 (+습도)를 측량하는 간단한 D.IoT.Y 기기만으로도 작지만 의미있는 일들을 

(가정에서 부터) 시작할 수 있습니다.


여러 분들도 손쉽게 D.IoT.Y 하시면서 비용도 줄이고 건강도 챙기는 일석이조의 효과 얻기를 바랍니다.

여기까지 읽어 주셔서 감사합니다.


행복한 (그리고 건강한) 겨울철 보내시길!


  1. 파이팅건맨 2014.11.28 22:56 신고

    오울, 좋아요!

  2. 2015.01.01 12:12

    비밀댓글입니다

    • 생각의 웹 WebofThink 2015.01.01 13:10 신고

      반갑습니다. 아내되시는 분이 비염이 심하다고 하시니 처음 뵙고도 공감대가 형성되네요. 궁금하신 구현은 남겨주신 연락처로 회신드릴께요. 새해 복 많이 받으세요 ^^

  3. 2015.01.07 14:27

    비밀댓글입니다

    • 생각의 웹 WebofThink 2015.01.07 14:30 신고

      안녕하세요. 블로그를 살펴보시면 구현 방법과 코드 등이 상세히 설명되어 있는 편(?)입니다. 살펴 보시고 추가 질의하실 부분이 있다면 webofthink@tistory.com 혹은 페이스북/doiotyourself 에 남겨주세요 ^^

안녕하세요,

"생각의 웹"입니다.


혹시 지난 "AppIN 세미나 - Do IoT Yourself" 강연에 참석하시고 꾸준히 이 블로그에 방문해 주시는 분들이 계신가요?

글을 시작하기 앞서 그 분들께 먼저 감사 말씀드립니다.


이번 포스팅에는 D.IoT.Y 두 번째 강연 시 대디스랩 송영광 대표님과 함께 만들었던 온도센서를 JavaScript로 구현해보고자 합니다.

이 강연은 다음 포스팅을 참조하시기 바랍니다.


Intuitive Understanding Arduino for IoT: Do IoT Yourself 2nd



여기서 실습한 온도 센서 만들기는  Sparkfun Starter Kit for RedBoard에 내장된 센서/엑추에이터로 한정해야 했기에 가격이 저렴한 서미스터 센서(Thermistor)로 기능을 구현하기 위해 arduino IDE에서 꽤 복잡한 코딩을 해야 했습니다. 


다음 코드는 실습 당시 복사/붙여넣기 했던 코드입니다.


#include <avr/pgmspace.h>

int led_state;
unsigned long time;

#define THERM_PIN   0  // 10k thermo & 10k resistor as divider.

/*
 *  Big lookup Table (approx 750 entries), 
 *  subtract 238 from ADC reading to start at 0*C. 
 *  Entries in 10ths of degree i.e. 242 = 24.2*C Covers 0*C to 150*C 
 *  For 10k resistor/10k thermistor voltage divider w/ therm on the + side.
 */
const int temps[] PROGMEM = { 0, 1, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 14, 
    15, 16, 17, 18, 19, 20, 21, 22, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
	34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 
	52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 68, 
	69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 
	87, 88, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 
	102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 114, 
	115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 124, 125, 126, 127, 
	128, 129, 130, 131, 132, 133, 134, 134, 135, 136, 137, 138, 139, 140, 
	141, 142, 143, 143, 144, 145, 146, 147, 148, 149, 150, 151, 151, 152, 
	153, 154, 155, 156, 157, 158, 159, 159, 160, 161, 162, 163, 164, 165, 
	166, 167, 167, 168, 169, 170, 171, 172, 173, 174, 175, 175, 176, 177, 
	178, 179, 180, 181, 182, 182, 183, 184, 185, 186, 187, 188, 189, 190, 
	190, 191, 192, 193, 194, 195, 196, 197, 197, 198, 199, 200, 201, 202, 
	203, 204, 205, 205, 206, 207, 208, 209, 210, 211, 212, 212, 213, 214, 
	215, 216, 217, 218, 219, 220, 220, 221, 222, 223, 224, 225, 226, 227, 
	228, 228, 229, 230, 231, 232, 233, 234, 235, 235, 236, 237, 238, 239, 
	240, 241, 242, 243, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 
	252, 253, 254, 255, 256, 257, 258, 259, 260, 260, 261, 262, 263, 264, 
	265, 266, 267, 268, 269, 269, 270, 271, 272, 273, 274, 275, 276, 277, 
	278, 279, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 289, 
	290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 301, 302, 
	303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 315, 
	316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 
	330, 331, 332, 333, 334, 335, 335, 336, 337, 338, 339, 340, 341, 342, 
	343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 
	357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 370, 
	371, 372, 373, 374, 375, 376, 377, 378, 379, 380, 381, 382, 383, 384, 
	385, 386, 387, 388, 389, 390, 392, 393, 394, 395, 396, 397, 398, 399, 
	400, 401, 402, 403, 404, 405, 406, 407, 408, 410, 411, 412, 413, 414, 
	415, 416, 417, 418, 419, 420, 422, 423, 424, 425, 426, 427, 428, 429, 
	430, 432, 433, 434, 435, 436, 437, 438, 439, 441, 442, 443, 444, 445, 
	446, 448, 449, 450, 451, 452, 453, 455, 456, 457, 458, 459, 460, 462, 
	463, 464, 465, 466, 468, 469, 470, 471, 472, 474, 475, 476, 477, 479, 
	480, 481, 482, 484, 485, 486, 487, 489, 490, 491, 492, 494, 495, 496, 
	498, 499, 500, 501, 503, 504, 505, 507, 508, 509, 511, 512, 513, 515, 
	516, 517, 519, 520, 521, 523, 524, 525, 527, 528, 530, 531, 532, 534, 
	535, 537, 538, 539, 541, 542, 544, 545, 547, 548, 550, 551, 552, 554, 
	555, 557, 558, 560, 561, 563, 564, 566, 567, 569, 570, 572, 574, 575, 
	577, 578, 580, 581, 583, 585, 586, 588, 589, 591, 593, 594, 596, 598, 
	599, 601, 603, 604, 606, 608, 609, 611, 613, 614, 616, 618, 620, 621, 
	623, 625, 627, 628, 630, 632, 634, 636, 638, 639, 641, 643, 645, 647, 
	649, 651, 653, 654, 656, 658, 660, 662, 664, 666, 668, 670, 672, 674, 
	676, 678, 680, 683, 685, 687, 689, 691, 693, 695, 697, 700, 702, 704, 
	706, 708, 711, 713, 715, 718, 720, 722, 725, 727, 729, 732, 734, 737, 
	739, 741, 744, 746, 749, 752, 754, 757, 759, 762, 764, 767, 770, 773, 
	775, 778, 781, 784, 786, 789, 792, 795, 798, 801, 804, 807, 810, 813, 
	816, 819, 822, 825, 829, 832, 835, 838, 842, 845, 848, 852, 855, 859, 
	862, 866, 869, 873, 877, 881, 884, 888, 892, 896, 900, 904, 908, 912, 
	916, 920, 925, 929, 933, 938, 942, 947, 952, 956, 961, 966, 971, 976, 
	981, 986, 991, 997, 1002, 1007, 1013, 1019, 1024, 1030, 1036, 1042, 
	1049, 1055, 1061, 1068, 1075, 1082, 1088, 1096, 1103, 1110, 1118, 1126, 
	1134, 1142, 1150, 1159, 1168, 1177, 1186, 1196, 1206, 1216, 1226, 1237, 
	1248, 1260, 1272, 1284, 1297, 1310, 1324, 1338, 1353, 1369, 1385, 1402, 
	1420, 1439, 1459, 1480, 1502 
};


void setup() {
  pinMode(13, OUTPUT);
  Serial.begin(19200);
  time=millis();
  //Serial.println("Ready");
}

void loop() { 

  int therm;   
  therm = analogRead(THERM_PIN) - 238;
  therm = pgm_read_word(&temps[therm]);
  
  //Serial.println(therm, DEC);
  float temp = (float)therm / 10.0;
  Serial.println(temp, 1);
  
  if (millis()-time > 1000) {   
    time = millis();
    digitalWrite(13,led_state);
    led_state =! led_state;
  }
  delay(2000);
}

약간 코딩 지식이 필요하기에 실습 시에는 많은 설명이 되지는 않았지만 여기서 조금 설명하자면
 look up table를 만들어 A0에서 읽어들인 값을 table에 있는 값에 대응해서 serial로 출력하는 logic이 되겠습니다.


보시듯, 여기서 이 프로그램의 logic의 핵심은 look up table을 어떻게 만들었는가이고 

이에 대한 답변은 table를 만들기 위해서는 서미스터 혹은 하드웨어 부품들에 대한 이해가 필요하다는 것입니다. 

즉 아래의 그림처럼 서미스터의 데이터 쉬트에서 table이 도출되었습니다. (송영광 대표님이 엑셀 신공을 사용하셨다고 하더군요. ^^a) 


서미스터는 회로 구성을 어떻게 했는가에 따라 (즉, 어떤 저항을 달았느냐)에 따라 다른 값을 내어 놓습니다. 

다시 말해 이 값은 위의 그래프에서 온도 X일때의 Y값과 같은 형태로 나옵니다.

하드웨어의 경우 물리의 세계에 닿아 있기에 재료의 특성과 환경에 따라 영향을 받기에 로직 만으로 이해하고자 하는 SW 쟁이는 이해하기 쉽지 않죠.  


따라서, 사실 원하는 동작을 얻기 위해서는 arduino 회로를 적절히 구성할 뿐 아니라
arduino IDE를 이용해 관련 로직을 구현한 후 해당 프로그램(속칭 펌웨어)을  

arduino 에서 전송해 테스트해 보는 일을 반복해야 합니다.


여기서 문제는 arduino에 이 동작 외에 추가로 기능을 구현해야 할 경우, 

반드시 arduino IDE로 펌웨어를 업드레이드해 주어야 합니다. 

이는 꽤 불편한 일이 아닐 수 없습니다. 


쓰다 보니 문제 제기로만으로도 꽤 길어졌는데 이에 대해 제가 제시하는 해결책은 다음과 같습니다.


1. arduino의 펌웨어에 호스트(host)의 명령을 처리해 동작을 수행하는 인터프리터(interpreter) 를 전송합니다.


2. 호스트는 arduino에 명령을 전송합니다. (e.g. A0 포트에서 아날로그 값을 읽어 오기)


3. 인터프리터는 명령을 받아 동작을 수행 후 결과를 호스트에 전송합니다.



혹시, 이 방식을 어디선가 본 듯한 느낌을 받은 분이 있나요? ;-)

앞서 소개한 바와 같이 이 방식으로 구현된 node.js 모듈이 바로 duino 입니다.   


관련 포스팅 : http://webofthink.tistory.com/13



이번에는 duino 모듈로 이 똑같은 동작을 수행해 보도록 하겠습니다. 


먼저, 아래 파일을 다운로드 받기 바랍니다.


duino.zip

(이 모듈은 현재 버전인 v0.0.9를 조금 수정해서 DHT11 센서 지원 및 윈도우즈에서 동작하도록 수정 확장한 버전입니다. 리눅스나 OS X는 기존 버전을 써도 무방합니다.)


이 파일의 압축을 풀어 src/du/du.ino 파일을 실행합니다. 

(먼저 Arduino IDE가 설치되어 있어야 합니다. 참고바랍니다.)


해당 arduino 펌웨어를 arduino 보드에 다운로드합니다.


정상적으로 전송되면 이제 node.js로 동일한 역할을 하는 코드를 구현해 봅니다.

코드를 다음과 같이 작성해 temp.js로 저장하고 콘솔에서 node temp 로 실행합니다.


var arduinoPort = 'COM7'; // only works in windows with patched duino module.
var pinName = '00'; // it means A0 pin

// look up table for resolving data to the appropriates temperature
var temps = [0, 1, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, 14, 
    15, 16, 17, 18, 19, 20, 21, 22, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33,
	34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 
	52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 68, 
	69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 
	87, 88, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 
	102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 114, 
	115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 124, 125, 126, 127, 
	128, 129, 130, 131, 132, 133, 134, 134, 135, 136, 137, 138, 139, 140, 
	141, 142, 143, 143, 144, 145, 146, 147, 148, 149, 150, 151, 151, 152, 
	153, 154, 155, 156, 157, 158, 159, 159, 160, 161, 162, 163, 164, 165, 
	166, 167, 167, 168, 169, 170, 171, 172, 173, 174, 175, 175, 176, 177, 
	178, 179, 180, 181, 182, 182, 183, 184, 185, 186, 187, 188, 189, 190, 
	190, 191, 192, 193, 194, 195, 196, 197, 197, 198, 199, 200, 201, 202, 
	203, 204, 205, 205, 206, 207, 208, 209, 210, 211, 212, 212, 213, 214, 
	215, 216, 217, 218, 219, 220, 220, 221, 222, 223, 224, 225, 226, 227, 
	228, 228, 229, 230, 231, 232, 233, 234, 235, 235, 236, 237, 238, 239, 
	240, 241, 242, 243, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 
	252, 253, 254, 255, 256, 257, 258, 259, 260, 260, 261, 262, 263, 264, 
	265, 266, 267, 268, 269, 269, 270, 271, 272, 273, 274, 275, 276, 277, 
	278, 279, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 289, 
	290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 301, 302, 
	303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 315, 
	316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 
	330, 331, 332, 333, 334, 335, 335, 336, 337, 338, 339, 340, 341, 342, 
	343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 
	357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 370, 
	371, 372, 373, 374, 375, 376, 377, 378, 379, 380, 381, 382, 383, 384, 
	385, 386, 387, 388, 389, 390, 392, 393, 394, 395, 396, 397, 398, 399, 
	400, 401, 402, 403, 404, 405, 406, 407, 408, 410, 411, 412, 413, 414, 
	415, 416, 417, 418, 419, 420, 422, 423, 424, 425, 426, 427, 428, 429, 
	430, 432, 433, 434, 435, 436, 437, 438, 439, 441, 442, 443, 444, 445, 
	446, 448, 449, 450, 451, 452, 453, 455, 456, 457, 458, 459, 460, 462, 
	463, 464, 465, 466, 468, 469, 470, 471, 472, 474, 475, 476, 477, 479, 
	480, 481, 482, 484, 485, 486, 487, 489, 490, 491, 492, 494, 495, 496, 
	498, 499, 500, 501, 503, 504, 505, 507, 508, 509, 511, 512, 513, 515, 
	516, 517, 519, 520, 521, 523, 524, 525, 527, 528, 530, 531, 532, 534, 
	535, 537, 538, 539, 541, 542, 544, 545, 547, 548, 550, 551, 552, 554, 
	555, 557, 558, 560, 561, 563, 564, 566, 567, 569, 570, 572, 574, 575, 
	577, 578, 580, 581, 583, 585, 586, 588, 589, 591, 593, 594, 596, 598, 
	599, 601, 603, 604, 606, 608, 609, 611, 613, 614, 616, 618, 620, 621, 
	623, 625, 627, 628, 630, 632, 634, 636, 638, 639, 641, 643, 645, 647, 
	649, 651, 653, 654, 656, 658, 660, 662, 664, 666, 668, 670, 672, 674, 
	676, 678, 680, 683, 685, 687, 689, 691, 693, 695, 697, 700, 702, 704, 
	706, 708, 711, 713, 715, 718, 720, 722, 725, 727, 729, 732, 734, 737, 
	739, 741, 744, 746, 749, 752, 754, 757, 759, 762, 764, 767, 770, 773, 
	775, 778, 781, 784, 786, 789, 792, 795, 798, 801, 804, 807, 810, 813, 
	816, 819, 822, 825, 829, 832, 835, 838, 842, 845, 848, 852, 855, 859, 
	862, 866, 869, 873, 877, 881, 884, 888, 892, 896, 900, 904, 908, 912, 
	916, 920, 925, 929, 933, 938, 942, 947, 952, 956, 961, 966, 971, 976, 
	981, 986, 991, 997, 1002, 1007, 1013, 1019, 1024, 1030, 1036, 1042, 
	1049, 1055, 1061, 1068, 1075, 1082, 1088, 1096, 1103, 1110, 1118, 1126, 
	1134, 1142, 1150, 1159, 1168, 1177, 1186, 1196, 1206, 1216, 1226, 1237, 
	1248, 1260, 1272, 1284, 1297, 1310, 1324, 1338, 1353, 1369, 1385, 1402, 
	1420, 1439, 1459, 1480, 1502
];


var arduino = require('duino');
var board = new arduino.Board({
    device: 'COM7',
    debug: false //true
});



board.on('ready', function () {
    console.log("arduino board is ready to serve.");
    board.pinMode(pinName, 'in');
    
    setInterval(function () {
        console.log('request to get an analog value from ' + pinName);
        board.analogRead(pinName);
    }, 1000);
});

board.on('data', function (message) {
    // message looks like {pin}::{data}. so it will be disassembled properly.
    var m = message.slice(0, -1).split('::'),
        err = null,
        pin, data;
    
    if (!m.length) {
        return;
    }
    
    pin = m[0];
    data = m.length === 2 ? m[1] : null;

    console.log('reading value from pin' + pin + ': ' + data );
    if (pin === pinName) {        
        var converted = temps[parseInt(data) - 238] / 10.0;
        console.log('current temperature is ' + converted + ' degree of celsius');
    }
});


C:\tests>node temp.js
arduino board is ready to serve.
request to get an analog value from 00
reading value from pin00: 489
current temperature is 23.5 degree of celsius
request to get an analog value from 00
reading value from pin00: 489
current temperature is 23.5 degree of celsius
request to get an analog value from 00
reading value from pin00: 489
current temperature is 23.5 degree of celsius
^C
C:\tests>


단순히 보면 위의 코드가 앞서 arduino 펌웨어의 코드보다 더 간략해 보이지 않지만, 

이 코드는 세번 째 강연으로 진행했던 사물 간의 연결을 위한 Open API에서
다루었던 serialport 모듈의 기능을 포함하고 있습니다.

(즉 비슷한 코딩 량으로 두 가지 일을 한번에 한 것입니다.)


이외에도 앞서 문제로 제기했던 것들의 해결책으로써 

호스트에서 arduino 원격 제어와 펌웨어 업데이트 없이 추가 기능 구현이 가능해 졌습니다. 


더 나아가 이를 RESTful Web API와 JavaScript API 형태인 Open API로 재 설계한다면
웹을 통해서 아두이노를 원격 제어하는 게 가능해 집니다.


마지막으로 사족을 붙여 보겠습니다.


아래 포스팅을 통해 사물과 사물 간의 대화를 위해서는 수 많은 기술적 제약들이 현재 존재함을 말씀드린 바 있습니다.


- 사물 인터넷을 지탱하는 것 

- 사물 인터넷은 어떻게 생각하게 될까?


저는 이 장벽을 푸는 첫 번째 기술적 열쇠로 자바스크립트 언어를 바라보고 있습니다. 

이 언어를 사용하는 많은 개발자들이 존재하면서도 지적 재산권(IP) 문제에 자유롭고 계속적으로 기능이 향상되고 있기 때문입니다.


최근 뉴스에 등장한 오라클과 구글의 안드로이드에서의 자바 언어 사용 관련 특허 분쟁은 사물인터넷 시대를 맞이 할 우리에게 시사하는 점이 많습니다.

처음 기술을 개발한 세력이 개방과 공유를 빙자해 전파하더라도 나중에 가서는 그것을 사유화하려고 할 것이기 때문입니다. 


그러나 우리는 지난 사반세기 동안 이런 사유화를 막고 지구적 공동체를 만들어낸 훌륭한 사례를 본 적이 있습니다. 

따라서 웹과 arduino가 그러했듯이 오픈 소스 소프트웨어오픈소스 하드웨어가 초연결 사회로 나아가는 축으로 자리 잡길 기대합니다.


감사합니다.  


안녕하세요,

"생각의 웹"입니다.


AllJoyn Framework (이하 올조인)은 퀄컴에서 개발한 P2P 기술을 오픈 소스로 공개 후 AllSeen Alliance (이하 올신) 주관으로 리눅스 재단의 프로젝트로 진행하는 만물 인터넷 (사물 인터넷보다 한단계 더 나아간 개념입니다만 저는 아직까지는 동의어 혹은 파생어로 봅니다.  ) 프레임 워크입니다.


이 기술을 공개된 지도 일 년이 지난 것으로 기억하는데 가장 최근인 올 해 7월 IFA 2014에서 공개한 데모에 대해 정리한 포스팅이 있어 올조인에 대해 아직 문외한인 분들은 읽어 보면 좋을 것 같아 링크 공유합니다.


퀄컴 올조인으로 물꼬튼 올신의 현재 (칫솔 - 초이의 IT 휴게실)  



올조인의 가장 긍정적인 면은 처음부터 누구나 소스 코드를 사용할 수 있도록 공개하고도 더불어 다양한 플랫폼 개발자들을 위해 여러 프로그래밍 언어의 API 문서와 프로그래밍 가이드를 잘 정리해 두었다는 점입니다.


튜토리얼: https://allseenalliance.org/alljoyn-framework-tutorial



오픈소스의 영향으로 인지는 모르겠지만 간단한 검색어를 통한 구글링으로도 꽤 많은 관련 포스팅이 눈에 띄는데 아래 '바쁜척쟁이 개발자의 블로그'에 기능 별로 잘 정리되어 있는 것 같아 살펴 보시길 추천합니다.


http://busydeveloper.tistory.com/category/Alljoyn



개인적으로 아쉬운 점이자 이 포스팅을 쓰게 된 동기는  official site의 가이드에는 JavaScript API가 준비되지 않았다는 점입니다.

개발 이력을 살펴 보니 NPAPI를 이용해 browser에서 사용 가능한 API를 만들려는 시도가 있었다가 실패한 듯 하고 (github에서 관련 프로젝트가 없어졌더군요.) 
대신 아래 경로처럼  node.js를 위한 npm 모듈이 존재하는 것을 확인했습니다.


https://github.com/octoblu/alljoyn


따라서, 현재 클라이언트의 주변에서는 올조인 기기들을 찾을 수 없겠지만 node.js를 탑재한 모바일 기기나 
클라이언트와 node.js 서버가 같은 네트워크 상에 있다는 가정 하에서는 Open API를 통해 기기 간 통신이 가능할 것으로 보입니다.


각론으로 들어가면 사실 올조인의 API는 P2P 개념이 부족한 분들에게는 조금 생소할 수도 있습니다.

하는 역할인 기기 간 통신에 비해 복잡해 보이기도 하고요. 

각 인터페이스들의 역할과 상호 작용의 개념을 명확히 이해하기 위해 먼저 위의 튜토리얼을 읽어 보실 것을 권합니다.

어느 정도 동작 방식에 대해 이해 하셨나요? 아래 코드는 위의 깃허브의 샘플 코드에서 유추해서 Web IDL 형태로 간단히 정리해 본 JavaScript API 입니다.

 


typedef DOMString AllJoynAppName; 

callback SignalMessageCallback = void (DOMString message, DOMString info);
[Constructor (DOMString appName)]
interface BusAttachment {

    void createInterface(AllJoynAppName name, InterfaceDescription description);

    void registerBusListener(BusListener listener);

    void start();

    void connect();

    void findAdvertisedName(AllJoynAppName name);

   void registerSignalHandler(BusObject bus, 
       SignalMessageCallback  smcb,
       InterfaceDescription description, 
       DOMString signalType);
};

[Constructor ()]
interface InterfaceDescription {

    void addSignal(DOMString target, 
        DOMString messageType,
        DOMString message);
};

callback FoundAdvertisedCallback = void (DOMString name);
callback LostAdvertisedCallback = void (DOMString name);
callback NameOwnerChangedCallback = void (DOMString name);

[Constructor (FoundAdvertisedCallback facb, 
    LostAdvertisedCallback lacb, 
    NameOwnerChangedCallback nocb)]
interface BusListener {
};

[Constructor (DOMString busName)]
interface BusObject {

    void addInterface(InterfaceDescription description);
};

callback AcceptSessionJoinerCallback = void (unsigned short port, AllJoynAppName joiner);
callback SessionJoinedCallback = void (unsigned short port, DOMString sessionId, AllJoynAppName joiner);

[Constructor (AcceptSessionJoinerCallback asjcb, SessionJoinedCallback sjcb)]
interface SessionPortListener {
};

문서화 수준과 지원하는 OS (유닉스 계열 - OS X, linux 만 지원)이 부족한 것으로 보아 아직 신뢰할 만한 수준이 아닌 것으로 보입니다.
즉 이 모듈을 사용할 때 각자가 해야 할 삽질이 정해져 있다는 것을 의미합니다. -_-;; 


어쨌든 올신에는 꽤 많은 기기 제작업체가 가입해 있고 슬슬 호환 기기들도 출시를 앞두고 있은 것 같아 기존 레거시 시스템들과 혹은 올신에 가입하지 않는 업체들의 기기와의 대화를 위해 인터프리터 역할을 할 노드가 필요하리라고 예측합니다.

추후 좀 더 구체화된 내용이 있으면 포스팅하도록 하겠습니다.


감사합니다.


행복한 하루 되시길! 

안녕하세요,

"생각의 웹"입니다.


혹시 이 블로그에 방문한 분 중 이 블로그의 제목인 "생각의 웹"이 어디서 유래했을까 궁금했던 분이 있을까 싶습니다.

(사실 그런 건 저만의 지나친 기대에 불과하다는 걸 잘 알면서도 혹시나 해서... ^^;)


먼저 블로그의 취지를 말씀드리면 이 블로그는 웹 기술과 사물 인터넷에 대해 공유하는 목적으로 만들었습니다. 

좀 더 살을 붙여 말하자면 지난 몇 년간 기업 연구소에서 모바일 및 가전 기기를 위한 웹 기술에 대해 연구해 온 것들을 정리하고 이를 통해 멀지 않은 미래에 도래할 초연결 사회의 기술적 기반인 사물인터넷에 대해 논의하면서 함께 만들어 가고 싶었습니다.

부속 프로젝트인 Do IoT Yourself 역시 그런 맥락으로 진행된 것이고요.


질문의 답은 web of think는 internet of things의 응용 계층(application layer)에 해당하는 web of things의 발음에 유사한 점을 착안해서 만들었습니다. (이걸 맞추신 분들과는 서로 '통'하였다는 기쁨을 나누고 싶군요.  :-) )


사실 오래 전부터 '스스로 사고하는 웹'으로써 semantic web이라는 기술 영역이 존재하고 이에 관련된 많은 연구들이 진행되어 왔습니다.

주로 '정보'와 '정보'의 관계를 온토롤지(onthology)로 구축함으로써 컴퓨터가 정보의 의미(semantics)를 사고(reasoning)하는 방향으로 흘러가고 있습니다.

하지만 사물 인터넷 상에서 사물들이 서로 대화하기 위한 생각으로써는 어떨까요? 아마도 semantic web를 포함한 그 무엇인가가 더 필요하지 않을까요?


다음의 포스트는 앞서 번역한 사물인터넷을 지탱하는 것에 이어 사물 인터넷 기기들이 어떻게 생각하게 될지에 대한 내용입니다.

앞서 번역한 것과 같이 오역이 심한 번역이지만 이 글을 통해 제가 얻은 통찰을 공유하고픈 마음에 공유드립니다.  

영어 능력자 분들은 되도록 원문을 참고하시기 바랍니다. (: 


원문 : http://readwrite.com/2013/07/15/how-the-internet-of-things-will-think





사물인터넷은 어떻게 생각할 수 있게 될까?

스마트 기기들이 동일한 언어로 말할 수 있게 된다고 할지라도 사물 인터넷에는 여전히 ‘무엇을 이야기 할지’에 대한 문제가 남는다.



업체, 개발자 그리고 사용자가 스마트 기기가 보편화된 미래를 향해 나아가는 것을 소위 사물 인터넷이라고 할 때, 그들은 사물인터넷 관련 핵심 이슈들을 산더미처럼 쏟아내기 시작했습니다. 이는 어떻게 사물인터넷에 연결된 다양한 기기들이 서로 대화하게 될까에 대한 질문에서 시작합니다.

그러나 설사 이 사물인터넷에서 기기들이 동일한 언어로 대화할 수 있도록 할 수 있게끔 한다 하더라도 실제로 이 세상에서 기기들이 서로 대화할 수 있게 만들 수 있는가에 대한 더 큰 도전에 직면하게 됩니다. 


말, 말, 말 그런데 할 말이 없다.


앞서 포스팅에서 대략 언급한 바와 같이, 사물인터넷은 기기들 사이의 대화를 위해 제조업체들이 만든 다량의 상호 호환성 없는 프로토콜들에 붙잡혀 있습니다. 

이런 프로토콜들은 각기 효율적이지만 서로 상이한 언어들이죠. 그 결과 인터넷에 연결된 기기들은 서로 대화하길 원함에도 불구하고 서로 대화할 수 없습니다.

이런 대화를 막는 방해물은 궁극적으로 기업 간의 의견 수렴을 통해 정의된 표준 프로토콜로 제거할 수 있습니다. 혹은 인터프리터 역할을 하는 집중된 “공통 지식”을 만듦으로써 상호 운용할 수 없는 다수의 기기들을 상호 대화할 수 있도록 만들 수 있습니다.

 

이 문제를 이렇게 가정해 봅시다. 이제 이런 스마트 기기들 – 스마트 폰, TV, 냉장고, 자동차, 시계, 스마트 의복과 이외 어떤 기기 – 가 무엇이든 간에 대화하게 될까요? 볼품 없는 질문 같지만 이런 단순한 예가 이 문제를 해결하기에 얼마나 교묘한지를 보여 줍니다. 


거실로 다시 초대합니다.


지난 포스팅에서 소개했던 네스트 온도조절기, 스파크 내장 조명 그리고 마키타 커튼 조절기로 이뤄진 스마트 거실에서의 상상 실험으로 돌아갑시다. 각각의 기기를 원격으로 제어하는 건 가능하기에 이를 위해 이런 기기들이 보유한 다양한 센서에서 값을 직접 읽어 들여 다른 기기에게 알려줄 수 있다고 가정해 봅시다. 

온도 조절기에서는 방 안 온도와 하루 중 원하는 온도에 대한 센서 값을 알려줄 수 있습니다. 조명기기는 주변의 기기에게 자신이 켜져 있는지 여부와 방안의 조도를 알려줄 수 있습니다. 커튼 조절기는 앞서 두 기기에 비해 상대적으로 부족하지만 커튼의 개, 폐 혹은 그 정도를 알려 줄 수 있겠네요.


그래서 온도 조절기는 열심히 센서 값을 조명기기와 커튼 조절기에게 알려주겠죠. 

여기서 첫 번째 질문입니다: 도대체 이 기기들이 고려하는 바가 무얼까요? 전 은하수를 여행하는 히치하이커를 위한 안내서에 나온 살인 경악이자 Paranoid Android인 마빈이 등장하자 the Heart of Gold을 향해 가는 문이 유쾌히 열리는 시나리오를 빗대어 상상하고 있습니다. 


커튼 조절기가 방안의 온도를 아는 것이 얼마나 중요한 지 알아야 하는지를 심각하게 고민해 봅시다. (지금껏 거의 고려해 본적이 없을 겁니다.) 조명기기도 유사합니다. 만일 조명기기가 지각 능력이 있다면 커튼에 불이 붙어 집이 전소하는 절망적인 상황에서 받을 과부하를 상상할 수 있습니다. 

물론 조명 기기들에게 지각 능력이 있다면 아마도 직관적으로 현재 시각과 온도가 기본적으로 규정된 온도 값에 비해 높다는 걸 인지하고 조명을 킬 것입니다. 문제는 기기에게 이런 ‘의미’를 넘겨 줄 수 있느냐겠죠.


거실의 지식 구조


스테판 웨이츠(Stefan Weitz) 그리고 맷 월레츠(Matt Wallaert)는 두 말할 것 없는 괴짜들입니다. 내가 그들에게 말을 걸었을 때는 최신 스타트렉 영화 개봉에 앞서 Bing(Bing) 검색 엔진에 클리곤(Klingon) 언어를 추가한 엔지니어들을 위한 기념회를 막 마쳤을 때였습니다. Bing에서 일하는 행동 과학자인 월레츠는 클리곤 언어의 관용구인 콰플라(Qapla') – 성공이라는 의미 – 를 머리 속에 새겨 넣었습니다. 


괴짜 항목에 이런 단어들을 추가하는 것은 그들의 스타트랙에 대한 애정뿐만은 아닙니다. 그들은 Bing과 보편적인 검색 엔진들의 미래에 대해 깊게 생각해 본 것입니다. 그들은 구글을 걷어 찰 미래에 대해 괘념치 않고 다른 다양한 것들을 상상하고 있습니다.


이런 친구들에게는 인터넷에 연결된 기기의 숫자가 증가한다는 것은 엄청난 데이터를 생성할 플랫폼을 의미하고 Bing 검색엔진과 이를 활용할 서비스들에게 큰 기회가 있다는 의미입니다. 

“어떤 형태의 제어 기기에서든 데이터를 제공할 수 있습니다”라고 마이크로소프트의 검색엔진 수석 이사인 웨이츠가 말했습니다. 

“어떤 기기의 어떤 신호나 어떤 입력이라도요.”  


실제 많은 정보를 산출하기에는 너무 잡음이 많아서 이런 건 진짜 불협화음처럼 들립니다. 그러나, Bing 엔지니어들은 이런 기기들이 더 많은 데이터를 만들어내기 위해 만드는 엄청난 잡음들을 제거하는 데 Bing 검색엔진이 중요한 역할을 할 수 있다고 봅니다.  


웨이츠와 월레츠는 의도적으로 스마트 거실 가설에 대해 반박합니다. 

온도 조절기가 이런 것들에 관심을 두도록 프로그래밍되었다는 가정한다면, 그들이 제안했던 바처럼, 온도 조절기는 날마다 방이 점점 더 더워지는 일정 시간을 기록할 것입니다.

평소대로라면 온도 조절계는 이런 종류의 이벤트에 대한 반응으로 에어컨을 켜거나 난로를 꺼는 동작을 취할 것입니다. 

그러나 웨이츠의 제안은 방이 하루 특정 시간에 더워지는 이유를 조사하도록 온도조절계를 프로그래밍할 수 있다는 것입니다.


이것은 기기들의 현재 설계가 어떻게 바뀌어야 할지에 대한 두드러진 변화가 될 것입니다. 

온도 변화를 받아 들이는 것으로 집안의 냉/난방기를 조절하는 건 시작에 불과합니다. 온도 조절기의 목표 변수들을 넘어서서 솔루션을 찾아야 합니다.


언젠가는 월레츠가 제안한 바와 같이, 온도 조절기가 햇빛이 창문을 통해 방안으로 쏟아지는 것과 동시에 온도가 올라간다는 것이 서로 관련이 있음을 알아야 할 것입니다. 그러면 (Bing과 같은) 인터넷 데이터 플랫폼을 통해 가능한 솔루션들을 검색할 수 있을 겁니다.   


그리고 나서 이런 솔루션들을 면밀히 검토해 보고 거기서 비현실적인 것들 – 예를 들어, 반 융합(anti-fusion) 기기로 태양에 핵 공격을 가하는 것 같은 – 을 제거하고 나면 올바른 것이 도출될 수 있을 겁니다. 

그러나 한 여름에 오후 2시부터 몇 시간 동안 커튼을 치는 건 어떤가요? 

이제 이게 하나의 방안이 되었습니다. 


결국, 온도조절기는 방 안의 두꺼운 커튼을 치라는 신호를 보낼 겁니다. 

조명기기는 방안의 조도가 낮아지는 것을 확인하고 방 안에 사람이 있을 경우에만 조명을 킬 겁니다.   

하나의 사례만 보더라도 꽤 직관적임을 알 수 있습니다. 왜냐하면 사람들은 이런 솔루션을 꽤 빨리 찾아낼 수 있기 때문이죠. 


그러나 잠시 멈춰 지금껏 일어났던 일들을 생각해 봅시다. 

사람들과 인터넷에 연결된 다른 기기로의 데이터와 정보를 이용해 볼 수도 없는 온도 조절기가 연동 가능한 다른 기기로 차단이 가능한 열원의 존재에 대해 배웠습니다. 


몹쓸 스마트 온도조절기 하나


그러면 된 것 아니냐고요? 이 온도조절기는 그 배후에 인터넷 자원이 있다고 하더라도 이 기기는 말도 안되게 복잡해야 합니다. 

독립적으로 대안을 찾고 지각에 대한 인터넷의 경계에 존재하는 지식으로부터 배워야 하는 능력  때문에 말입니다.


더 유사하게는 이 온도조절기의 프로그래밍은 다음과 같이 판단 호출을 만들기 위한 제약된 조건들을 고려해야 합니다. 

먼저 지역 날씨 데이터, 주변 조도 센서 값, 전력 소모량 (아마 누군가 원격 제어가 안 되는 난방기를 돌리고 있고 있을 수 있으니까요.) 그리고 아마도 (점유 기간을 측정하기 위한) 이산화탄소 농축도에 대한 정보를 수집해야 하고 그것을 통해 냉/난방 여부를 결정하는 데 쓸 것입니다. 

만일 햇볕 좋은 날에는 커튼을 칠 것이고 만일 방 안에 많은 사람들이 있다면 에어컨을 키고 커튼은 열어 놓을 겁니다.   


이렇게 즉각적인 결정을 내리기 위해 정보를 수집하도록 프로그래밍된 어떤 기기든지 인터넷에서 이와 관련된 상관관계를 만들 수 있도록 공개된 정보로 인해 이득을 얻을 수 있게 됩니다. 웨이츠에 따르면, 데이터 과학자들은 지식 패브릭(knowledge fabric) 혹은 융합 네트워크(mesh network)로써 이런 종류의 저장소를 참고합니다. 


“이런 저장소는 완전히 새로운 정보 구조가 될 것입니다.”


웰레츠가 첨언하기를 “사물을 위한 바벨 피쉬” 처럼 동작할 데이터 변역 서비스입니다. 

변화를 가져올 정보가 필요한 기기들은 자신의 프로그래밍에 기반하여 지식 패브릭에 접속해 이에 따라 제어를 조정하게 될 것입니다.  


Bing 엔지니어로써, 지식 패브릭을 생성하는 것은 최고의 검색 결과를 찾는 것보다 원대한 목표를 의미합니다. 

웰레츠는 구글과는 다르게 Bing은 “현상을 이해하는 계층(layer)을 만드는 것”이라고 주창합니다. 

이로써 Bing은 단순히 검색 결과 대신 데이터에 행위(action)을 적용하는 기술로써 자리매김할 것입니다.


이것이 바로 사물 인터넷이 동작하게 하는 기술입니다.


명령과 제어


Zonoff의 CEO인 마이크 해리스에게 사물인터넷에 대한 개인적 견해에 대해 물었더니 그는 몇 가지 반대 의견들을 조심스레 꺼냈습니다. 

그 첫 번째로 해리스는 스마트 기기 제조업체들 간 경쟁의 합의로 하나의 지식 패브릭을 사용하기로 한다는 것을 상상하기 힘들다고 합니다. 

그들이 누구든지 기업 간 경쟁에서 경쟁 우위의 업체들은 합의를 깨뜨릴 가능성이 높습니다. 


해리스는 “현실에는 많은 수의 기업들이 ‘그들의 데이터를 소유’하고자 한다”고 말합니다.” 

그리고 그 결과에 따른 마찰은 Bing 팀이 말했던 것 같은 기술적 진보를 방해할 가능성이 있습니다.


그러나, 해리스는 사물인터넷은 어쨌든 진보할 것이라고 보았습니다. 

다양한 가전 업체들의 제품을 제어하는 스마트 홈 오토메이션 기기 업체로써 스마트 홈 영역에서 중요한 역할을 하는 Zonoff를 찾았을 때처럼 놀라운 소식은 아니겠지만요.


해리스는 기계 학습을 통한 지식 패브릭의 개념은 흥미롭지만 지금으로써는 보다 실제적인 접근법을 통해 회사를 이끌고 있다고 합니다: 홈 오토메이션 기기들을 위한 중앙 형 명령/제어 시스템을 다루는 소프트웨어 플랫폼을 만드는 것이죠. 


해리스가 Zonoff의 홈 제어 시스템을 설명하는데 사용한 비유는 Bing 팀이 Bing을 가정의 두뇌로 사용하는 것과 크게 다르지는 않습니다. 

Wi-Fi 혹은 Z-Wave (홈 오토메이션을 위해 설계된 저 대역 주파수) 표준을 통해 기기들을 네트워크에 연결하고 프로토콜을 정렬해서 관련 명령과 응답을 조율합니다.


후자는 지금껏 출시된 기기의 종류와 그 기기 간의 조합 가능성을 생각해 보면 엄청난 일이 아닐 수 없습니다. 

그럼에도 여기 약간의 영리함이 있습니다: Zonoff 시스템은 기술적 지식이 없는 집주인들이 스마트 기기를 손쉽게 프로그래밍할 수 있는데 기기를 추가 설치한 후 환경 설정을 향상할 수 있도록 보다 학습된 피드백을 사용자에게 제공하기 위해 기기 실제 사용 빈도를 모니터링합니다.


데이터 분석과 크라우드 소싱 데이터가 조합하면, 예를 들어 문을 잠그고 알람을 켜고 가전 기기들을 절약 모드로 바꾸는 “잘 자” 명령 생성이 가능합니다.

이런 시스템은 심지어 집주인의 생활 습관 – 아이들이 있나요? 애완동물은요? - 에 대해 질의해서 홈 오토메이션 시스템에 더 나은 피드백을 반영할 수 있는 관련 규칙을 적용할 수 있습니다.   


스카이넷이 도래하는가?


사물인터넷을 향한 “지식 패브릭”에 까지는 도달하지 못했다고 하더라도 Zonoff 같은 컨트롤 허브들은 이미 출시되었고 머지 않은 미래에는 홈 오토메이션 시장에서 독점하리라고 보입니다.

그러나 기계 학습을 통한 지식 패브릭에 대한 비전은 주목하지 않을 수 없습니다. 기계가 많은 것을 배우지 못했던 오랫동안 이 기술은 이 지구 상의 인간들과 관련된 반쯤만 탁월한 아이디어들을 만들어 냈습니다.


이런 연유로 이 기술을 물리쳐서는 안되나 이를 위해 해결해야 할 기술적 문제가 많다는 것은 인정해야 합니다. 

경제학자 안드류 맥아피가 최근 TED 강의에서 냉소적으로 말했던 것처럼요:


기계가 스스로 인지하게 되고 우리를 대적하여 반란을 일으키도록 결정하면서 일어나는 상황에 대한 디스토피아적인 예측은 끊임이 없습니다. 저는 이런 미래를 컴퓨터가 프린터를 인식하기 시작하면서부터 우려하기 시작했습니다.




안녕하세요.

"생각의 웹"입니다.


앞서 '사물인터넷을 지탱하는 것' 이라는 포스팅에서 다음과 같이 레인할트의 말을 인용한 바 있습니다.


"모든 기술이 정의되지 않은 상태이고 사물 인터넷에 대해 개똥 철학과 전문 용어들만이 난무할 뿐이다."


따라서 이번 포스팅에서는 사물 인터넷 기술을 정의하기 위해 인텔과 삼성이 주도하고 있는 Open Interconnect Consortium (이하 OIC) 에 대해 소개드릴까 합니다. 

먼저, OIC의 비전 영상을 하나 공유합니다.



지금까지 사물인터넷에 대해 관심을 가지고 지켜 보신 분들에게는 뻔한 시나리오겠지만 기술을 만드는 것보다 실 생활에 실현하는 것이 더 가치있는 일이 아닐 수 없기에 OIC의 비전을 과소 평가하기는 섣부를 수 있다고 생각합니다. 단, OIC라는 이름과 걸맞지 않게 공식 사이트인 http://openinterconnect.org/ 에서 관련 상세 정보를 일반인(?)들은 볼 수 없다는 점이 매우 아쉽습니다. (먼저, 다짜고자 멤버쉽부터 가입하라는데 과연 이를 너그러히 받아들일 사람 (단체 말고)은 얼마나 될까요? :-( )


따라서, 지난 9월 16~7일 개최한 삼성 오픈소스 컨퍼런스 (Samsung Open Source CONferernce - SOSCON) 에서 OIC에 관해 공개된 내용을 이 포스팅을 통해 소개드리고자 합니다.


OIC에 대해서는 인텔 측과 삼성 측에서 각각 한 세션 씩 두 번 발표했기에 두 세션을 나누어 공유합니다.


첫번째, 인텔의 David G Brenner가 발표한 내용입니다.




발표 자료:  http://soscon.net/file/(4)SOSCON_1day_tr2-4.pdf


다음은 제가 요약한 발표 내용입니다. (대부분 발표 자료에 기록된 내용이지만 요약 차원에서 도움이 되길 바라며 공유합니다. ;-) )

Complex Ecosystem requires Simplicity

- N dimension problem :

  : There is no single OS, standard, radio tech. -> very complex now -> need common framework!


Challangings 

- Unboxing & provisioning 

- Device/User Identity & Grouping 

- Discovery

- Connectivity


Create Single common Interoperable solution

- OIC will deliver Specification

- Open source reference implementation

- interoperability compliance

- build on existing standards (WiFi, bluetooth, ...)


OIC covers

- protocols for discovery and connectivity across multiple D2D (device to device) transports

- security and identity

- service-level protocols





Core Tech.

- Intel Common Connectivity Framework Concept.

  : identity (as a key in managing security)

  : discovery (abstract and aggregate radio specific tech.)

  : connection initiation and control (invitation/responder process, socket )


How developers can participate with OIC?

- Git clone code at OIC web site & contribute it

- Join as a member

- Lead work group



두 번째는 삼성전자 정진국 수석이 발표한 내용입니다.



발표자료: http://soscon.net/file/(5)SOSCON_1day_tr2-5.pdf


IoT 정의들의 공통점

- Identification

- Connection

- Communication


사물의 99%는 여전히 연결되지 않음.


IoT is Son of Internet 

- key is 'INTER'. and 'OPEN' to connect billions of devices

- "Open source & Standard" two track community 


OIC 철학

- Resource oriented architecture (based on the Principle of RESTful arch.)

- Web을 IoT에 확장 적용하는 개념 (CRUD & N (push) operation)


인텔은 CCF (Common Connectivity Framework), 삼성은 TGM (Things Graph Manager), SSM (Soft Sensor Manager), NM (notification manager)로 OIC 기여

- TGM: 기기 그룹화, 동시 제어 등을 제공

- SSM: 센서 데이터 저장 및 특정 상황에 따라 알람. 개발자의 편의를 위해 센서의 위치, 종류와 상관없이 추상화 제공

- NM: notification broker로 고사양 기기(스마트폰)을 이용


legacy,  proprietary plugin 지원을 위한 binary  plugin (*.so) 지원하는 architecture 



발표하신 정 수석님은 다음과 같이 한 줄로 OIC를 요약했습니다.

OIC는 connection among various things의 첫 걸음!


마지막으로 OIC에 대한 제 의견입니다.


첫 번째,'열기 상호 컨소시엄' 이라는 제목에 걸맞게 (저 번역은 제가 임의로 한게 아닙니다.  -_-;;  SOSCON 자료에 의거한 제목입니다.) 좀 더 열린 자세로 표준화에 임하면 어떨까 싶습니다.

아래 컨소시엄 마일스톤을 보면 빠르게 1.0을 공개하고 이후 의견을 수렴하겠다는 (사실은 표준을 주도하겠다는 뜻으로 봐야 겠지요.) 모습이 역력합니다. 이는 표준이 가져야 할 제 1 덕목인 합의성을 약화시켜 멤버쉽에 가입한 기업들조차도 OIC 표준을 기반으로 상품화 하겠다는 동기를 갖지 못합니다. 물론 퀄컴 등이 주도하는 Allseen Alliance보다 시작이 늦었기 때문에 급한 마음이 들겠지만 그럴수록 진정성을 갖춘 열린 표준으로 경쟁력을 갖춤으로써 차별화해야 할 것으로 보입니다.



지난 25년 간 웹의 성장이 보여주듯 개방과 공유를 통한 혁신은 몇몇 글로벌 업체들의 '주도한' (이라고 쓰고 '말로 만'이라고 읽습니다.) 혁신보다 인류 사회의 발전에 기여한 바가 큽니다. 이는 권력의 집중은 기술의 요구사항이 특권 계층의 필요에만 머무르게 되고 반면 다수를 차지하는 계층의 요구는 외면하게 됨으로써 필연적으로 변화의 속도를 더디게 만들기 때문이 아닌가 싶습니다. 

사물 인터넷을 통해 꿈꾸는 초 연결 사회는 (인종과 국적 및 취향이 다른) 사람들 뿐 아니라 (제조 사와 제품의 스펙, 가격 등이 다른) 사물들이 함께 어우러져 운용될 수 있는 기반에 대한 합의가 우선되어야 합니다. 


두 번째, 일정 상으로는 preview나 spec 0.5에 관련된 내용이 내부 릴리즈 된 것으로 보이나 앞서 말씀드린 바와 같이 일반 개발자에게는 공개되지 않았습니다.

따라서, 인텔이 이미 공개한 CCF (Common Connectivity Framework)를 통해 기술적 상세를 살펴 볼 수 있을 듯 한데 관련 사이트에 가보면 SDK를 받기 위해 CCF Developer Program에 동의가 필요합니다. 굳이 SDK를 다운로드 하지 않더라도 안드로이드에서 CCF 이용해 구현하기 같은 기사가 있어 살펴 보니 SDK라기 보다는 라이브러리 정도의 지원으로 보입니다. 성급한 판단이지만 이런 기술적 장벽을 추상화해서 개발자들이 손쉽게 진입하는 노력이 지속되어야 할 듯 싶습니다.


이후 OIC 외의 다른 사물인터넷 표준화 단체들의 진행 방향에 대해서도 살펴 볼 계획이지만 부디 엔지니어링 이슈에 대한 논쟁이나 옹졸한 비즈니스 정책 때문에 미래를 여는 기회를 스스로 차 버리는 오류를 범하지 않기를 바랍니다.


지금껏 읽어 주셔서 감사합니다.

행복한 하루 되시길!         



안녕하세요.

"생각의 웹"입니다.


사물인터넷에 대해 여러분들과 보다 적극적으로 소통하고자 하는 목적으로 (라고 쓰고 박인효님의 제안으로 라고 읽습니다.)
페이스 북에 팬 페이지를 개설했습니다.


https://www.facebook.com/doiotyourself 


부담없이 강연 및 소스 관련해서 궁금하신 점이나 사용 상 문제가 있는 부분 혹은 개선해야 할 점을 이곳에 공유해 주시면 지속적으로 발전시켜 나가도록 하겠습니다.

감사합니다.


행복한 하루 되시길!  

안녕하세요, 

'생각의 웹'입니다.


앞서 포스팅한 강연들의 결과물로써 만든 서비스를 아래 github에 MIT 라이센스 조건 하에 공개합니다.

(MIT 라이센스는 출처만 명확히 밝히시는 조건으로 마음껏 사용할 수 있습니다.) 


https://github.com/hyunghunny/DIoTY



이 서비스가 제공하는 기능은 다음과 같습니다.

  • 1. 현재 온도 측정 (My thermometer)
  • 2. 지금까지 측정한 모든 온도 데이터를 line chart로 도식화 (Temperature Trend)
  • 3. JavaScript API 문서
  • 4. TypeScript API 구현체
  • 5. JavaScript API 구현체

이 서비스에 대한 스크린 샷은 다음과 같습니다.


012345


이상입니다. 

감사합니다.



안녕하세요,

"생각의 웹"입니다.


오늘 저녁 강연을 마지막으로 예정된 사물 인터넷 만들기 과정의 마무리를 합니다.

사실 스스로도 강연을 통해 어떤 메세지를 던져야 하는가에 대해 고민이 많았던 중에 아래 블로그 포스팅에서 영감을 받아 에필로그 삼아 번역하여 공유합니다.

오역의 소지가 다분하니 보다 올바른 의미를 느끼고픈 분들은 아래 원문을 참고하시기 바랍니다.


http://readwrite.com/2013/06/14/whats-holding-up-the-internet-of-things    




사물 인터넷을 지탱하는 것

- 문제는 사실 상  우리가 스마트 기기들 간의 대화에 대해서는 전혀 알지 못한다는 것.


사물인터넷 – 일용품들이 똑똑해지고 연결되면서 다양한 새로운 서비스들을 만들 수 있는 – 이 교통 체증, 환경 문제 등을 해결하는 스마트 시티로의 발전에 대한 청사진을 제시합니다. 문제는 많은 과학 기술자들이나 신 기술 추종자들이 사물 인터넷에 대해 떠벌리고 일부 이미 제품 화된 것들이 있다고 해도 진정한 의미의 사물 인터넷은 존재하지 않는다는 겁니다.
확실히 데이터를 수집해서 다른 기기에게 전송하는 스마트 기기들 – 예를 들면 가정용 경보기, 카메라, 난방 센서와 비중계 같은 - 이 시장에 많이 존재합니다.
 그러나 아마 이미 알고 있겠지만 냉장고가 우유가 떨어진 걸 인식하고 자동으로 주문을 한다거나, 슈트케이스가 스스로 일정표를 확인해서 출장 건이 있으면 이에 맞는 여벌의 옷이 준비되었는지를 확인하는 등의 시나리오가 가능하게 되려면 한참은 더 기다려야 합니다.
 여기에 그 이유가 있습니다.


공용어가 존재하지 않는다.

기본적으로 인터넷은 어떤 기기와 다른 기기 간을 연결해주는 네트워크에 지나지 않습니다.
이런 연결만으로는, 이런 기기들이 서로 어떻게 대화할 지를 알게 될 것이라는 걸 의미한다 할지라도, 기기 간에 무언가를 말하게 될 것에 비하면 터무니 없이 부족합니다.
언젠가 기기 간에 대화할 수 있을 때가 된다면 이는 일반적으로 하나 혹은 이상의 ‘프로토콜’ 혹은 특정한 작업을 다루기 위한 전문화된 언어를 통해 이뤄질 것입니다.
그 중 인터넷에서 가장 유명한 프로토콜인 HTTP (하이퍼텍스트 전송 프로토콜) – 브라우저 주소 창에서 “http://”으로 시작되는 걸 봤다면 바로 그것입니다. – 은 한 번쯤은 들어봤을 겁니다.
HTTP는 컴퓨터로 다양한 파일들과 이미지 그리고 비디오를 웹을 통해 다른 컴퓨터에게 전송할 수 있게 해 줍니다.
 HTTP외에도 e-mail 전송을 위해 SMTP, POP 그리고 IMAP과 같은 프로토콜을 사용한다거나, 파일 전송을 위해 FTP프로토콜을 사용하는 것처럼 특정한 통신 목적에 따라 다양한 프로토콜들이 사용되고 있습니다.
이런 특정한 목적의 프로토콜은 일반적으로 잘 동작해 왔고 웹이 시작된 이후로 메일, FTP 서버는 보통 상호 간에 통신할 일이 거의 없었습니다. (만일 그런 일들이 필요하다면 단순 변환 S/W가 이 역할을 하겠죠.)
웹이 진화한 것처럼, 여러 개의 단순하고 안정화된 특정 목적의 프로토콜을 사용하는 것이 이런 프로토콜들을 묶어서 보다 복잡한 프로토콜로 만드는 것보다 유지하기 쉬웠습니다. 여기서부터 문제가 보일 겁니다. 사물 인터넷 상의 기기들은 아마 다양한 임무들을 수행해야 할 것이며 이를 위해 사용하는 프로토콜에 대해 합의가 전혀 없습니다. 즉 다른 말로 표현하면, 여기서부터는 대화가 안됩니다. 


클라우드 관리 시스템 스타트업 회사인 레이어 7의 제품 아키텍트인 홀거 레인할트(Holger Reinhardt)는 “모든 기술이 정의되지 않은 상태이고 사물 인터넷에 대해 개똥 철학과 전문 용어들만이 난무할 뿐이다.” 라고 말합니다.

하나의 바벨 탑

그러므로 오늘날의 초기 사물 인터넷 기기들은 사물간 직접 대화하는 것보다는 관련 개발자나 회사에 의해 제어되는 중앙 서버와 주로 대화하게 됩니다. 이는 고리타분한 방식으로 현재로써는 잘 동작하겠지만 상호간 완벽히 대화할 수 있는 기기들로만 이뤄진 분할된 여러 서브네트워크로 이끌 것이고 결국 사실 상 다른 서브 네트워크의 기기들과는 대화할 수 없게 만들 겁니다.


포드 포커스라는 차량을 예로 들죠. 이 차량은 인터넷을 통해 포드 서비스나 데이터 센터로 자신의 데이터를 보내서 완벽하게 대화할 수 있습니다.
만일 부품 교체가 필요하다면, 이 차량의 시스템이 대신 차량 소유주에게 통보하는 포드 서비스에 보고하게 됩니다. 


 그런데 주행 중 발생한 실시간 위급 상황에 대해 경고를 전파해 주고 싶다고 해봅시다.
당신이 타고 있는 포드 자동차는 다른 포드 자동차에게만 대화할 수 있도록 만들어져 있기에 주변의 혼다, 포르쉐, 테슬라 차량에게는 전파하지 못할 겁니다.
왜냐하면 이 차량은 공용어로 대화할 수 없기 때문이죠.
따라서, 예를 들어 어떤 멍청한 녀석이 90 마일 이상의 속도로 차를 몰아 아직 건설 중인 도로를 향해 달려가고 있을 때 데이지 체인(daisy-chain) 경고를 알려 주기 힘듭니다.
 이런 문제들 중의 일부는 단순히 네트워크 구조에 관한 것입니다. 즉 기기들 간에 어떤 통신 방식 – 블루투스, NFC 등- 으로 대화할 지에 관련된 것입니다.
이런 문제는 상대적으로 쉽게 바꿀 수 있습니다. 


반면 프로토콜 이슈는 사물 인터넷에 대한 직접적인 방해물이 됩니다.
왜냐하면 그 기기를 보유한 특정 업체들 간에서만 대화 가능한 사일로(silo) 형태의 기기들 때문에 인터넷을 만들지 못할 겁니다.
(단순히 사물 컴퓨서브(CompuServe) 혹은 캐치(Catchy)로 끝나겠죠. 아닐까요?)


너무나 다양한 방언들

이제 심지어 경쟁이 치열한 차량 메이커 업체 사이에서도 사업 상 유익함 때문에 하나의 공용 데이터 프로토콜이 필요하다고 인식하게 될 겁니다.
그렇다고 해서 프로토콜 문제가 해결된 것이 아닙니다.
이것은 단지 모든 신규 차량이 포함되는 큰 사일로(silo)를 만든 것 뿐이죠.
여전히 엄청난 양의 차량과 대화하고 싶으나 대화 할 수 없는 다른 종류의 기기들 (말하자면 톨 게이트의 요금 징수기부터 가스 펌프 같은)이 있습니다.
이런 기기들은 서로 다른 기기들은 알아 들을 수 없는 방언으로 대화 합니다.


인터넷에 연결된 세 가지 기기들 - 네스트(Nest) 자동 온도 조절기, 스파크 내장 조명, 마키타(Makita) 자동 커튼 조절기 - 로 이뤄진 스마트 거실 사례를 들어 좀 더 상세히 살펴 보죠.
 각각의 기기들은 데이터를 수집해서 제조사에게 보내어 그 결과 아주 제한된 동작만을 할 수 있습니다.
만일 방이 너무 덥다면 네스트는 곧 에어컨을 가동 시킬 겁니다.
또 만일 밖이 어둡다면 마키타 제어기는 커튼을 닫을 겁니다.
만일 누군가가 방안에 있고 충분히 어둡다면 스파크는 조명을 켤 수 있습니다.


혹시 일어나지 않는 것이 무엇인지 아시겠어요?
네스트, 스파크, 마키타는 서로 대화할 수 없습니다.
따라서 최선은 허브 형태의 가전 제어 시스템을 통해 이 기기들을 제어하는 겁니다.
그러나 이런 컨트롤러도 종종 가정용 TV 만능 리모컨의 설치 과정에서 발생했던 동일한 문제에 사로잡히게 됩니다.
이런 기기들이 인터넷에 연결되었는지 여부는 중요치 않습니다.
온라인이라 함은 오직 기기들 각각을 여러분의 스마트폰으로 제어할 수 있다는 의미에 불과하니까요.


엔니지어들의 범람을 탓할 수도 있겠습니다.
새로운 기술들이 표준을 채택하는 대신에 그들만의 방식을 추구하는 개발자들 사이에서 황야의 무법자 같은 태도를 불러일으키고 있으니까요.
그 결과 기기 간 대화를 위한 미친 듯이 많은 프로토콜들 – IBM의 MQTT, OMG의 AMQP 기반 DDS, RESTful HTTP, XMPP, CoAP, NanoIP 그리고 SSL - 을 보유하게 되었습니다.

솔직히, 몇 가지 다른 프로토콜 방언들이 존재하는 이유가 있습니다.
HTTP 같은 경우는 실시간 요청-응답이라는 양 방향 웹 통신 형식의 웹 서버에서 잘 동작합니다.
사물 인터넷 상의 모든 기기들이 기기 간 대화를 위해 존재하지는 않을 겁니다.
베터리로 동작하거나 신호가 불규칙하거나 약한 곳에서 동작하는 기기들은 실시간 HTTP 요청을 항상 응답할 수 없습니다.
이것이 바로 다른 프로토콜들 – 예로 하나 들면 기회가 있을 때 하나의 기기에서 다른 기기로 메시지를 전달하는 – 을 의지하려는 이유지요.
(여기에 예를 들어 MQTT가 포함된 PubSub 류의 프로토콜이 있습니다.)
여전히 이런 방언들이 사물 인터넷에 대한 새로운 도전이 되고 있습니다.


우리에게 돈을 주세요

진짜 연결된 사물 인터넷이 동작하게 만드는 유일한 방법은 레이어7의 레인할트와 같은 전문가의 언급처럼 기기 제조업체들에게 경제적 인센티브를 통해 그들이 만든 기기의 제어권과 기기가 생성한 데이터에 대한 접근권을 공유하도록 하는 것입니다.

유의미한 방법을 통해 스마트 기기간 대화할 수 있도록 하려면 엄청난 노력이 들 겁니다. 


레인할트는 공원의 스마트 쓰레기 통을 예로 듭니다.
만일 쓰레기 수거업체가 쓰레기 통에서 데이터를 받고자 할 때 (예를 들어, 통이 가득 찼는지 등) 쓰레기 통 제조업체는 먼저 수거 업체의 시스템과 쓰레기 통이 통신할 수 있는지 확인해야 합니다.
그 후, 쓰레기 통의 데이터를 접근할 수 있는 허가권을 수거 업체에게 요청해야 합니다.


오늘날에는 이 첫 번째 단계에서도 많은 시간 소요와 어려움이 많이 발생합니다.
결국 이런 비용이 쓰레기 통 소유자가 얼마나 자주 이런 과정을 무시하게끔 하는 트집거리가 됩니다.
또한 이는 쓰레기통 자체보다는 근무자들이 언제 통을 수거해야 하는지 결정하기 원하는 수거 업체로부터 해당 데이터를 얻기 힘들게 만듭니다.


이제 쓰레기 통이 쓰레기 수거 업체의 시스템과 별도로 통신할 수 있다고 가정해 봅시다.
그러면 쓰레기 통 제조업체들은 통의 버튼만 누르면 그 데이터를 누구에게나 손쉽게 전송할 수 있도록 만들 수 있습니다.
데이터 공유를 가능케 하는 절차를 쉽게 복제할 수 있다면 기기 제조업체들은 수익 추구를 위해 데이터를 공유하는데 더욱 관심을 보일 겁니다.


연결된 사일로냐 섬들의 인터넷이냐?

궁극적으로 사물인터넷은 둘 중 하나의 모습을 취하게 될 것입니다.
현재의 경향이 지속된다면 앞서 스마트 홈 사례에서 보듯 기기에서의 혹은 기기로의 데이터는 집중화된 사일로 내에 갇힐 것입니다.
결국 회사들과 업체들이 이런 사일로들을 연결하게 될 것이고 프로토콜 간의 차이를 서로 상이하게 다듬게 되겠죠.
그러면 경제적 인센티브 역시 줄줄이 일어날 겁니다.


그러나 데이터는 보다 훨씬 공유하기 힘든 형태로 남을 것이며 사일로 간의 연결을 새로 만드는데 주어진 필요만큼만 공유될 겁니다.
이런 형태는 데이터 획득을 위해 데이터는 훨씬 먼 거리를 여행해야 하고 허브에서는 혼잡을 발생시킬 수 있으므로 서비스를 지연시킬 겁니다. 
그리고 집중화된 데이터는 보안과 사생활에 관련된 우려를 일으킬 겁니다.
여전히 이런 배치가 지금 상태보다 진정한 사물인터넷에 가까울지도 모르겠습니다.


이에 반해 강력하면서 보다 보편적으로 쓰이는 프로토콜을 사물 인터넷 기기에 사용하는 것으로써 레인할트의 표현을 빌려 속칭 “섬들의 인터넷”을 만들어 낼 수 있습니다.
방 안의 기기들은 서로 직접 대화할 수 있게 되고 이런 식으로 집과 이웃집 사이에서 대화가 가능합니다.
데이터는 이런 작은 영역에서 머무르게 되며 서비스는 빨라지고 사생활은 강화될 것입니다.


이 후자 형태의 네트워크는 보다 유연하고 반응적인 사물인터넷을 의미합니다.
서로 다른 기기들과 자유롭게 대화하는 다양한 기기들을 허용한다면 자동화된 시스템이 이 세계 속에서 무슨 일들이 벌어지는 지 학습해서 사람의 필요에 맞도록 순응합니다.


현재의 나쁜 기술 경향과 근시안적인 경제 정책이 사물인터넷을 올바른 방향으로 이끌지 못하고 있습니다.

안녕하세요,

'생각의 웹'입니다.


4주 차에 걸쳐 진행된 직접 IoT 만들기(Do IoT Yourself!) App In 세미나가 이번 주 금요일(2014년 10월 24일)을 마지막으로 대장정의 마무리를 내립니다.


짧지 않은 시간동안 평일 저녁과 주말을 포함해 여러 회에 걸쳐 진행된 강연이였기에 참석조차 쉽지 않으셨을 텐데 빠지지 않고 참석해 주신 분들께 감사드립니다.

강사 또한 참석자 분들의 배움의 열정에 감탄을 금치 못했으며 가르침을 통해 배움 못지 않은 많은 깨달음을 얻었습니다. 



이번 마지막 강연에서는 지난 3주 차 강연에서 만들어 본 RESTful Web API를 손쉽게 사용할 수 있도록 JavaScript API로 만들어 보고 이 API를 이용해서 현재 온도를 알려주는 온도계와 지금까지의 온도 변화를 보여주는 경향(trend) 그래프(graph)를 google chart API를 이용해 만들어 봅니다.



지난 번 강의 시, 제가 시간 관리를 제대로 하지 못해 다음 예정된 강의에 지장을 초래할 정도로 지연되었는데 

부디 이번 강의에서는 제 시간에 끝났으면 합니다.

(그런데 초안 슬라이드를 작성해 보니 2시간 내에 제대로 다루기에는 벅찬 느낌이 들기도 하네요. ^^;; )


마지막으로 다시 한번 매 강연마다 호평을 아끼지 않으시고 적극적으로 참여해주신 참석자 분들께 다시 한번 감사의 말씀 전합니다.

또한 강연 자리를 마련해 주시고 값 비싼 아두이노 호환 보드 세트를 원가에 못 미치는 가격에 참석자 분들께 제공해 주신 AppCenter 분들께도 감사드립니다.


제 소망은 초 연결 미래 사회를 향한 이 작은 발걸음들을 통해 새로운 통찰을 얻고 비즈니스에 적용하여 미래를 만들어 가는 분들이 등장하는 것입니다.

사물 인터넷의 시대, 여러분들의 아이디어를 직접 만들어 평가하고 공개하고 개선해서 멋진 서비스로 발전시켜 가시길 바랍니다!


P.S. 이 모든 자료는 크리에이티브 커먼스(Creative Commons) 3.0에 의거하여 출처를 밝히는 조건 하에서 자유롭게 사용하실 수 있습니다. 

P.S. 2. github에 공개한 DIoTY 코드에 대한 설치 가이드자주 나온 질문들을 링크와 같이 정리했습니다. 참고하시기 바랍니다.

 

안녕하세요, 

생각의 웹입니다.



지난 2번의 Do IoT Yourself 세미나에 이어 오는 10월 18일에 발표할 세 번째 강연의 슬라이드를 아래와 같이 선 공개 합니다.

혹시 참석하지 못하신 블로거 분들은 지난 세미나 관련 정보를 아래 링크를 통해 확인하실 수 있습니다.




이번 강의에서 다룰 내용은 웹을 구성하는 기술들에 대한 배경 지식과 개념들이 필요하기 때문에 이 분야에 경험이 전무하신 분들에게 조금 난해할 수 있겠다는 생각을 합니다. (특히 프로그래밍 경험이 전무한 비전공자 분들에게는요.)

이 자료의 초기 버전 (initial draft version)을 지인에게 공유했을 때에도 이해하기 힘들다는 피드백이 있어 개념을 전달하기 위해 몇 장의 슬라이드를 추가 보강했습니다.

혹시 자료를 보시고 난해한 부분이 있다면 댓글로 의견 주시면 추가 반영하여 보다 이해하기 쉽도록 개선하겠습니다.

(강의 중 Q&A 로 슬라이드에 잘 표현되지 않은 부분이 있다는 의견이 있어 추가 반영한 버전으로 슬라이드를 교체했습니다. ;-) )


짧은 시간에 내용을 제대로 전달하는데 무리가 있을 것 같은 우려에도 불구하고 이 내용을 포함시키고자 하는 이유는 이것이 사물 인터넷의 핵심 중 하나이기 때문입니다.

많은 미래학자들이나 관련 연구를 하시는 오피니언 리더 분들의 의견을 들어보면 사물 인터넷은 '사물'이 아닌 '인터넷'에 주안점을 두어야 하기에 특히, 다양한 사물 간의 대화를 가능케 하는 표준화된 인터페이스(interface)와 API의 중요성을 강조합니다.


History Does Not Repeat Itself, But It Rhyme


역사는 스스로 반복되지 않지만 운율이 있다는 뜻입니다.


이 격언을 인용한 이유는 인터넷을 보급한 핵심 서비스는 다름 아닌 웹이였고 웹의 HTTPURLHTML 세가지 기술은 전 세계 사람들을 연결하는 데 그 역할을 훌륭히 해 냈습니다. 따라서 사 반세기를 통해 검증되고 보급된 이 웹 기술들이 이제는 그 운율이 되어 사물 간, 그리고 만물 간의 인터넷에도 적용될 것이라는 기대와 확신이 저에게는 있습니다.


또한 여기서 설명하고 있는 RESTful Web API는 웹 서비스를 위해 도입된 다소 무겁고 폐쇄적인 WS-* 기술이 아닌 기존의 HTTP만으로도 웹 서비스가 가능하도록 만든 API 설계 원칙이고 이런 하위 호환성의 장점을 기반으로 사람 뿐 아니라 기계가 이해하고 사용할 수 있는 형태의 hypermedia API로 진화하는 중에 있기에 그 미래가 밝다라고 봅니다.


REST API에 대한 보다 기술적이고 자세한 내용이 궁금하신 분들은 이 블로그의 다음 포스팅을 참고하시기 바랍니다.



가진 지식을 나누며 생각을 키워 가는 것이 참 즐거운 일임을 오프라인 세미나를 통해서 다시 깨닫습니다.
온라인에서도 다양한 블로거 분들과 즐겁게 소통하며 함께 성장해 나가길 기대합니다.


읽어 주시고 관심가져 주셔서 감사합니다.

행복한 하루 되시길!


P.S. github의 DIoTY 프로젝트에 대한 설치 가이드자주 나온 질문들을 위키 페이지로 정리했습니다. 참고하시기 바랍니다.

+ Recent posts