An IoT system connects physical observation, processing and communication. The sensor provides a reading to ESP32; the board prepares a message; the network transports it; a local service validates and stores the last accepted reading; the app retrieves and presents it. Arrows have direction and purpose: sending a measurement and querying the latest one are different actions. The network carries information but does not automatically decide whether a measurement is valid.

Components do not know the entire path or necessarily work simultaneously. ESP32 may measure without managing to send. The service may respond with an earlier reading while the sender is disconnected. The app may retain a visible number after a failed query. A number on screen therefore proves neither a current measurement nor physical assembly. A test identifier and timing record can track a reading without adding personal data. The project can operate on an authorised local network without public Internet; that choice defines dependencies we must explain and test.

WiFi connects a device to a wireless network; HTTP organises application requests and responses. A WiFi connection does not guarantee service availability. BLE is another technology requiring compatible components and programming; it does not automatically replace HTTP exchange. In the classroom architecture, ESP32 is a client of the prepared network, and the service computer must be reachable from authorised devices.

An IP address identifies an interface on its network. The port identifies where the process listens and the path identifies the requested resource. The form http://address:8000/lectura distinguishes those parts without inventing the school’s actual configuration. 127.0.0.1 and localhost refer to the device itself: on a tablet they do not reach the service computer. A server listening only there does not thereby accept other devices’ connections. The teacher prepares listening interface, network and firewall; changing the client address does not configure the server or enable authorised access.

JSON represents data using names, values and types. The laboratory contract accepts valor as a finite number between 0 and 100 and unidad as the exact text escala. The number 42 is not the string “42”, and a similar name does not replace an agreed key. The receiver must check fields, types and domain: receiving text resembling JSON does not establish that it contains an interpretable reading.

The scale is educational and normalised, without assigning lux, centimetres or physical humidity percentage. The first ESP32-generated series is labelled SIMULADO. To incorporate the validated sensor, replace the reading function and document any conversion, retaining origin and limitations. Changing a label does not transform simulation into a real measurement. The service adds receipt time and rejects invalid messages without replacing the last valid reading. Receiver-side validation matters because another client may send unexpected data even when the team’s sender works correctly.

HTTP organises an exchange between a client requesting an action and a service responding to it. A request includes a method, destination, headers and, where appropriate, a body. In the laboratory, POST sends a reading and GET queries the latest available one. The access key travels in a header and the measurement is represented in the JSON body. This separation helps explain what is requested, which resource is addressed and what information is supplied; sending the request does not yet confirm that the service accepted it.

The response contains a code and content that must be interpreted together. The school contract uses 201 for an accepted submission, 400 for invalid data, 401 when valid credentials are missing and 404 for an unknown path. These outcomes describe the service’s response rather than universal sensor messages. Receiving a rejection establishes that a response arrived, even though the requested action was not authorised or accepted. An error message must therefore not become confirmation of an update.

Even a query returning code 200 requires examining its contents. Before the first accepted submission, it may return disponible: false: communication worked, but SIN DATOS should be displayed. Showing zero would invent a reading. The client checks the code first, then the structure, and finally data availability and age. This sequence distinguishes absence of a reading, rejection and no response. It also directs investigation towards the observed stage instead of blaming every problem on WiFi or treating any received text as valid.

Asynchronous communication separates requesting information from receiving it. When Update is pressed, the app prepares Web.Url and RequestHeaders, displays CONSULTANDO and calls Get. A new response may still not exist after that call. The label can retain the previous query’s number because its contents do not change simply because another reading was requested. The waiting state explains what is happening while the app continues responding to user interaction.

Reception is handled in GotText using responseCode and responseContent. SaveResponse must be disabled for this text-based path. The code identifies the appropriate response branch; the JSON is then interpreted and its structure checked before its fields are used. JsonTextDecodeWithDictionaries turns JSON text representing an object into a dictionary, where each key locates its value by name. Obtaining the dictionary does not replace checking that the expected data are present and meaningful under the contract.

Waiting also needs an outcome when no response arrives. A finite Timeout allows TimedOut to be tested and the expired interval to be communicated; other component errors likewise require an understandable message. The initial version uses a button so each phase can be observed. If a clock is added later, requests must not accumulate without control. Pending state belongs to that query and is temporary. Saved local configuration may help prepare another request, but it does not establish that a current reading has been received.

edad_s expresses elapsed time since the service received its last valid reading. In the project, an age above ten seconds produces DATO ANTIGUO; this interval is a teaching decision, not a universal rule. An accessible service with stale data differs from an inaccessible service. If querying fails, the app must show SIN CONEXIÓN or the appropriate error rather than silently presenting the last number as current.

Receipt time does not always equal physical measurement time: a device storing before transmission can introduce delay. Here measurement and sending happen close together, and that simplification is stated. After communication recovers, a new reading can equal the previous value; renewal is established through receipt and age, not mandatory numeric change. Test a stopped sender, stopped service and inaccessible tablet separately. Record what each observation distinguishes and what remains uncertain, without attributing every missing response to one cause.

The laboratory service checks a header key to reject unauthorised requests. That control does not encrypt traffic: local HTTP leaves content without transport protection. Authenticating access, limiting permissions, encrypting and recovering files address different needs. The practice runs on a teacher-prepared isolated network, exposes no Internet ports and includes no personal data. A real service would need controls appropriate to its context.

Access configuration stays outside the submission; secrets.example.h shows names with fictional values while secrets.h remains on the authorised device. Review screenshots and copies too. Restoring a backup demonstrates file recovery, not secrecy during communication. Cloud architecture adds a provider, accounts, remote access, retention and Internet dependence. A local service depends on the laboratory computer and network. Compare purpose, outgoing data, audience and disconnection behaviour; study the alternative using a diagram and prepared screenshots without creating or publishing services.

Integration checks that contracts match from end to end. A physical reading needs a sensor sheet, interpretation and documented conversion; a simulated series establishes only the stages it uses. The microapp must actually query and display waiting and a validated response. An architecture diagram or prepared screenshot does not replace performing the initial reading–sending–querying chain included in A01.

Final tests include five valid values, an out-of-contract message, wrong key, staleness after stopping the sender and recovery with new data. Add initial absence and communication failure to explain view states. Record input or action, expected response, observation and conclusion in temporal order. An improvement requires repeating comparable cases and retaining editable board and app files. Each partner explains events, storage used and a modification. The result recognises limitations of the local service, unencrypted HTTP and available diagnostics without turning a school demonstration into a public deployment.