SilverLight: Monitor ambiental basat en Arduino per a sales de servidors: 3 passos (amb imatges)

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:13

Un cop em van donar la tasca de buscar una sonda ambiental per controlar la temperatura a la sala de servidors de la meva empresa. La meva primera idea va ser: per què no utilitzar un Raspberry PI i un sensor DHT, es pot configurar en menys d’una hora, inclosa la instal·lació del sistema operatiu. Per a això, vaig rebre la freda resposta de la gent amb els ulls embenats que no ho farem perquè costaria més en hores de treball configurar-lo que comprar un dispositiu. Haver d’acceptar persones de mentalitat estreta com aquesta durant una part de la meva vida va ser una cosa i vaig demanar una brossa EATON de qualitat empresarial a Ebay i trucar-la, però en aquell moment vaig decidir que per a la meva pròpia sala de servidors construiré un Arduino de codi obert completament basat en un dispositiu que serà molt millor del que acabo de demanar.

Aquest projecte es diu SilverLight, no em pregunteu d’on treuen aquests noms:) Acabo de mirar la caixa de mitjà acrílic brillant i vaig decidir amb aquest nom, no té res a veure amb el producte microhoof del que vaig saber després.

Pas 1: disseny de maquinari

Visió general del maquinari comercial.

D'acord, així que ni tan sols començo amb la gran idea de la qual era posar un monitor d'entorn dins d'una empresa, però òbviament hi ha un mercat, així que anem a veure què poden fer:

COMPATIBILITAT del dispositiu de control ambiental

La xarxa de 10/100 MB-MS, PXGUPS, PXGPDP i PXGMS.

El ConnectUPS-X de 10 / 100Mb, el ConnectUPS-BD i el ConnectUPS-E amb FW V3.01 i versions posteriors. DIMENSIONS (LXWXH)

2,26 x 1,48 x 1,15 (polzades) 57,6 x 37,6 x 29,3 (mm) PES

34 g

És una informació molt útil, oi? No us preocupeu perquè no poden fer gran cosa. Fins i tot per començar, el vostre SAI haurà de tenir una altra targeta complementària que connecti això amb el sensor ambiental que compreu per separat, normalment amb un cable CAT5 estàndard (ni tan sols intenteu connectar res al port perquè no hi ha res estàndard sobre això). Afirmen que el dispositiu necessita 10 minuts per "escalfar-se", que en realitat passaven hores i, un cop ho va fer, va aparèixer a la seva interfície java que s'actualitzava lentament i tenim temperatura i humitat. Establir condicions basades en alertes va ser fàcil a partir d’aquest moment, però a qui li importa construïm alguna cosa millor.

Aquest projecte és una conjunció de múltiples dels meus projectes: estació meteorològica Natalia, Shadow of phoenix. El quadre pot supervisar les restriccions ambientals següents:

• Índex de temperatura / humitat / calor
• Concentracions de GLP, fum, alcohol, propà, hidrogen, metà i monòxid de carboni a l'aire (MQ2)
• Sensibilitat solar (la llum està encesa a la sala de servidors?)
• Sensor de moviment PIR (fins i tot podeu encendre / apagar els llums automàticament a partir d’ara gràcies al sensor de moviment quan algú entra a l’habitació)

Totes aquestes dades es mostren molt bé en una pantalla LCD i es retransmeten a un ordinador (Orange PI Zero) per a processos i alertes posteriors. Tot i que seria possible connectar directament a sensors digitals com el DHT i el pin digital del MQ2 a l’OrangePI, sempre prefereixo utilitzar micros dedicats per a aquestes tasques i quan calgui actualitzar la pantalla LCD i fer altres nivells de baix nivell coses, l'Arduino és immillorable i pot funcionar de manera fiable sense parar durant molts anys (de fet, no m'ha fallat cap Arduino que funciona 24/7). L’OrangePI amb les seves deficiències (diguem-ne, és un ordinador de 10 $), com a inutilitzable per a càrregues de treball pesades, sense compatibilitat amb BSD, el wifi integrat està inflat, etc.

