BBQ Pi (s vizualizací dat!): 4 kroky (s obrázky)

2024 Autor: John Day | [email protected]. Naposledy změněno: 2024-01-30 08:20

Úvod

Grilování se obvykle týká pomalého procesu používání nepřímého tepla k vaření vašich oblíbených mas. Ačkoli je tento způsob vaření velmi populární-zejména v USA-má to, co někteří mohou považovat za poměrně vážnou slabinu: vyžaduje to hodiny poloviční pozornosti, kterou je třeba věnovat sledování teploty vaší jámy a jídla. Zadejte: Raspberry Pi.

Původní projekt

Původní zdroj tohoto projektu lze nalézt zde: https://old.reddit.com/r/raspberry_pi/comments/a0… Podstatou je, že uživatel reddit Produkt dokázal předat údaje o teplotě jídla a jám z relativně levných, komerčně dostupné bezdrátové teploměry k Raspberry Pi (který měl na svých GPIO pinech připojen malý RF modul). V původním projektu (odkaz výše) měl Produkt data uložena v databázi sqlite a zobrazena na místně hostovaném webu apache2 php.

Toto řešení již řeší původní problém, kterého se dotklo v úvodu tohoto blogu: Nyní můžete teplotu jídla a jámy sledovat vzdáleně pomocí webového prohlížeče. Ale co kdybychom to chtěli rozšířit? Zadejte: GridDB.

Zásoby

Raspberry Pi4

Bezdrátový přijímací modul SUNKEE 433 MHz Superheterodyne

Krok 1: GridDB Web API & FluentD

Když jsem viděl tento projekt, mojí první myšlenkou - po počáteční vlně vzrušení - bylo přemýšlení o způsobech, jak rozšířit funkčnost. Pomocí GridDB a jeho pluginu Grafana jsem se snažil vizualizovat svá data o jídle a jámách. Kromě toho jsem si přál nastavit anotace Grafana k vyhledávání jakýchkoli anomálních datových bodů - nemůže mít žádné zuhelnatělé maso!

Abych mohl začít, potřeboval jsem použít kód C z původního projektu, abych přečetl data přicházející z bezdrátového teploměru a zveřejnil je na mém serveru GridDB. Abych to zprovoznil, roztočil jsem server GridDB v Azure pomocí virtuálního počítače CentOS. Nejsnadnější způsob sdílení dat z našeho edge stroje (Raspberry Pi) na náš cloudový server byl prostřednictvím webového rozhraní API GridDB. Na tomto VM jsem tedy nastavil WebAPI GridDB spolu s Fluentdem a doprovodným konektorem GridDB.

Než jsem skutečně odeslal data do cloudu, potřeboval jsem vytvořit základní schéma pro svůj BBQ Pi kontejner. Vstup datové sady je velmi jednoduchý: máme dva teplotní senzory, jedno ID kuchaře a samozřejmě časové razítko. Naše schéma tedy vypadá takto:

timeseries = gridstore.put_container ("bbqpi", [("čas", griddb. GS_TYPE_TIMESTAMP), ("cookid", griddb. GS_TYPE_INT), ("sonda1", griddb. GS_TYPE_INT), ("sonda2", griddb. GS_TYPE_INT)], griddb. GS_CONTAINER_TIME_SERIES)

K vytvoření tohoto kontejneru timeseries jsem jednoduše použil WebAPI (port 8080):

curl -X POST --základní -u admin: admin -H "Typ obsahu: aplikace/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/kontejnery

Když byl kontejner vytvořen, potřeboval jsem použít Fluentd (port 8888) k odeslání skutečných dat do našeho kontejneru. Zde je příkaz CURL zveřejňující některá fiktivní data:

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

Odtamtud jsem potřeboval připojit původní kód k odeslání požadavku HTTP POST, kdykoli náš Pi četl data z naší jámy (asi jednou za ~ 12 sekund).

Jako vedlejší poznámka: psaní tohoto kódu mě naučilo ocenit, jak upřímný jazyk C může být:

int postData (char time , int cookid, int sonda1, int sonda2, char url )

