Cube J1 でスマートメーターの電力を Grafana に送る

2026-10-03 cube-j1grafanatelegrafmqtthomelab

家のスマートメーターから瞬時電力を取り出し、Grafana Cloud のダッシュボードで眺められるようにしました。
取り出しには、サービスが終了した NextDrive Cube J1 を使っています。
この記事では、Cube J1 が MQTT に送った値を Telegraf で受けて Prometheus 形式に直し、Grafana Cloud に remote write するまでの構成と設定を紹介します。

Cube J1 と cube-j1-mqtt

Cube J1 は、スマートメーターの B ルート¹から電力を読み取る Wi-SUN ゲートウェイです。
NextDrive のクラウドサービスは 2025 年 3 月 31 日に終了し、いまは本体だけが中古で出回っています。

この Cube J1 を Home Assistant 用の MQTT デバイスとして使うツールを、つよぽんさんが cube-j1-mqtt として公開しています。
設定ファイルを書いた USB メモリを挿して電源を入れるだけで、本体内蔵の Wi-SUN モジュールからスマートメーターに問い合わせ、結果を MQTT で送信するプログラムが常駐します。
分解せずに root を取ってプログラムを常駐させる仕組みは、同じ作者の Zenn の記事に詳しく書かれています。

公開時のポストでは、Cube J1 がヤフオクで 2,500 円ほどで手に入ることにも触れられています。

https://x.com/tsuyopon_dev/status/2054137344824049913

我が家には、B ルートの電力値を読める Nature Remo E lite もあります。
ただ、Remo E lite の電力データを取れる API は、Nature のサーバーを経由する Cloud API だけです。
家の中から直接呼べる Local API は赤外線信号の送受信にしか対応しておらず、電力値は読めません。
Cloud API には、Nature アカウントごとに 5 分あたり 30 回までというリクエストの上限もあります。
クラウドを通さないと値を取り出せない点が、以前から不満でした。
値段も、現行の後継機 Nature Remo E2 lite が公式ストアで 19,800 円（2026 年 10 月時点）なので、気軽には勧めにくいと感じています。

cube-j1-mqtt は Home Assistant に送ることを想定していますが、MQTT のメッセージはほかのプログラムからも購読できます。
今回は Telegraf で受信し、Grafana Cloud に送信しました。

全体の構成

スマートメーター
   │ Wi-SUN (920 MHz) / ECHONET Lite
   ▼
Cube J1 ── mqtt_bridge.py
   │ MQTT (Wi-Fi 2.4 GHz)
   ▼
家の Linux サーバー (Docker Compose)
   ├─ Mosquitto ……… MQTT ブローカー
   ├─ Home Assistant … 同じトピックを購読（任意）
   └─ Telegraf ……… MQTT を購読して remote write
          │
          ├─▶ Grafana Cloud (Prometheus)
          └─▶ ローカルの Prometheus

Cube J1 は cubej/<device_id>/<センサー名> というトピックに、数値だけを含むペイロードを送信します。
cube-j1-mqtt が送るのは次の 5 つです。

我が家は単相 2 線式なので T 相がなく、スマートメーターは T 相の電流を ECHONET Lite の「計測なし」を表す値（0x7FFE）で返します。
cube-j1-mqtt のコードはこの値も区別せずに換算するので、このメーターでは T 相が 3276.6 A という値で送られるはずです。
手元で使っているブリッジはこの値を捨てるようにしてあり、T 相の値は送っていません。

Home Assistant と Telegraf は、どちらも Mosquitto から同じトピックを購読します。
Cube J1 から見ると送り先はブローカー 1 つだけなので、Grafana 向けの経路を足しても Cube J1 側の設定は変わりません。

Cube J1 の準備

手順は cube-j1-mqtt の README のとおりです（この記事は 2026 年 5 月時点の版で確かめています）。
production_tool/config.json に B ルートの認証情報と MQTT ブローカーの接続先を書き、production_tool/wpa_supplicant.conf に Wi-Fi の SSID とパスワードを書きます。