Es tracta d’un projecte de maquinari molt senzill que requereix els components següents:

• Arduino PRO Micro
• Pantalla LCD 2x16 caràcters RGB
• Mòdul d'alimentació de commutador aïllant AC-DC 220V a 5V HLK-5M05 (són molt bons per a projectes Arduino / ESP), aquesta és la versió 5V / 5W.
• Resistències de 2x300ohm
• 2xleds (vermell / verd)
• Sensor de moviment PIR
• Sensor MQ2
• DHT22
• LDR
• Resistència de 2X10Kohm
• Zumbador
• Taronja PI Zero
• cable de dades mini USB

Ni tan sols em vaig molestar a fer un PCB per a aquesta placa de pa normal, que només s'utilitzava perquè els components es poden connectar simplement a l'Arduino (vegeu les imatges adjuntes):

-DHT22 requerirà una extracció de 10 K a VCC (digital)

-LDR requerirà un desplaçament de 10 K a GND (analògic)

-MQ2 es pot connectar directament a qualsevol pin analògic (analògic) <prefereixo utilitzar analògic perquè per què no quan tenim una MCU amb pins analògics on podem obtenir el valor exacte en lloc d’ajustar una mica de pot a la part posterior del dispositiu per obtenir HIGH o BAIX d’això, a causa de l’encolat del meu disseny que de totes maneres és inaccessible. Comproveu:

-PIR es pot connectar directament a qualsevol pin (digital)

-LCD: es pot accionar amb 4 pins, es pot connectar a qualsevol pin (digital) necessitarà +2 RS / E (digital)

-Buzzer: es pot connectar directament a qualsevol pin Arduino (digital)

El pinout que he utilitzat es pot veure al codi. Connectar-ho tot junt després d'això és bastant senzill, també podeu fer-los un per un, assegureu-vos que 1 sensor funcioni perfectament i, a continuació, procediu al següent. / gnd per a un sensor, fins ara això mai va matar cap dels meus dispositius). El que voldria assenyalar aquí que hi havia massa VCC i GND apilats per a mi, no els podia passar per una tira terminal, així que els vaig soldar tots.

No us oblideu dels altres projectes sobre els DHT: si poseu la biblioteca DHT al vostre codi i el sensor DHT no està connectat o no està connectat DHT incorrecte (per exemple, 11 definit en el codi que esteu utilitzant 22) que pot conduir al programa per penjar per sempre al principi.

Quant als sensors de detecció de moviment PIR, com podeu veure a la meva imatge, hi ha un munt de falsificacions falses, fins i tot em costaria comprar-ne un de genuí a Ebay. Les falsificacions funcionen igual de bé, fins i tot a la llarga, però tenen el circuit reflectit, cosa que fa que es inverteixin els pins + i -, també són fàcils de reconèixer: vénen amb un PCB blau que no és el verd habitual, falten les etiquetes per a els potòmetres. Vaig tenir la sort de trobar un autèntic a la meva caixa, en cas contrari, canviar la posició cobriria els dos leds per a mi. He comprovat que ambdues olles s’estrenyen fins a la meitat del camí. Això us proporcionarà un abast prou llarg per a la detecció, també quan hi ha moviment, la cama digital es mantindrà en posició ALTA durant aproximadament un minut, de manera que no haureu de compensar el codi. A les falsificacions és fàcil determinar quin costat és el - i + només cal mirar les potes corresponents per als taps electrolítics connectats als passadors.

Per tallar la caixa he utilitzat un cap de dremel de diamant (que era un excés però va funcionar molt bé) i una perforadora regular. Aquestes caixes de connexió són fàcils de treballar i, tot i que no m’agrada enganxar, no tenia cargols i cargols a l’hora de construir-ho, així que vaig prendre la possibilitat d’enganxar coses (que també es poden escalfar fàcilment i desmuntar-les més tard utilitzant el mateix gluegun sense filament).

Pas 2: disseny de programari

El codi Arduino també és senzill, bàsicament treu totes les lectures del sensor al principi de cada bucle. Encén els LED si hi ha moviment o fum i també reprodueix un so d'alarma al brunzidor si hi ha fum (aquest és l'únic codi de bloqueig, per tant, el vaig fer curt), després mostra les dades a la pantalla LCD i finalment les envia a l'ordinador amb un període de retenció de 10 segons, per no inundar el port.

Aquest projecte utilitza una comunicació unidireccional des d’Arduino-> OrangePI, no hi ha cap tipus d’ordres implementats. Tot i que això seria perfectament possible, com ho vaig fer en un dels meus altres projectes, on l’ordinador pot enviar LCD_PRINT1 o LCD_PRINT2 per sobreescriure una línia de la pantalla LCD amb el seu propi missatge (per exemple: adreça IP, temps d’activitat, data del sistema, etc.). l’ús de la CPU), l’àrea de la pantalla és tan petita per mostrar dades de 3 sensors que ni tan sols em vaig molestar. Els valors SOL i SMK poden pujar fins a 4 dígits 0000-1023 i ocupen ja 8 personatges valuosos a la pantalla.

Amb la pantalla LCD podeu notar un petit truc al codi que després de cada valor mesurat s’aplica una impressió d’espais en blanc (""), i després moc el cursor a posicions fixes per col·locar les noves icones i dades. Hi ha perquè la pantalla LCD no és tan intel·ligent per entendre els números, només dibuixa el que obté i, per exemple, si teniu un valor solar de 525 que de sobte va disminuir a 3, es mostrarà 325 deixant la brossa vella a la pantalla allà.

Un codi de control C que s’executa a l’OrangePI i registra les dades ambientals i envia alertes per correu electrònic quan calgui.

OrangePI està executant Armbian (que en el moment d’escriure es basa en Debian Stretch). Inclouré això a la part del programari pel que fa a un problema de gran resolució. Aquests són els consums mitjans d’energia del dispositiu:

0,17 A: només Arduino + sensors

0,5-0,62 A - Arrencada OrangePI

0,31 A - Taronja PI al ralentí

0,29 A - Orange PI apagat (realment no el pot apagar, no té ACPI ni res per l'estil)

0,60 A: prova d’esforç: 100% d’ús de CPU en 4 nuclis

Fa temps que tenia aquest OrangePI en una caixa. Amb el nucli vell, el dispositiu esgotava tanta intensitat (ja que el mesurador deia que arribava a un punt màxim de 0,63 A), el que la PSU probablement no podia proporcionar perquè simplement no s’iniciés, el procés d’arrencada estava atrapat i vaig aconseguir que els dos leds ethernet s’encenguessin. constantment i sense fer res.

Ara això és una mica molest, ja que l'HLK-5M05 afirma que pot fer 5W en 5V, cosa que permet proporcionar 1 Amp, però amb aquests dispositius que surten de la Xina no se sap, el pic de 0,63 A era molt inferior al màxim nominal valor. Per tant, estava executant proves de reinici senzilles, a partir de 10 reinicis, l’OrangePI només s’arrencaria dues vegades amb èxit, cosa que gairebé em va fer llançar-lo del projecte, ja que no m’agrada el comportament incoherent dels circuits. Així que vaig començar a buscar en Google, potser hi ha una manera de reduir el consum d’energia en arrencar des del programari (ja que aleshores només era un problema) i vaig trobar algun article parlant de modificar el script.bin, però era per a l’Orange PI PC i el faltaven fitxers a l'emmagatzematge, de manera que, com a últim recurs, he fet la màgica "actualització apt" per actualitzar el firmware, el nucli i tota la resta, amb l'esperança que s'esgoti menys i que el dispositiu pugui arrencar i:

Linux silverlight 4.14.18-sunxi # 24 SMP Div. 9 de febrer 16:24:32 CET 2018 armv7l GNU / Linux

Linux silverlight 4.19.62-sunxi # 5.92 SMP Wed Jul 31 22:07:23 CEST 2019 armv7l GNU / Linux

Ha funcionat! Llançar maquinari a un problema de programari sol ser un mandrós desenvolupador de Java, però en aquest cas hem resolt un problema de maquinari amb programari, tot un èxit. He fet com 20 proves de reinici més que el dispositiu arrencava en cada cas. Tot i així, recordo que la pujada de potència en activar l'Opi (connectar / desconnectar) és tan gran que restablirà l'Arduino en qualsevol moment (un simple reinici només parpellejarà la pantalla LCD però no causarà més problemes), però aquest problema continua sent amagat ja que el 2 s'arrencarà junt.

També he vist els mòduls del nucli:

usb_f_acm u_serial g_serial libcomposite xradio_wlan mac80211 llima sun8i_codec_analog snd_soc_simple_card gpu_sched sun8i_adda_pr_regmap sun4i_i2s snd_soc_simple_card_utils TTM sun4i_gpadc_iio snd_soc_core cfg80211 snd_pcm_dmaengine industrialio snd_pcm snd_timer SND sun8i_ths soundcore cpufreq_dt uio_pdrv_genirq UIO thermal_sys pwrseq_simple

Què necessitem realment? D'acord, el pwr i el termal poden ser útils, però el so, el port sèrie, el wifi (hw ja trencat) no necessitem tots aquests es poden incloure a la llista negra. També crearé un nucli personalitzat amb els mòduls necessaris més endavant.

El que necessitem i no es carrega per defecte és que el CDC ACM es comuniqui amb l'Arduino, activeu-lo amb:

echo "cdc-acm" >> / etc / modules

Després d'això, ja podeu provar la connexió amb:

screen / dev / ttyACM0 9600

Hauríeu de veure les dades d’estat que s’envien cada 10 segons.

Alertes i seguiment

A partir de les alertes, acabo de posar trucades system () al codi de control C que rep les dades de sèrie, de manera que no calen eines externes. Alguns exemples d'alertes:

- La temperatura supera els 30 ° C

- La humitat supera el 70% (no és saludable per als servidors)

- Moviment detectat a la sala (això pot resultar molest si continueu a la vostra sala de servidors)

- S'ha detectat fum o gas (les alertes de més de 100 es poden prendre seriosament, he jugat amb aquest sensor i s'encén per moltes coses, per exemple, crear fum al costat del sensor amb soldador va resultar una mica més de 50 mentre es fumava cigarreta) o va augmentar fins a 500, fins i tot va detectar gas del desodorant normal de lluny)

Per conservar les dades històriques no em vaig molestar a desenvolupar una eina perquè per què reinventar la roda quan aconseguim excel·lents marcs de control. Mostraré un exemple de com integrar-ho al meu favorit personal, Zabbix:

apt-get install zabbix-agent

Afegiu-lo al final de: /etc/zabbix/zabbix_agentd.conf

UserParameter = silverlight.hum, cap -1 /dev/shm/silverlight-zbx.log | awk -F "," '{print $ 1}'

UserParameter = silverlight.tmp, cap -1 /dev/shm/silverlight-zbx.log | awk -F "," '{print $ 2}' UserParameter = silverlight.sol, cap -1 /dev/shm/silverlight-zbx.log | awk -F "," '{print $ 4}' UserParameter = silverlight.mot, cap -1 /dev/shm/silverlight-zbx.log | awk -F "," '{print $ 5}' UserParameter = silverlight.smk, cap -1 /dev/shm/silverlight-zbx.log | awk -F "," '{print $ 6}'

Executant zabbix_agentd -p hauria de retornar ara els valors adequats:

silverlight.hum [t | 41]

silverlight.tmp [t | 23] silverlight.sol [t | 144] silverlight.mot [t | 0] silverlight.smk [t | 19]

L’índex de calor, el recullo, però no en veig cap ús pràctic, de manera que només queda registrat. Al codi de control C he implementat 2 funcions de registre, la primera registrarà totes les dades en format fàcil d'utilitzar:

