Automation means preparing rules so that a system responds to inputs without a human command for every action. First define the need: which situation we want to recognise, which response would help and when it would be unnecessary. A requirement turns an intention such as ‘improve the classroom’ into testable behaviour. It must state conditions, response and scope. Our model represents a classroom need, but it does not modify the electrical installation or demonstrate energy savings by itself.

Manual control depends on a direct command; automatic control interprets inputs. Both can coexist if their priority is defined. An override must prevent the output even when the automatic rule requests activation. The system must also communicate whether it is enabled: permission to operate and a sensor alert are different information. Usefulness is justified by comparing the model with and without automation, considering reused materials and avoided actions. Claiming measured savings would require measuring consumption under comparable conditions.

Inputs carry information with different meanings: a measurement describes a situation, while a command expresses a choice. In our model, integrated light sensing provides a number and a button produces an event. Understanding that difference requires separating the physical quantity from its representation. An analogue signal can vary continuously; a digital signal distinguishes discrete states. A converter represents analogue values as digital numbers. A comparison then turns a reading into a Boolean condition, whose result can only be true or false.

These conditions form the control rule. AND requires both to be true, whereas OR accepts at least one being true. Changing the operator therefore changes the response even when the inputs and wiring stay the same. A truth table brings together the four possible combinations of two conditions and helps check the difference each rule makes. Its value lies in relating each combination to the requirement the system must meet.

Operation also depends on what is remembered between readings. A brief press can change the Boolean variable habilitado and preserve the choice after the button is released. While events change this enabling state, the loop measures again and consults the retained permission to decide. Reinitialising the variable inside the loop would break that continuity: the next cycle would overwrite the choice. Measurement, condition and memory therefore work together to produce a consistent response.

A threshold is a reference against which we compare a reading to make a decision. Choose it from observations, not because a number is convenient. In MakeCode, micro:bit’s integrated light sensing uses a relative scale from 0 to 255: larger numbers represent more light. These are not lux. The first call starts sensing and returns 0; start the reading and allow it to update before collecting the useful observation series.

Collect five readings per condition, keeping position, orientation and procedure consistent. Record the scale and origin of the data, including when an external module is used. Two devices may show the same number with different meanings or reverse the direction of response. If series overlap, one boundary cannot separate them perfectly. Revising placement or describing uncertainty is more honest than deleting values. This characterisation relates the reading to the observed situation; it does not automatically turn the relative scale into a calibrated physical unit.

A reading can fluctuate slightly even when the observed situation seems stable. With a single threshold, a small variation can put it on one side of the boundary and then the other. If every crossing requires switching on or off, the alert changes repeatedly without a substantial change in the surroundings. Hysteresis reduces this instability by using one limit for activation and another for deactivation. In the workshop, the alert activates with light below 45 and deactivates with light above 55; these are relative-scale references, not universal illumination values.

Separating the limits creates a region in which the previous state is retained. Knowing only the current reading therefore does not always predict the output: the alert’s previous state and the program’s starting state also matter. The workshop comparisons are strict. A reading exactly equal to 45 or 55 does not meet the condition for a change and preserves memory. The previous state is part of the decision, rather than an incidental item in the record.

This relationship explains why checking requires sequences from both initial states. An isolated reading does not show which transition occurred. Hysteresis changes the conditions for switching; averaging combines readings, while waiting delays actions. These are different approaches. The guided improvement explores fewer changes near the threshold, but it neither makes an unsuitable sensor suitable nor eliminates every disturbance.

A controller interprets inputs and generates commands; an actuator turns a command into a physical effect. An LED can communicate and a servo can move a part. The signal expressing a decision is different from the power supply providing energy. A signal pin must not be used as a direct power source for a motor. The validated interface adapts the command to the component and may require a specific supply, according to its documentation and authorised assembly.

Separating the decision from applying the output preserves the logic when replacing the LED matrix with a compatible indicator. The alert variable expresses intention; the output block translates it. Some modules activate at different logical levels: active polarity must be checked. micro:bit, ACEBOTT and Echidna Black2 can be studied as stations with similar functions without assuming interchangeable wires, voltages or programs. Record board, module reference, voltage, signal, connector and environment; connect with power off and use only the diagram reviewed with the teacher.

A design must state what happens at startup, override and re-enabling. For this model, the output starts inactive and override prevents later automatic requests until enabling again. In the guided improvement, B disables the system and sets alert false; A allows the current reading to be interpreted again. If the reading lies between thresholds, the state left by override matters. Adding a button is insufficient if the loop immediately activates the output again.

The response to a lost input depends on what the program can actually recognise. An in-range number may come from a stuck sensor; checking the interval alone does not detect that problem. Record symptom, hypothesis and a test to investigate it. This model adopts an inactive output for the anticipated fault, without claiming that switching off is always safe in every system. Test override while the automatic rule is requesting action: pressing stop when everything is already off provides little evidence of its priority.

Integration means checking that the parts cooperate according to the requirements. First read inputs; then determine the new state; finally apply a consistent output. A trace records that path cycle by cycle, including reading, enabling, previous state and new state. Simulation controls values and explores boundaries, but it does not demonstrate wiring, real sensor response or power supply. Physical verification requires the validated assembly and a record identifying its test conditions.

Design assignment A01 brings together requirements, diagram, algorithm, resources and an already completed micro-test; it is more than a promise to build. Product assignment A02 includes editable code, assembly, tests and an evidenced improvement. Intermediate practice contributes to these two assignments without creating another. To compare an improvement, keep conditions consistent and change one decision at a time. Record unexpected results too and limit conclusions to observations. Each partner must trace data to an effect and explain a personal decision, prediction and concrete modification or review.

Technical documentation answers a specific question. The lightLevel reference explains range and first reading; the safety guide supports checking board handling. A tutorial may demonstrate an application, but its decisions do not replace your requirements or guarantee compatibility. Before adapting an example, identify version, input, output, conditions and expected result. This turns a recipe into an explanation you can defend in a different situation.

Transfer preserves a pattern while reviewing context-dependent details. Changing from light to another sensor might preserve read, decide and act, but require checking scale, reading direction, thresholds and interface. Replacing an icon with a motor also changes resources and physical response. Optional videos can be paused and supported by text; they are not required to complete the mission. In Google Docs, record which question each source answers and what remains untested. Use compatible permissions and attribution for external resources, without confusing citation with permission to reproduce them.