This week started off with the interim demo on Monday. From there, I continued work on the front-end of the web application this week. While the visuals for the web application were fine for the demo, I believe there was room for improvement. Next, one piece of feedback\/one question that I was given during the demo was “How does each machine know which id it is?” The process for the demo was to have the nodeMCU send a POST request with its id preconfigured — but for setting up a new nodeMCU, this was tedious. Instead, I worked on the backend for registering a new device\/machine. The nodeMCU sends a POST request to the web app and receives back its unique ID, which the web app also stores in a model. Overall, I would definitely agree this is a much more streamlined solution for registering new devices.<\/p>\n
This coming week, I plan on fixing any bugs with existing code, as well as implementing the final functional feature, which is the average time spent on the machine.<\/p>\n
In terms of schedule, I would say I am on track with the schedule posted for the interim demo, except for sockets (which we mentioned in the demo that POST requests might just suffice).<\/p>\n
The tests that I have run and am planning on running are:<\/p>\n
– testing adding new machines with the register api<\/p>\n
– updating busy and free status for existing machines<\/p>\n
– testing reporting a machine as broken<\/p>\n
In particular, the second test is the most important because in order to meet our requirement, we need to ensure that updating the machine is accurate <\/strong>and quick<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":" This week started off with the interim demo on Monday. From there, I continued work on the front-end of the web application this week. While the visuals for the web application were fine for the demo, I believe there was room for improvement. Next, one piece of feedback\/one question that I was given during the … <\/p>\n