Innholdsfortegnelse:

SKYMONITOR Med AWS & ARDUINO - Elektrisk gutt: 6 trinn
SKYMONITOR Med AWS & ARDUINO - Elektrisk gutt: 6 trinn

Video: SKYMONITOR Med AWS & ARDUINO - Elektrisk gutt: 6 trinn

Video: SKYMONITOR Med AWS & ARDUINO - Elektrisk gutt: 6 trinn
Video: All Sky Infrared and Visible Sky Monitor (ASIVA) 2024, Juli
Anonim
SKYMONITOR Med AWS & ARDUINO - Elektrisk gutt
SKYMONITOR Med AWS & ARDUINO - Elektrisk gutt

Det er et enkelt prosjekt - slå på lyset når noe går galt … Bli stadig nummen mot varsler med så mange dashbord på datamaskinene våre i disse dager, hvordan kan vi sikre at vi ikke går glipp av de virkelig viktige. Svaret er en fysisk statusindikator. Eller mer spesifikk for oppgaven, en Cloud Monitor, som kan sitte på skrivebordet ditt - alltid i sikte. Som navnet antyder, vil skjermen bidra til å holde et øye med helsen til skytjenestene dine (… eller noe annet egentlig, himmelen er grensen, unnskyld ordspillet). Selv du, som meg, trenger å lage en? Selv om ikke, kan du ha en idé for et fremtidig IoT -prosjekt.

Vel, hvis du er klar, la oss starte!

Trinn 1: Komponenter, rekvisita, nødvendige verktøy, apper og online service

KOMPONENTER OG LEVERANSER

_ Arduino Micro e Genuino Micro (1 enhet) … eller hvilken som helst liten Arduino -kompatibel - i mitt tilfelle en freetronics LeoStick (https://www.freetronics.com.au/collections/arduino/products/leostick)

_ ThingM BlinkM - I2C -kontrollert RGB LED (1 enhet)

_ Mini skylys (1 enhet) … eller et annet gjennomsiktig fartøy etter eget valg

_ USB-A til B-kabel (1 enhet) … eller hvilken som helst gammel USB-kabel med en type A-kontakt

VERKTØY NØDVENDIG

_ Loddejern (generisk)

APPER OG ONLINE SERVICE

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

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

Trinn 2: Maskinvare

Maskinvare
Maskinvare
Maskinvare
Maskinvare

Nattlyset kommer allerede med en innebygd LED - kald hvit i mitt tilfelle. Jeg tenkte at det ville være fint å indikere forskjellig status med forskjellige farger. Så jeg beholdt bare det skyformede foringsrøret. For hjernen til operasjonen valgte jeg den minste Arduino -kompatible jeg hadde tilgjengelig: Freetronics LeoStick har vært min foretrukne prototypeplattform i mange år, og jeg har mange reservedeler. Den leveres med gode ting: en piezo -høyttaler, to RGB -lysdioder (den ene er knyttet til strøm, RX og TX skjønt) og best av alt, du kan ganske enkelt koble den til en USB -port - ingen ekstern FTDI eller kabel er nødvendig. Det er også lite, men brødbrett kompatibelt.

Hvorfor valgte jeg ikke en ESP8266? For å være ekte trådløs kan du like godt kutte strømledningen - noe som gjør ting litt mer kompliserte for å legge til et batteri og ulempe ved lading. Siden skyskjermen vil sitte ved siden av datamaskinen min, er det mye lettere å bruke USB -strøm. Å sette opp Wi-Fi-tilkoblingen er ikke alltid rett frem. Basert på ATmega32u4, deler Arduino Micro og LeoStick det rare med I2C-data på D2 og klokke på D3. Dette blir relevant når du kobler til BlinkM RGB LED. I motsetning til de vanlige Atmega328 -kortene hvor du ganske enkelt kan koble BlinkM -skjoldet til overskriftene A2.. A5, fungerer ikke dette her (jeg brydde meg ikke om det myke I2C -biblioteket).

Ved å avlodde de mannlige overskriftene VCC og GND på BlinkM, kunne jeg deretter utvide dem med ledning og beholde alt i en liten pluggbar pakke. BlinkM har sin egen mikrokontroller ombord og gir mulighet for avanserte applikasjoner: f.eks. spille manusfargede fargemønstre uten at en Arduino er tilkoblet. Jeg føler nesten at en WS2812 (Adafruits NeoPixels er flotte) ville ha tjent meg bedre - akk jeg hadde ingen tilgjengelig. For å fullføre maskinvarebiten, kuttet jeg den motsatte enden av den mannlige type A-USB-kontakten, trådet den gjennom et forhåndsboret hull nær foten av skylyset og loddet ledningene til LeoStick (rød: 5V, hvit: Data-, grønn: Data+, svart: Ground).

Trinn 3: Løsningsarkitektur

Løsningsarkitektur
Løsningsarkitektur
Løsningsarkitektur
Løsningsarkitektur

Det eneste sterke kravet jeg påla meg selv, var å få monitoren til å kjøre bak en brannmur. Selv om det var en avgjørende funksjon, gjorde dette webkroker for hendelsesendringer upraktiske. En avstemningsmekanisme er kostbar når det gjelder TCP -trafikk og kan forsinke hendelser avhengig av avstemningsfrekvens.

Løsningen finnes i WebSockets som gir full dupleks kommunikasjon. Amazons IoT -tjeneste gir en meldingsmegler som støtter MQTT over WebSockets. Som det viser seg, kan tjenesten kalles uten å måtte konfigurere ting, skygger, retningslinjer eller regler.

Det er en SDK -enhet tilgjengelig for Arduino Yún, og det gjøres en viss innsats for å overføre SDK -en til andre plattformer som ESP8266. Men fordi skjermen alltid vil være tilkoblet med et serielt grensesnitt, bestemte jeg meg tidlig for å ha et NodeJS -program (kjørt på den stasjonære datamaskinen) for å implementere klient -API og bare bruke Arduino for å motta og vise fargekoder. På den måten kan du enkelt gjøre endringer i JavaScript, uten å måtte bry deg om opplasting av fastvare. For å teste et lite eksempel på infrastruktur er det nødvendig. La oss si at vi har en lastbalanse aktivert på tvers av tilgjengelighetssoner som utfører helsekontroller på en webserverforekomst og retningslinjer for automatisk skalering basert på CPU -belastning. Den tilsvarende CloudFormation -malen kan ▶ ️ sees i Designer eller ▶ ️ opprettes direkte fra konsollen. Merk: Noen av tjenestene i denne bunken kan påløpe kostnader.

Jeg utvidet malen med egenskaper for Lambda -funksjonen og nødvendige tillatelser. Senere må IoT REST API -endepunktet settes inn som en parameter. For å automatisere dette skrev jeg et lite skallskript som bruker CLI for å be om ARN (> aws iot beskriver-endepunkt) og deretter kaller create-stack med parameteren in-line. Eller du kan fortsatt gjøre det for hånd:

// RETRIVE IoT REST API ENDPOINT

aws iot beskrive-endepunkt

// 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_NAMEDI

// DELETE STACK> aws cloudformation delete-stack --stack-name MiniCloudMonitor

Ideelt sett burde jeg bruke de samme alarmgrensene som utløser automatisk skalering, for også å ringe til Lambda -funksjonen og på den måten oppdatere statusen til skjermen. Foreløpig er dette bare mulig når du bruker SNS som et mellomprodukt. På det tidspunktet føltes dette ekstra laget overflødig, og jeg bestemte meg for å bruke CloudWatch EC2 livssyklusregler for å ringe Lambda direkte. Likevel vil jeg utforske alternativet til SNS → Lambda i fremtiden.

Trinn 4: Programvare

Jeg begynte med å skrive Arduino Sketch. Hovedløkken () er å lese Tegn fra den serielle tilkoblingen og bygge en streng til den mottar et nytt linjetegn. Det antas da at en hex -fargekode ble sendt, og den riktige I2C -kommandoen skrives til BlinkM LED. Dette handler ikke så mye om effektivitet som bekvemmelighet. De komplette kildene for denne skissen og andre filer kan fås på GitHub. Følgende er noen relevante kodebiter:

void loop () {

mens (Serial.available ()) {

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

hvis (inChar == '\ n') {

langt tall = strtol (inputString.c_str (), NULL, 16);

byte r = tall >> 16;

byte g = tall >> 8 & 0xFF;

byte b = nummer & 0xFF;

BlinkM_fadeToRGB (blinkm_addr, r, g, b);

inputString = "";

} annet {

inputString += inChar;

}

}

}

NodeJS -appen må implementere grensesnitt til AWS og Arduino. Senere kan oppnås med bare noen få kodelinjer når du bruker den utmerkede serieportpakken:

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

baudRate: SERIAL_BAUD_RATE

});

