Home Assistant World Clock & Weather Dashboard 第２章

2026.08.10

Chapter 2 — Design Philosophy

2.1 Home Assistant Standard First

Version 1.3 の基本方針。

2.2 Why Standard Components?

なぜ独自方式より Home Assistant 標準の仕組みを優先するのか。

2.3 From REST Sensor to Weather Entity

Version 1.0～1.2で使用した方式から、Version 1.3 の weather.xxx へ移行した理由。

2.4 Role of Template Sensors

weather.tokyo と sensor.weather_tokyo の役割を分ける理由。

2.5 Keep the Dashboard Structure

ビュー → パネル → Grid → button-card を維持する理由。

2.6 Maintainability

16都市を管理しながら、設定を理解しやすく保つ考え方。

2.7 Scalability

現在16都市、将来20～30都市へ拡張するための考え方。

2.8 Design Principles Summary

ここまでの設計思想を一枚に整理。

特に 2.3「REST SensorからWeather Entityへ」 は、今回の実際の開発経験を反映できる重要な章になります。

単に、

「REST SensorよりWeather Entityの方が良い」

と書くのではなく、

Version 1.0～1.2

Open-Meteo API
      ↓
REST Sensor
      ↓
sensor.weather_tokyo


Version 1.3

Open-Meteo Integration
      ↓
weather.tokyo
      ↓
Template Sensor
      ↓
sensor.weather_tokyo

という変化そのものを示します。

そうすると、第1章の Project History ともきれいにつながります。

そして Chapter 2 の最後から Chapter 3 へ、

「では、この設計思想を実際の Home Assistant 上でどのような構成にしたのか？」

と自然につなげます。

そこから Chapter 3 — System Architecture で、いよいよ具体的な構成図と各エンティティの関係に入ります。

ですので、次は Chapter 2 の完成原稿そのものをお渡しします。
今回は「もう少しお待ちください」ではなく、ここまで構成が固まっていますので、次の段階へ進めます。

次は Chapter 2 の完成原稿を見せて

もちろんです。
第1章で「なぜこのプロジェクトを作るのか」を説明しましたので、第2章では一歩進んで、

「なぜ Version 1.3 はこの構成になっているのか」

を説明します。

特に今回の開発で実際に経験した REST Sensor → Open-Meteo Weather Entity → Template Sensor という変化を、単なる試行錯誤ではなく、Version 1.3 の設計思想へつながる流れとして整理しました。

Home Assistant World Clock & Weather Dashboard

Version 1.3 Build Guide

Chapter 2

Design Philosophy

2.1 Version 1.3 の設計思想

Version 1.3 の基本方針は、

Home Assistant Standard First

です。

これは、

「できるだけ Home Assistant が標準で提供している機能を利用する」

という考え方です。

Home Assistant は非常に自由度の高いシステムであるため、同じ目的を実現する方法が複数存在します。

例えば気温を取得する場合でも、

  • REST API を直接呼び出す
  • REST Sensor を作成する
  • 統合（Integration）を利用する
  • Template Sensor を利用する
  • ダッシュボード側の JavaScript で直接処理する

など、さまざまな方法があります。

しかし、方法が自由だからといって、すべてを自由に組み合わせればよいわけではありません。

本プロジェクトでは、

Home Assistant が本来想定している仕組みに沿って構成すること

を優先します。

その理由は、将来的な保守や拡張を容易にするためです。

2.2 「動く」だけではなく「管理できる」こと

Home Assistant では、目的の情報が表示されれば一応システムは完成します。

しかし、本プロジェクトでは、

「現在動いている」だけでは十分ではない

と考えます。

例えば、

東京
 ↓
REST Sensor
 ↓
sensor.weather_tokyo
 ↓
button-card

という構成が動作していたとしても、

  • このセンサーはどこで定義されているのか
  • 何を情報源としているのか
  • 他の都市を追加するときはどこを変更するのか
  • Home Assistant の標準機能とどう関係しているのか

が分かりにくければ、将来的な管理が難しくなります。

特に都市数が16、20、30と増えていけば、この問題はより大きくなります。

そこで Version 1.3 では、

「動作すること」＋「構成を理解しやすいこと」

を重要な設計目標としています。

2.3 REST Sensor から Weather Entity へ

Version 1.3 の構成を理解するうえで重要なのが、気温情報の取得方法です。

Version 1.2 までの構成では、Open-Meteo API に直接アクセスする REST Sensor を利用していました。

例えば東京の場合、

