CLOUD MONITOR avec AWS & ARDUINO - Electric Boy : 6 étapes

2024 Auteur: John Day | [email protected]. Dernière modifié: 2024-01-30 09:08

C'est un projet simple - allumer une lumière quand quelque chose ne va pas… Devenant de plus en plus insensible aux notifications avec autant de tableaux de bord sur nos ordinateurs ces jours-ci, comment pouvons-nous nous assurer de ne pas manquer les plus importants. La réponse est un indicateur d'état physique. Ou plus spécifique à la tâche, un Cloud Monitor, qui peut s'asseoir sur votre bureau - toujours en vue. Comme son nom l'indique, le moniteur vous aidera à garder un œil sur la santé de vos services cloud (… ou quoi que ce soit d'autre vraiment, le ciel est la limite, excusez le jeu de mots). Même toi, comme moi, tu as besoin d'en faire un ? Même si ce n'est pas le cas, vous avez peut-être une idée pour votre futur projet IoT.

Eh bien, si vous êtes prêt, commençons !

Étape 1: Composants, fournitures, outils nécessaires, applications et service en ligne

COMPOSANTS ET FOURNITURES

_ Arduino Micro e Genuino Micro (1 unité) … ou tout petit Arduino compatible - dans mon cas un freetronics LeoStick (https://www.freetronics.com.au/collections/arduino/products/leostick)

_ ThingM BlinkM - LED RVB contrôlée I2C (1 unité)

_ Mini cloud light (1 unité) …ou tout autre récipient translucide de votre choix

_ Câble USB-A vers B (1 unité) …ou tout ancien câble USB avec une prise de type A

OUTILS NÉCESSAIRES

_ Fer à souder (générique)

APPLICATIONS ET SERVICE EN LIGNE

_ Amazon Web Services AWS Lambda (https://aws.amazon.com/it/lambda/)

_ Amazon Web Services AWS IoT (https://aws.amazon.com/it/iot/)

Étape 2: Matériel

La veilleuse est déjà livrée avec une LED intégrée - blanc froid dans mon cas. J'ai pensé que ce serait bien d'indiquer un statut différent par des couleurs différentes. Je n'ai donc gardé que le boîtier en forme de nuage. Pour le cerveau de l'opération, j'ai choisi le plus petit compatible Arduino dont je disposais: le Freetronics LeoStick est ma plate-forme de prototypage préférée depuis des années et j'ai beaucoup de pièces de rechange. Il est livré avec de bonnes choses: un haut-parleur piézo, deux LED RVB (une est liée à l'alimentation, RX et TX cependant) et le meilleur de tous, vous pouvez simplement le brancher sur un port USB - aucun FTDI ou câble externe n'est nécessaire. Il est également petit mais compatible avec les maquettes.

Pourquoi n'ai-je pas choisi un ESP8266 ? Pour être vraiment sans fil, autant couper le cordon d'alimentation - ce qui complique un peu les choses pour l'ajout d'une batterie et les inconvénients de la recharge. Étant donné que le moniteur cloud sera assis à côté de mon ordinateur, il est beaucoup plus facile d'utiliser l'alimentation USB. De plus, la configuration de la connexion Wi-Fi n'est pas toujours simple. Sur la base de l'ATmega32u4, l'Arduino Micro et le LeoStick partagent l'étrangeté d'avoir des données I2C sur D2 et une horloge sur D3. Cela devient pertinent lors de la connexion de la LED RGB BlinkM. Contrairement aux cartes Atmega328 courantes où vous pouvez simplement brancher le blindage BlinkM dans les en-têtes A2.. A5, cela ne fonctionnera pas ici (je ne me suis pas soucié de la bibliothèque logicielle I2C).

En dessoudant les embases mâles VCC et GND sur le BlinkM, j'ai pu ensuite étendre ceux-ci avec du fil et garder le tout dans un petit boîtier enfichable. Le BlinkM a son propre microcontrôleur à bord et permet des applications avancées: par ex. jouer des motifs de couleurs scriptés sans qu'un Arduino soit connecté. J'ai presque l'impression qu'un WS2812 (les NeoPixels Adafruits sont géniaux) m'aurait mieux servi - hélas, je n'en avais pas de disponible. Pour terminer le matériel, j'ai coupé l'extrémité opposée de la prise USB mâle de type A, je l'ai enfilée dans un trou pré-percé près de la base de la lumière du nuage et j'ai soudé les fils au LeoStick (rouge: 5 V, blanc: Data-, vert: Data+, noir: Terre).

Étape 3: Architecture de la solution

La seule exigence forte que je me suis imposée était de faire fonctionner le moniteur derrière un pare-feu. Bien qu'il s'agisse d'une fonctionnalité cruciale, cela rendait les crochets Web pour les modifications d'événements peu pratiques. Un mécanisme d'interrogation est coûteux en termes de trafic TCP et peut retarder des événements en fonction de la fréquence d'interrogation.

La solution se trouve dans les WebSockets qui assurent une communication full-duplex. Le service IoT d'Amazon fournit un courtier de messages qui prend en charge MQTT sur WebSockets. Il s'avère que le service peut être appelé sans avoir à configurer les objets, les ombres, les politiques ou les règles.

Il existe un SDK de périphérique disponible pour l'Arduino Yún et des efforts sont faits pour porter le SDK sur d'autres plates-formes comme l'ESP8266. Mais comme le moniteur sera toujours connecté par interface série, j'ai décidé très tôt d'avoir une application NodeJS (exécutée sur l'ordinateur de bureau) pour implémenter l'API client et utiliser l'Arduino uniquement pour recevoir et afficher les codes de couleur. De cette façon, les modifications peuvent être facilement effectuées dans JavaScript, sans avoir à se soucier des téléchargements de firmware. Pour tester, un petit exemple d'infrastructure est nécessaire. Supposons que nous ayons un équilibreur de charge activé sur les zones de disponibilité qui effectue des vérifications de l'état sur une instance de serveur Web et des politiques de mise à l'échelle automatique basées sur la charge du processeur. Le modèle CloudFormation correspondant peut être ▶️ visualisé dans le Designer ou ▶️ créé directement depuis la console. Remarque: certains des services de cette pile peuvent entraîner des frais.

J'ai étendu le modèle avec des propriétés pour la fonction Lambda et les autorisations nécessaires. Plus tard, exiger que le point de terminaison de l'API REST IoT soit inséré en tant que paramètre. Pour automatiser cela, j'ai écrit un petit script shell qui utilise la CLI pour demander l'ARN (> aws iot describe-endpoint), puis appelle create-stack avec le paramètre en ligne. Ou vous pouvez toujours le faire à la main:

// RÉCUPÉRER LE POINT DE FIN DE L'API REST IoT

aws iot describe-endpoint

// CREATE STACK> aws cloudformation create-stack --stack-name MiniCloudMonitor --template-body file://cfn-template.json --parameters ParameterKey=IotRestApiEndpoint, ParameterValue={IoT_REST_API_ENDPOINT} --capabilities CAPABILITY_NAMED_IAM

// SUPPRIMER LA PILE> aws cloudformation delete-stack --stack-name MiniCloudMonitor

Idéalement, je devrais utiliser les mêmes seuils d'alarme qui déclenchent la mise à l'échelle automatique, pour également appeler la fonction Lambda et ainsi mettre à jour l'état du moniteur. Actuellement, cela n'est possible qu'en utilisant SNS comme intermédiaire. À l'époque, cette couche supplémentaire semblait redondante et j'ai décidé d'utiliser les règles de cycle de vie CloudWatch EC2 pour appeler directement le Lambda. Néanmoins, je souhaite explorer l'option SNS → Lambda à l'avenir.

Étape 4: Logiciel

J'ai commencé par écrire l'Arduino Sketch. La boucle principale () lit les caractères à partir de la connexion série et crée une chaîne jusqu'à ce qu'elle reçoive un caractère de nouvelle ligne. On suppose alors qu'un code de couleur hexadécimal a été envoyé et que la commande I2C appropriée est écrite sur la LED BlinkM. Il ne s'agit pas tant d'efficacité que de commodité. Les sources complètes de ce Sketch et d'autres fichiers peuvent être obtenues sur GitHub. Voici quelques extraits de code pertinents:

boucle vide() {

while (Serial.available()) {

char inChar = (char)Serial.read();

if (inChar == '\n') {

nombre long = strtol(inputString.c_str(), NULL, 16);

octet r = nombre >> 16;

octet g = nombre >> 8 & 0xFF;

octet b = nombre & 0xFF;

BlinkM_fadeToRGB(blinkm_addr, r, g, b);

chaîne d'entrée = "";

} autre {

inputString += inChar;

}

}

}

L'application NodeJS doit implémenter des interfaces vers AWS et Arduino. Plus tard peut être accompli en quelques lignes de code en utilisant l'excellent paquet serialport:

var serialport = require('serialport');port = new serialport(PORT_COM_NAME, {

Débit en bauds: SERIAL_BAUD_RATE

});

port.on('ouvrir', fonction() {

});

port.on('erreur', fonction(err) {

});

La connexion à AWS IoT ne demande pas non plus beaucoup d'efforts. Le seul écueil est de savoir que l'utilisation de MQTT+WebSockets sur le port 443 nécessite une authentification via des clés d'accès. Le SDK les lira à partir des variables d'environnement. Il peut être nécessaire d'exporter explicitement AWS_ACCESS_KEY_ID et AWS_SECRET_ACCESS_KEY.

var awsiot = require('aws-iot-device-sdk'); var appareil = awsiot.device({

clientId: 'MiniCloudMonitor-' + (Math.floor((Math.random() * 100000) + 1)), région: AWS_REGION, protocole: 'wss', port: 443, débogage: vrai

});

device.on('connect', function() {

appareil.subscribe(MQTT_TOPIC);

});

device.on('message', function(sujet, charge utile) {

if (port && payload && topic == MQTT_TOPIC) {

var message = JSON.parse(charge utile);

si (message.hasOwnProperty(MQTT_JSON_KEY))

{ revenir;

}

}

});

La fonction Lambda accepte un code couleur comme paramètre d'entrée - pas joli, mais très flexible à ce stade. Pour pouvoir publier dans la rubrique MQTT, il instancie un objet IotData, qui nécessite le point de terminaison de l'API REST IoT. Le modèle CloudFormation s'en est occupé lors de la création de la pile.

var AWS = require('aws-sdk'); var mqtt = new AWS. IotData({

point de terminaison: process.env. MQTT_ENDPOINT});

exports.handler = function(événement, contexte, rappel) {

paramètres var = {

sujet: processus.env. MQTT_TOPIC, charge utile: '{"colour\":\"' + event.colour + '\"}', qos: 0

};

mqtt.publish(params, function(err, data) {

rappel (err);

});

};

Étape 5: Conclusion

J'ai vraiment aimé amener un événement virtuel "né" dans le cloud dans le monde physique. Et comme mon petit projet d'animal de compagnie, c'était très amusant. Pour passer au niveau supérieur, je considérerais…

• amélioration de la robustesse et de la gestion des exceptions
• explorer de meilleures façons d'intégrer les métriques du cloud AWS
• expérimenter avec des indicateurs plus physiques comme des jauges, des graphiques à barres, …
• avoir la possibilité de passer à d'autres plateformes comme Azure, Google, Heroku, …
• surveiller les événements spécifiques aux applications pour Jenkins, GitHub, …

J'espère que vous avez apprécié la lecture de ce guide et que vous avez peut-être même trouvé quelque chose de nouveau en cours de route. Si vous pouvez penser à une façon différente/meilleure de faire les choses, partagez-la dans les commentaires ci-dessous. Et bien sûr, si vous repérez des erreurs, un avertissement serait très apprécié. Merci pour votre temps.