port.on ('åpen', funksjon () {

});

port.on ('feil', funksjon (feil) {

});

Å koble til AWS IoT krever neppe mye innsats heller. Den eneste fallgropen er å vite at bruk av MQTT+WebSockets over port 443 krever autentisering via Access Keys. SDK vil lese disse fra miljøvariablene. Det kan være nødvendig å eksplisitt eksportere AWS_ACCESS_KEY_ID og AWS_SECRET_ACCESS_KEY.

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

clientId: 'MiniCloudMonitor-' + (Math.floor ((Math.random () * 100000) + 1)), region: AWS_REGION, protokoll: 'wss', havn: 443, feilsøking: sant

});

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

enhet. abonnere (MQTT_TOPIC);

});

device.on ('melding', funksjon (emne, nyttelast) {

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

var melding = JSON.parse (nyttelast);

if (message.hasOwnProperty (MQTT_JSON_KEY))

{ komme tilbake;

}

}

});

Lambda -funksjonen godtar en fargekode som en inngangsparameter - ikke pen, men veldig fleksibel på dette stadiet. For å kunne publisere til MQTT -emnet, instansierer det et IotData -objekt, som krever IoT REST API -endepunktet. CloudFormation -malen tok seg av det under opprettelsen av stabelen.

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

endepunkt: process.env. MQTT_ENDPOINT});

exports.handler = funksjon (hendelse, kontekst, tilbakeringing) {

var params = {

emne: process.env. MQTT_TOPIC, nyttelast: '{ "color \": / "' + event.colour + '\"}', qos: 0

};

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

tilbakeringing (feil);

});

};

Trinn 5: Konklusjon

Jeg likte virkelig å bringe en virtuell hendelse "født" i skyen inn i den fysiske verden. Og som mitt lille kjæledyrprosjekt var det masse moro. For å ta dette til neste nivå vil jeg vurdere …

  • forbedring av robusthet og unntakshåndtering
  • utforske bedre måter å integrere AWS -skyberegninger
  • eksperimentere med flere fysiske indikatorer som målere, søylediagrammer, …
  • har muligheten til å flytte til andre plattformer som Azure, Google, Heroku, …
  • overvåke applikasjonsspesifikke hendelser for Jenkins, GitHub, …

Jeg håper du likte å lese denne guiden og kanskje til og med tok opp noe nytt underveis. Hvis du kan tenke deg en annen/bedre måte å gjøre ting på, vennligst del den i kommentarene nedenfor. Og selvfølgelig, hvis du oppdaget feil, vil en heads up bli verdsatt. Takk for din tid.

Anbefalt: