Tohle by mě opravdu zajímalo. I slepé uličky 
Zkusím teda aspoň naťuknout, jak o tom uvažuju já. Pokud bude mít někdo jinou zkušenost, bude jedině super je porovnat a pokecat si o tom
Možná vám to bude připadat triviální, jasně, však na nobelovku to není
Budu psát ve zkratce, snad to bude srozumitelný.
Celkem asi zjevný je, že člověk v tom modelu musí mít nějaká
zařízení (konkrétní "krabička", uzel sítě) na která jsou napojeny nějaké
sensory a nějaké
aktuátory. Pokud zpracování dat má být nějak sjednocené, pak se dá předpokládat, že data chodí do nějakých oddělených
topiků (kanálů, http endpointů, to je jedno). Pro jednoduchost budu předpokládat, že topiky jsou identifikované stringy (v MQTT to tak i je a v HTTP může být).
Dejme tomu, že člověk má třeba krabičku měřící teplotu a vlhkost. První věc, co ho napadne, je pojmenovat si zařízení třeba "kuchyň" a data posílat na topiky "kuchyn/teplota" a "kuchyn/vlhkost" podle schematu ZARIZENI/MERENI. Na první jednoduché pokusy je to super, ale imho je to slepá ulička, protože člověk rychle narazí. Např. krabička je nějaká nestabilní a člověk si z ní chce začít posílat uptime. Ok, takže topic kuchyn/uptime. Fakt? Kuchyn ma uptime?
Nebo ho napadne, ze by chtel krabicku prenaset. Jenze topic je v ni napevno. Takze s kazdym prenesenim preflashovat? Hm, dost opruz.
Takže na základě tohodle foukání kouře do vody jsem dospěl k názoru, že nejlepší model je rozlišovat
fyzické ID a
logické ID a mapovat mezi nima na backendu, kde se mapování dá snadno měnit. Je to podobný jako MAC adresa <-> IP adresa.
Takže krabička má nějaké nevýznamové ID (12345) a data posílá třeba na topiky "12345/teplota", "12345/vlhkost" a "12345/uptime" (což už dává lepší smysl). Na backendu pak chceme mapovat:
1. meření, která se týkají krabičky, na nějaké ID krabičky (klidně to může být to samé co fyzické)
2. ostatní měření mapovat pomocí mapy id_krabicky -> lokace
Takže pak mám třeba mapu
let physLocMap = {
'12345': 'kuchyn',
}
a po mapování dostávám data do nových "logických" topiků takhle:
kuchyn/temp <- 25
kuchyn/vlhkost <- 75
12345/uptime <- 24
...no a tohle je jenom taková jedna hloupost. Podobné kapitoly pak jsou ještě třeba:
1. jak označovat vícenásobná měření (třeba krabička měří tři teploty a umí ovládat dva ventily) - buď můžu použít jenom indexy podle typu měření/aktuátoru: temp1, temp2, temp3, valve1, valve2. Anebo můžu mít nějaké "porty", které sdružují funkce - tj. port1/temp, port1/valve. To se může hodit, protože pak vím, že port1/valve zavírá tu trubku, jejíž teplota je port1/temp.
2. Úplná věda je jak označovat význam měření. Podle mě na to žádná stříbrná kulka není. Ze začátku vám třeba přijde úplně jednoznačný označit měření jako "výkon" - dokud nezačnete měřit činný a jalový
Pak zkusíte třeba OBIS kódy. Ale zas začnete chtít měřit něco, co nepokrývají (aktuální cena Bitcoinu
)
3. chci, aby zařízení posílala s daty i nějaká metadata, nebo je budu mít autoritativně na backendu? Tj. zařízení může posílat jenom třeba "25.4,62,346" a na backendu mám záznam, že je to sensor veličin X,Y,Z. Nebo může krabička posílat něco ve stylu "{temp: 25.4, hum: 62, uptime: 346}" Oboje má svoje pro a proti.
4-n různé další
zapeklitosti zajímavé intelektuální výzvy
Abych to moc nenatahoval, prozatím jsem dospěl k tomu, že když chce člověk model, který opravdu dobře pokrývá prakticky jakýkoli use case, chce to minimálně tyhle atributy (pro sensory, obdobně pro aktuátory):
1. kdo - identifikace subjektu měření (jaké zařízení to naměřilo)
2. koho - objekt měření ("koho měřím")
3. co - veličina, kterou měřím
4. naměřená hodnota
5. jednotka
...přičemž minimálně 1 a 2 neškodí mít hierarchizovatelné (např. kdo="wifi_nody:esp_1", koho="mistnosti:kuchyn"). Když cokoli z 1-5 chybí, existuje use-case, kterej je pak opruz pokrývat.
---
Takže tak no, jako taková malá ilustrace, že se fakt vyplatí nad tím datovým modelem trochu předem podumat, než to tam člověk nafláká
Snad to někomu pro nějakou inspiraci poslouží...
Ale zas na druhou stranu se s tím taky člověk nesmí úplně mořit, protože úplně stopro dobře to imho snad ani vymyslet nejde a vždycky člověk až v praxi narazí na use case, se kterým nepočítal. Takže nepřemýšlet zas moc dlouho, aby se člověk vůbec k tomu hraní si s tím dostal
Zobrazit příspěvky