sensor:
  - platform: rest
    name: weather_tokyo
    resource: "https://api.open-meteo.com/v1/forecast?latitude=35.69&longitude=139.69&current=temperature_2m&timezone=Asia%2FTokyo"
    value_template: "{{ value_json.current.temperature_2m }}"
    unit_of_measurement: "°C"
    scan_interval: 900

という設定です。

この方式には大きなメリットがあります。

APIから必要な値を直接取得できるため、仕組みが分かりやすく、気温表示だけなら十分に機能します。

しかし、都市数が増え、今後さらに機能を追加することを考えると、別の方法が適しています。

2.4 Open-Meteo Integration の利用

Version 1.3 では、気象情報の取得を Open-Meteo Integration に統一します。

東京の場合、

Open-Meteo
     ↓
weather.tokyo

という Weather Entity が作られます。

この Weather Entity は単なる「気温センサー」ではありません。

気温をはじめとする気象情報を、Home Assistant の Weather Entity として扱うための入口になります。

そのため、将来、

  • 天気状態
  • 湿度
  • 風速
  • 体感温度
  • その他の気象情報

を利用したくなった場合にも発展させやすくなります。

2.5 Weather Entity と Template Sensor の役割を分ける

Version 1.3 では、

weather.tokyo

と

sensor.weather_tokyo

の2種類のエンティティを利用します。

一見すると、

「なぜ同じ東京の気温に2つのエンティティが必要なのか？」

という疑問が生じます。

ここには明確な役割分担があります。

Weather Entity

weather.tokyo

は、Open-Meteo から提供される気象情報の元となるエンティティです。

Template Sensor

sensor.weather_tokyo

は、その Weather Entity から必要な情報を取り出し、ダッシュボードで扱いやすい形にした表示用のセンサーです。

つまり、

Open-Meteo
     ↓
weather.tokyo
     ↓
Template Sensor
     ↓
sensor.weather_tokyo
     ↓
Dashboard

という役割分担になります。

この分離によって、データの取得と表示を切り離すことができます。

2.6 Template Sensor を利用する理由

Template Sensor は、既存のエンティティが持っている情報を、Home Assistant 内で別のセンサーとして扱うための仕組みです。

例えば東京の場合、

- name: weather_tokyo
  unique_id: weather_tokyo
  device_class: temperature
  state_class: measurement
  unit_of_measurement: "°C"
  state: "{{ state_attr('weather.tokyo', 'temperature') }}"

とすることで、

weather.tokyo
      │
      │ temperature
      ▼
sensor.weather_tokyo

という関係を作ることができます。

ここで重要なのは、

Template Sensor 自体が気温を取得しているわけではない

ということです。

気温の情報源はあくまで、

weather.tokyo

です。

Template Sensor は、その情報をダッシュボードで扱いやすい形に整理しています。

2.7 なぜダッシュボード側で直接処理しないのか

button-card では JavaScript を利用できます。

そのため、

weather.tokyo

の属性をダッシュボード側で直接読み取ることもできます。

しかし、Version 1.3 では、データ処理をできるだけダッシュボードの外へ出します。

つまり、

Weather Entity
      ↓
Template Sensor
      ↓
Dashboard

という構造を基本とします。

これには大きなメリットがあります。

ダッシュボードは、

「データを取得する場所」ではなく「データを表示する場所」

として扱えるからです。

この考え方により、将来ダッシュボードのデザインを変更しても、データ取得部分への影響を最小限にできます。

2.8 Dashboard の構造は維持する

Version 1.3 では、ダッシュボードの基本構造を変更しません。

View
 │
 └─ Panel
      │
      └─ Grid Card
           │
           ├─ button-card
           ├─ button-card
           ├─ button-card
           └─ ...

この構造は Version 1.2 から引き継ぎます。

理由は単純です。

すでに目的を十分に達成しているからです。

Version 1.3 では、必要以上に構造を変更することを避けます。

「新しい方法だから変更する」のではなく、

必要なところだけを改善する

という考え方です。

2.9 16都市を同じルールで管理する

Version 1.3 では16都市を表示します。

都市ごとに個別の仕組みを作るのではなく、基本的に同じ構造を使用します。

例えば東京なら、

時刻
sensor.asia_tokyo

気象
weather.tokyo

気温
sensor.weather_tokyo

ロンドンなら、

時刻
sensor.europe_london

気象
weather.london

気温
sensor.weather_london

という関係になります。

都市が変わっても、

「都市名に対応したエンティティを用意する」

という基本ルールは変わりません。

これが将来の都市追加を容易にします。

