$name

日常の記録から技術メモまで

黒電話が生えてきました。

ここ最近、電話技術にとても興味を持ち、アナログ回線の仕組みや電話機の仕組みについて沢山調べていました。すると、「黒電話」として親しまれている、600形電話機というのが、大変丈夫であるうえ、当時の水準としてはとても優れた性能をもっていると知り、興味が湧いてきました。

1台黒電話が欲しい・・・!整備は自分でやるから状態が悪くても欲しい・・・!

そう思いながら、元日に地元のハードオフに出かけると、思いもよらない邂逅が。

なんですかこれは!野生の黒電話ではありませんか!

600-A2形という形式のもので、私が欲しいと思っていた機種のひとつです。

有無を言わさずお買い上げ。税込550円也。しかし今年最初の買い物が黒電話になるとは、どういう風の吹き回しですか・・・。

何がどうなっているか分からない、最悪中身が空っぽかもしれないという覚悟で買ってきたのですが、予想とは裏腹に大変状態が良いものでした。テスターで調べる限りでは、各部の抵抗値など正常で、チャタリング等もありません。送話器も受話器も状態が良さそうです。

ダイヤル波形やベルの状態、インピーダンス等は、手持ちの道具では測定できません。機器に繋いでみて動かなければ考える、ということになるかなぁ。

そういえば、ダイヤル接点を閉じると、L1, L2間の直流抵抗が4~10Ωほどまで下がることに気づきました。直流抵抗がそんなに下がって大丈夫なのか?と、回路図を追いつつテスターを当てたりしていると、PAD設定があるということに気づきました。PADを入れると、通話回路のゲインが-3dBになるほか、ベル・ダイヤル回路に300Ωの直流抵抗が入るようです。PAD無しでは、通話回路のゲインは0dB、ベル回路に直列の抵抗なし、ダイヤル接点閉路時にL1-L2がショート状態という回路構成になるわけですね。

そんなわけで、調べる限り回路の動作は回路図と一致していて、いまのところは非常に状態が良さそうだということがわかりました。

念のため、PAD無しで直流電源に繋いでテストするときは、必ず外部に抵抗を直列に入れないと短絡のおそれがあって危険ですね(あやうく失敗するところだった)。

 

肝心の電話機の使途についてですが・・・。

「東京広域電話網」という、有志が集まって私設VoIP電話網を構築するコミュニティがあることを知り、わたしもSIPサーバーを接続して相互接続予定です。今月上旬には繋がるかな?VoIPルーターを手配したり、SIPサーバーの構築のための準備をしたりしているところ。

 

黒電話を買ってみると、他の電話機も欲しくなってきますね。シンプルでベーシックな電話機がすきなもので、601形とか、ハウディ・クローバーホンとか、気になってます。

実家の固定電話を安全・快適に使えるようにした

実家にはひかり電話を引いています。といってもほとんど使われてなくて、番号を維持するために残しているようなもの。

電話機には、シャープのUX-F50CLという、コードレス子機付きFAX電話を使っています。

実家で稼働中の固定電話機

この電話機ですが、5年以上前から調子が悪く、「こちらの声が相手に聞こえない」「通話中に電話が切れる」「受話器を取っても着信を受けられない」といった症状が多発。ただでさえ誰も取りたがらない固定電話なのに、ますます家族が電話を取りたがららず、忌避される悲しい存在に・・・。

せっかくひかり電話を引いているのだから買い替えてはどうかと思うところですが、今更固定電話にお金を掛けたくないというのが本音のよう。しかし、せっかくFAXを置いているのだから、FAX機能は残しておきたいとのこと。
個人的には、ヤフオクやらメルカリやらで中古のFAX機を落札するのが一番のように思いますが・・・にわかにやる気が出たので、ゼロ円で修理できないかトライしてみます。

ついでに、詐欺電話対策も行い、より安全に電話を使える環境を目指します。

子機の処分と後悔

本題に入る前に・・・。この電話機には子機が付いていました。修理に着手した時点で、安定動作せず。液晶もバックライトが付くのみで、表示が出ず、通話もできませんでした。

液晶が点灯するようにできないか、分解を試みましたが、結局こちらは分解整備に失敗し、一式を処分してしまったんですね。

しかしよく考えると、液晶が点灯しなくても発着信だけはできるので、通話ができるように電池交換などから試していけばよかったなあと後悔。

そんなわけで、今あるのは親機のみです。

フックスイッチ、受話器コネクタの研磨

電話機は、基本的に普通のドライバーでは分解できないように作られています。ですが大変運がいいことに、左側の受話器置台だけはネジ1本で分解可能。

受話器を上げるとフックスイッチが導通する仕組みですが、導通状態の抵抗値がコロコロ変わって測定不能。「通話中に電話が切れたり、受話器を取っても着信を受けられない」という症状はこれが原因でした。

模型用の油目やすりで、フックスイッチの節点部分を研磨したところ、修理直後の時点で導通抵抗が0.6Ωにまで改善。1週間以上経過しますが、安定して通話できています。

受話器コネクタは、RJ-9というモジュラーコネクタでできています。この接点部分はマイナスドライバーで何度かなぞって表面の汚れや酸化物を落としました。

今回はゼロ円での修理が目的なので、ケミカル類を用意せずにこういうことをしていますが・・・本来は無水アルコールなどで優しく清掃するのが良いと思います。
捨てるつもりでの延命なので、荒っぽいやり方ですがお許しを。

通話が切れることもなく、お互いの声も非常にスムーズにやり取りできています。数回ほど固定電話から発着信しましたが、問題なしです。

非通知電話を着信拒否する

通話が安定してできるようになって、めでたし・・・といきたいところですが、全く別の問題に直面します。詐欺電話対策です。固定電話は詐欺に狙われやすいようで、不審な着信履歴が確かに確認できます。

詐欺に合わないためには、不審な着信に出ないということがまず重要です。家族には、極力こうした電話には出てほしくありません。

そんな不審な着信の一つが、非通知での着信です。

非通知電話の着信拒否の方法には、「NTT側での着信拒否サービスを使う」「電話機側の着信拒否機能を使う」の2択があります。

前者は、申し込みと月額利用料が本来必要です。高齢の家族がいるので、無償化の対象に入っているとは思うのですが、うちはあいにくコラボ光を使っているため、この辺りの手続きが煩雑になってしまいます。

