Experiment record

SwitchBotとGoogle Apps Scriptによる住宅環境の長期収集・外部気象連携・解析(改訂版)

12台のSwitchBot環境センサーを約5分周期で継続収集する住宅環境ロガー。元の物理解析は2026-07-28~08-13の104,578行を対象とし、2026-09-06の長期監査では非公開Measurementsが270,760行まで増加、SUCCESS 270,698・ERROR 62(行ベース成功率約99.977%)となった。ただしRaw行数は一意な5分観測slot数と同義ではないため、完全性評価には時刻正規化が必要である。

結論

SwitchBot環境センサー、SwitchBot OpenAPI v1.1、Google Apps Script、Google Sheetsを組み合わせ、住宅内外の温度、相対湿度、絶対湿度、CO₂等を継続保存する長期データ基盤を構築した。最終構成では12台の環境センサーを対象としている。

元の物理解析区間は2026-07-28 05:28頃~2026-08-13 21:28頃で、Measurements 104,578行、SUCCESS 104,564行、ERROR 14行だった。この区間について、屋根裏の大きな温度変動、床下の高相対湿度と外気に近い絶対湿度、CO₂の一時ピーク、住宅外気センサーと外部気象観測の高い相関を確認した。

2026-09-06に長期保存状態を再監査したところ、非公開の Measurements は 270,760行まで増加していた。行ベースのAPI状態は SUCCESS 270,698行、ERROR 62行、成功率約99.977% だった。

ただし、この270,760行をそのまま「5分周期の観測成功数」と解釈してはならない。長期Rawには取得対象時刻と記録時刻があり、異なる時刻パターンの行が混在することを確認した。そのため、Raw行数は一意なnominal 5分slot数と同義ではなく、欠測率・完全性は時刻を正規化してから評価する必要がある。

この長期更新では、元の温熱・湿気・CO₂統計を新しい全期間統計へ置き換えていない。旧統計と図は元の検証済み解析区間に限定して有効であり、2026-09-06までの全期間統計はslot正規化・重複/遅延行の扱いを確定してから再計算する。


2026-09-06 長期観測アップデート

観測された事実

項目2026-08-13時点の元解析2026-09-06長期監査
観測開始2026-07-28 05:28頃同左
観測終端2026-08-13 21:28頃2026-09-06 23:10頃(取得対象時刻)
Measurements 行数104,578270,760
SUCCESS104,564270,698
ERROR1462
行ベース成功率約99.987%約99.977%
有効環境センサー12台12台

ERROR の絶対件数は14件から62件へ増えたが、データ量と観測期間も大きく増えている。したがってエラー件数だけから信頼性が悪化したとは判断できない。

新たに確認したデータ品質上の論点

Rawの末尾付近を監査すると、同一センサーについて、5分境界に対応する取得対象時刻の行と、それとは異なる実取得/記録タイミングを反映した行が交互に存在する区間がある。このため、行数だけを期待5分slot数と比較すると、完全性を誤判定する可能性がある。

長期収集の品質評価では、少なくとも次を分離する。

  1. API行品質:各保存行が SUCCESS / ERROR のどちらか。
  2. 測定値品質:通信成功でも値が物理的に妥当か。
  3. slot完全性:本来取得すべき5分slotが存在するか。
  4. 時刻品質:取得対象時刻、実取得時刻、保存時刻のずれや重複がないか。

この区別により、「API成功率99.977%」と「5分slot欠測率」を同じ指標として扱わない。


公開時のプライバシー境界

本記事は実験結果と実装・解析方法を公開するものであり、生の家庭内テレメトリを公開するものではない。認証情報、deviceId、Spreadsheet ID、個人を識別し得る部屋名、正確な住宅位置、具体的な外部観測地点、生の5分時系列は公開しない。

公開するのは、取得周期、データ構造、匿名化した解析地点、集計条件、統計量、解析図、運用上の失敗と修正方針である。


1. 実験の目的

市販IoT環境センサーを現在値確認だけに使うのではなく、時系列として保存し、後から住宅の熱・湿気・換気特性を解析できる基盤を作ることを目的とした。

主な問いは、外気・居室・床下・屋根裏の応答差、高相対湿度が実際の水蒸気量増加を意味するか、CO₂が換気・在室変化の手掛かりになるか、住宅外気センサーが地域気象とどの程度一致するか、長期自動収集でどのようなデータ品質問題が生じるか、である。


2. システム構成

確認された基本経路は次のとおり。

SwitchBot環境センサー
        ↓
SwitchBot Cloud
        ↓
SwitchBot OpenAPI v1.1
        ↓
Google Apps Script
        ↓
Google Sheets

測定値本体、端末設定、実行ログ、設定、外部気象を分離して保存した。環境センサーのdeviceTypeとして Meter、MeterPlus、MeterPro(CO2)、WoIOSensor を確認した。

取得処理はnominal約5分周期で、各端末のstatusを取得し、温度・相対湿度・絶対湿度・CO₂(対応機器)・電池残量・API状態等を保存した。1台の一時的失敗で全体を停止しないよう、端末単位で例外処理した。

LockServiceについての後続評価