[SILVERLIGHT] Dades rebudes el 10-09-2019 23:36:08 => Humitat: 44, Temp: 22, Hola: 25, Solar: 0, Moviment: 0, Fum: 21

[SILVERLIGHT] Dades rebudes el 10-09-2019 23:36:18 => Humitat: 44, Temp: 22, Hola: 25, Solar: 0, Moviment: 0, Fum: 21 [SILVERLIGHT] Dades rebudes el 09-09-2019 -10 23:36:29 => Humitat: 44, Temp: 22, Hola: 25, Solar: 0, Moviment: 0, Fum: 22 [SILVERLIGHT] Dades rebudes el 10-09-2019 23:36:39 => Humitat: 44, temperatura: 22, alta: 25, solar: 0, moviment: 0, fum: 21

El segon:

void logger2 (caràcter * text) {

FITXA * f = fopen ("/ dev / shm / silverlight-zbx.log", "w"); if (f == NULL) {printf ("Error en obrir el fitxer de registre de memòria! / n"); tornar; } fprintf (f, "% s", text); fclose (f); tornar; }

D’aquesta manera es posarà un registre de 1 liner a la memòria (s’eliminaran les operacions rw innecessàries a la sdcard) que sempre se sobreescriuran la propera vegada. Aquest registre només contindrà les 6 columnes de dades i cap marca de temps, és fàcil de llegir per a Zabbix.

Com a bonificació final: com programar l’Arduino directament des de l’OrangePI perquè no hagueu d’anar al dispositiu cada vegada i endollar-lo al portàtil.

Hi ha dues maneres:

-Fàcil: instal·leu l'IDE complet d'Arduino i les biblioteques utilitzen un escriptori remot com X11 amb reenviament, Xrdp, Xvnc, Nxserver, etc.

-Direcció: instal·leu l'IDE Arduino i utilitzeu la línia d'ordres

Aquesta vegada ho farem de manera difícil, ja que no m’agrada instal·lar X11 als servidors. Per a això, necessitareu 6 components:

1, IDE Arduino per a ARM de 32 bits ->

2, Python serial -> apt-get install python-serial

3, projecte Arduino Makefile -> git clone

4, biblioteca DHT

5, definicions de taules Sparkfun

6, SilverLight.ino, codi principal

Per fer-ho més fàcil, he agrupat els fitxers necessaris per als darrers 4 punts (sketchbook.tgz), de manera que només necessiteu els 2 primers

Primer és el millor per crear un usuari normal que tingui accés rw al port USB:

adduser plata

usermod -a -G marcatge de plata

SCP sketchbook.tgz al dispositiu del directori inicial de l'usuari recentment creat i extreu-lo allà mateix:

cd / home / plata

tar xvzf sketchbook.tgz

Per entendre una mica què passa sota el capó quan utilitzeu l'IDE gràfic:

El flux de treball de construcció de la creació d'un esbós Arduino quan s'utilitza l'IDE Arduino es descriu al lloc web d'Arduino https://www.arduino.cc/en/Hacking/BuildProcess i amb més detall aquí: https://www.arduino.cc/ ca / Hacking / BuildProcess

Generalment, el procés de compilació estàndard d'Arduino és:

Combineu fitxers.ino al fitxer d'esbós principal. Transformació del fitxer d'esbós principal: afegiu la sentència #include; crear declaracions de funcions (prototips) de totes les funcions al fitxer d'esbós principal; afegiu el contingut del fitxer main.cxx de l'objectiu al fitxer d'esbós principal. Compileu el codi als fitxers objecte. Enllaceu els fitxers objecte amb un fitxer.hex preparat per carregar-lo a l'Arduino.

Hi ha algunes lleugeres diferències entre el procés de compilació estàndard Arduino i el procés de construcció mitjançant Arduino-Makefile:

Només s’admet un fitxer.ino. Les declaracions de funcions no es creen automàticament al fitxer.ino. L’usuari s’ha d’encarregar de crear les declaracions de funció correctes.

