TOPへ
今回の製作の概要図です。
今回はWebSocketを使用した双方向通信を行います。
"良き部下"であるArduinoとsakuraio通信モジュールに与える主な任務は
・電源電圧の測定
・電流の測定
・消費電力の計算
・消費電力量の計算
この4つを常に行なってもらい、そして
・これら計算結果を指令に応じて報告
この計5つを行ってもらいます。
そして、"上司"であるWeb画面からは
・現在値の報告
・継続的な報告
・50／60Hz切替
・初期化
を"良き部下"に対し指令します。
こちらはJavaScriptで実装します。
○電気回路図
電流を測定するCTの為の回路と、電圧を測定するVTの為の回路で構成されます。
実際に製作した回路がこちらになります。
それぞれの回路は以下の説明通りです。
1.電流測定回路
使い方は2本のリード線に10[Ω]の抵抗をつなぐだけです。
最初はCTをピンヘッダ・ソケットで接続するようにしていましたが
"CTは開放したらマズい"→"ピンヘッダ・ソケットでは抜ける恐れがあるんじゃね？"
ということに作り終わったあと気づいたので、抜けないようにするためにCTをターミナルブロックに接続できるようにしました。
ネジ止めですので、まず抜けません。
Arduinoへの接続はピンソケット・ヘッダで全く問題ありません。
2.電圧測定回路
電流測定回路と同じサイズの基板に収めてます。
電圧はコンセントから取るようにしてますが、注意点が一つ。
基板上にAC100Vのラインができます。
結構、割と危ないので気をつけましょう。
一応安全のためにヒューズは付けていますが、その上流側でショートしたらヒューズも意味がないですし、どうしてもAC100Vラインがむき出しになる場所はできてしまうので、くれぐれも気をつけましょう。 (最低でも、第二種電気工事士以上の知識・技能を持つことが望ましいです)
今回は基板裏のAC100Vラインのはんだ＆リード線部分をホットボンドで固めた上、ゴムシートを被せています。
○交流をanalogRead関数で読み取るために
さて、回路図のArduinoA0～ArduinoA3をそれぞれArduinoのA0～A3にそれぞれつなぎます。
Arduinoのアナログ値読み取りのためのanalogRead関数はDC0～5[V]を0～1023の整数値を返し、それを元に測定値を計算させるのですが、今回測定する対象は正弦波交流です。
そのまま入力すると電流・電圧が負の値を取るとき読み取れません。
ほぼほぼ参考サイト様を参考にしてますが、通常0[V]を中心とした正弦波交流を、2.5[V]底上げするためにArduinoからの5Vを4.7[kΩ]の直列接続で分圧して2.5[V]を作り出しています。
最初、分圧回路を電流測定回路、電圧測定回路の二つで共通に使ってましたが、2.5[V]ラインが二つの回路の干渉を受けてしまうのか変な値が出てしまうので それぞれの基板に分圧回路を組んでいます。
○Arduinoサイドのプログラム(部下の調教)
こちらもほぼほぼ参考サイト様の手法を参考にして実装しました。主に以下の点がほぼほぼ参考にしたところです。
・サンプリングは250[μs]毎のタイマーを用いて一周期分の波形をサンプリング
・50[Hz]の場合は周期が20[ms]なので80回サンプリング(0.25*80=20[ms])
・60[Hz]の場合は周期が約16.7[ms]なので67回サンプリング(0.25*67=16.75[ms])
・「CT0→V→CT1→CT2→待ち時間」というように、一つずつ測定対象を切り替えてサンプリング
問題はここからで、サンプリングで得られた波形データから自分が求めたい数値を演算しなければなりません。 いくつかポイントがあると思うので、プログラムしながら感じたポイントを書いていきます。
電圧・電流の測定データについて
今回の測定対象は交流なので、0[V]を中心に正負の振動を繰り返します。
これに2.5[V]の直流で底上げしているので、analogReadのサンプリング値は512を中心とした正弦波となるハズですが、実際にグラフに描いてみると 正弦波の中心が512からかなり外れます。
いわゆる、オフセットがあります。
回路的にこれを除外するのは難しいので、演算処理で除外することにしました。
演算の流れとしては
サンプリングデータを全て足す
↓
それをデータ数で割るとオフセットの値がわかる
↓
サンプリングデータの全ての値からオフセットの値を引けば、中央値は512に戻る
という手法でオフセットを除外しました。
電圧・電流の実効値について
どの電気の教科書にも書いていることですが。正弦波交流であれば
実効値=最大値／√2
で求められますが、実際のサンプリングデータから計算して求めた電流波形の例を示しますとこのようにギザギザの波形になります。
最大値を求めるのはプログラム的に簡単ですが
"波形データの最大値を√2で割って実効値だ！"
とやるのは、波形データのうち、一個でもノイズが乗って異常に高い値が出てしまうとその値を元に実効値を計算することになるので それ以外の正しく取得できた波形データが全くの無駄になります。
ここは定義に戻って、以下の実効値の計算式を用いましょう。
こうすることで、波形データの中にノイズが乗った異常値があっても影響は小さくなります。
これは実際の数式なので、プログラムで演算させるためには以下の数値計算式を使用します。
これが、今回電圧・電流の実効値を求める計算式となります。
電力の計算について
交流の電力は力率という問題が絡むので、単純に
電圧の実効値×電流の実効値
では求められません。
電圧・電流の位相差を求めて、そこから力率を求めて
電圧の実効値×電流の実効値×力率
とやってやれないことはないですが、上記の通り電流がギザギザで位相差を正確に出せるとも限らず、
苦労の割にあまり報われなさそうな結果しか得られない予感がします。
ですので、これも定義に立ち戻って、以下の計算式を使用します。
実効値の時と同様にプログラムでの演算なので以下の数値計算式を使用します。
それはよいのですが、もう一つのポイントとしてこの計算の為には
同時刻にサンプリングした電流と電圧のサンプリングデータを使う必要があります。
ですが、同時刻に、250[μs]の間に電圧と電流を同時にサンプリングすることは出来ませんでした。
(実際にコードを組んで動かしてみましたが、サンプリングが止まりました)
仕方がないので、CT0の値を一周期分(80個のデータ)読み取った直後からVの値を一周期分読み取り
「この二つは同時刻にサンプリングされたものである」
とみなすことにします。
電力量について
消費電力量は消費電力P[W]と使用時間t[h]がわかれば求められます。
今回は10[s]毎にサンプリングを開始するので使用電力量W[Wh]は単純に
W=P×10/3600[Wh]
を求め、その値をひたすら足し算していけば電力メーターと同じように使用電力量を積算できます。
ですが、ただ単に
電力×時間
を積算していくと、下のグラフのような計算を行っていくことになり、誤差が大きいです。
ここでは誤差を少なくするために一工夫して数値計算の手法の一つである台形公式を用いて計算します。
台形公式を用いると、グラフ的には以下のような計算を行っていくことになります。
計算式的には
(前の電力の値(上底)+今の電力の値(下底))×時間(高さ)÷2
という、正に台形の公式と同じ計算を行います。
実際の測定波形
さて、以上いろいろ踏まえた上で、Arduinoに実際に測定させてみました。
シリアルモニタに出てきた測定値をエクセルでグラフ化したのが以下の図になります。
赤線が電圧波形で、縦軸は左側の数値になります。
ピークが大体140[V]付近なので良いですね。(最大値=100√2≒140[V])
次に青線が電流値で、縦軸は右側の数値になります。
仮の負荷として600[W]のヘアドライヤー使ってます。
ピークが大体9[A]付近です。 クランプで測ると大体6[A]くらいなので良いですね。(最大値=6√2≒8.5[A])
ちなみに負荷を0にしますと、以下のような波形になりました。
CT両端に10[Ω]の抵抗がついていまして、その両端の電圧からCT比、Arduinoの分解能の数値を使って電流値を求めています。 このCTセンサは30[A]測定して初めて0.1[V]の電圧が出てくるものなのでArduinoの0～5[V]の8bitの分解能に対してこの変化量は小さ過ぎますので どうしても誤差は大きくなりがちです。
OPアンプを使うとか色々手はあるでしょうけれども、今回はこのままで使います。
一応、arduinoReadで読み取った1024段階の数値で、1段階違うとどれだけ違うのかも計算してみました。
やっぱりでかいですね。ですが、今回これぐらいは許容しましょう。
○Webサイドのプログラミング(上司)
やることは案外少ないです。
・通信モジュールに指令を出し、報告を受ける。
・受けた報告を元に、各種パラメータを表示。
これだけです。見た目をわかりやすくするために電流計・電圧計・電力計・電力量計上に値及び棒グラフを表示します。
絵面としてはこんな感じに作ってみました。
「接続先URL」と「モジュール」、それに「接続」「切断」に関しては今までと同じで、WebSocket通信を確立するための項目です。
接続成功すると、自動的に「現在報告」の指令を通信モジュールに出します。
「現在報告」
通信モジュールに現在の測定値を報告させる指令を出します。
指令を受けた通信モジュールは一旦返答し、その後測定値をWebに送信します。
WebSocketを接続したときに自動的に一回実行されます。
「継続報告」
通信モジュールに測定値を継続的に報告させる指令を出します。
指令を受けた通信モジュールは一旦返答し、その後約10秒毎に測定値をWebに送信します。
10回報告した後に自動的にWebへの送信を終了します。
連続回数は10回でも100回でも1000回でもいいですが、制限を設けないとsakura.ioポイントをどこまでも消費してしまいますので それを防止するために上限回数を設けています。
「継続報告」
継続報告中の通信モジュールに継続報告の中止をさせる指令を出します。
「計器初期化」
Web画面の計器類を初期表示に戻します。(通信モジュールとの通信は無し)
「接続確認」
通信モジュールとの接続を確認するためのボタンです。正常に接続されている場合、通信モジュールから返答があります。
「初期化」
通信モジュールに、Arduinoの各変数の値を初期化させる指令を出します。
主な用途は「使用電力量」のリセット用ですね。
「50/60Hz」切替
通信モジュールに、50[Hz]の交流をサンプリングさせるか、60[Hz]でサンプリングさせるかの指令を出します。 デフォルトでは50[Hz]です。お住まいの地域に合わせて周波数をセットしてください。 そうしないと、狂った数値が出てきます。
契約アンペア数
電気料金の計算のために使います。ご契約されているアンペア数を選択すると電気料金の概算を示してくれます。
※金額は2017年10月18日現在の北海道電力従量電灯Bメニューに従います。
※燃料費調整額、再生可能エネルギー発電促進賦課金は考慮していません。
メッセージログ
Web側と通信モジュール側とのやり取りを記述していく画面です。
○施工
最後の仕上げが、装置の設置です。
幸いにしてわたくしの家は単相2線式100V30A契約という旧式の契約なので測定も楽です。
実際にCTを取り付けた様子がこちらの写真になります。
かなり古めかしい分電盤ですが、なんとかCTを取り付けられました。
(本当は漏電ブレーカーの下流に付けたいですが、狭くて無理でした)
全体の取り付け状況はこんなかんじです。
かなり実験機材チックのものが付きましたが(まぁ実験機材ですが)
これが今回のIoT電力測定装置です。
測定対象は
・電源電圧
・主幹電流
・4つの漏電ブレーカのうち、最もよく使う2つのブレーカの電流
以上4つの項目につき、この装置が常に測定を行い、指令に応じて報告してくれます。
○結果
誤差はありますが、おおむねクランプメーターと同じような値が出るので良好でしょう。 上記したWeb画面の説明画面で使ってる画像内の数値が実際の測定数値です。
ですが、しばしば、以下のように異常な数値がでますねぇ・・・
1000[W]も使っていません(笑)本当は上のような300[W]程度の数値が出るのが本当なんですが、ごくたまにこういう異常高値が出るときがあります。Webサイドの方は数値を受け取っているだけなので問題は無いです。
悪いとすればArduino側です。実際、波形をグラフに描いてみると電流の方が滅茶苦茶な波形になっていたりもするので
・本当に波形が乱れている
・analogRead関数が変な値を吐き出している
のどちらかだと思うので、思い当たりそうな理由を考えると
・CTの配線が長すぎてノイズ拾う→ノイズ対策のコンデンサがあるので、これが原因だとしてもこれ以上は対策不能。
・CT同士が干渉？→分電盤内が狭すぎて対策不可。リード線もこれ以上短くできない。
・サンプリングの処理が重すぎる→ちゃんとデータ取れているときの説明がつかないので多分違う。
・プログラム間違い→ちゃんとデータ取れているときの説明がつかないので多分違う。
・回路がどこかおかしい→ちゃんとデータ取れているときの説明がつかないので多分違う。
・・・・・・と打つ手無しな感じです。
まぁ・・・
毎回とかあまりにも頻度が高かったらあれですが、たまの1回や2回であれば消費電力量値に与える影響も微小ですし、 色々工夫はしたつもりですが元々測定誤差の大きい測定回路なので
"たまに間違っちゃう困った部下だ"
と思うことにします。
・・・とはいうものの、画像の数値的には
Amain(主幹)=A1(子ブレーカ)+A2(子ブレーカ)
と、キルヒホッフの法則を満たしているあたりいやらしいですね。CT同士が干渉？という線が濃厚でしょうか？
もし、CTを使われる際は、こういう例もあると参考にしてみてください。
○まとめ
・今回、測定精度は諦めてます。"測定する"というのは単純だけど奥深いところもあるので、キリもないし主眼はここではないので、"大体わかればOK"程度が出来ればよいです。
・"モノに指令を出し、インターネットを通じて報告させる"という、今までの空気線図・モールスよりも"IoTらしい形"になったのではなかろうかと思います。
・当然ですが、通信モジュールから返答を貰っている分はsakura.ioポイントの使用量が増えます。その分、「届いているのか届いていないのかわからない」という不安は払拭できます。
・"上司＆部下"の例えを出しましたが、"IoT化というのは一つにはモノを部下化するようなものだなぁ"と思いつつ出した例えです。今回はsakura.ioの通信モジュールを介してモノを部下化しています。
・今回Webサイドはこんなデザインで作りましたが、Web画面の方は凝った作りにしようと思えばいくらでも出来ると思います。
―使用電力量を元にして、各電力会社の料金メニューに従って電気料金も表示できるようにしよう・・・とか。
―高圧需要家以上で問題となる最大需要電力(デマンド)の監視のように、契約アンペア数再考の為に一般家庭でもできるようにしよう・・・とか。
―Web画面で見ている間は値の変化をグラフでも表示させるようにする・・・とか。
・今回は電気ネタを扱っており測定データを表示させるだけですが、測定したデータを蓄えれれば、特に電気ネタのデータは分析等々にも役立つでしょう。 ですが、データを蓄える云々の手法は押えていないのでそれはまたのお話で。。。