Version 1.3 Build Guide
Chapter 3
System Architecture
3.1 本章の目的
第1章では、このプロジェクトの目的を説明しました。
第2章では、Version 1.3 がどのような設計思想に基づいて構成されているのかを説明しました。
本章では、いよいよその設計思想を実際の Home Assistant の構成へ落とし込みます。
Version 1.3 のシステム全体を一枚の図にすると、次のようになります。
Home Assistant
│
┌────────────────┴────────────────┐
│ │
▼ ▼
World Clock Open-Meteo
│ │
▼ ▼
Time Sensor Weather Entity
│ weather.xxxまし
│ │
│ ▼
│ Template Sensor
│ │
│ ▼
│ sensor.weather_xxx
│ │
└──────────────┬──────────────────┘
▼
button-card
│
▼
Dashboard
この図が Version 1.3 の「設計図」です。
以降の章では、この設計図に沿って各部分を順番に構築していきます。
3.2 システム全体の考え方
Version 1.3 は、大きく4つの役割に分けて考えることができます。
1. 時刻を取得する
↓
2. 気象情報を取得する
↓
3. 気温を表示用センサーとして整理する
↓
4. ダッシュボードに表示する
それぞれを担当する仕組みは次のとおりです。
| 役割 | 使用する仕組み |
|---|---|
| 現在時刻 | World Clock |
| 気象情報 | Open-Meteo Integration |
| 気温センサー | Template Sensor |
| 画面表示 | button-card |
| 配置 | Grid Card |
| 全体 | Home Assistant Dashboard |
このように役割を分けることで、それぞれの機能を独立して確認・変更できます。
3.3 World Clock の役割
世界時計部分では、各都市の現在時刻を取得します。
例えば東京の場合、
sensor.asia_tokyo
が東京の現在時刻を提供します。
ロンドンなら、
sensor.europe_london
ニューヨークなら、
sensor.america_new_york
となります。
これらは気温情報とは別の役割を持っています。
つまり、
sensor.asia_tokyo
↓
現在時刻
です。
気温については別のエンティティを使用します。
3.4 Open-Meteo の役割
気象情報は Open-Meteo Integration から取得します。
例えば東京の場合、
weather.tokyo
という Weather Entity が作られます。
同様に、
weather.london weather.paris weather.new_york
など、都市ごとに Weather Entity が存在します。
この Weather Entity が、気温を含む気象情報の基礎となります。
重要なのは、
Open-Meteo Integration が気象情報を取得し、Home Assistant の Weather Entity として提供している
という点です。
Version 1.3 では、REST APIへ直接アクセスして気温だけを取得する方式ではなく、この仕組みを利用します。
3.5 Weather Entity の役割
Weather Entity は、都市の気象情報をまとめて扱うためのエンティティです。
例えば、
weather.tokyo
には現在の気温などの情報が含まれています。
そのため、東京の気温は、
weather.tokyo
│
└── temperature
という形で取得できます。
ここで重要なのは、
weather.tokyo
そのものが「気温センサー」なのではなく、
気象情報をまとめて持つ Weather Entity
であるということです。
Version 1.3 では、その中から現在気温を取り出して、別の Template Sensor として扱います。
3.6 Template Sensor の役割
Template Sensor は Weather Entity から必要な情報を取り出し、独立した温度センサーとして扱うために使用します。
東京の場合、
weather.tokyo
│
│ temperature
▼
sensor.weather_tokyo
という関係になります。
Template Sensor の基本的な設定は次のようになります。
- 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
が情報源です。
そして、
sensor.weather_tokyo
が表示や履歴管理に利用する温度センサーになります。
3.7 なぜ Template Sensor を間に置くのか
一見すると、
weather.tokyo
から直接ダッシュボードへ表示すればよいように思えます。
しかし Version 1.3 では、
weather.tokyo
↓
Template Sensor
↓
sensor.weather_tokyo
↓
Dashboard
という構造を採用します。
この構造には重要な意味があります。
Template Sensor によって、
- 気温という値を独立したセンサーとして扱える
- 温度センサーとしての属性を設定できる
- 履歴を管理しやすくなる
- ダッシュボード側の処理を簡単にできる
- 将来の表示方法変更に対応しやすい
というメリットがあります。
つまり、
Weather Entity は気象情報を提供し、Template Sensor はその中から表示したい値を整理する
という役割分担です。
3.8 button-card の役割
ダッシュボード上の各都市カードには button-card を使用します。
button-card は、時刻と気温を一つのカードにまとめて表示します。
東京の場合、概念的には次のようになります。
┌─────────────────────────┐ │ 🇯🇵 東京 │ │ │ │ 08:30 29℃ │ └─────────────────────────┘
button-card が参照する情報は、
sensor.asia_tokyo
↓
時刻
sensor.weather_tokyo
↓
気温
です。
つまり button-card は、情報を取得する場所ではありません。
すでに Home Assistant 内に存在する情報を表示する役割を担当します。
3.9 Dashboard の構造
Version 1.3 の Dashboard は、次の構造を維持します。
View
│
└── Panel
│
└── Grid Card
│
├── button-card
├── button-card
├── button-card
├── button-card
└── ...
Grid Card の中に各都市の button-card を配置します。
現在は4列表示とします。
┌────────┬────────┬────────┬────────┐ │ 東京 │ ロンドン │ パリ │ NY │ ├────────┼────────┼────────┼────────┤ │ LA │ ベルリン │モスクワ │シンガポール │ ├────────┼────────┼────────┼────────┤ │ シドニー │ 北京 │ケープタウン │ドバイ │ ├────────┼────────┼────────┼────────┤ │ サンパウロ │ダラス │オスロ │デリー │ └────────┴────────┴────────┴────────┘
16都市の場合、4列×4行となります。
3.10 一つの都市で見るデータの流れ
Version 1.3 の構造を理解するには、一つの都市を例にすると分かりやすくなります。
東京を例にします。
Step 1 — 現在時刻
World Clock が東京の時刻を提供します。
sensor.asia_tokyo
↓
08:30
Step 2 — 気象情報
Open-Meteo Integration が東京の Weather Entity を提供します。
weather.tokyo
Step 3 — 気温を取り出す
Template Sensor が Weather Entity の temperature を読み取ります。
weather.tokyo
↓
temperature
↓
sensor.weather_tokyo
↓
29℃
Step 4 — Dashboard へ表示
button-card が2つの情報を組み合わせます。
sensor.asia_tokyo
+
sensor.weather_tokyo
↓
┌─────────────────────┐
│ 🇯🇵 東京 │
│ │
│ 08:30 29℃ │
└─────────────────────┘
これが一つの都市の基本的なデータフローです。
3.11 16都市のエンティティ構成
Version 1.3 では16都市を使用します。
各都市について、
- World Clock の時刻エンティティ
- Open-Meteo の Weather Entity
- Template Sensor
の3つを対応させます。
| 都市 | 時刻エンティティ | Weather Entity | 気温Template Sensor |
|---|---|---|---|
| 🇯🇵 東京 | sensor.asia_tokyo | weather.tokyo | sensor.weather_tokyo |
| 🇬🇧 ロンドン | sensor.europe_london | weather.london | sensor.weather_london |
| 🇫🇷 パリ | sensor.europe_paris | weather.paris | sensor.weather_paris |
| 🇺🇸 ニューヨーク | sensor.america_new_york | weather.new_york | sensor.weather_new_york |
| 🇺🇸 ロサンゼルス | sensor.america_los_angeles | weather.los_angeles | sensor.weather_los_angeles |
| 🇩🇪 ベルリン | sensor.europe_berlin | weather.berlin | sensor.weather_berlin |
| 🇷🇺 モスクワ | sensor.europe_moscow | weather.moscow | sensor.weather_moscow |
| 🇸🇬 シンガポール | sensor.asia_singapore | weather.singapore | sensor.weather_singapore |
| 🇦🇺 シドニー | sensor.australia_sydney | weather.sydney | sensor.weather_sydney |
| 🇨🇳 北京 | sensor.asia_shanghai | weather.beijing | sensor.weather_beijing |
| 🇿🇦 ケープタウン | sensor.africa_johannesburg | weather.cape_town | sensor.weather_capetown |
| 🇦🇪 ドバイ | sensor.asia_dubai | weather.dubai | sensor.weather_dubai |
| 🇧🇷 サンパウロ | sensor.america_sao_paulo | weather.sao_paulo | sensor.weather_saopaulo |
| 🇺🇸 ダラス | sensor.america_chicago | weather.dallas | sensor.weather_dallas |
| 🇳🇴 オスロ | sensor.europe_oslo | weather.oslo | sensor.weather_oslo |
| 🇮🇳 デリー | sensor.asia_kolkata | weather.delhi | sensor.weather_delhi |
注意
時刻エンティティと Weather Entity は、必ずしも都市名がそのままエンティティ名になるとは限りません。
例えば、
北京 sensor.asia_shanghai
や、
デリー sensor.asia_kolkata
のように、使用する統合側の仕様によりエンティティ名が異なる場合があります。
そのため、エンティティ名を推測せず、実際の Home Assistant に作成されたエンティティを確認することが重要です。
3.12 16都市を同じ構造として考える
16都市にはそれぞれ異なる都市名、タイムゾーン、緯度・経度があります。
しかし、システム構造はすべて同じです。
都市
│
├── 時刻エンティティ
│
├── Weather Entity
│
└── Template Sensor
│
▼
button-card
例えば東京でもロンドンでも、
時刻 + 気温 ↓ button-card
という関係は変わりません。
この「同じ構造を繰り返す」という考え方が、Version 1.3 の拡張性を支えています。
3.13 カードをクリックしたときの動作
各都市カードには tap_action を設定します。
基本的には、その都市の気温センサーを対象として詳細情報を表示します。
例えば東京なら、
tap_action: action: more-info entity: sensor.weather_tokyo
とします。
これによって、
東京カード
↓
sensor.weather_tokyo
↓
気温の詳細・履歴
という流れになります。
この設計によって、一覧画面では現在の気温を確認し、必要な都市だけクリックして詳細な履歴を確認できます。
3.14 データ取得と表示を分離する
Version 1.3 の重要な設計ポイントを、もう一度整理します。
【データ取得】
World Clock
↓
現在時刻
Open-Meteo
↓
気象情報
↓
【データ整理】
Template Sensor
↓
現在気温
↓
【表示】
button-card
↓
Dashboard
このように、それぞれの役割を分離します。
これにより、
- 気象情報の取得方法を変更する
- Dashboard のデザインを変更する
- 都市を追加する
- 表示項目を増やす
といった変更を行う場合でも、他の部分への影響を小さくできます。
3.15 Version 1.3 Architecture の完成形
ここまでの内容をまとめると、Version 1.3 の設計図は次のようになります。
Home Assistant
│
┌───────-──────┴──────────────┐
│ │
│ │
┌──────▼──────┐ ┌──────▼──────┐
│ World Clock │ │ Open-Meteo │
└──────┬──────┘ └──────┬──────┘
│ │
▼ ▼
sensor.xxx weather.xxx
│ │
│ │
│ temperature
│ │
│ ▼
│ Template Sensor
│ │
│ ▼
│ sensor.weather_xxx
│ │
└──────────────┬─────────────┘
│
▼
button-card
│
▼
Grid Card
│
▼
View
│
▼
Dashboard
この構造が、Version 1.3 の基本アーキテクチャです。
3.16 将来の拡張
この設計は、現在の「時刻＋気温」だけに限定されません。
例えば将来的に、
weather.tokyo
│
├── temperature
├── humidity
├── wind_speed
├── weather_condition
├── sunrise
└── sunset
などの情報を利用できるようになれば、Dashboard をさらに発展させることができます。
将来的には、
現在時刻 現在気温 天気 湿度 風速 最高気温 最低気温 日の出 日の入り
などを一つの都市カード、あるいは詳細画面にまとめることも可能です。
つまり Version 1.3 の設計は、
現在の機能を完成させるためだけの設計ではなく、将来の拡張を受け入れるための設計
でもあります。
3.17 Architecture Summary
Version 1.3 のシステムをまとめると、次のようになります。
World Clock
│
└── 現在時刻
Open-Meteo
│
└── Weather Entity
│
▼
Template Sensor
│
└── 現在気温
現在時刻 ＋ 現在気温
│
▼
button-card
│
▼
Grid Card
│
▼
Dashboard
重要なのは、各機能に明確な役割があることです。
| 機能 | 役割 |
|---|---|
| World Clock | 現在時刻を提供 |
| Open-Meteo | 気象情報を提供 |
| Weather Entity | 気象情報を管理 |
| Template Sensor | 気温を独立したセンサーとして整理 |
| button-card | 都市情報を表示 |
| Grid Card | 都市カードを配置 |
| Dashboard | ユーザーに情報を提供 |
Chapter 3 Summary
本章では、Home Assistant World Clock & Weather Dashboard Version 1.3 のシステムアーキテクチャを説明しました。
Version 1.3 は、単純に16個のカードを並べたダッシュボードではありません。
時刻 ↓ World Clock 気象情報 ↓ Open-Meteo ↓ Weather Entity ↓ Template Sensor 時刻 ＋ 気温 ↓ button-card ↓ Grid ↓ Dashboard
という明確なデータフローを持っています。
そして、この構造を16都市について繰り返しています。
そのため、新しい都市を追加するときも、基本的には既存の都市と同じ構造を用意すればよく、システム全体を作り直す必要はありません。
これが Version 1.3 における拡張可能な設計の基本となります。
次章
Chapter 4
Preparation
ここまでで、
- なぜこのダッシュボードを作るのか
- なぜこの構成を採用するのか
- システム内部がどのようにつながっているのか
が明確になりました。
次章からは、いよいよ実際の構築に入ります。
Chapter 4 では、Version 1.3 を構築する前に必要となる Home Assistant の環境確認、単位設定、必要な統合、エンティティの確認などを整理します。
「何を設定するのか」だけでなく、「設定後に何が存在していれば正しいのか」まで確認できる形にすることで、途中で問題が発生しても原因を切り分けやすい手順にします。
※ChatGPT により作成した。