Wat is MQTT, en waarom het elke skool se IoT-les skielik 'n makelaar nodig?
MQTT is 'n liggewig-boodskapprotokol wat mikrobeheerders in die klaskamer toelaat om data te deel sonder direkte eweknie-tot-eweknie-verbindings. Deur verkeer deur 'n sentrale makelaar te stuur, omseil dit beperkende skoolbrandmure en verhoed dit dat toestelle onder netwerklas ineenstort.
As jy onlangs na 'n KABV-belynde Kodering-en-Robotika-sillabus gekyk het, of probeer het om 'n Internet van Dinge (IoT) -praktikum vir jou klaskamer te ontwerp, het jy waarskynlik die akroniem MQTT en die vereiste van 'n "MQTT-makelaar" teëgekom. Vir 'n IT-onderwyser of 'n besige tegnologiekoördineerder kan dit soos onnodige ingewikkeldheid voel. Waarom kan 'n mikrobeheerder, soos 'n ESP32 of 'n Raspberry Pi Pico W, nie eenvoudig sy sensordata direk oor die plaaslike Wi-Fi-netwerk na 'n leerder se skootrekenaar of foon stuur nie?
Die kort antwoord is dat direkte toestel-tot-toestel-kommunikasie bros en hulpbronswaar is, en byna heeltemal onversoenbaar met skoolnetwerksekuriteit. MQTT (Message Queuing Telemetry Transport) los dit op deur die sender van die data van die ontvanger te skei en alle boodskappe deur 'n sentrale bestuurder te stuur wat 'n makelaar genoem word. Dit is die bedryfstandaard vir industriële IoT, en dit word al hoe noodsaakliker vir fisiese rekenaarwerk in die klaskamer.
Die kennisgewingbord in die klas: verstaan pub/sub
Om te verstaan waarom MQTT werk, verbeel jou 'n klas van 40 leerders. As elke leerder wat die huidige buitetemperatuur wou weet na die een leerder langs die venster moes stap en vra: "Wat is die temperatuur?", sou daardie vensterleerder die hele les lank herhalende vrae beantwoord in plaas daarvan om sy eie werk te doen. As nog tien leerders wou weet wanneer die volgende pouse is, sou hulle die onderwyser direk moes onderbreek.
Stel nou 'n kennisgewingbord in die gang bekend. Die vensterleerder skryf "Temperatuur: 22°C" op 'n plakkertjie en speld dit onder die opskrif "Weer" vas. Die onderwyser speld "Volgende pouse: 10:30" onder "Rooster" vas. Enigiemand wat die temperatuur of die pouse-tyd wil weet, stap eenvoudig na die bord en lees dit. Die vensterleerder weet nie en gee nie om wie die temperatuur lees nie; hy plaas net die opdatering. Die lesers hoef nie die vensterleerder te steur nie.
Dit is die publiseer/inteken- (pub/sub-) model wat MQTT gebruik:
- Die publiseerder: Die mikrobeheerder met 'n sensor (die vensterleerder) wat data na die makelaar stuur.
- Die intekenaar: Die paneelbord, foontoepassing of databasis (die leerders wat die bord lees) wat daardie data wil ontvang.
- Die makelaar: Die sentrale bediener (die kennisgewingbord) wat boodskappe van publiseerders ontvang en dit na die regte intekenaars stuur.
Die tegniese kern: onderwerpe, behoue boodskappe en laaste wilsbeskikkings
MQTT steun op drie kernbegrippe om kommunikasie doeltreffend en betroubaar te hou, selfs oor swak draadlose verbindings.
1. Onderwerpe: Boodskappe word nie na spesifieke toestelle gestuur nie; hulle word na "onderwerpe" gepubliseer. Onderwerpe word met skuinsstrepe gestruktureer, wat 'n hiërargie skep soos school/lab1/temp of home/garden/moisture. 'n Toestel kan op 'n baie spesifieke onderwerp inteken, of plekhouertekens gebruik om na verskeie onderwerpe gelyktydig te luister. Byvoorbeeld, deur op school/+/temp in te teken, kan 'n enkele paneelbord temperatuurlesings van elke laboratorium op die kampus wys.
2. Behoue boodskappe: Normaalweg, as 'n sensor 'n lesing publiseer en niemand op daardie presiese millisekonde ingeteken is nie, is die boodskap vir altyd verlore. As 'n leerder vyf minute later sy paneelbordtoepassing oopmaak, sien hy 'n leë skerm totdat die sensor weer uitsaai. Deur die "behoue" vlaggie op 'n boodskap te stel, sê die publiseerder vir die makelaar: "Hou hierdie laaste waarde in die lêer. Die volgende keer as iemand op hierdie onderwerp inteken, gee hulle onmiddellik hierdie waarde." Dit is krities vir stadig veranderende data, soos grondvog of watertenkvlakke.
3. Laaste wil en testament (LWT): Mikrobeheerders in Suid-Afrikaanse klaskamers staar gereelde, skielike ontkoppelings in die gesig weens beurtkrag, pap batterye of leerders wat per ongeluk kragkabels uittrek. Wanneer 'n toestel die eerste keer aan die makelaar koppel, registreer dit 'n "laaste wil"-boodskap (byvoorbeeld, onderwerp: status/sensor1, boodskap: offline). As die toestel skielik krag verloor sonder om 'n skoon ontkoppelsein te stuur, bespeur die makelaar die gebroke verbinding en publiseer outomaties die "laaste wil"-boodskap namens die toestel, wat die res van die stelsel waarsku dat die hardeware vanlyn is.
Drie dinge wat op 'n skoolnetwerk verkeerd loop
Hoewel MQTT robuust is, verg die implementering daarvan in 'n opvoedkundige omgewing dat jy die realiteite van skool-IT-infrastruktuur navigeer. Drie algemene falingswyses ontwrig gereeld klaskamerlesse:
Algemene skoolnetwerkfalings
| Netwerkkenmerk | Waarom dit bestaan | Hoe dit die IoT-les breek |
|---|---|---|
| WPA2-Enterprise-sekuriteit | Beskerm skoolnetwerke deur individuele leerdergebruikersname en wagwoorde te vereis. | Standaard mikrobeheerders (soos basiese ESP8266-skyfies) kan nie sonder meer Enterprise-sekuriteitsprotokolle onderhandel nie, wat hulle verhoed om by die Wi-Fi aan te sluit. |
| Toegangspunt- (AP-) isolasie | Verhoed dat leerders mekaar se skootrekenaars oor die plaaslike Wi-Fi kap of daartoe toegang kry. | Blokkeer plaaslike eweknie-tot-eweknie-verkeer. As jy 'n MQTT-makelaar op 'n Raspberry Pi in die klaskamer bedryf, sal leerdertoestelle op dieselfde Wi-Fi geblokkeer word om dit te bereik. |
| Dinamiese IP-omsetting (DHCP) | Hergebruik IP-adresse om te verhoed dat die skool se roeteerder sonder adresse raak. | As jy wel 'n plaaslike makelaar op 'n skootrekenaar bedryf, sal die IP-adres daarvan gereeld verander. Enige mikrobeheerderkode met 'n hardgekodeerde IP-adres sal die volgende dag nie kan koppel nie. |
Om hierdie plaaslike netwerkhindernisse te omseil, moet opvoeders gewoonlik kies tussen 'n stryd met hul IT-afdeling oor pasgemaakte roeteerderkonfigurasies, of om hul verkeer deur 'n eksterne, wolkgehuisveste makelaar te stuur wat oor standaard webpoorte toeganklik is. Vir onderwysers wat 'n vaartbelynde, klaskamergereed oplossing soek wat hierdie plaaslike netwerkhoofpyne heeltemal omseil, bied die Sheen IoT-platform 'n voorafopgestelde, wolkgehuisveste MQTT-omgewing wat spesifiek ontwerp is om binne die beperkings van skoolbrandmure te werk.
Deur die boodskaplas van die mikrobeheerders af te skuif na 'n toegewyde makelaar, verseker MQTT dat die klaskamer se IoT-toestelle betroubaar en veilig kan kommunikeer, selfs al is 'n leerder se kode ongeoptimeer of die skool se Wi-Fi swak.