{
    "br_id": "（B ルート認証 ID、32 文字）",
    "br_pwd": "（B ルートパスワード、12 文字）",
    "mqtt_host": "192.168.1.10",
    "mqtt_port": 1883,
    "mqtt_user": "cubej1",
    "mqtt_pass": "（MQTT のパスワード）",
    "device_id": "cubej1",
    "serial_port": "/dev/ttyS1",
    "poll_interval": 60
}

mqtt_host には、Mosquitto を動かすサーバーの IP アドレスを書きます。
FAT32 でフォーマットした USB メモリのルートに、リポジトリ直下の空ファイル CubeJMTS.txt と production_tool/ ディレクトリをコピーします。
この USB メモリを Cube J1 に挿して電源を入れると、セットアップが始まります。
終わると LED が白く 10 回点滅します。

ここで一度つまずきました。
Cube J1 の Wi-Fi は 2.4 GHz にしか対応していません。
我が家のアクセスポイントは 2.4 GHz と 5 GHz で同じ SSID を出しており、この状態では Cube J1 が Wi-Fi に繋がりませんでした。
原因までは切り分けていませんが、wpa_supplicant.conf の network ブロックに freq_list を書き、2.4 GHz の周波数だけを候補にしたところ繋がりました。

network={
    ssid="（SSID）"
    psk="（パスワード）"
    freq_list=2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472
}

Mosquitto を立てる

ブローカーには Eclipse Mosquitto 2 を使い、後で立てる Telegraf と同じ compose.yaml で動かします。
同じ Compose プロジェクトのサービスは同じネットワークに入るので、Telegraf からはサービス名の mosquitto で接続できます。
Cube J1 は別の機器から接続してくるので、1883 番ポートをサーバーの LAN 側のアドレスに公開します。
この例では LAN 内だけで使う前提で、TLS は設定していません。
ルーターでインターネット側に公開せず、必要に応じてサーバーのファイアウォールでも接続元を制限してください。

services:
  mosquitto:
    image: eclipse-mosquitto:2
    restart: unless-stopped
    ports:
      - "192.168.1.10:1883:1883"
    volumes:
      - ./mosquitto/config:/mosquitto/config:ro
      - ./mosquitto/data:/mosquitto/data
      - ./mosquitto/log:/mosquitto/log

mosquitto/config/mosquitto.conf では匿名接続を禁止し、パスワードファイルで認証します。

persistence true
persistence_location /mosquitto/data/

log_dest file /mosquitto/log/mosquitto.log
log_dest stdout

listener 1883
protocol mqtt

allow_anonymous false
password_file /mosquitto/config/passwd

パスワードファイルは mosquitto_passwd で作ります。
Cube J1 用、Home Assistant 用、Telegraf 用にユーザーを分けておきます。
分けているのは認証情報を機器ごとに分けるためで、ACL は設定していません。
認証されたユーザーは、すべてのトピックへの送信と購読ができます。
Cube J1 の設定ファイルには MQTT のパスワードが平文で入るので、ACL で送信できるトピックを絞ることも検討してください。

docker run --rm -it -v "$PWD/mosquitto/config:/mosquitto/config" eclipse-mosquitto:2 \
  mosquitto_passwd -c /mosquitto/config/passwd cubej1

2 つ目以降のユーザーは -c を外して追加します。
Cube J1 が送り始めたら、mosquitto_sub で値が届いているかを確かめられます。

mosquitto_sub -h 192.168.1.10 -u telegraf -P '（パスワード）' -t 'cubej/#' -v

cubej/cubej1/power 821
cubej/cubej1/current_r 9.0

Telegraf で受けて remote write する

Telegraf は inputs.mqtt_consumer でトピックを購読し、outputs.http の prometheusremotewrite 形式で Prometheus に書き込みます。
設定の全体は次のとおりです。

[agent]
  omit_hostname = true

[[inputs.mqtt_consumer]]
  servers = ["tcp://mosquitto:1883"]
  topics = [
    "cubej/+/power",
    "cubej/+/energy_forward",
    "cubej/+/energy_reverse",
    "cubej/+/current_r",
    "cubej/+/current_t",
  ]
  username = "telegraf"
  password = "${MOSQ_PASSWORD}"
  client_id = "telegraf-cubej"
  data_format = "value"
  data_type = "float"
  name_override = "mqtt_measure"

  [[inputs.mqtt_consumer.topic_parsing]]
    topic = "cubej/+/+"
    tags = "_/device_id/sensor"

