Il s'agit toujours d'un problème classique lors de la découverte dans un nouvel environnement de développement, ainsi que d'un nouveau langage de programmation (quand bien même il est sous la forme de blocs visuels). Le principal problème rencontré fut celui de l'enregistrement des données dans un fichier texte. En effet il est nécessaire de faire un flush après l'écriture d'une nouvelle ligne (le flush force l'enregistrement du fichier). Autrement le fichier reste vide.
Le stick stocke les données mesurées dans un fichier texte dans sa mémoire. Ce fichier est créé dans le Setup et s'il existe déjà un fichier celui-ci est alors écrasé. Le problème est que le Setup s'exécute à l'allumage du stick. Celui-ci s'allume dès qu'il se trouve sous tension ( il n'y a pas de bouton Power). Dès lors afin de pouvoir télécharger le script sur le stick sans exécution automatique, il faut débrancher le capteur (ce qui empêche l'exécution du code car le capteur est initialisé au début du Setup).
En théorie le stick synchronise son horloge via NTP dès lors qu'il est connecté à internet. Cependant cette connexion n'a pas été utilisée au cours de ce projet. Dès lors, il a fallu donner cette heure dans le code mais avec un désavantage évident que cela n'est pas précis. Aussi il y a eu confusion sur la Timezone à utiliser (il a été choisi de ne pas modifier le paramètre de base). Le stick est donc resté en UTC et il a été nécessaire de retirer 3600 secondes lors du calcul de l'heure de chaque mesure. Car notre Timezone (à savoir CET pour Central Europe Time) à 1 heure de retard sur l'UTC.
Lors des tests faits avec une base de données contenant des mesures faites toutes les secondes, il n'y avait pas de problèmes particuliers avec des requêtes sur des valeurs quelconques. Cependant, une fois la base de données finale connectée, la requête SQL à échoué car, à moins de faire une requête sur une valeur présente dans la table, la plupart des requêtes ne trouvent rien (les mesures sont espacées de 15 secondes). Afin de résoudre cette impasse, il a été trouvé un concept permettant de faire un arrondi sur la valeur demandée et de renvoyer la valeur la plus proche de la demande.
Un second problème avec le Timestamp vient du retour du formulaire GET. En effet, lorsque l'utilisateur demande une heure où les secondes sont égales à 00, le formulaire ne transmet pas la partie dévolue aux secondes. Dès lors la fonction effectuant le calcul du Timestamp à partir de la date ne reçoit plus une string avec la bonne longueur. Ce bug fut résolu en rajoutant "manuellement" la partie seconde si la longueur de la string n'est pas assez longue.
Lors du développement de l'affichage du graphique généré par MatplotLib, deux problèmes ont été rencontrés. Pour commencer la conservation de l'image générée (afin de pouvoir la transmettre à la page d'affichage). Au cours de recherches dans le but de résoudre le problème, deux solutions ont été indentifiés. La première est de sauvegarder l'image dans le cache et la seconde est de sauvegarder l'image dans le dossier "./static/figures", puis de l'afficher dans l'autre page en la rappelant depuis le dossier. La seconde option a été choisie, car à la fois plus simple mais aussi parce que tout le reste du frontend fonctionne déjà avec cette technique pour l'affichage des images.
La seconde difficulté rencontrée fut d'ordre de logique python. En effet la logique backend de la page "AfficheData" fonctionne avec un test logique, afin de savoir s'il l'on doit afficher une table html ou un graphique. Dans le cadre de la table html la fonction backend renvoie une string. Mais quand il s'agit d'afficher une image, il n'est plus possible d'écrire le code html dans le code backend. Elle devrait renvoyer du code contenant une image (qui n'est pas une string). Dès lors le code html a été écrit à part, et la fonction renvoie un render_template avec comme paramètres les dates de début et de fin dans le but de les afficher dans la page html.