Paso 7: Una mirada más de cerca cómo funciona: código de agente
Lo primero que el agente hace cuando arranca para arriba es comprobar y ver si se reinicia solo y ya sabe el ID de dispositivo. Cuando el agente tiene que ir y obtener el ID del dispositivo desde el dispositivo, guarda en la nube de imp con server.save() tan pronto como consiga la actualización. Así, si el agente siempre se reinicia, puede tomar el ID de inmediato sin necesidad de comprobar con el dispositivo llamando al server.load():
Justo debajo de esto, llevamos a cabo en una función gigante con una cadena muy grande de varias líneas en él. Esta función se llama prepWebpage, y todo lo que hace es concatenar cadenas unos juntos. Estas cadenas tan resultan ser un sitio web. Este sitio web es la web UI para el termómetro de la barbacoa, y es lo que se ve cuando se solicita la agentURL en un navegador. Porque el agente tiene la capacidad para configurar un controlador HTTP, puede responder a ciertas peticiones por que esta muy larga cadena - básicamente, el agente actúa como un servidor web pequeño. El sitio web incluye incluso un simple javascript que se ejecuta en el equipo cliente.
Después de la página web, el agente tiene una función que realiza un seguimiento de actividad en el dispositivo y utiliza un contador de tiempo y algunas heurísticas simples para averiguar si el dispositivo debe ir a dormir para ahorrar batería.
Esto funciona mucho como verter arena en la parte superior de un reloj de arena. Si la temperatura está cambiando rápidamente, el agente agrega más arena a la cima del reloj de arena, dando el dispositivo más tiempo para trabajar. Si disminuye la tasa de cambio de temperatura, el agente deja agregar arena, el reloj de arena acabe finalmente, y el agente le dice el dispositivo para ir a dormir. Si la temperatura está sobre cierto umbral, el agente asume que el dispositivo está todavía involucrado en algo de cocina y espera a que la temperatura disminuya otra vez antes de enviar la orden de dormir.
Después de esto, hay una gran parte del código dedicada a trabajar con Xively. Se trata de una clase genérica, y puede aprender más sobre ella, así como otras clases para trabajar con otros servicios web, por echar un vistazo a electric imp webservices página de github.
A continuación, vemos al agente registrando algunos controladores de eventos para los eventos del dispositivo, tal como vimos en el código anterior. Lo más interesante aquí es el controlador de eventos "temp", que hace todo lo tiene que hacer para publicar los nuevos datos de temperatura para Xively y actualización del temporizador:
Debido a cómo está cableado este dispositivo, realmente no siempre disparará la alarma de batería baja; Esto fue para un dispositivo similar que fue impulsado en un par de pilas AA de litio sin un regulador entre las baterías y el imp, por lo que el imp podría ver directamente el voltaje de la batería. El código quedó por si acaso alguien se intrépido y construye uno dentro de la caja original!
En la parte inferior del firmware agente, vemos una de las partes más importantes del agente: el controlador de solicitudes HTTP. Este controlador procesa las solicitudes HTTP entrantes y define cómo debe responder el agente.
La mayoría de las peticiones al agente van a ser las peticiones para la página web, para las solicitudes sin parámetros adicionales a la página web como respuesta. También hay un "gancho" aquí para servicios externos a la imp para ir a dormir, que no utiliza la página web.
Por último, el agente crea una instancia de un objeto de cliente Xively que utilizará en tiempo de ejecución para publicar datos en la secuencia de Xively, pide el ID del dispositivo si es necesario y comienza a ejecutar el temporizador:
Y eso es todo allí está a él!
Buena suerte y bon appetit :)
