エコノナビットからリアルタイムデータを取得
新築と同時に太陽光発電（京セラ製）を導入。発電・消費電力をモニターするエコノナビットも導入しました。
これはスタンドアローンシステムなので、なんとかネットワークに接続できないかと考える。
○良い点
・スタンドアローンで動く（良くも悪くも）
・データを長期保存している
・タッチパネルで誰でも使える
・無線式なので設置の制約が少ない（電源はアダプタ）
・USB経由でデータをPCから吸える
×悪い点
・付属PCソフトがショボい
・ネットワークコネクティビティが無い
（PCからデータ吸出し出来るが、現在値をモニタできないのようなので、PC経由のコネクティビティも不可っぽい）
今、新規にこれと同じことをやろうとすると、端末側はスマホやｉＰａｄになるんじゃないでしょうか。
ネットワークレディなわけですが、太陽光発電は１０年２０年と使うものなので、スマホ
やｉＰａｄの製品ライフよりずっと長く、こういったプロプラエティな製品のほうがいいのかも。
でも、TCP/IPはしゃべってほしいなぁ。
ネットワークコネクティビティを確保して、発電・消費電力をネットワーク越しに観測、蓄積できるようにする。
それだけ。
１．USB接続（PC経由のコネクティビティ可能性は？）
USB仮想シリアル接続で、シリアルオープンすると、エコノナビットのLCD表示がPC接続中になる。ここからして期待薄。
都度、固定長のデータ(32kB)をPCへ送ってきているようだ。
リアルタイムに測定結果を取得したいが、そのようなコマンドもわからない。
シリアルオープンだけでLCD表示がPC接続中に変わるため、仮にデータを取れたとしてもエコノナビットの機能が損なわれる。ぼつ。
２．有線接続
表示器−センサ送信機間を有線接続し、有線上のデータから現在値を読み取れないか？
メーカーサポートに有線＆無線接続混在について問い合わせてみるが、不可とのこと。
今の表示器は無線のままにしておきたいので、ぼつ。
ただし、無線なら表示機を増やせますとの情報を得た。
３．無線接続
この表示器のためだけに、無線をスクラッチから設計するとは考えにくい。内蔵の無線機はモジュールと予想。
同じ無線モジュールを用意すれば、データを取れる可能性はある。
表示器内部のモジュールを調査。加賀電子(製造元：ミヨシ電子)のKM-154Aであった。
ずいぶんとピンが多いCPUパッケージです。
ググる。
IEEE 802.15.4/zigbee 対応の無線モジュールとのこと。ファームで左記仕様を分けているようだ。
zigbeeという名前は聞いたことがあるが、ノーチェックの技術。秋月なんかにxbeeモジュールが売られている程度の知識。
１．zigbeeって何？
IEEE802.15.4 上に構築されたアプリケーション層も含む規約。
OSIモデルでいうと、 物理・データリングが IEEE802.15.4 で、それ以上の層に zigbee が居る。
zigbee自体は下位層をIEEE802.15.4に限定しないとしているが、実際のところ、IEEE802.15.4しかない。
ネットワークがわかる人なら、イーサネットとIP層以上の関係。
下位層のIEEE802.15.4 は、簡単にいうとブルートゥースの仲間みたいなもの。低速・低消費電力を売りにした無線とでも理解しておこう。
主な用途はセンサーネットワークとのことだ。今回のような無線用途にはぴったりだ。
ちなみにスマート家電の期待の星だったはずだが、スマート家電自体が今ひとつなので、zigbeeもさえない。
２．エコノナビットのKM-154Aは IEEE802.15.4 なのか zigbee なのか？
いろいろ調べる。
ナビットの表示器をメンテナンス画面にすると、PAN-ID というのが出てきた。PAN-IDとは無線LANでいえばESSIDみたいなものだ。
IEEE802.15.4のPAN-IDは16ビットで、zigbeeのExpanded PAN-ID(EPID)は64ビットとのことだ。
ここから、zigbee であろうことを確信する。
KM-154Aなら確実だが、リテール品が見つからない。xbee は秋月でも売られているので、こちらを物色。
xbeeは
ネット情報が多いのも○。
IEEE802.15.4 のものと、zigbeeのものは別品番のようだ。さらに、Wifi接続のものがある。
また、PRO というのがあり、アンテナによる区分も加わってずいぶんと品種が多い。どれを買えばいいのか迷う。
IEEE802.15.4 と Wifi は違うのでさっさと外す。
PROはハード的に違うであろうと検討をつけて外す。
ちなみに、ハイパワー無線版がここでいうPROとのこと。後述のZigbee PRO プロファイルのことではない。（紛らわしい）
アンテナは何でもいいので、PCBにした。ＸＢ２４−Ｚ７ＰＩＴ−００４ ￥１７００也。
ほかに、USB接続用のゲタ基板とマイクロUSBケーブルをお買い上げ。
X-CTUを起動していじってみる。ネット情報が多いので、進めやすい。
エコノナビットに対して特段の反応は無い。xbeeのマニュアルを読みあさる。
zigbeeネットワークに入らない場合は、プロファイル確認せよとあるので、2(Zigbee Pro)を選択したらあっさりと
接続（Associated）された。
しかし、こんな簡単にネットワーク(PAN)に参加できていいんだっけ？
表示器側（Zigbee コーディネータ）で何にも接続許可とかしてないんだけどなぁ。
これだと、誤って隣家のエコナビに対して勝手に表示器を追加できそうだ。表示だけなら問題ないのかもね。
エコノナビットPANに参加したxbeeからは勝手にデータが出てくる。
APIモードにしてHEXを眺める。APIデータの3バイト目はペイロード長だが、0x2c, 0x4bの2種類がほとんど。この2種類は対で現れるよう。
0x4b長のデータをみていると、消費電力に呼応していそうなフィールドの気配。
勝手にデータが出てくることから、ブロードキャストデータではないかと推測される。
詳細にパケットを把握するには、パケットアナライザ、いわゆるスニファーが欲しくなる。
xbeeでキャプチャ出来ないか調べるが、どうやら無理のよう。それは、xbeeがインテリジェントで、ネットワーク層まで処理しているためだ。
売り物のIEEE802.15.4スニファーは数万円以上する。これはちょっと見たいだけなので、手が出ない。
と思ったらありましたTiの「CC2531 USB評価モジュールキット」。
無償でTi製スニファーも用意されてます。（有償のサードパーティスニファーもある）
50ドルくらいなので即オーダー。フェデッスクでオランダからフランス->インド->中国を経由してやってきました。
これが外箱
入っているのは、紙切れと これだけ。ソフトはＤＬです。開発キットなので裸です。
さっそくパケットをキャプチャ。
大きく、３種類のパケットがあるようだ。（それ以外も時折出現する）
１．表示器がデータ要求と思しきパケットを、ブロードキャストで送出する。
２．センサ送信機は表示器にユニキャストで応答。
３．表示器は他の表示器？宛と思われるデータを、ブロードキャストで送出する。
このうち、xbeeでは１と３が見えていたのだ。結局、スニファーでわかったのはこの程度。
３のパケットに現在値が入っているっぽいことは事前に予測できていたので、結果的にスニファーによるアドバンテージはほとんど無かった。
0x4b長のパケットを解析すれば、リアルタイムデータを得られるはずだ。
しかし
データをみていると、予想もつかない動きをしており、ぱっと見で何だかわからない。
下記の仕組みでデータをため込み、解析を行うこととした。
データをため込むのは玄箱PROで、うちでは24時間稼働のファイルサーバ、DLNAサーバになっている。
かつては、これがmomose.comのプライマリDNS、メール、Web、FTP、VPN、内向けDHCPサーバになっていた。
Linuxディストリビューションを一切使用せず、全てソースから完全スクラッチでLinux、サーバ構築した貴重な箱だ。
ずいぶんと勉強させてもらった。
実
消費電力との関係をもれなく記録するため、本末転倒ではありますがワイヤレス電流モニターを作りました。
使用したCT（カレントトランス）はU-RD社のCTL-16-CLSで、偶然にもエコノナビットのCTと同一品でした。
配線途中のポリイミドテープの中はCT負荷抵抗、整流、平滑回路です。
送信機は秋月で追加購入したxbeeで、1秒毎にAD変換値を送出するよう設定。
このxbeeもエコノナビットのPANに参加しており、玄箱で受信しています。
このくらいならxbee単体で、外部マイコンなしでできてしまうところが、xbeeのいいところかと思います。
分電盤に安全ブレーカの空きが1回路あったため、盤内に埋込コンセントを仮設してACアダプタと電流モニターユニットを押し込みました。
VVFケーブルの皮むきは電気工事士受験以来かもしれません。
昔は電工ナイフのみ、今はストリッパーが使えると聞いてます。
今回の主目的である、発電・消費電力を把握することができた。さらに、積算電力などそれ以外のデータも把握した。
フレームデータ一例
+0 +1 +2 +3 +4 +5 +6 +7 +8
+9 +A +B +C +D +E +F
7e 00 4b 90 00 24 f6 00 00 01 d1 c5 00 00 01 5b // 0x00 - 0x0F c3 60 0e c1 5d f4 f7 00 83 39 e7 a5 f5 eb 60 28 // 0x10 - 0x1F 59 60 fb a8 a6 f8 e5 b9 1f 89 4d a1 88 f7 f5 e7 // 0x20 - 0x2F 0f 61 86 fe c5 4b 1e 95 82 99 5c dc be d2 73 d0 // 0x30 - 0x3F 97 46 96 a6 37 a1 91 76 10 76 7c ef 6f b2 08 // 0x40 - 0x4E |
オフセット00〜0e はxbee APIお決まりデータ
| オフセット(16進) | 意味 |
| 00 | 開始デリミタ (0x7e) |
| 01〜02 | データ長(0x4b) |
| 03 | API識別子 (0x90 データ受信) |
| 04〜0b | 64ビットソースアドレス |
| 0c〜0d | 16ビットソースアドレス |
| 0e | 受信オプション |
オフセット0f〜4dはペイロードでエコノナビットの送信データ、最後のオフセット4eはAPIフレームのチェックサム
エコノナビットの
各データフィールドは素直な値ではなく、マジック値？とデータ値の xor を取ったものになっている。
従って、最初はその動きが非常に読みにくかった。マジック値は個々のエコノナビットで異なるのかもしれない。
以下、frameが受信データフレーム、value が目的のデータ値として記述。
| オフセット(16進) | 意味 |
| 29 | 日のよう 不詳 |
| 2b | 時 value = frame[0x2b] ^ 0xa1 valueは 0〜23。 |
| 2c | 分 value = frame[0x2c] ^ 0xae valueは 0〜59。 |
| 2f | 潮流電力フレームまとめ数（たぶん） value = frame[0x2f] ^ 0xe6 何らか（通信ドロップ等？）の原因でフレームをまとめた場合、フレーム積算数になるようだ。 通常、value = 1 である。 |
| 30〜31 | 潮流電力 value = (frame[0x31] ^ 0x61) << 8 | (frame[0x30] ^ 0x69) 16ビット符号有り。 valueは 1LSB=10W で、正は買電、負は売電。 積算数で割る。 value = value / 潮流電力フレーム積算数 |
| 32〜35? | 積算売電電力量 value = (frame[0x35]^0x4b) << 24 | (frame[0x34] ^ 0xc5) << 16 | (frame[0x33] ^ 0xf7) << 8 | (frame[0x32] ^ 0xde) 32ビットと仮定。（16,24ビットかもしれない） 1LSB = 1kWh |
| 36〜39? | 積算買電電力量 value = (frame[0x39] ^ 0x99) << 24 | (frame[0x38] ^ 0x82) << 16 | (frame[0x37] ^ 0x9e) << 8 | (frame[0x36] ^ 0x2c) 32ビットと仮定。（16,24ビットかもしれない） 1LSB = 1kWh |
| 3c | 発電電力フレームまとめ数（たぶん） value = frame[0x2f] ^ 0xbf 何らか（通信ドロップ等？）の原因でフレームをまとめた場合、フレーム積算数になるようだ。 通常、value = 1である。 |
| 3d〜3e | 発電電力 value = (frame[0x3e] ^ 0x73) << 8 | (frame[0x3d] ^ 0xd2) 16ビット値。 1LSB=10W だが、10LSB単位(0.1kW)でしか動かない。 積算数で割る。 value = value / 発電電力フレーム積算数 |
| 3f〜42? | 発電積算電力 value = (frame[0x42] ^ 0x96) << 24 | (frame[0x41] ^ 0x46) << 16 | (frame[0x40] ^ 0x9c) << 8 | (frame[0x3f] ^ 0x68) 32ビットと仮定。（16,24ビットかもしれない） この値はエコノナビットの画面に出ている発電積算電力と一致。 1LSB = 1kWh |
| 43 | 状態 value = frame[0x43] ^ 0xa6 0：休止中（夜間）／１：運転中（昼間）／２：？（下記） |
エコノナビット自体は、主幹にセットしたCTで潮流電力を計測している。
発電電力はパワーコンディショナから取得し、消費電力は発電電力＋潮流電力で計算している。（潮流電力は売電側が負）
夜間は発電電力＝０なので、潮流電力＝消費電力となり、１LSB=10Wで消費電力を把握できる。
昼間は発電電力が１０LSB単位でしか動かないので、消費電力も１０LSB分解能でしか意味を持たなくなる。
昼間外出時の電灯の切り忘れなど、１００W未満の負荷の変化を拾うことができず、ちょっともったいない。
潮流電力は1LSB=10Wなので消費電力も10W単位で動くことになるが、エコノナビット表示器は0.1kWまでしか表示していない。
潮流電力の0.01kWは、四捨五入ではなく切り捨てしているようだ。
2013/8/21 落雷と思われる停電発生。上記データに変化があったのでメモ。
| 停電直前の記録(stat：状態/gen：発電/flow：潮流) time=19:27,stat=0,gen=0,flow=57,genint=3893,sellint=3036,buyint=3455
復帰後の記録（30秒ほどの停電だが、玄箱サーバが止まっていたので3時間ほど記録抜け） 発電開始時の記録 |
2013/09/04 ピーク電力の乖離
| これまでも、エコノナビット表示器のピーク記録と、逐次データの不整合が数回あった。9/4の乖離をメモ。 表示器のピークは 3.4kW
@11:21
だが、受信データは 3.6kW @11:22 になっている。 (2014/03/15)証跡画像追加
time=10:11,stat=1,gen=340,flow=-305,genint=5969,sellint=4528,buyint=6082,genmulti=1,flowmulti=1
表示器のピーク発電時刻は、最初に上限リミット(定格×1.1)にあたった時点でホールドされるようだ。
time=12:28,stat=1,gen=360,flow=-336,genint=5973,sellint=4531,buyint=6082,genmulti=1,flowmulti=1 |
2013/11/20 ピーク電力の乖離
| Zigbee CHを変えてから通信は安定だが、数日に1回程度の明らかなピーク乖離を観測
うちは3.1kWのシステムなので、9.6kW発電はあり得ず、明らかにデータパース上の問題と思える。 前後のフレームを見る限り2.4kW発電安定中なので、4フレームを1フレームにまとめたと考えると、潮流電力が大きいことも説明が付く。 |
データ収集＆解析をする間、先行してハード設計。
消費電力、発電電力を2桁の7セグLEDと10ポイントのバーLEDで表示します。
給電および受信データ出力はUSBとしました。
結局xbeeのシリアルからデータを取れるので、こういったハードを作らずともやりたいこと（ネットワークコネクティビティ確保）はできます。
ぱっと見てわかりやすいLED表示器の形にしました。
基板発注した後で気づいたのですが、USBを使う場合、外部クリスタルが必須です。基板裏で空中配線することにしよう。
ハード製作といっても、単に半田付けだけです。エコノナビット表示器と並べて撮影。
基板の残りがあります。作ってみたい方は送料込み1000円で基板（部品なし）をおわけします。
前述のとおり、マジックナンバーが個々の装置毎に異なる可能性があります。
そのあたりの解析と対処ができる方に限定させてください。
(2013.11.18)アクリルスタンド取り付け
最終目的である、ネットワークコネクティビティを確立。
前述の玄箱Proを用いて、簡単ながらネットから見えるよう環境を構築。
とりあえず現在値を表示のみ。
RDBなのでいろいろできるでしょう。もうちょっと練っていきます。
ちょくちょく途切れてRSSIランプが消える。また、日々の受信回数ばらつきも大きいのでチャネル変更。
調子の良いときは2.3万回/日程度受信、悪いときは半分程度になる。
バースト的に受信できなくなるので、他との干渉可能性大。夜受信できないことが多いようだ。
無線LANとの干渉、青とオレンジは家のもの。隣家の無線LANも結構強い。
現行のCH23から空いているCH26へ変更。XbeeのScanChannelsを0xFFFF→0x8000 へ変更。
しばらく様子見。
個人利用に限り、断りなく使ってもらって結構です。
権利は放棄しません。再配布はご遠慮ください。
[戻る]
Created: 2013/07/07
Updated: 2014/03/15
