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.
We confirmed that a route exists for sending a bath-switch toggle.
The attempted state route returned 404, so it did not provide the current state.
We did not verify physical start, completion, or stop of a bath-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 command route
Verified
There is an entry point for requesting a switch action
Toggle-route invocation record
Verified
Prior records show the route was invoked, but downstream transmission and device reception are unverified
Current state retrieval
Unverified
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
Photo: a prototype that adds a small servo and control board to an existing wall panel. The image alone does not verify command transmission, appliance reception, or bath-fill state.
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.
A switch position proves that a press occurred, not that hot water flowed.
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, the correct response after sending a toggle is not “Your bath is ready.”
“The switch action was sent; 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.
