# An IoT-Based Glucose Monitoring Algorithm to Prevent Diabetes Complications
## 4 Results  
To assess the operation of the proposal, tests were carried out on each of the stages and the whole system. Initially, we checked the sending of the glucose reading by the NodeMCU. After that, the connection to the previously defined Wi-Fi network was made. Then, it connected with the server, and thus began to transfer the information. To verify the result of the template, the most popular browsers, i.e., Internet Explorer or Microsoft Edge, Mozilla Firefox and Google Chrome, were used, obtaining similar results in all three cases. Figure 4 displays the home page in the Chrome browser. It can be seen that the image is fully loaded, and the elements placed in their correct position. The marquee works properly, and the menu and the remaining elements are deployed successfully. Figure 4: Web page used to visualize profiles. The patient \"[PERSON]\" with device serial number \"111\" was taken as an example, and ten values were considered, as listed in Table 1. We proposed a noninvasive wireless sensor to be used in the system. However, due to restrictions, the readings were obtained using a traditional glucometer for an older patient before and after the intake. The values of the table were considered in the double average technique to make a prognosis in a three-hour period. According to the food intake and the peak that this generates, this period is considered to be appropriate. The obtained graph is presented in Figure 5.  
We followed the recommendations of the International Diabetes Federation and the American Diabetes Association, which state that glycemic control in an older adult corresponds to preprandial plasma glucose (before eating) of 90 to 130 mg/dL and lower postprandial plasma glucose up to 180 mg/dL. We also considered both categories of dependency, independent and depend functionally defined by the International Diabetes Federation. No intervention is required to make the readings. The actions of the caregivers after the notification should be defined by the specialist. Examining the graph, we notice that there are no peaks or variations in the prognosis generated by the system, there is no critical state, and therefore no alert must be issued. According to the readings analyzed, the early hours fell within the preprandial stage. Subsequently, there was a food intake that caused an increase in the level of glucose, but without exceeding 180 mg/dL, including the prognosis. In the absence of values that exceeded 180 mg/dL, it was not necessary to send an orange alert. If the prognosis exceeds 200 mg/dL, it means that there is an upward tendency and the system sends a red alert indicating a critical condition. It is worth mentioning that the algorithm takes into consideration the condition of when the patient ingests food and does not issue a false notification. \begin{table}
\begin{tabular}{c c} \hline
**Reading** & **Glycemia Value** \\ \hline
1 & 100 \\
2 & 108 \\
3 & 105 \\
4 & 102 \\
5 & 105 \\
6 & 123 \\
7 & 124 \\
8 & 131 \\
9 & 134 \\
10 & 125 \\ \hline \end{tabular}
\end{table} 
Table 1: Blood glucose values for a simulated patient. Figure 5: Glucose level prognosticated using the double moving average under normal conditions. A critical behavior was simulated, we manually changed the readings in order to test the functionality of the algorithm under this situation, as shown in Figure 6. When detecting an upward tendency in the readings that is consistent for several hours (i.e., not due to an intake of food), the system activates the mechanisms for sending notifications, i.e., first a medium alert and, then, a high alert. The prognosis is located above the critical value for three hours, thus, the notification is correct, as there is a critical condition with a tendency to decrease. The system was validated with the creation of profiles for different cases. The personal page of the patient \"[PERSON]\" with serial number \"111\" used in previous tests was stored.