後者の方法は、電話機の設定で簡単にできるので、とりあえずこちらの方法を試しました。非通知で着信があっても着信音が鳴らず、番号を通知して再発信を促す旨のメッセージが相手に流れます。ただし、着信履歴自体は残ります。

国際電話を着信拒否する

最近増えているのが、国際電話からの詐欺電話です。海外の詐欺拠点で、日本人が「掛け子」として働いているという報道も見聞きしたことがあり、警戒しています。

うちに、海外に電話をするような友人や親戚はいませんから、国際電話はすべて着信拒否しても問題ない環境です。

国際電話不取扱受付センターというところで、国際電話の着信を一括して拒否でき、なおかつ費用も掛からないようなので、家族の了承を得て、利用することにしました。

Webサイトで案内されている番号にダイヤルして、Web申し込み用のパスワードを取得し、フォーム入力に進みました。2025/12/31にダイヤルしましたが、特に待たされることもなくパスワードを入手できました。

手続きにはしばらくかかるようですが、着信頻度自体は少ないので、これを最後に国際電話はかかってこなくなるだろうと予想しています。

電話機の清掃

受話器置台を中心に、黄色くべったりした汚れが付着していました。アルコール洗浄剤などでは取れない汚れです。

水にぬらしたキッチンペーパーにアルカリ性の洗剤を一滴垂らして拭いてみると、結構しっかりとれます。受話器も快適に使えるようにしっかりお掃除しました。

洗剤が多すぎるとシミになったり樹脂を侵すので、目立たないところで微量から試してください。私は失敗しました笑。

アルコールや中性洗剤で取れるならその方が表面が荒れにくくおススメ。

おわりに

安全・快適に固定電話を使える環境が整いました。

せっかく月額料金を払っているのですから、これを機に、固定電話を使う機会を増やしたいところですが・・・。
私自身は長距離通勤をしているため、一番電話を使いたい平日の日中というタイミングに、自宅から電話を掛けたり受けたりできないんですよねぇ。電話する頻度自体も少ないし。
しかも、かかってくる電話の少なくない割合が、営業やテレアポなので、家族にも電話に出て欲しいとはいえないです。

難儀なものだねぇ。

独自ドメインメールの設定を見直しました

独自ドメインのメールアドレスとして、 sola@hk-shuttle.net を運用しています。いつから使い始めたかは記憶にありませんが、2021年から使用している模様。たしか、ちょうどこの時期に、サーバーやインフラ分野の勉強を本腰入れて始めた記憶です。4年も経つんですね・・・。

