BBQ Pi (cu vizualizare date!): 4 pași (cu imagini)

2024 Autor: John Day | [email protected]. Modificat ultima dată: 2024-01-30 11:42

Introducere

Gratarul se referă de obicei la procesul lent de utilizare a căldurii indirecte pentru a găti carnea preferată. Deși această metodă de gătit este extrem de populară - în special în SUA - are ceea ce unii ar putea considera o slăbiciune destul de gravă: necesită ore de atenție semi-lucidă pentru a fi cheltuite monitorizând temperatura gropii și a alimentelor. Introduceți: Raspberry Pi.

Proiectul Original

Sursa originală a acestui proiect poate fi găsită aici: https://old.reddit.com/r/raspberry_pi/comments/a0… Esența este că utilizatorul reddit Produkt a reușit să transmită datele despre temperatura alimentelor și a gropilor de la un preț relativ ieftin, termometre wireless disponibile comercial la un Raspberry Pi (care a atașat pinilor GPIO un mic modul RF). În proiectul original (legat mai sus), Produkt avea datele sale stocate într-o bază de date sqlite și afișate pe un site web apache2 php găzduit local.

Această soluție rezolvă deja problema inițială atinsă în introducerea acestui blog: puteți monitoriza acum temperatura alimentelor și a gropilor de la distanță cu un browser web. Dar dacă am vrea să ne extindem asupra acestui aspect? Introduceți: GridDB.

Provizii

Raspberry Pi4

SUNKEE 433Mhz Superheterodyne Wireless Receiver Module

Pasul 1: GridDB Web API și FluentD

După ce am văzut acest proiect, primul meu gând - după valul inițial de entuziasm - a fost să mă gândesc la modalități prin care extind funcționalitatea. Folosind GridDB și pluginul său Grafana, am căutat să-mi vizualizez datele despre alimente și gropi. Dincolo de asta, am dorit să înființez adnotări Grafana pentru a căuta puncte de date anormale - nu pot avea carne carbonizată!

Pentru a începe, a trebuit să folosesc codul C din proiectul original pentru a citi datele care vin de la termometrul wireless și pentru a posta datele pe serverul meu GridDB. Pentru a pune acest lucru în funcțiune, am creat un server GridDB pe Azure folosind o mașină virtuală CentOS. Cel mai simplu mod de a partaja date de pe mașina noastră de margine (Raspberry Pi) către serverul nostru cloud a fost prin intermediul API-ului web GridDB. Deci, pe acel vm, am configurat WebAPI-ul GridDB împreună cu Fluentd și conectorul GridDB însoțitor.

Înainte de a trimite de fapt date în cloud, trebuia să creez schema de bază pentru containerul meu BBQ Pi. Setul de date care intră este extrem de simplu: avem doi senzori de temperatură, un cod bucătar și, desigur, marca de timp. Deci, schema noastră arată astfel:

timeseries = gridstore.put_container ("bbqpi", [("timp", griddb. GS_TYPE_TIMESTAMP), ("cookid", griddb. GS_TYPE_INT), ("probe1", griddb. GS_TYPE_INT), ("probe2", griddb. GS_TYPE_INT)], griddb. GS_CONTAINER

Pentru a crea acest container de timeseries, am folosit pur și simplu WebAPI (portul 8080):

curl -X POST --basic -u admin: admin -H "Content-type: application / json" -d

'{"container_name": "bbqpi", "container_type": "TIME_SERIES", / "rowkey": true, "columns": [{"name": "time", "type": "TIMESTAMP"}, {"name": "cookid", "type": "INTEGER"}, {"name": "probe1", "type": "INTEGER"}, {"name": "probe2", "type": "INTEGER"}]} '\ https:// localhost: 8080 / griddb / v2 / defaultCluster / dbs / public / containers

Odată cu containerul creat, a trebuit să folosesc Fluentd (portul 8888) pentru a posta date reale în containerul nostru. Iată o comandă CURL care postează câteva date fictive:

curl -X POST -d 'json = {"date": "2020-01-01T12: 08: 21.112Z", "cookid": "1", "probe1": "150", "probe2": "140" } 'https:// localhost: 8888 / griddb

De acolo, trebuia să adaug codul original pentru a trimite o cerere HTTP POST ori de câte ori Pi-ul nostru citea date din groapa noastră (aproximativ o dată la ~ 12 secunde).

Ca o notă secundară: scrierea acestui cod m-a învățat să apreciez cât de detaliat poate fi limbajul C:

int postData (char time , int cookid, int probe1, int probe2, char url )

{CURL * curl; CURLcode res; / * În Windows, aceasta va iniția lucrurile winsock * / curl_global_init (CURL_GLOBAL_ALL); char errbuf [CURL_ERROR_SIZE] = {0,}; agent char [1024] = {0,}; char json [1000]; snprintf (json, 200, "json = {" date / ": \"% s.112Z / ", \" cookid / ": \"% d / ", \" probe1 / ": \"% d / ", / "probe2 \": / "% d \"} ", ora, cookid, sonda1, sonda2); / * obține un mâner curl * / curl = curl_easy_init (); if (curl) {/ * Setați mai întâi adresa URL care urmează să primească POST-ul nostru. Această adresă URL poate fi la fel de bine o adresă https:// dacă aceasta ar trebui să primească datele. * / snprintf (agent, mărimea agentului, "libcurl /% s", curl_version_info (CURLVERSION_NOW) -> versiune); agent [sizeof agent - 1] = 0; curl_easy_setopt (curl, CURLOPT_USERAGENT, agent); curl_easy_setopt (curl, CURLOPT_URL, url); curl_easy_setopt (curl, CURLOPT_USERNAME, "admin"); curl_easy_setopt (curl, CURLOPT_PASSWORD, "admin"); curl_easy_setopt (curl, CURLOPT_VERBOSE, 1L); curl_easy_setopt (curl, CURLOPT_ERRORBUFFER, errbuf); curl_easy_setopt (curl, CURLOPT_POSTFIELDS, json); / * Efectuați solicitarea, res va primi codul de returnare * / res = curl_easy_perform (curl); if (res! = CURLE_OK) {size_t len = strlen (errbuf); fprintf (stderr, "\ nlibcurl: (% d)", res); if (len) fprintf (stderr, "% s% s", errbuf, ((errbuf [len - 1]! = '\ n')? "\ n": "")); fprintf (stderr, "% s / n / n", curl_easy_strerror (res)); go go cleanup; } curățare: curl_easy_cleanup (curl); curl_global_cleanup (); retur 0; }}

Cu această funcție scrisă, am avut nevoie doar să o rulez în același timp în care datele sqlite erau postate:

if (goodData == 1) {

if (last_db_write == 0 || (secs-last_db_write> = 10)) {snprintf (sql, 100, "INSERT INTO readings (cookid, time, probe1, probe2) VALUE (% d, '% s',% d, % d); ", cookID, buff, probe1, probe2); printf ("% s / n", sql); rc = sqlite3_exec (db, sql, callback, 0, & zErrMsg); if (rc! = SQLITE_OK) {printf ("Eroare SQL:% s / n", zErrMsg); } else {last_db_write = secs; } char url = "https://xx.xx.xx.xx: 8888 / griddb"; postData (buff, cookID, probe1, probe2, url); }}

Pentru a vă asigura că datele dvs. sunt introduse efectiv în serverul dvs., puteți rula următoarea comandă pentru a interoga baza de date și a vizualiza rezultatele:

curl -X POST --basic -u admin: admin -H "Content-type: application / json" -d '{"limit": 1000}' https:// localhost: 8080 / griddb / v2 / defaultCluster / dbs / public / containere / bbqpi / rows

Pasul 2: Grafana

Cu codul în poziție, acum când folosim portalul web original pentru a începe un „bucătar”, vom stoca simultan datele noastre de temperatură în serverul nostru GridDB.

Următorul pas va fi vizualizarea datelor noastre utilizând Grafana. Pentru a face acest lucru, am urmărit informațiile de pe acest blog: aici. Interesantul acestei implementări este că este extrem de ușor să vedem datele noastre într-un grafic frumos. De asemenea, adaugă adnotări.

Adnotările discutate în blog ne fac extrem de ușor să monitorizăm când ceva nu merge fie cu mâncarea noastră, fie cu groapa în sine. În cazul meu, găteam coaste scurte de vită. Cu acestea, nu am vrut ca temperatura din groapă să crească peste 275 de grade Fahrenheit. Dacă aș vedea că temperatura depășește acest nivel, aș putea opri arzătorul și aș permite căldura să scadă din nou:

Am avut o regulă similară pentru senzorul care păstrează efectiv alimentele în sine: dacă mâncarea a ajuns la o temperatură internă de 203 grade Fahrenheit, coastele erau gata. Aici puteți vedea adnotarea individuală la sfârșitul bucătăriei:

Una peste alta, bucătarul mi-a luat doar aproximativ 4 ore sau cam așa ceva, dar acest tip de aranjament ar fi excelat cu adevărat dacă aș fi gătit ceva care ar fi necesitat și mai mult timp în grătar (gândiți-vă la un fum slab lent care durează ~ 12 ore). În ciuda acestui fapt, cred că valoarea dacă acest instrument este ușor de văzut: posibilitatea de a înregistra rezultatele alimentelor și apoi de a le compara cu bucătarii anteriori înseamnă că grătarul dvs. se va îmbunătăți încet în timp, deoarece puteți utiliza datele pentru a vedea ce funcționează și ce nu nu este.

Pasul 3: Mancarea

Aceasta a fost prima dată când am făcut vreodată coaste scurte de vită; pentru condimente, am folosit pur și simplu sare, piper negru și pudră de usturoi. În ciuda unor probleme cu arzătorul care a devenit prea mare pentru un pic acolo la început, coastele au ieșit fantastic. Te rog uita-te:

Pasul 4: Concluzie

În cele din urmă, mâncarea a ieșit grozav, senzorii, GridDB și Grafana au funcționat frumos în concert și am obținut câteva date valoroase despre cum să gătești din nou aceste lucruri pentru data viitoare când vrem să impresionăm câțiva prieteni.