El centre del procés de construcció és el Makefile. No us preocupeu, tot està preparat per a vosaltres, és una mica més complicat quan es compila d’aquesta manera per a taules no estàndard com la sèrie SparkFun.

BOARD_TAG = promicro

ALTERNATE_CORE = SparkFun BOARD_SUB = 16MHzatmega32U4 ARDUINO_PORT = / dev / ttyACM0 USER_LIB_PATH = / home / silver / sketchbook / libraries ARDUINO_DIR = /opt/arduino-1.8.9 include /home/silver/sketchino/Ark

I tot el que heu d’escriure és: make upload (que crearà els fitxers.hex primer i després utilitzarà avrdude per penjar-los), acabarà amb alguna cosa com:

mkdir -p build-promicro-16MHzatmega32U4

make reset make [1]: Introduint el directori '/ home / silver / sketchbook' / home / silver / sketchbook / Arduino-Makefile / bin / ard-reset-arduino --caterina / dev / ttyACM0 make [1]: Sortint del directori ' / home / silver / sketchbook 'make do_upload make [1]: Introducció al directori' / home / silver / sketchbook '/opt/arduino-1.8.9/hardware/tools/avr/bin/avrdude -q -V -p atmega32u4 - C /opt/arduino-1.8.9/hardware/tools/avr/etc/avrdude.conf -D -c avr109 -b 57600 -P / dev / ttyACM0 / -U flash: w: build-promicro-16MHzatmega32U4 / sketchbook. hex: i Connexió al programador:. Programador trobat: Id = "CATERIN"; tipus = Versió del programari S = 1.0; No s'ha proporcionat cap versió de maquinari. El programador admet increment automàtic. El programador admet l'accés a memòria emmagatzemada amb memòria intermèdia = 128 bytes. El programador admet els dispositius següents: Codi del dispositiu: 0x44 avrdude: Dispositiu AVR inicialitzat i llest per acceptar les instruccions avrdude: Signatura del dispositiu = 0x1e9587 (probablement m32u4) avrdude: lectura del fitxer d'entrada "build-promicro-16MHzatmega32U4 / sketchbook.hex" avrdude: flash d'escriptura (11580 bytes): avrdude: 11580 bytes de flash avrdude escrit: safemode: Fusibles OK (E: CB, H: D8, L: FF) avrdude fet. Gràcies.

Doncs gràcies avrdude, i ara el nostre Arduino es restableix i es programa amb el nou codi, el que només podeu editar amb vi o el vostre editor favorit localment, sense necessitat de cap IDE. Tinc en compte que hauríeu de tancar tant el programa de control C, la pantalla o qualsevol altra cosa que accedeixi a l'arduino mentre es carrega, en cas contrari, el port tornarà com / dev / ttyACM1 després del reinici.

Pas 3: tancament i llista de tot

Tot i que he creat aquesta caixa de sensors ambientals per a sales de servidors, la podeu utilitzar per a laboratoris de química / electrònica, magatzems, sales normals i qualsevol altra cosa. I sí, ja que utilitza TCP / IP, és un dispositiu IoT, G també ho hauria d’haver posat al títol per fer-lo més emprenedor:)

Podeu modificar fàcilment tant el maquinari com el programari per poder encendre els llums de la sala automàticament. Feu una ullada al meu altre projecte: Shadow of Phoenix, com funciona això per al control de la llum, teniu tot el maquinari a mà per fer el mateix (utilitza temporitzadors de retenció per mantenir els llums encesos sempre que es detecti moviment dins d’un període de temps, si es torna a produir moviment, es dispararà el temporitzador).

Amb OrangePI amb una pila completa Armbian, les possibilitats són il·limitades, podeu crear una interfície web local escrita des de zero en PHP per mostrar dades històriques als gràfics. No és millor que tingueu un dispositiu de codi obert complet que supervisi la vostra sala de servidors del que us pugueu sentir orgullós de construir, si ho creieu, construïu-ho vosaltres mateixos!