Stap 2: De serverimplementatie van het knooppunt van de app
Zoals we hebben gezien is er een andere laag van netwerk tussen de eindgebruikers dat wil zeggen de gewone mensen en van het wsn. Deze laag bestaat uit een serverknooppunt of serverknooppunten. Ons idee was om een server-farm die van het wsn in de hele regio voor snellere reactie coördinaten. Voor het prototype model als gevolg van gebrek aan middelen en tijd van de tweede laag is een knooppunt van één server. De belangrijkste reden we voor een serverknooppunt gingen is om dat een interrupt gebaseerd systeem en real-time systeem als de kwestie die we proberen te pakken is gevoelig en tijdsverloop wordt niet getolereerd.
Het idee is dat de onderste laag van de WSN JSON objecten naar het serverknooppunt met een constante snelheid, dat wil zeggen de gemiddelde stroom van water (in verband met de druk) en het vochtgehalte van de bodem is doorgeven. We dan convet de JSON-objecten naar csv formaat en vervolgens de database laden. De bestandsstructuur van de database en de ontvangst van de sensor gegevens code is opgenomen in de bestanden.
Wij zijn het gemiddelde debiet per minuut sensing en vervolgens vergelijken met gemiddelde tot nu toe dat we beslissen of de waterstand alarmerend is of niet. Dan hebben we de alarmerende systeem dat is gebaseerd op de IFTTT-module van de bout verwerkingseenheid. Hoe beter geschikt sensoren waren water stroom sensoren en sonar als ze nauwkeuriger middelen van de diepte van het water dat een belangrijke factor bieden is bij de opsporing van overstromingen. Toen verhuisden we naar plotten grafieken met behulp van de gegevens die we opgeslagen met behulp van gnu plot die vervolgens zal worden geladen op het webportaal van de eindgebruiker uitgelegd in de volgende sectie. Knooppunt-serverimplementatie DBMS-structuur
