Étape 7: Une présentation détaillée de comment cela fonctionne : Code de l’Agent
La première chose que l’agent fait lors du démarrage est de vérifier et voir si elle est juste redémarré et connaît déjà l’ID de périphérique. Chaque fois que l’agent doit aller et obtenir l’ID de périphérique de l’appareil, il l’enregistre dans le nuage d’imp avec server.save() dès qu’il obtient la mise à jour. De cette façon, si jamais l’agent redémarre, il peut saisir l’ID tout de suite sans même avoir à vérifier avec le périphérique en appelant server.load() :
Juste en dessous de cela, nous nous heurtons à une fonction géante avec une très grande chaîne multiligne dedans. Cette fonction est appelée prepWebpage, et il ne fait que concaténer plusieurs chaînes ensemble. Ces chaînes juste pour arriver à un site web. Ce site web est l’interface web pour le thermomètre BBQ, et c’est ce que vous voyez lorsque vous demandez l’agentURL dans un navigateur. Parce que l’agent a la possibilité de mettre en place son propre gestionnaire HTTP, il peut répondre à certaines demandes en servant cette chaîne très longue - fondamentalement, l’agent agit comme un serveur web minuscule. Le site web inclut même un simple javascript qui s’exécute sur l’ordinateur client.
Après le site Web, l’agent a une fonction qui conserve la trace de l’activité sur l’appareil et utilise une minuterie et quelques simples heuristiques pour déterminer si l’appareil doit aller pour dormir pour économiser la batterie.
Cela fonctionne comme le sable de coulée dans le dessus d’un sablier. Si la température change rapidement, l’agent ajoute plus de sable en haut du sablier, donnant l’appareil plus de temps pour travailler. Si le taux de variation de température ralentit, l’agent cesse d’ajout de sable, le sablier s’écoule par la suite, et l’agent indique à l’appareil d’aller pour dormir. Si la température dépasse un certain seuil, l’agent suppose que l’appareil est toujours impliqué dans faire cuire quelque chose et attend que la température baisse à nouveau avant d’envoyer l’ordre de sommeil.
Après cela, il y a un gros morceau de code dédié à travailler avec Xively. Il s’agit d’une classe générique, et vous pouvez apprendre plus à ce sujet, ainsi que d’autres classes pour travailler avec d’autres services web, de regarder par l’imp électrique page github webservices.
Ensuite, nous voyons l’agent d’inscription des gestionnaires d’événements pour les événements de l’appareil, tout comme nous l’avons vu dans le code de l’appareil. Le plus intéressant ici est le gestionnaire d’événements « temp » qui fait tout ce qu’il faut faire pour poster les nouvelles données de température à Xively et mettre à jour la fonction SLEEP :
En raison de comment cet appareil est câblé vers le haut, il en fait ne jamais déclencher l’alarme de batterie faible ; Cela a été inclus pour un dispositif similaire qui a été alimenté hors d’une paire de piles AA au lithium sans un régulateur entre les batteries et l’imp, donc l’imp pourrait se pencher directement sur la tension de la batterie. Le code a été laissé en juste au cas où quelqu'un obtient intrépide et construit l’un à l’intérieur du boîtier original !
Au bas du firmware agent, nous voyons une des parties plus importantes de l’agent : le gestionnaire de demandes HTTP. Ce gestionnaire d’analyse les requêtes HTTP entrantes et définit comment l’agent doit répondre.
La plupart des demandes à l’agent vont être demandes juste pour la page web, afin que les requêtes sans paramètres supplémentaires obtenir juste la page web comme une réponse. Il y a également un « crochet » ici pour des services extérieurs de l’imp d’aller pour dormir, de dire qui n’utilise pas la page web.
Enfin, l’agent instancie un objet de Client de Xively qu’il utilisera lors de l’exécution pour publier des données dans le flux de Xively, demande à l’ID de périphérique si nécessaire et démarre la minuterie d’endormissement :
Et c’est tout là est à lui !
Bon appetit chance et bon:)