[[processors.starlark]]
  namepass = ["mqtt_measure"]
  source = '''
SUFFIX = {
    "power": "power_watts",
    "energy_forward": "energy_forward_kwh_total",
    "energy_reverse": "energy_reverse_kwh_total",
    "current_r": "current_r_amperes",
    "current_t": "current_t_amperes",
}

def apply(metric):
    suffix = SUFFIX.get(metric.tags.get("sensor"))
    v = metric.fields.pop("value", None)
    if suffix == None or v == None:
        return None
    metric.name = "cube_j1_smart_meter"
    metric.fields[suffix] = v
    metric.tags.pop("topic", None)
    metric.tags.pop("sensor", None)
    return metric
'''

[[outputs.http]]
  url = "${GRAFANA_PROM_URL}"
  method = "POST"
  data_format = "prometheusremotewrite"
  username = "${GRAFANA_PROM_USER}"
  password = "${GRAFANA_PROM_KEY}"

  [outputs.http.headers]
    Content-Type = "application/x-protobuf"
    Content-Encoding = "snappy"
    X-Prometheus-Remote-Write-Version = "0.1.0"

ペイロードは数値 1 つだけなので、data_format = "value" でそのまま読めます。
デバイス ID とセンサー名はトピックに入っています。
そこで topic_parsing でトピックを / で区切り、2 番目を device_id タグに、3 番目を sensor タグにしています。

Starlark のプロセッサーは、メトリクス名を整えるために入れました。
prometheusremotewrite 形式では、Prometheus 上のメトリクス名が「measurement 名 + _ + field 名」になります。
何もしないと、電力も電流も積算電力量も mqtt_measure_value という 1 つのメトリクス名になり、sensor ラベルの違いだけで区別されます。
Prometheus では、同じメトリクス名を持つ系列には同じ意味と単位を持たせるのが慣例です。
そこで measurement 名を cube_j1_smart_meter に揃え、field 名にセンサーごとの接尾辞を入れて、cube_j1_smart_meter_power_watts や cube_j1_smart_meter_current_r_amperes という名前で届くようにしました。
接尾辞には単位名を入れ、増え続ける積算値には _total を付けています。
積算電力量はスマートメーターが返す kWh のまま扱っているので、Prometheus が推奨する基本単位（エネルギーならジュール）には合わせていません。

mqtt_consumer はメッセージを受け取るたびにメトリクスを作る入力プラグインなので、[agent] の interval はサンプルの間隔に影響しません。
Prometheus に入るサンプルの間隔は、Cube J1 の poll_interval で決まります。

Grafana Cloud の接続情報と Telegraf の起動

remote write の宛先は、Grafana Cloud のポータルで Prometheus の「Details」を開くと確認できます。
URL は https://prometheus-prod-XX-prod-<リージョン>.grafana.net/api/prom/push の形で、ユーザー名は数字のインスタンス ID です。
Telegraf はこれを HTTP の Basic 認証として送り、パスワードにはメトリクスの書き込み権限（metrics:write）を付けたアクセストークンを使います。
画面上の項目名やトークンの発行手順は変わることがあるので、Grafana Cloud の接続画面に表示される値を確かめてください。

これらは Telegraf の設定ファイルに直接書かず、telegraf.env に書いて環境変数として渡しています。
Telegraf は設定ファイル中の ${VAR} を環境変数で置き換えます。

MOSQ_PASSWORD=（Mosquitto の telegraf ユーザーのパスワード）
GRAFANA_PROM_URL=https://prometheus-prod-XX-prod-<リージョン>.grafana.net/api/prom/push
GRAFANA_PROM_USER=（インスタンス ID）
GRAFANA_PROM_KEY=（アクセストークン）

