BBQ Pi (z vizualizacijo podatkov!): 4 koraki (s slikami)

2024 Avtor: John Day | [email protected]. Nazadnje spremenjeno: 2024-01-30 12:03

Uvod

Žar se najpogosteje nanaša na počasen postopek uporabe posredne toplote za kuhanje vašega najljubšega mesa. Čeprav je ta način kuhanja zelo priljubljen-zlasti v ZDA-ima nekaj, kar bi nekateri menili za precej resno pomanjkljivost: zahteva ure pollucidne pozornosti za spremljanje temperature vaše jame in hrane. Vnesite: Raspberry Pi.

Izvirni projekt

Prvotni vir za ta projekt najdete tukaj: https://old.reddit.com/r/raspberry_pi/comments/a0… Bistvo tega je, da je uporabnik reddita Produkt lahko posredoval podatke o temperaturi hrane in jame iz relativno poceni, komercialno dostopnih brezžičnih termometrov do Raspberry Pi (ki je na nožice GPIO priključil majhen RF modul). V prvotnem projektu (zgoraj povezanem) je imel Produkt svoje podatke shraniti v podatkovno bazo sqlite in jih prikazati na lokalno gostujoči spletni strani apache2 php.

Ta rešitev že rešuje prvotni problem, o katerem smo govorili v uvodu tega spletnega dnevnika: zdaj lahko s spletnim brskalnikom na daljavo spremljate temperaturo hrane in jame. Kaj pa, če bi to želeli razširiti? Vnesite: GridDB.

Zaloge

Malina Pi4

SUNKEE 433Mhz superheterodinski brezžični sprejemniški modul

Korak: Spletni API GridDB & FluentD

Ko sem videl ta projekt, sem po začetnem valu navdušenja najprej pomislil, kako razširiti funkcionalnost. Z uporabo GridDB in vtičnika Grafana sem si želel vizualizirati svoje podatke o hrani in jami. Poleg tega sem želel nastaviti opombe Grafana, da bi poiskal nepravilne podatkovne točke - ne morem imeti ogljenca!

Za začetek sem moral uporabiti kodo C iz prvotnega projekta, da sem prebral podatke, ki prihajajo iz brezžičnega termometra, in jih objavil v svojem strežniku GridDB. Da bi to lahko zagnali, sem v Azureu z virtualnim strojem CentOS ustanovil strežnik GridDB. Najlažji način za izmenjavo podatkov z našega robnega računalnika (Raspberry Pi) na strežniku v oblaku je bil prek spletnega API -ja GridDB. Tako sem na tem vm -ju nastavil WebAPI GridDB skupaj s Fluentdom in pripadajočim priključkom GridDB.

Preden sem dejansko poslal podatke v oblak, sem moral ustvariti osnovno shemo za svoj vsebnik BBQ Pi. Nabor podatkov, ki prihaja, je zelo preprost: imamo dva temperaturna senzorja, enega ID -ja kuhanja in seveda časovni žig. Torej naša shema izgleda tako:

timeseries = gridstore.put_container ("bbqpi", [("time", griddb. GS_TYPE_TIMESTAMP), ("cookid", griddb. GS_TYPE_INT), ("sonda1", griddb. GS_TYPE_INT), ("sonda2", griddb. GS_TYPE_INT)], griddb. GS_ER_)

Za ustvarjanje tega vsebnika časovne serije sem preprosto uporabil WebAPI (vrata 8080):

curl -X POST --basic -u admin: admin -H "Vrsta vsebine: aplikacija/json" -d

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

Z ustvarjenim vsebnikom sem moral uporabiti Fluentd (vrata 8888) za objavo dejanskih podatkov v naš vsebnik. Tu je ukaz CURL, ki objavlja nekaj lažnih podatkov:

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

Od tam sem moral dodati izvirno kodo za pošiljanje zahteve HTTP POST, kadar koli je naš Pi bral podatke iz naše jame (približno enkrat na približno 12 sekund).

Kot stransko opombo: pisanje te kode me je naučilo ceniti, kako natančen je lahko jezik C:

int postData (čas char , int cookid, int sonda1, int sonda2, char url )