{CURL *curl; CURLcode res; / * V oknech to spustí věci 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, cookid, sonda1, sonda2); / * get curl handle */ curl = curl_easy_init (); if (curl) { /* Nejprve nastavte adresu URL, která se chystá obdržet náš POST. Tato adresa URL může být stejně jako adresa URL https://, pokud by měla přijímat data. */ snprintf (agent, sizeof agent, "libcurl/%s", curl_version_info (CURLVERSION_NOW)-> verze); 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 (zvlnění, CURLOPT_PASSWORD, "admin"); curl_easy_setopt (zvlnění, CURLOPT_VERBOSE, 1L); curl_easy_setopt (zvlnění, CURLOPT_ERRORBUFFER, errbuf); curl_easy_setopt (zvlnění, CURLOPT_POSTFIELDS, json); / * Proveďte požadavek, res získá návratový kód */ 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)); přejít na vyčištění; } vyčištění: curl_easy_cleanup (zvlnění); curl_global_cleanup (); návrat 0; }}

S touto napsanou funkcí jsem potřeboval, aby byla spuštěna současně se zveřejňováním dat sqlite:

if (goodData == 1) {

if (last_db_write == 0 || (secs-last_db_write> = 10)) {snprintf (sql, 100, "INSERT INTO readings (cookid, time, probe1, probe2) VALUES (%d, '%s',%d, %d); ", CookID, buff, sonda1, sonda2); printf ("%s / n", sql); rc = sqlite3_exec (db, sql, zpětné volání, 0, & zErrMsg); if (rc! = SQLITE_OK) {printf ("Chyba SQL: %s / n", zErrMsg); } else {last_db_write = s; } char url = "https://xx.xx.xx.xx: 8888/griddb"; postData (buff, cookID, sonda1, sonda2, adresa URL); }}

Chcete -li se ujistit, že se data skutečně vkládají na váš server, můžete spustit dotaz na databázi a zobrazit výsledky:

curl -X POST -základní -u admin: admin -H "Typ obsahu: application/json" -d '{"limit": 1000}' https:// localhost: 8080/griddb/v2/defaultCluster/dbs/ veřejné/kontejnery/bbqpi/řádky

Krok 2: Grafana

Když je kód na místě, nyní, když použijeme původní webový portál k zahájení „vaření“, budeme současně ukládat naše údaje o teplotě na náš server GridDB.

Dalším krokem bude vizualizace našich dat pomocí Grafany. K tomu jsme sledovali informace z tohoto blogu: zde. Hezké na této implementaci je, že je velmi snadné vidět naše data v grafu do pěkného grafu. Také přidává anotace.

Anotace diskutované v blogu nám extrémně usnadňují sledování, když se něco pokazí buď s naším jídlem, nebo samotnou jámou. V mém případě jsem vařil hovězí krátká žebra. S těmi jsem nechtěl, aby teplota v jámě rostla nad 275 stupňů Fahrenheita. Pokud jsem viděl, že teplota jde nad rámec toho, mohl bych vypnout hořák a nechat teplo znovu klesnout:

Měl jsem podobné pravidlo pro snímač, který ve skutečnosti držel karty na samotném jídle: pokud se jídlo dostalo na vnitřní teplotu 203 stupňů Fahrenheita, žebra byla připravena. Osamělou anotaci na konci kuchaře si můžete prohlédnout zde:

Celkově mi kuchař trval jen asi 4 hodiny, ale tento typ nastavení by opravdu vynikal, kdybych vařil něco, co by na grilu vyžadovalo ještě více času (myslím, že pomalý kouř, který trvá ~ 12 hodiny). Navzdory tomu věřím hodnotě, pokud je tento nástroj snadno zřejmý: schopnost zaznamenávat výsledky vašich potravin a porovnávat je s předchozími kuchaři znamená, že se vaše grilování bude postupem času zlepšovat, protože pomocí údajů můžete zjistit, co funguje a co ne 't.

Krok 3: Jídlo

Bylo to vůbec poprvé, kdy jsem dělal krátká hovězí žebra; na dochucení jsem jednoduše použil sůl, černý pepř a česnekový prášek. Navzdory některým problémům s tím, že se hořák na začátku příliš zvýšil na trochu, žebra vyšla fantasticky. Prosím podívej se:

Krok 4: Závěr

Nakonec jídlo vyšlo úžasně, senzory, GridDB a Grafana fungovaly krásně sladěně a získali jsme cenná data o tom, jak tyto věci znovu uvařit, abychom příště chtěli zapůsobit na některé přátele.