Experiment record
Rinnai API 401 ERR_0010: recovering a Kantakun Apps Script collector
A Google Apps Script Kantakun collector received Rinnai HTTP 401 / ERR_0010. The failure was localized to the Rinnai authentication path, and the retained implementation did not demonstrate a verified automatic credential-renewal path. A later retained record states that authentication was restored, but the exact recovery operation is unknown.
Summary
A Kantakun collector running in Google Apps Script stopped after the Rinnai API returned HTTP 401 / ERR_0010. Review of retained execution evidence and implementation details localized the incident to the Rinnai authentication path rather than a general Google Apps Script failure or downstream Kantakun state-processing logic.
The retained implementation read a bearer token from Apps Script Script Properties. When HTTP 401 occurred, it stopped with an error; no verified automatic token-renewal and bounded-retry path was retained in that code.
A later retained record states that authentication was restored during separate follow-up troubleshooting. The exact corrective action is not present in the retained evidence. This Experiment therefore does not claim a verified refresh endpoint, refresh-token flow, re-login method, header correction, or token lifetime.
Background
The Kantakun state and utility-cost collector had been running on a scheduled Google Apps Script path when the previously working collection stopped with Rinnai API HTTP 401 / ERR_0010.
Other scheduled work in the same Apps Script environment continued to run, so the investigation needed to distinguish a Kantakun-specific authentication-path failure from a broader collector or Apps Script failure.
The purpose of this Experiment was to localize the failure using retained HTTP responses, execution history, stack traces, and implementation details, and to identify the credential-lifecycle issue and the uncertainties that matter for handling the same class of failure in long-running operation.
Methods
Experimental target
The Experiment target was a Rinnai gas clothes dryer, Kantakun RDT-93.
The model was confirmed on August 23, 2026 from the experiment-used unit. That later model confirmation did not rerun or reverify the August 14 authentication incident.
Experimental environment
- iPhone Kantakun app: traffic-observation target during protocol investigation. The exact app version used at the time is not retained.
- Local HTTPS inspection environment: used to inspect request structure from app traffic. The retained evidence does not establish the exact inspection product, so no specific tool name is asserted.
- Google Apps Script: used for test access to the Rinnai API and scheduled collection.
- Script Properties: used to keep runtime authentication material separate from source code.
- Rinnai API: target service for Kantakun state and utility-cost data.
- Apps Script execution history and stack traces: used to localize the HTTP failure.
The app-traffic observation provided enough request structure to test the Rinnai API from Google Apps Script. The conceptual paths were:
iPhone Kantakun app
→ local HTTPS inspection environment
→ API request-structure observation
Google Apps Script
→ Rinnai API request
→ authenticated request
→ Kantakun state / utility-cost data
→ collection and aggregation logic
Diagnostic method
The investigation compared the API response, Apps Script execution history, stack trace, and retained implementation around rinnaiGet_(). Successful unrelated scheduled work in the same Apps Script environment was used as negative evidence when localizing the fault.
Experiment Log
HTTP 401 / ERR_0010 observed
The representative response was:
HTTP 401
errorCode: ERR_0010
message: token is invalid
The stack trace identified this failure path:
rinnaiGet_()
→ pollKantakun_()
→ pollKantakunHourly()
Other scheduled collection work visible in the same Apps Script execution history completed successfully. This argues against treating the incident as a general time-driven-trigger or Apps Script outage.
Retained authentication implementation reviewed
The credential was read from Script Properties rather than hard-coded into ordinary runtime code. The actual property-key name is not needed for reproduction and is omitted from the public example:
const token = PropertiesService
.getScriptProperties()
.getProperty(TOKEN_PROPERTY_KEY);
The retained rinnaiGet_() path raised an error and stopped when HTTP 401 occurred. It did not demonstrate a verified token-renewal operation followed by one bounded retry.
Recovery result
A later retained record states that authentication was restored during separate follow-up troubleshooting. The specific change history from that work is not present in the retained evidence.
The retained evidence therefore does not establish whether recovery used bearer-token replacement, a refresh-token exchange, fresh login/authentication, header correction, or another implementation change.
Conclusion
HTTP 401 together with Rinnai ERR_0010 supports localizing the incident to the Rinnai authentication path. Other scheduled Apps Script work continued successfully, so the retained evidence does not support describing the incident as a general trigger or platform outage.
The retained implementation also establishes that the investigated 401 path stopped without a verified automatic credential-renewal and bounded-retry mechanism. Long-running unattended collection therefore cannot safely assume indefinite validity of a previously captured bearer token.
A later record indicates that authentication was restored, but the exact successful corrective operation is not established by the retained evidence. No specific refresh endpoint, token lifetime, refresh-token semantics, or recovery mechanism is therefore concluded by this Experiment.
Evidence summary
The Evidence States for the information obtained in this Experiment are as follows.
| Recorded content | Evidence State | Basis in this experiment |
|---|---|---|
| The incident was in the Rinnai API authentication path rather than a general Apps Script outage | VERIFIED | HTTP 401 / ERR_0010 plus successful unrelated scheduled work |
| The failure occurred before Kantakun payload processing and downstream aggregation | INFERRED | The authentication helper failed before downstream logic was reached |
| The retained collector did not demonstrate verified automatic token renewal and bounded retry on 401 | OBSERVED | The retained 401 path stopped immediately with an error |
| The exact operation that restored authentication cannot be established from retained evidence | OBSERVED | A later recovery record exists, but the specific follow-up change history is unavailable |
| Long-running unattended collection should explicitly manage credential lifecycle | INFERRED | An invalid credential stopped collection and the retained path lacked verified renewal logic |
See Evidence State for the shared definitions.
Unresolved questions
The retained evidence does not establish:
- the exact Rinnai token lifetime;
- revocation or rotation conditions;
- an official refresh endpoint;
- whether a refresh token exists and, if so, its semantics;
- the exact successful corrective operation used during later troubleshooting.
These points cannot be decided from the currently retained evidence. Confirmation requires either authoritative Rinnai documentation or direct observation of the authentication-renewal behavior and successful recovery sequence.
Operational implications
For continuous Kantakun collection, authentication failures such as HTTP 401 should be detected separately from ordinary data gaps or transient API failures. Until authentication is restored, downstream aggregation should not receive missing or invalid Kantakun state and utility-cost data as though they were valid observations.
Cost-settlement delay handling, estimated usage calculations, aggregation with other equipment data, and similar downstream processing should operate only on data obtained through a successful authenticated request.
For long-running unattended collection, distinguish ordinary API errors from authentication errors. Only when a credential-renewal method has been directly confirmed or authoritatively documented should the collector attempt that renewal, and the retry should be bounded. If no confirmed renewal method is available, or if a bounded retry still returns 401, collection should stop that path and retain non-secret diagnostic information. Unbounded re-login or retry loops should be avoided.
Experiment data
Complete original execution logs and the full collector source are not retained as public artifacts. This limits retrospective analysis of the exact recovery action and token lifetime.
Reproduction resources
The main resources needed to understand or reproduce the diagnostic method are Google Apps Script, a private secret/configuration store such as Script Properties, authorized access to the relevant Rinnai API environment, and a logging/diagnostic environment capable of capturing and inspecting HTTP status, API error information, and stack traces.
The historical execution log itself is not a reproduction prerequisite; the requirement is the ability to obtain equivalent diagnostic information during a new test. No dedicated purchasable hardware is required as a reproduction prerequisite for this authentication incident.
Reproduction considerations
Keep authentication/authorization material and information that could identify a specific unit or installation out of source code and public logs, and store necessary secrets in an appropriate secret/configuration store. The 401 fault-localization method and credential-lifecycle design can be reproduced without sharing the original private information.
Machine-readable experiment record
A machine-readable canonical record of this Experiment is published as JSON.