{CURL *curl; CURLcode res; / * V oknih bo to sprožilo stvari winsock */ curl_global_init (CURL_GLOBAL_ALL); char errbuf [CURL_ERROR_SIZE] = {0,}; char agent [1024] = {0,}; char json [1000]; snprintf (json, 200, "json = {" date / ": \"%s.112Z / ", \" cookid / ": \"%d / ", \" sonda1 / ": \"%d / ", / "sonda2 \": / "%d \"} ", čas, kuhanje, sonda1, sonda2); / * dobite ročaj curl */ curl = curl_easy_init (); if (curl) { /* Najprej nastavite URL, ki bo kmalu prejel naš POST. Ta URL je lahko prav tako URL https://, če bi to morali sprejeti podatki. */ snprintf (agent, sizeof agent, "libcurl/%s", curl_version_info (CURLVERSION_NOW)-> različica); 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); / * Izvedite zahtevo, res bo dobila vrnilno kodo */ res = curl_easy_perform (curl); če (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)); pojdi na čiščenje; } čiščenje: curl_easy_cleanup (curl); curl_global_cleanup (); vrnitev 0; }}

Ko je bila napisana ta funkcija, sem jo moral zagnati hkrati z objavo podatkov sqlite:

if (goodData == 1) {

if (last_db_write == 0 || (secs-last_db_write> = 10)) {snprintf (sql, 100, "INSERT INTO odčitki (kuhanje, čas, sonda1, sonda2) VREDNOSTI (%d, '%s',%d, %d); ", cookID, odboj, sonda1, sonda2); printf ("%s / n", sql); rc = sqlite3_exec (db, sql, povratni klic, 0 in & zErrMsg); if (rc! = SQLITE_OK) {printf ("Napaka SQL: %s / n", zErrMsg); } else {last_db_write = secs; } char url = "https://xx.xx.xx.xx: 8888/griddb"; postData (buff, cookID, sonda1, sonda2, url); }}

Če želite zagotoviti, da so vaši podatki dejansko vstavljeni v vaš strežnik, lahko izvedete naslednji ukaz za poizvedbo v zbirki podatkov in ogled rezultatov:

curl -X POST --basic -u admin: admin -H "Vrsta vsebine: application/json" -d '{"omejitev": 1000}' https:// localhost: 8080/griddb/v2/defaultCluster/dbs/ public/zabojniki/bbqpi/vrstice

2. korak: Grafana

Ko je koda vzpostavljena, bomo zdaj, ko za začetek "kuhanja" uporabljamo prvotni spletni portal, istočasno shranjevali podatke o temperaturi v strežnik GridDB.

Naslednji korak bo vizualizacija naših podatkov z uporabo Grafane. V ta namen smo sledili informacijam s tega spletnega dnevnika: tukaj. Lepo pri tej izvedbi je, da je naše podatke izredno enostavno videti v lepem grafu. Dodaja tudi opombe.

Opombe, obravnavane v spletnem dnevniku, nam zelo olajšajo spremljanje, kdaj gre kaj narobe z našo hrano ali s samo jamo. V mojem primeru sem kuhal goveja kratka rebra. S temi nisem želel, da temperatura v jami naraste nad 275 stopinj Fahrenheita. Če bi videl temperaturo, ki presega to, bi lahko izklopil gorilnik in pustil, da se toplota spet potopi:

Imel sem podobno pravilo, da senzor dejansko spremlja hrano: če je hrana dosegla notranjo temperaturo 203 stopinj Fahrenheita, so bila rebra pripravljena. Samotni pripis na koncu kuharja si lahko ogledate tukaj:

Skratka, kuhar mi je vzel le približno 4 ure ali več, vendar bi bila takšna nastavitev resnično odlična, če bi kuhala nekaj, kar bi zahtevalo še več časa na žaru (pomislite na nizko počasen dim, ki traja ~ 12 ure). Kljub temu menim, da je vrednost, če je to orodje zlahka očitno: če zabeležite rezultate svojih živil in jih nato primerjate s prejšnjimi kuharji, pomeni, da se bo vaš BBQ sčasoma izboljšal, saj lahko s podatki vidite, kaj deluje in kaj ne 't.

3. korak: Hrana

To je bilo prvič, da sem kdaj naredil goveja kratka rebra; za začimbe sem preprosto uporabil sol, črni poper in česen v prahu. Kljub nekaterim težavam, ko je gorilnik na začetku previsok, so rebra izpadla fantastično. Prosim, poglejte:

4. korak: Zaključek

Na koncu je bila hrana izjemna, senzorji, GridDB in Grafana so odlično delovali in dobili smo nekaj dragocenih podatkov o tem, kako te stvari spet skuhati, ko bomo naslednjič želeli narediti vtis na prijatelje.