初期実装では多重実行防止のため LockService を使用していた。これは歴史的実装事実として保持する。ただし後続監査では、ロック取得失敗時に観測自体が行われない制御フローがsilent gapを作り得ることが別途検討対象となった。

したがって、本記事では「LockServiceを使ったから5分Rawが完全だった」とは主張しない。長期完全性は保存行数ではなく、観測時刻を基準に別途検証する。


3. 絶対湿度

相対湿度は温度に強く依存するため、温度と相対湿度から絶対湿度を計算して保存した。

e_s = 6.112 × exp((17.67 × T) / (T + 243.5))
AH = (2.1674 × e_s × RH) / (273.15 + T)

T は温度[℃]、RH は相対湿度[%]、AH は絶対湿度[g/m³]である。20℃・50%RHでは約8.64 g/m³となることを実装時に検算した。


4. 元の検証済み物理解析区間

以下の統計・図はすべて 2026-07-28 05:28頃~2026-08-13 21:28頃 の104,578行を対象とする。2026-09-06までの全期間へ自動的に一般化しない。

4.1 温度

住宅内外の温度推移(1時間平均)

場所平均温度最低温度最高温度
外気26.90℃21.2℃37.6℃
リビング25.80℃異常低値1件を確認27.4℃
1F床下24.84℃23.9℃26.2℃
2F屋根裏29.09℃20.9℃44.3℃

屋根裏は大きな熱的変動を示し、床下は比較的狭い温度範囲だった。これは観測された温度応答からの解釈であり、熱流束を直接測定した結論ではない。

4.2 床下の相対湿度と絶対湿度

外気と1F床下の相対湿度の平均日内変動

外気と1F床下の絶対湿度の平均日内変動

場所平均相対湿度平均絶対湿度
外気約78.7%RH約20.08 g/m³
1F床下約86.9%RH約19.86 g/m³

床下は高い相対湿度を示したが、絶対湿度は外気と近かった。この区間では、床下の高%RHは水蒸気量の大幅な超過だけでなく、低温の寄与を強く受けていると推定した。結露・カビリスクの否定を意味するものではない。

4.3 CO₂

リビングCO₂濃度の推移(1時間平均)

指標CO₂
中央値約729 ppm
95パーセンタイル約906 ppm
最大値2,037 ppm
1,000 ppm以上約2.1%
1,500 ppm以上約0.94%

一時的なピークは確認されたが、具体的な生活イベントとの因果対応はこの観測データだけでは確定していない。

リビングCO₂濃度の平均日内変動

4.4 外部気象との比較

自宅外気センサーと外部気象観測の比較(1時間平均)

比較対象気温相関係数SwitchBot外気との平均差
匿名化した外部公開観測A約0.924SwitchBot側が約+1.72℃
匿名化した外部公開観測B約0.944SwitchBot側が約+1.16℃

高い相関は地域的な温度変動を追従していることを示す。一方、平均差には設置条件、局所微気象、センサー差等が混在し得るため、校正誤差だけとは断定しない。


5. SUCCESS と測定値品質は別である

元の解析で、物理的に不自然な0.0℃値が SUCCESS 行に含まれていた。したがってHTTP/APIが成功したことと、測定値が解析に適格であることを分離する必要がある。

Rawは監査用として保持し、解析時には VALID、MISSING、OUTLIER、INVALID 等の品質状態を別途付与する設計が望ましい。


6. 外部気象APIの運用上の失敗

外部気象取得ではOpen-Meteoを試したが、長期無人運用でアクセス上限に関連する欠測が発生した。呼び出し頻度を下げても必要な連続性を満たせず、主要データ源から外した。

ここから、APIが技術的に呼び出せることと、必要な期間・頻度で安定運用できることは別の実験条件であると判断した。


7. 制限事項


8. 今後の解析

長期データでは、まず取得対象時刻・取得時刻・保存時刻を整理し、nominal 5分slotへ正規化した上で欠測・重複・遅延を品質フラグ化する。その後に全期間の温度、RH、AH、CO₂統計、季節変化、外気→屋根裏/床下の時間応答、設備運転との関係を再計算する。

特に、Rawの完全性評価と物理解析を分離する。欠測補間値を実測値として扱わず、原Rawは変更せず保持する。


9. 再現性の境界

再現に必要なのは、所有する環境センサー、OpenAPI認証、Apps Script、約5分周期のスケジューラ、測定/設定/ログの分離、絶対湿度計算、端末単位の例外処理、時刻品質と異常値を扱う解析工程である。

一方、認証情報、deviceId、Spreadsheet ID、個人宅固有名称、正確な住宅位置、生の家庭内テレメトリは技術的再現に不要なので公開しない。


10. Revision history

まとめ

この実験の価値は、住宅環境の長期Rawを蓄積したことだけでなく、通信成功、測定値妥当性、観測slot完全性を別々の品質軸として扱う必要があることを実運用から確認した点にある。

2026-09-06時点でデータ蓄積は継続しているが、長期物理統計は「行数が増えたから更新する」のではなく、時刻と欠測を正規化した後に再検証する。元の観測結果、失敗、後続の品質問題を同じEvidence Chainに残す。