このメールアドレスはプロフィールWebサイト(https://hk-shuttle.net/about)にて広く公開しているメールアドレスです。誰に知られても、何が送られてきてもいいつもりで、連絡先として公開するために作ったメールアドレスです。

これとは別に、プライベートなメールアドレスとしては、Gmailのアドレスをメインに使っているのですが、あまり大っぴらには公開していません。

メールサーバーは独自で建てているわけではなく、さくらのメールボックスを使用しています。信頼性や構築・保守難易度を考え、さくらのメールボックスを使っています。

メールアドレスを作ってから4年あまり、ほとんど受信専用に使っていました。もちろんメールの受信通知くらいはスマホに届くようにしていましたが、このアドレスからメールを送る機会はしばらくなかったのです。

急に用事ができたため、久しぶりに自分のドメインのアドレスからメールを送ってみたところ、案の定、Gmailで迷惑メール扱いされてしまうことがわかりました。理由はシンプルで、DKIM/DMARCの設定をしていなかったためです。普段から使っていないと、こういうザルな設定に中々気づかないものですね。

せっかくの機会ですから、hk-shuttle.net.ゾーンの、メール関連のDNS設定を抜本的に見直すことにしました。

  • 逆引き可能なFQDNをMXレコードに設定
    さくらのメールボックスでは、メールサーバーのホスト名とは別に、自分で好きなホスト名を設定できます。こちらをMXレコードに設定していましたが、逆引きができないため、迷惑メール判定に影響するようです。逆引きが可能な、初期ホスト名をMXレコードに設定しました。
  • SPFレコードをIPアドレスベースからホスト名ベースに変更
    IPアドレスベースで記述しても構文上問題ありませんが、ホストのIPアドレスが変更される可能性に備え、ホスト名ベースで記述しなおしました。
  • DKIM, DMARCレコードを設定
    大手メールサービスの迷惑メールフィルタに引っ掛からないようになりました。
    秘密鍵の設定は、さくらのメールボックスのWebGUIからワンタッチででき、とても簡単でした。
  • 不要なレコードの削除
    未使用だった、mail.hk-shuttle.net.のCNAMEレコードを削除。DNS設定がすっきりしました。

設定内容が正しいことも確認済みです。

久しぶりにメール関連の設定を見直しましたが、独自ドメインメールの運用は少し大変ですね。ですがとても勉強になりました。

自分で整備したサービスは、自分でこまめに使わなきゃだめですね。放っておくといざ使いたいときにメンテナンスの手間が倍増してしまいます。

ドコモACアダプタ07の謎に迫る

以前の記事で取り上げたドコモのACアダプタ07。原因究明と修理・改造を兼ねて、少し遊んでみました。

概要

ドコモ純正のUSB PD充電器「ACアダプタ07」を、Xperia 1 II(XQ-AT42)で日常的に使用していたところ、断続的に充電が停止・再開を繰り返す症状が発生。以前の記事では分解と外観の調査までを試しました。
今回、より一層踏み込んだ原因の切り分けと動作の安定化を目指して調査と改造を試しました。

不具合の内容

ざっと大まかにまとめると、こんな感じ。

  • Xperia 1 IIとの組み合わせで、充電が一時停止する現象が頻発

  • 停止後すぐに再開されるが、ランダムな間隔でこの動作を繰り返す

  • プラグを差しても充電されないケースや、充電停止後再開しないケースも稀に発生
  • 他のPD充電器(例:Apple 61W充電器)とXperia 1 IIの組み合わせでは安定して充電を継続できる

  • 他のスマートフォンとACアダプタ07の組み合わせでも同じ症状が起こる場合がある
  • ノートPCなど、ACアダプタ07に繋ぐSinkによっては安定して充電できる場合もある
  • Xperiaの充電残量によっても発生頻度が変わり、満充電に近いときのほうが安定している?

  • 症状の再現性の高い条件を完全には特定できず

このように、何が原因か全く分からない所から検証をはじめました。

使用機器・検証環境

  • 充電対象Xperia 1 II(XQ-AT42)
     - USB PD対応
     - 最大受電電力:18W
     - 5V, 7V, 9VのFixed Supply PDOに対応、PPS対応
     - 充電状況に応じてかなり頻繁にPDOを切り替えながら充電している模様?
      - 7Vと5Vをずっと行ったり来たり。7V対応充電器では9Vを利用しない模様

  • 充電器:ACアダプタ07
     - ミツミ電機製造、ドコモ純正アクセサリとして販売
     - 5V 3A/7V 3A/9V 3A, 12V 2.25AのFixed Supply PDOに対応、PPS非対応
     - Richtek製RT7786LC(フライバック制御IC)搭載
     - 不明なPDコントローラー(WQFN-24、「6Z=」印字)

  • その他:PDパケットアナライザなど特殊な道具は持ち合わせていません

不具合の原因調査・その1

はじめ、真っ先に電解コンデンサの不調を疑って分解しました。
でも、液漏れや膨張の兆候もなく、コンデンサには十分な静電容量があるように思われました。2次側の固体高分子電解コンデンサは使用中に少し熱をもっているようでしたが、スイッチングノイズを吸収しているのが理由と考えられ、正常動作の範疇に収まっていそうです。
見た目で分からない微妙な不具合がある可能性も否定できないので、本来は取り外して単体検査すべきところなのですが、はんだの脱着時に部品を傷める可能性もあること、明確な不良も見つからなかったのでひとまずコンデンサは交換しませんでした。

次に目を付けたのは、ケーブルの電圧降下。この充電器はCaptive Cableという、充電器本体にケーブルが直付けされた構造をしています。

5Vで給電しているとき、基板側(電源端)の供給電圧は、5.2Vでほぼ一定。多くの電流を引いても供給電圧は変わらず、安定した電圧を出せています。基板側だけ見る限りでは、電圧に問題は無さそうです。
しかし、USB-C電圧電流チェッカーを使って、デバイスとUSB-Cプラグの間(負荷端)の電圧を調べてみると、電圧降下が顕著であることがわかりました。電流供給時に4.1V~4.8V程度*1まで電圧が落ちていることがわかり、しかも電流を引けば引くほど電圧が降下する傾向がみられました。これは、ケーブルの抵抗値が高すぎるとみて間違いなさそうです。

では、この電圧降下を改善すれば安定動作するのでしょうか?気になります。物は試しということで、Captive Cableを取っ払って、USB Type-C レセプタクル基板を取り付ける改造を施します。
レセプタクル基板を取り付けると、MicroUSB機器の充電など、色々な用途に転用可能になるので、利便性も上がるはずです。

改造してみる

というわけで、材料はこんなかんじ。

VBUSとGND、CC端子をACアダプタ07の基板からType-Cレセプタクル基板につなぎ、電源コードも基板にはんだ付け。

ですが、そのままだとうんともすんとも動きません。
どうやら、Captive Cableのプラグ側には、温度監視のためのサーミスタが入っていたみたいです。470Ωの抵抗を基板のTH-GND間に挿入してプラグを差すと動きます。AC通電中に一度でもTH端子が開放状態になると、プラグを抜くまで動作を停止しっぱなしになるので、TH端子をどうすれば動くのか、通電しながらの検証が難しかったです。

最終的に、Vbus, GND, CC1をレセプタクル基板に結線。TH端子を470Ωの抵抗を介してGNDに落としました。
レセプタクル基板側のCC2端子は開放。D+、D-端子は、スズめっき線で短絡しています。

この実装だと、USB PD、Type-C Current、USB BC DCP 1.5Aで充電できるはずです。ですが、Type-Cプラグを差すときに、上下を間違えると充電できません(笑)。CC2が基板から出ておらず、結線できていないためです。

AC入力側は、VFFコードの0.75sq品を選定しました。家電製品に使われているごく普通の電源コードで、7Aまで耐えられるものです。充電器に使うには十分な通電性能です。

ACアダプタ07にType-Cレセプタクルを取り付けた

仮配線を綺麗に整えて、ケースに入れたら完成です。食品用のポリプロピレン樹脂製タッパーを使い、やすりでケーブルが通る穴を頑張って開けました。この作業が一番大変だった。

蓋も閉まるようになり、絶縁も確保されました。これで普段使いできます。

ケースに封入したようす

改造結果

Captive Cableを除去してType-Cレセプタクル基板に置き換えたことで、電圧降下は減り、充電の安定性は向上しました。レセプタクルという接触部分が増えましたが、それでもなお、元々ついていたCaptive Cableよりも電圧降下が減ったようです。
AppleのC to Cケーブル(60W, USB2.0)を使ったときで、5V充電時で4.8V程度確保できるようになりました。これくらいの電圧降下は許容範囲です。

また副次的なメリットになりますが、Type-C to MicroUSBなどの、他の形状のプラグも挿さるようになり、多くの機器を充電可能になりました。

ですが、PD対応スマホの充電においては、不安定さも残る結果になりました。私の使用しているXperia 1 II XQ-AT42においても、充電中に一瞬充電が止まる現象がときどきあります。でも、繋いでも充電が始まらないという現象はほぼなくなりました。

仕様調査

ChatGPTと会話しながら、この充電器のさらなる仕様を調査しました。以前の記事では詳しくわからなかった、PDコントローラー周りの仕様を中心に調べました。

RT7207ベースのカスタムPDコントローラーを使っている?

ChatGPTによると、2018年頃のRichtek製PDコントローラーにRT7207という製品があることが分かりました。調べてみると、WQFN24パッケージを採用していて、本機に搭載されているものと機能面でも似通った部分があります。
フライバック制御ICにRT7786を使い、PDコントローラーにRT7207を使う組み合わせはRichtekのウェブサイトで2017年頃に公開されており、ACアダプタ07が2018年発売であることを踏まえると、RT7207を採用していたとしてもおかしくありません。

www.richtek.comですが、RT7207の標準品をそのまま採用しているかというと、その可能性は若干ですが低い気がします。このUSB充電器は7V3AのFixed Supply PDOに対応していますが、これは日本のキャリアスマホ向けに見られる独自仕様です。RT7207をベースに、7V3Aに対応するようにカスタムされたPDコントローラーを使っている可能性がありそうです。

2次側の基板実装まとめ

2次側のPDコントローラー周辺の実装について調査したのでまとめます。

  • 2次側のフライバック巻線および平滑コンデンサ付近に大きめのダイオードが表面実装されている
    →2次側に同期整流を用いていない可能性がある(RT7207は同期整流対応)
  • 1次側への電圧フィードバックにフォトカプラを用いている
    →RT7207のリファレンス実装と一致している
  • プラグ先端に温度検出用のサーミスタを用いている
    →RT7207には温度監視機能が備わっている点と一致している
  • CC2未配線、D+/D-未配線
    →RT7207のリファレンス実装と異なるが、Captive Cable向けの基板実装と考えれば不自然ではない

この基板実装内容からは、RT7207系のコントローラーを採用していたとしても矛盾がありません。RT7207系のカスタム品を採用している可能性は十分にあるでしょう。

不具合の原因調査・その2

このACアダプタの不具合についてですが、以下のような要因が考えられそうです。

  1. ケーブル電圧降下
    元のCaptive Cableでは電圧降下がひどく、大電流を引いたときに充電が不安定になっていた可能性があります。
  2. 温度検知の不具合
    改造過程で気づきましたが、プラグ側にはNTCサーミスタが埋め込まれている様子がうかがえました。改造過程で、NTCサーミスタを除去して、カーボン抵抗に置き替えました。改造後に充電の安定性が向上したことから、温度検知に不具合があり、「正常な温度であっても何らかの理由から異常を誤検知していた」または「端末側の温度上昇を拾って充電を停止していた」などの可能性はありそうです。
  3. PDコントローラーの不具合
    7Vという、USB PDにおいて非標準的な電圧に対応していることから、PDコントローラーに何かしらのカスタム実装がなされていると思われます。この実装に穴があり、端末側からのPDOの頻繁な切り替えを繰り返すとリセットがかかる、とう不具合がある可能性が考えられます。
    2018年と、USB PD対応機器が一斉に普及し始めた初期の充電器であることも踏まえると、なおさらコントローラーの不具合が見過ごされていた可能性も捨てきれません。

いずれも、確たる根拠のもと断定に至ったものではありません。あくまで可能性の一覧であると思って見ていただけるとありがたいです。

おわりに

読者の中にも、ドコモACアダプタ07の不具合で困っている方がいるかもしれません。スマホが悪いのかアダプタが悪いのかもやもやしながら使っている方もいることでしょう。

ですが、ACアダプタ07自体がかなり癖のある製品かもしれないこと、発売からすでに7年経過していることも踏まえれば、迷うことなくACアダプタ07を捨てて、新しいものに買い替えてしまっても構わないと思います。

また、「私ならもっと踏み込んだ原因究明ができる💪」という、心強い諸先輩方、特にPDプロトコル解析ができる方がいらっしゃいましたら、さらなる情報を貰えるとうれしいです。

*1:ちゃんとデータを取る前に分解しちゃったのでうろ覚えです...🙏

発電・電力使用状況可視化プロジェクト「helioview」をアップデートしました

以前ブログ記事でご紹介しました、発電・電力使用状況可視化プロジェクト「helioview」をアップデートしました。

機能や使い方、設定ファイルの記述などに変更点はありませんが、セットアップや運用、実装面で改善を行ったので紹介します。

Node.js製データ収集ツールを「heliostat」と命名

helioviewは、以下の3種類のツールで構成されています。

- helioview (Docker Compose プロジェクト)
  - heliostat (自作のデータ収集ツール)
  - InfluxDB (時系列データベース)
  - Grafana (データ可視化ツール)

従来は、heliostatに名前が与えられておらず、「データ収集ツール」などと呼称しておりましたが、固有名詞が与えられていた方が便利なのでこのたび命名しました。

heliostatは英語で「太陽を追尾する装置」といった意味合いがあります。オムロン製の太陽光発電計測ユニットに対してポーリングを行い、データを収集するツールであるため、このような名前を与えました。

リポジトリ名に変更はありません。Composeプロジェクト全体を「helioview」と呼んでいます。

InfluxDBの自動コンフィギュレーション

今回のアップデートによる目玉機能は「自動コンフィギュレーション」です。

以前は、helioviewを初回起動する前に、InfluxDBコンテナを先に立ちあげて、InfluxDBのWebUIを通じて、OrganizationやBucketの設定を手動で行っておく必要がありました。手作業によるInfluxDBの設定をユーザーに要求するのは親切な設計ではありませんでした。

今回のアップデートで、helioviewの起動時に、使用するOrganizationやBucketがあるかを前もって確認し、存在しなければこれらを自動生成するようになりました。ユーザー自身によるOrganizationやBucketの設定が不要になりました。

このアップデートは、すでに本プロジェクトを使用している既存のユーザーには影響ありません。

ログの表示改善

ログの重要度を「ERROR」「WARN」「INFO」の3段階に分けて表示するようにし、ログの視認性や検索性を向上させました。

改善されたエラーログ表示

モジュール分割

今までindex.jsに固めてモノリシックに実装をしていましたが、今後の拡張性や保守性を考え、モジュール分割を取り入れました。

以下のようにモジュール分割をしています。

- src/
  - database.js : データベースへのコネクションを扱うクラス
  - index.js : プログラム全体の実行の流れを制御するモジュール
  - init.js : データベースの初期化関数を実装するモジュール
  - power-metrics.js : データの取得とDBへの格納を実装するモジュール

データベースへのコネクションは、複数のモジュールから利用します。データベースへのコネクションはシングルトンなクラスとして実装し、同じコネクションが複数存在しないよう工夫しました。データベースの操作はメソッドとして抽象化しています。

今後の見通し

これまで、電圧・電流・電力などリアルタイムに変化するデータを扱ってきましたが、電力量についても、GrafanaによるリッチなUIを通じて分かりやすく可視化出来たら良いと考えるようになりました。電力量の収集機能も追加したいです。

また、InfluxDBに関しては設定自動化ができた一方で、Grafanaについては手動設定に頼る状態が続いているので、こちらも設定を簡略化・自動化できたらいいなと模索しています。

リポジトリへのリンク

今後も随時更新するので、オムロン製の太陽光発電計測ユニットをお持ちの方はぜひお試しください。

github.com

太陽光発電システムを活用しておうちの電力をGrafanaで可視化(後編)

こんにちは。前回の記事では、実家の太陽光発電システムを活用した、電力使用状況の可視化について、全体の概要とデータの考察をご紹介しました。

後編となる今回の記事では、実装を中心に解説します。

実装環境・バージョン

実装環境は次の通りです。

  • Debian 12.8
  • Docker 27.3.1
  • Docker Compose 2.29.7
  • node:lts-bookworm コンテナイメージ(Node.js 22.14.0)
  • influxdb:2 コンテナイメージ(InfluxDB 2.7.11)
  • grafana コンテナイメージ(Grafana 11.6.0)

データ収集ツール「heliostat」

太陽光発電の計測システムにGETリクエストを送り、JSONデータを取得し、InfluxDBにデータを書き込む自作ツールです。

開発環境はnvm, npmを用いて構築し、ある程度形ができあがってからDockerコンテナとして動作するようにしました。環境構築の解説はこの記事のメインテーマではないので割愛します。

予備実験

実験として、太陽光発電の計測システムにGETリクエストを送り、レスポンスが得られること、さらにJSONとして値を取得できることを確認します。

Node.js公式の学習ページにあるコーディングサンプルを参考に、Undiciを用いてGET処理を行います。

以下に、コンソールに電圧・電流・電力を出力するプログラムを示します。

電圧などの定数名は前編の「設計」の項を参照してください。また、${solarUrl}は計測ユニットのホスト名またはIPアドレスに置き換えてください。

async function main() {

    setInterval(fetchData, 1000);

    // 1秒ごとに fetchData() を実行

}
 

async function fetchData() {

    // GETリクエストを行い、レスポンスをJSONとして読み込み

    let response = await fetch(`${solarUrl}/asyncquery.cgi?type=SysInfo`);

    const sysInfo = await response.json();

    response = await fetch(`${solarUrl}/asyncquery.cgi?type=CurCtDir`);

    const curCtDir = await response.json();

    response = await fetch(`${solarUrl}/asyncquery.cgi?type=PcsOne&pcsNumber=0`);

    const pcsOne = await response.json();

 

    // JSONから値を取得

    const pu = sysInfo.mainSensorData.costValueU;

    const vu = sysInfo.mainSensorData.voltageU / 10;

    const iu = sysInfo.mainSensorData.currentU / 10;

    const pw = sysInfo.mainSensorData.costValueW;

    const vw = sysInfo.mainSensorData.voltageW / 10;

    const iw = sysInfo.mainSensorData.currentW / 10;

    const ptrade = curCtDir.instantPower.tradedPower;

    const pconsume = curCtDir.instantPower.consumedPower;

    const pgen = pcsOne.onePcsInfoData.power;

    const vdc = pcsOne.onePcsInfoData.directVoltageArray[0] / 10;

    const idc = pcsOne.onePcsInfoData.directCurrentArray[0] / 10;
 

    // 取得した値をコンソールに出力

    console.log("Phase U: " + vu + "V " + iu + "A " + pu + "W");

    console.log("Phase W: " + vw + "V " + iw + "A " + pw + "W");

    console.log("Traded: " + ptrade + "W");

    console.log("Power Consumption: " + pconsume + "W");

    console.log("Generated Power: " + pgen + "W");

    console.log("DC Bus: " + vdc + "V " + idc + "A\n");

}

実行例は次のようになります*1

Phase U: 103.5V 23.5A 2189W

Phase W: 99.8V 4.2A 335W

Traded: 2524W

Power Consumption: 2524W

Generated Power: 0W

DC Bus: 0V 0A

InfluxDBの利用

予備実験を通して、太陽光発電の計測システムから電圧・電流・電力の各値を取得できることがわかりました。先ほどのコードを元に、取得したデータをInfluxDBに格納するコードを作成します。

まず、InfluxDB OSS v2 Documentationを参考に、@influxdata/influxdb-clientと@influxdata/influxdb-client-apisをnpmコマンドでインストールします。公式ドキュメンテーションにはTypeScriptをインストールするよう指示がありますが、今回はJavaScriptで開発するのでTypeScriptをインストールする必要はありません。

続いて、コードを書いていきます。

Import文

configをインポートしているのは、計測ユニットのIPアドレスやデータの取得間隔、InfluxDB関連の情報など、環境依存の情報をconfig.jsonファイルにすべてまとめるためです。これらを別のファイルに分離すると、環境が変わってもコードを書き換える必要はなくなります。

import { InfluxDB, Point } from "@influxdata/influxdb-client";
import config from '../config.json' with { type: 'json' };

main関数

configファイルのfetchIntervalSecondsキーで指定した秒数おきに、計測ユニットにGETリクエストを投げます。

async function main() {
    setInterval(fetchData, config.fetchIntervalSeconds * 1000);
}

fetchData関数

計測ユニットにGETリクエストを投げ、データの取得ができたら、write関数を呼びます。
データの取得に失敗してもプログラムが落ちないように、try-catch文によるエラーハンドリングを入れています。データの取得に失敗したら、格納をスキップし、エラーが起きた旨をコンソールに吐き出します。

async function fetchData() {
    try {
        let response = await fetch(`${config.solarUrl}/asyncquery.cgi?type=SysInfo`);
        const sysInfo = await response.json();
        response = await fetch(`${config.solarUrl}/asyncquery.cgi?type=CurCtDir`);
        const curCtDir = await response.json();
        response = await fetch(`${config.solarUrl}/asyncquery.cgi?type=PcsOne&pcsNumber=0`);
        const pcsOne = await response.json();

        await write(sysInfo, curCtDir, pcsOne);
    } catch (error) {
        console.error(new Date() + ": " + error);
    }    
}

write関数

InfluxDBクラス、Pointクラスの基本的な使い方は Write data with the InfluxDB JavaScript client library | InfluxDB OSS v2 Documentation を見ると良いと思います。

今回は、realtimedataというMeasurement名を使用し、タグを付けずに、取得したデータをフィールドに投入しています。

Pointの挿入が完了したらコンソールにログを出します。ただ、本番運用ではエラーログが流れると不便なので、configのsuppressLogがtrueであれば、成功時のログは出しません。

async function write(sysInfo, curCtDir, pcsOne) {
    const influxdb = new InfluxDB({ url: config.influxdb.url, token: config.influxdb.token });
    const writeApi = influxdb.getWriteApi(config.influxdb.org, config.influxdb.bucket);
    const point_realtimedata = new Point('realtimedata')
        .floatField('Vu', sysInfo.mainSensorData.voltageU / 10)
        .floatField('Iu', sysInfo.mainSensorData.currentU / 10)
        .intField('Pu', sysInfo.mainSensorData.costValueU)
        .floatField('Vw', sysInfo.mainSensorData.voltageW / 10)
        .floatField('Iw', sysInfo.mainSensorData.currentW / 10)
        .intField('Pw', sysInfo.mainSensorData.costValueW)
        .intField('Ptrade', curCtDir.instantPower.tradedPower)
        .intField('Pconsume', curCtDir.instantPower.consumedPower)
        .intField('Pgen', pcsOne.onePcsInfoData.power)
        .floatField('Vdc', pcsOne.onePcsInfoData.directVoltageArray[0] / 10)
        .floatField('Idc', pcsOne.onePcsInfoData.directCurrentArray[0] / 10);

    writeApi.writePoint(point_realtimedata);
    if(!config.suppressLog){
        console.log(new Date() + ": Write OK");
    }
}

コードの全体は、helioview/src/index.js at main · HKShuttle/helioview · GitHubを見てください。

うっかり経験したトラブルとしては、データ収集プログラムからInfluxDBにアクセスできない、というものがありました。データ収集プログラムから「localhost」や「127.0.0.1」を指定してInfluxDBに接続しようとしていましたが、これではアクセスできません。「influxdb2」を指定すると接続できました。
Docker Composeはコンテナのサービス名を用いて名前解決ができるので、別コンテナにアクセスしたいときはcompose.ymlで定義したサービス名をホスト名として使うのが良いようです。別のコンテナにアクセスするわけですから、localhostじゃ繋がらないのは当たり前ですね...。

Docker

先ほどのプログラムをコンテナとして動作させるために、まずDockerfileを書きます。このように書きました。
コンテナをビルドすると、npm installまでが実行されます。コンテナを実行すると、ENTRYPOINTに書いたコマンド「npm run test」が実行されます。

FROM node:lts-bookworm

COPY . /helioview

WORKDIR /helioview

RUN npm install

ENTRYPOINT [ "npm", "run", "test"]

上記のコンテナを、InfluxDBやGrafanaと連携して動作させるためのcompose.ymlを書きます。長いので、全体はhelioview/compose.yml at main · HKShuttle/helioview · GitHubを見てください。

データ収集プログラムはInfluxDBに依存して動くので、compose.ymlに以下のようなhealthcheckを入れています。

healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8086/health"]
      interval: 5s
      timeout: 10s
      retries: 10

InfluxDB

InfluxDBでは、RDBと違う用語がいくつか出てきます。

InfluxDBにおいて、PointはRDBにおけるレコードの行に相当するといわれています。同様に、Measurementはテーブル、Bucketはデータベースに相当するといわれています。

また、InfluxDBにおいて、Pointを挿入する前にBucketを作成する必要はありますが、Measurementを作成する必要はありません。Pointを挿入すれば、存在しないMeasurementは自動で作成されますし、同じ名前のMeasurementが存在すればそちらにPointが追加されていきます。

準備としては、まず、ターミナルで $ sudo docker compose up -d influxdb2 を実行し、InfluxDBを立ち上げます。正常に起動すれば、ブラウザでInfluxDBにアクセスできます。アクセスできない場合は、ターミナルで $ sudo docker compose logs -f influxdb2 を実行してログを確認します。

Organizationの作成

Organizationは、Bucketにアクセスするための資格情報になります。WebUIからOrganizationを作成すると、Bucketも自動で作成されます。

左側の青い「O」ボタンをクリックし、Create Organizationをクリックします。すると下の画像のような画面が出るので、Organization Nameに任意の名前、Bucket NameにそのOrganizationで使いたいBucketの名前を入力して、CREATEを押します。

これで、Organizationの作成は完了です。

Organizationの作成

ここまでの準備がうまくいけば、計測ユニットから取得したデータがInfluxDBに格納されるはずです。

InfluxDBにデータが格納されている様子

Grafana

Data sourceの設定

ブラウザでGrafanaにアクセスし、メニューバーの「Connections」から「Data soueces」を選びます。Data sourcesの画面で「Add new data source」をクリックします。Add data sourcesの画面で「InfluxDB」を選択します。ここまでは簡単ですよね。

InfluxDBの追加画面では、「Query language」に「Flux」を選択します。「HTTP>URL」には「http://influxdb2:8086*2と入力します。「InfluxDB Details」の「Organization」「Token」「Default Bucket」にも適切なものを入力します。他は初期値のままで構いません。

「Save & test」をクリックして、設定がうまくいっていることを確認します。

Data sourceの設定

ダッシュボードの作成

メニューバーから「Dashboards」を選択してダッシュボード一覧画面を表示します。右側の「New」ボタンをクリックし、「New dashboard」をクリックします。

空のダッシュボードが表示されるので、画面中央の「+Add visualization」をクリックします。

空のダッシュボード。ここにVisualizationを追加していく

Add visualizationをクリックすると、「Select data source」のモーダルが出ます。先ほど追加したinfluxdbがハイライトされているので、それをクリックします。すると、データベースへのクエリ文を入力する画面が出るはずです。クエリ結果として時系列データが返ってくれば、カラム*3ごとの時系列の値の変化をGrafanaが自動的にグラフ化してくれます。

クエリ文の入力画面

クエリ文のビルド

Data sourceを追加するときに、クエリ言語には「Flux」を指定しました。Fluxによるクエリ文は、InfluxDBのWebUIで簡単にビルドできるので、それを試してみます。

InfluxDBのData Explorer画面で、可視化したいフィールドキーにチェックを付け*4、「SUBMIT」をクリックします。例として、電流値3種類を可視化してみます。左上のプルダウンメニューで「Graph」を選ぶと、値の時系列変化がグラフとして描画されることを確認できます。

可視化したいフィールドキーにチェックを付けてグラフを確認

そのまま、右側の「SCRIPT EDITOR」をクリックすると、Flux言語によるクエリ文が得られます。このクエリ文を、GrafanaのVisualization作成画面に貼り付けて、「Reflesh」ボタンを押せば、Grafanaでグラフが描画されます。

自動でビルドされたクエリ文を取得できる

グラフに単位を付ける

グラフに単位があるとグラフを読みやすいです。Grafanaの活用法の一例として、「グラフに単位を付ける」機能を紹介します。

先ほどの例では、電流値3種類をグラフ化しました。電流の単位は「アンペア(A)」ですので、縦軸をアンペアにしてみます。

右側のメニューの「Standard options」から「Unit」の欄内をクリックします。電気の単位は「Energy」に分類されているので、Energyから「Ampare」をクリックします。これで、グラフの縦軸に単位が付きます。

グラフに単位を付ける

ダッシュボードの保存

作成したパネルには名前を付けておくとよいでしょう。右側メニューの一番上「Panel options」から「Title」を選び、パネルに名前を付けます。

また、グラフの更新間隔や時間軸も保存されるので、最も見やすいと思うものを選択しておきます。

最後に、右上の「Save dashboard」を押し、ダッシュボードに好きな名前を付けて保存します。ここまでくればようやく、一通りの作業が完了です!

1枚のダッシュボードには複数のパネルを表示できますし、Visualizationの種類も折れ線グラフ以外にさまざまなものがあります。ここで紹介しきれない機能も多く、私自身がまだ使いこなせていない機能、見つけきれていない機能も数多くありますが、まさに「習うより慣れよ」で、色んな操作を試してみるのが良さそうです。

感想

太陽光発電の計測システムを色々いじっていて、電圧や電流といった情報を取ってきて可視化できそうだということには1年以上前から気づいていました。作りたいとはずっと思っていたのですが、なかなか時間ができず寝かせていました。実際に作ってみると拍子抜けするほど簡単で、早く作ればよかったなと思いました。

そして今回、Node.jsやInfluxDBなどの技術を実践的に学ぶ機会ができました。InfluxDBのスキーマ設計など、まだよくわかっていない点も多く、今後も触れることがあればさらに勉強を重ねたいです。

技術記事を書いたのもかなり久しぶりで、アウトプットの難しさを痛感しました。単にものを作るだけではなく、誰かに読んでもらえるような文章を残す事も今後続けたいです。

リポジトリの紹介

今回開発したプロジェクトはGitHubで公開しています。同じ太陽光発電システムをお持ちの方はぜひぜひ自由に使ってください。

オムロン製の計測ユニット「KP-MU1P」系列以外には対応していません。

私の実装を流用して、他の太陽光発電システムやHEMSに対応するように改良してもらってもかまいませんし、コードを参考に別のプロジェクトを作ってもらってもかまいません。

なにかあればPRを投げてもらえるとうれしいです。

github.com

*1:力率の関係で、有効電力は電圧と電流の積より小さくなります

*2:compose.ymlで定義したサービス名

*3:InfluxDBの場合はField keyが相当

*4:チェックを付けなければすべてのフィールドキーを選択できます

太陽光発電システムを活用しておうちの電力をGrafanaで可視化(前編)

こんにちは。久しぶりに趣味開発をしたので今回はその記事です。

実家の太陽光発電システムを活用して、電力使用状況をGrafanaで可視化してみました。

実装の解説は後編の記事にまとめるので、今回は全体の概要とデータの考察を記事にします。

出来上がったもの

細かい話はさておき、まずはどんな風に電力使用状況を可視化できているかお見せします。

直近24時間の電力使用状況グラフ

こんなGrafanaダッシュボードを作ってみました。左上から時計回りに「電力消費と発電量のグラフ」「主幹電圧」「太陽電池の電圧」「主幹電流と太陽電池の電流」「電力会社との取引電力」の5種類のグラフを表示しています。このグラフでは、直近24時間のデータの変化を折れ線グラフで描画しています。我が家のリアルタイムの電力使用状況はこのダッシュボードを見れば一目瞭然です。

背景

実家では、長州産業の太陽光発電システムが2017年から稼働しています。計測ユニットとして、オムロン製「KP-MU1P」相当と思われる「CMCS-Z01A」が設置されています。

機器の設置状況。左が計測ユニット、右がパワーコンディショナー

計測ユニットは電力使用状況や発電状況を記録するほか、無線LANを経由して専用モニター(カラー表示ユニット)にこれらの状況を表示できます。また、ソフトウェア更新や出力制御情報のやり取りのために、家庭の無線アクセスポイントに接続することもできます。

我が家では計測ユニットを家庭の無線LANに繋いでいます。そこで試しに、計測ユニットに割り当てたIPアドレスにブラウザからアクセスしてみると、専用のモニターに映るのと同じ画面がなんとブラウザでも表示できてしまいます。

ブラウザから計測ユニットにアクセスすると電力使用状況が見られる

この電力使用状況はリアルタイムで更新されるので、ブラウザと計測ユニットの間でどんな通信をしているか気になりました。開発者ツールで確認すると、計測ユニットがJSONを返していることが判明。

計測ユニットはJSONを喋れる

JSONデータを解析すると、売買電力や発電電力など、色々なデータが含まれていることがわかりました。その後も解析を続け、電圧や電流など、計測ユニットのUIではグラフ化されないデータもJSONレスポンスとして受け取れることがわかりました。

計測ユニットに標準で実装されているUIでは、発電・売電・消費・買電した電力量を1時間単位でグラフとして表示できます。とても見やすく操作性も決して悪くありませんが、他の情報、たとえば電圧や電流、電力といったものをグラフ化することはできませんし、時間軸を細かく変えてグラフ化することもできません。

JSONレスポンスとして受け取れる情報をデータベースに蓄積し、可視化ツールを通して閲覧することで、計測ユニットだけでは見られない細かな情報を分析できるのではないかと考えました。

設計

まず収集するデータの種類ですが、以下の通りとします。V、I、Pは、それぞれ電圧、電流、電力の量記号を用いています。

  • 電圧(V)
    • Vdc: 太陽電池アレイの直流電圧
    • Vu: U相の主幹交流電圧
    • Vw: W相の主幹交流電圧
  • 電流(I)
    • Idc: 太陽電池アレイの直流電流
    • Iu: U相の主幹交流電流
    • Iw: W相の主幹交流電流
  • 電力(P)
    • Pconsume: 全消費電力
    • Pgen: パワーコンディショナーの発電電力
    • Ptrade: 電力会社からの買電(正)または売電(負)電力
    • Pu: Ptrade のうちU相に流れた電力
    • Pw: Ptrade のうちW相に流れた電力

データを分析してグラフ化するツールとしては、Grafanaを用います。以前、JANOGNOCをやっていたときにGrafanaを知り、自身でも使ってみたいと思っていました。Grafanaを使って、家庭の電圧・電流・電力を可視化したいと思いつきました。

Grafanaが提供するのは、すでにあるデータソースを読み取って、データを可視化する機能だけです。データソースはもちろんのこと、データを収集する機能も別で用意しなければなりません。

データソースとしては、時系列のデータを蓄積する、データベースのようなものがあれば良さそうです。はじめは、個人的な好みでMariaDBとかPostgreSQLなんかを使ってみたいと思っていたのですが、時系列データの扱いに向いたInfluxDBというデータベースがあるのを知りました。今回の用途には適任だと思い、InfluxDBを採用しました。

データを収集するツールは、学習を兼ねて自作します。言語選定については少し迷いましたが、「JSONを扱うならJavaScriptとの親和性が高いのでは?」と思い、Node.js公式の学習ページにあるコーディングサンプルを眺めてみました。GETレスポンスでJSONを受け取るコードがすごく簡単に書けることがわかり、Node.jsで開発することに決めました。

データを収集する自作のツールはheliostatと命名します。

heliostat、InfluxDB、Grafana、これらを組み合わせて電力状況を可視化します。これら3つの構成要素それぞれはDockerコンテナとして動かし、Docker Composeを用いて、単一のプロジェクトとして管理します。

プロジェクトの概略を図で表すとこのような感じです。Linuxマシンとしては以前から稼働している自宅サーバーを流用するので、追加で必要になるハードウェアは全くありません。

プロジェクトの構成図

データと考察

今回のシステムで、実家の電圧・電流・電力をそれぞれ可視化できたので、これらのデータについて考察します。

主幹電圧・主幹電流

主幹に流れる交流電圧・交流電流のグラフを図に示します。短期的な変化を見ても特徴が掴みづらいため、2日間の電圧・電流の変動を見てみます。

日中は電圧が高く、102V以上になる時間帯が多いです。時間帯によっては104Vを超えることがあります。夜間は電圧が下がり気味で、97V近くまで降下することがあります。

電圧降下は電流との相関が大きいため、電圧のグラフと電流のグラフを上下に並べて比較しました。夕方から夜間にかけてスパイク状の電流波形がみられ、それに同期して電圧が降下していることがわかります。日中の電流波形の盛り上がりは発電に起因しており、電圧が上昇していることが分かります。
周りが住宅街のため、特に平日の日中は低圧配電系統全体が軽負荷になっているところ、さらに住宅太陽光発電で電力が送り込まれるため、日中に電圧が上昇しやすいのだと考察します。

さらに過去の期間までさかのぼって見ると、宅内で負荷を使用していないのに電圧が降下することがありました。同じ低圧配電系統につながる他の住宅で負荷を使用したタイミングで電圧が変動した可能性があります。

単相100Vの配電電圧は101V±6Vと規定されており、これまで計測した期間中に異常な電圧上昇・電圧降下は確認できませんでした。電圧変動は許容範囲内といえるでしょう。

交流電圧・交流電流のグラフ

直流電圧・直流電流

パワーコンディショナー入力点における太陽電池アレイの直流電圧と直流電流を図に示します。晴れた日の1日の電圧・電流の変化をグラフ化しました。

太陽電池は電流源としての特性をもち、その出力電流は日射強度に応じて増加します。また、開放電圧は内部ダイオードの順方向電圧によって決まり、ある程度以上の日射があればほぼ一定の開放電圧に落ち着きます。

朝方に太陽電池アレイの直流電圧が立ち上がります。開放電圧が100Vを超える5:30頃から、パワーコンディショナーが起動しようと試みますが、日射強度が十分に高まるまでは、電流を引き出すと出力電圧が急激に低下するため、パワーコンディショナーが起動できません。この日は5:51頃にパワーコンディショナーが起動し、交流出力運転を開始しています。

出力中の太陽電池アレイの電圧は、110Vから130V程度を保つように運転されていました。パワーコンディショナーは、太陽電池アレイから最大出力が得られる負荷電流に追従して運転します。最高出力点に追従すると、概ねこの程度の電圧に落ち着くのでしょう。

太陽電池アレイの電圧は出力が低いときに高く130Vくらいで、ピーク出力時には電圧が降下して116Vほどまで落ちます。おそらく、セルの電圧を一定程度に保って運転しており、負荷端から見ると配線の抵抗によって電圧が降下しているのではないかと考えます。

18:55ごろに出力運転が停止し、その後19:00を過ぎてパワーコンディショナーがシャットダウンすると、太陽電池アレイの電圧が一旦急上昇します。その後、日没とともに太陽電池の開放電圧が落ち、最終的に0Vに落ちます。

直流電圧・直流電流のグラフ

電力

まずは、消費電力、発電電力、取引電力、各相の有効電力を1枚に表示したグラフをお見せします。目玉のような波形が描かれていますが、縦軸の中央を基準に上方向が消費+発電電力、下方向が売電電力となっています。

日中に軽負荷となっており、発電した電力から消費電力を差し引いた分が売電されています。

電力のグラフ

消費電力の傾向をもう少し分析したいので、消費電力だけを表示したグラフを示します。

この日は夜中に冷え込んでいたので暖房器具が動いていた時間帯があるのと、朝の4:00頃から6:00過ぎまでエコキュートが沸き上げ運転を行っていたので、夜間の電力使用が多くなっています。朝7:00頃から8:00すぎまで調理器具を使用したので、その部分も波形が立っていますね。

日中は在宅していましたが、窓を開けており空調、照明、洗濯などの負荷をまったく使っていないので電力消費が少ないです。夕方以降に家族が帰宅したので、夕方から夜以降は再び電力消費が増えます。

日によって多少の違いはあるものの、やはりオール電化なので深夜帯に電力消費が多い傾向は毎日共通してみられます。

消費電力のグラフ

感想

電圧・電流・電力の各データを可視化できたことで、単に瞬時値を見るだけでは分からない、データの時系列の変化がつかめるようになりました。データを蓄積すれば、1ケ月、半年など、長期的なデータの変化も見られるでしょうから楽しみです。

今回、電力量(kWh)については可視化していません。電力量については計測ユニットでも十分にグラフ化できていることからあまり不満がない事もあり、まずは計測ユニットで可視化できない情報を補完的に可視化したかった点が第一の理由。そしてもう一つの理由は、どんなデータを取得してどんなふうに表示できれば良いか、まだ構想が十分に沸いていない点にあります。積算値を出すか差分値を出すか、データの最小間隔をどれくらいにするか、などなど...。いいアイデアが思いついたら電力量も可視化したいですね。

リポジトリの紹介

実装の詳細は後編の記事にてご紹介します。

今回開発したプロジェクトはGitHubで公開しています。同じ太陽光発電システムをお持ちの方はぜひ自由に使ってください。

オムロン製の計測ユニット「KP-MU1P」系列以外には対応していません。

私の実装を流用して、他の太陽光発電システムやHEMSに対応するように改良してもらってもかまいませんし、コードを参考に別のプロジェクトを作ってもらってもかまいません。

なにかあればPRを投げてもらえるとうれしいです。

github.com