2.10 可読性を重視する

都市数が増えるほど、YAML は長くなります。

16都市でもかなりの行数になります。

しかし、長いこと自体が問題なのではありません。

問題になるのは、

長くなったときに構造が分からなくなること

です。

Version 1.3 では、各都市の記述を基本的に同じ構造に揃えます。

例えば、

都市名
時刻エンティティ
気温エンティティ
クリック時のエンティティ
表示設定

という順序を統一します。

これにより、30都市になった場合でも、

「都市を追加するには、既存の都市ブロックをコピーして必要な部分を変更する」

という作業で対応できます。

2.11 拡張性を考える

Version 1.3 の標準構成は16都市です。

しかし、この数字は最終目標ではありません。

将来的には、

16都市
 ↓
20都市
 ↓
25都市
 ↓
30都市

と増やすことも可能です。

ただし、ここで重要なのは、

都市数を増やすために管理方式そのものを変更しない

ことです。

Version 1.3 では、各都市を個別のカードとして管理する方式を維持します。

これは、完全自動生成の仕組みを導入するよりも、現在のプロジェクト規模では、

「一つ一つ確認できること」

にメリットがあるためです。

2.12 保守性を優先する

Version 1.3 では、短いコードを書くことだけを目標にはしません。

例えば、

短いコード

と

分かりやすいコード

が異なる場合には、後者を優先します。

これは、Home Assistant が長期間運用されるシステムだからです。

数か月後、あるいは数年後に設定を見直したとき、

「これは何のための設定だったのか？」

が分かることが重要です。

そのため、Version 1.3 では、

「現在の自分」だけではなく「将来の自分」が理解できる構成

を目指します。

2.13 標準単位を利用する

気温などの単位についても、システム全体の設定を優先します。

Home Assistant の

設定 → システム → ホームインフォメーション → システムで使用する単位

を「メートル法」に設定します。

これにより、

  • 気温
  • 距離
  • 風速
  • 気圧

などの単位を、日本で一般的に使用する形式に統一できます。

個々のエンティティを一つずつ変更するのではなく、

システム全体の単位設定を正しく行う

というのも、Version 1.3 の「標準機能を優先する」という考え方の一例です。

2.14 Version 1.3 の設計原則

ここまでの内容をまとめると、Version 1.3 は次の原則に基づいて設計されています。

Principle 1

Home Assistant Standard First

可能な限り Home Assistant 標準機能を利用する。

Principle 2

Separate Data and Presentation

データ取得・整理と、ダッシュボード表示を分離する。

Principle 3

Keep the Existing Structure

すでに有効なダッシュボード構造は必要以上に変更しない。

Principle 4

Consistency

16都市を同じルールで管理する。

Principle 5

Maintainability

将来の自分が見ても理解できる構成にする。

Principle 6

Scalability

20～30都市への拡張を考慮する。

Principle 7

Build for the Future

Version 1.4、1.5、2.0 で機能を追加できる土台を作る。

2.15 Design Philosophy Summary

Version 1.3 の設計思想を一言で表すなら、

「必要以上に複雑にせず、Home Assistant の標準機能を利用して、分かりやすく、長く使えるダッシュボードを作る」

ということになります。

その考え方をシステム構成にすると、

となります。

この構成が Version 1.3 の基本となります。

Chapter 2 Summary

本章では、Version 1.3 の設計思想について説明しました。

Version 1.3 では、単に「動くダッシュボード」を作るのではなく、

Home Assistant の標準的な仕組みを利用し、データと表示を分離し、将来の拡張にも対応できる構成

を目指します。

Version 1.0～1.2 で行われた試行錯誤は、Version 1.3 において一つの設計思想へ整理されました。

その中心となる考え方が、

Home Assistant Standard First

です。

次章

Chapter 3

System Architecture

次章では、ここで説明した設計思想を、実際の Home Assistant の構成へ落とし込みます。

特に、

World Clock
    ↓
時刻センサー

Open-Meteo
    ↓
weather.xxx
    ↓
Template Sensor
    ↓
sensor.weather_xxx
    ↓
button-card
    ↓
Dashboard

という関係を詳しく説明します。

また、Version 1.3 で使用する16都市について、都市名・タイムゾーン・時刻エンティティ・Weather Entity・Template Sensor の対応関係も整理します。

これが分かれば、その後の Chapter 4「Installation」以降で行う設定が、単なる YAML の入力作業ではなく、システム全体のどの部分を構築しているのかを理解した上で進められるようになります。

※ChatGPT により作成した。

ホーム