Once a remote system can press the bath button, it is tempting to say that it can prepare the bath automatically.
A toggle has no desired state, however.
The same command starts a stopped system and stops one that is already running.
Safety scope: This external-servo prototype is not a manufacturer-approved remote control. Do not run it unattended; test only while a person can verify water level, temperature, and overflow, and always follow the heater manual and built-in controls.
The implementation exposes POST /bath/switch/toggle, which sends the configured press pulse to the ESP32 servo, waits briefly, and then sends the release pulse.
No API route reports the current bath state, so the system cannot establish whether the appliance is running or stopped.
Endpoint success proves only that both press and release HTTP requests received 2xx responses; it does not verify physical servo movement, panel acceptance, or the start, completion, or stop of a fill cycle.
“Automation” in this article means a prototype path that assists the normal switch of an existing appliance.
It does not bypass the water heater's safety mechanisms or directly control combustion or water supply.
What is currently established
Separating the evidence into levels makes the status clear.
Item
Verification
What can be claimed
Toggle endpoint
Verified in code
POST /bath/switch/toggle requests press and release in sequence
Servo HTTP responses
Code-level success condition
The endpoint succeeds when both requests return 2xx; physical movement remains unverified
Current state retrieval
Not implemented
The API cannot establish whether the system is running
Bath fill started
Unverified
There is no evidence that the appliance accepted the action
Bath fill completed
Unverified
There is no evidence that the tub received the intended amount of hot water
A prototype with a small servo and control board mounted in front of a wall panel
Photo: a prototype that adds a small servo and control board to an existing wall panel. The image alone does not verify physical pressing, panel acceptance, or bath-fill state.
Photo safety note: The low-voltage board and wiring are exposed in this prototype. A splash-resistant enclosure, wiring strain relief, and permanent-installation safety have not been verified. Keep it away from water and humidity, and do not leave this configuration installed or operating unattended.
The current system should not be described as finished bath automation.
It is a prototype remote-toggle path.
Toggles fail badly under retries
Network operations time out and retry.
If the first toggle reached the appliance but only its response was lost, sending the same toggle again can stop a cycle that just started.
A person pressing a button can use an indicator light or appliance sound to judge the result.
Remote control needs its own observation path.
For a bath, “request accepted,” “filling started,” and “target fill completed” are three different states.
Combining them into one success flag can report an empty tub as ready or issue another toggle during operation.
Prefer explicit start and stop
A safer API describes the desired state instead of exposing an unknown toggle.
Start acts only when the system is stopped.
Stop acts only when it is running.
If the desired state already exists, return the same result without changing anything.
If current state cannot be observed, fail rather than guessing and pressing.
This property is called idempotency.
Receiving the same request twice does not reverse the result.
When the existing appliance accepts only toggle input, the automation layer must observe the current state before pressing the switch once.
Until that observation exists, automatic retries should be disabled and control should return to a person.
What should be observed
Choose a way to observe state without modifying the existing appliance and while keeping the manufacturer's safety mechanisms intact.
Possible signals include:
Detecting the position of the mechanism that presses the switch.
Reading the control-panel indicator with a light sensor that has no electrical connection to the appliance.
Using an official integration or notification offered by the appliance.
Using an independent temperature or flow sensor when it directly matches the required outcome.
No single signal necessarily proves that the bath is ready.
The press-mechanism position can show that the mechanism moved, but it does not prove panel contact or successful hot-water delivery.
An indicator can show operation without proving the tub's water level.
Define the completion condition first, then select an observation that measures it.
If the goal is “ready to bathe,” command transmission alone is insufficient.
Build timeout and manual recovery first
Bath automation handles water and heat.
Stopping conditions must exist before a convenient start control.
Do not act when current state is unavailable.
After starting, if no progress is observed within a set time, report a fault and stop the automation workflow.
Do not resend the toggle; confirm appliance shutdown on site using the manufacturer's normal manual control.
Do not automatically repeat the same command.
Preserve the appliance's existing safety controls and manual operation when communication fails.
Keep a person present during physical tests; do not begin with unattended operation.
Never bypass the water heater's own interlocks.
The automation layer should assist the normal control and return to manual operation whenever state is uncertain.
What Jarvis should say
With the current prototype, even an endpoint success response does not justify saying “Your bath is ready.”
“The press and release requests to the servo succeeded; physical pressing, fill state, and completion are not verified” matches the available evidence.
Even after observation is added, start, progress, and completion should remain separate notifications.
The final completion message should be emitted only when an independent observation satisfies the defined condition.
The first component to build is not a finger that can press the button.
It is an eye that can observe the result and a rule that stops when the result is unknown.
HTTP idempotency informs retry design; it does not certify a water heater. Confirm temperature limits, permitted remote controls, and stopping behavior in the exact model manual.