このファイルはリポジトリに入れず、権限を 600 にしておきます。
Telegraf のサービスは、Mosquitto と同じ compose.yaml の services に追加します。
手元では Telegraf 1.32 で動かしています。

  telegraf:
    image: telegraf:1.32
    restart: unless-stopped
    volumes:
      - ./telegraf/telegraf.conf:/etc/telegraf/telegraf.conf:ro
    env_file:
      - ./telegraf/telegraf.env

起動したら、docker compose logs telegraf に設定エラーや remote write の HTTP エラーが出ていないかを確かめます。
認証情報を間違えていると、ここに 401 や 403 が出ます。

Grafana で見る

値が届いたら、Grafana Cloud の Explore で Prometheus のデータソースを開き、次の PromQL を実行するとグラフを確認できます。
冒頭の画像は、このクエリをそのまま時系列パネルにしたものです。

cube_j1_smart_meter_power_watts{device_id="cubej1"}

ダッシュボードには、ほかに次のようなパネルを並べています。

• 直近 1 時間の平均電力: avg_over_time(cube_j1_smart_meter_power_watts[1h])
• 直近 24 時間の最大電力: max_over_time(cube_j1_smart_meter_power_watts[24h])
• 相ごとの電流: cube_j1_smart_meter_current_r_amperes と cube_j1_smart_meter_current_t_amperes

我が家は単相 2 線式なので、電流のパネルには R 相の線だけが出ています。

我が家では夜間に 600〜800 W で推移し、朝と夕方に電子レンジやドライヤーを使うと 2 kW を超えます。
冒頭の画像の 24 時間では、平均が約 770 W でした。

Grafana Cloud Free の保持期間と長期保存

しばらく運用してから、私が使っている Grafana Cloud の Free プランでは、14 日より前のメトリクスを参照できないことに気付きました（2026 年 9 月に確認）。
長期の履歴を溜めているつもりでしたが、残っていたのは直近 14 日分だけでした。
保持期間は変わることがあるので、最新の値は Grafana Cloud の料金ページで確かめてください。

長期の推移も見たかったので、同じサーバーで動かしている Prometheus にも二重に書き込むことにしました。
Telegraf に、ローカルの Prometheus 用の outputs.http を追加しています。
手元の Prometheus は Grafana と一緒に別の Compose プロジェクトで動かしており、Telegraf と共通の外部ネットワーク（networks に external: true を付けたネットワーク）に参加させています。
そのため、Telegraf からサービス名の prometheus で接続できます。

[[outputs.http]]
  url = "http://prometheus:9090/api/v1/write"
  method = "POST"
  data_format = "prometheusremotewrite"

  [outputs.http.headers]
    Content-Type = "application/x-protobuf"
    Content-Encoding = "snappy"
    X-Prometheus-Remote-Write-Version = "0.1.0"

受け取る Prometheus 側は、--web.enable-remote-write-receiver を付けて起動しないと書き込みを受け付けません。
データの保持上限は、期間を指定する --storage.tsdb.retention.time と、容量を指定する --storage.tsdb.retention.size で設定できます。
両方を指定すると、先に達したほうの条件で古いデータが消えます。
私の環境ではディスクの空きに合わせて、2 年（2y）と 120 GB（120GB）にしました。
ローカルの Grafana にも、同じ PromQL のパネルを並べたダッシュボードを作っています。

グラフが途切れる問題

この構成で動かし始めた直後は、グラフが数十分単位で途切れていました。
Mosquitto のログを見ると、Cube J1 の接続が約 12 分おきに exceeded timeout で切られていました。
ブリッジは 1 本のループで、スマートメーターへの問い合わせ、応答待ち、MQTT の ping 送信、次の問い合わせまでの待機を順に回しています。
MQTT の keepalive は 60 秒で、ブローカーはその 1.5 倍の 90 秒間、クライアントから MQTT の制御パケットを受信できないと接続を切ります。
メーターの応答が返らず値を送れない周回が続いたり、Wi-SUN の再接続が長引いたりすると、この間に ping も測定値も送られずに切断されます。
この処理の停止から MQTT の再接続までの間は新しい測定値がブローカーに届かず、グラフが欠けていました。

その後、手元でブリッジを改造して途切れをかなり減らしました。
原因の調べ方と対策は、続編に書きました。