As I Please

MTのいんすとーるの練習と、その他びぼうろく・・・

タグ「python」が付けられているもの


IIJmio の3つのsimで容量シェアしたときに一番安い組み合わせ

いま3つのsim契約をしていて、データ容量シェアしている。使わなかった分は翌月に持ち越しできるので、容量オーバーにならないよう細かに契約料の変更をしていけば、わずかに(200円程度?)は無駄を無くせる。
で、1sim契約あたり、2,5,10,15,20 Gの契約ができて、どの組み合わせが最適(最安)か?というのを計算しておく。
3つの契約で5パターンのコンビネーションで、重複ありのケースは35通りあるようで、そのおのおののケースの契約総容量と金額を作って、金額の順にソートしていったもの。
〇が意味があるところで、×は他の契約パターンで金額が逆転してしまうので選択してはいけないケース。
パターンは、0=2G,1=5G,2=10G,3=15G,4=20G を意味している。
2023/09での金額は、2G=850,5G=990,10G=1500,15G=1800,20G=2000

家族での利用料を見ると月に 7Gから18G あたりをうろちょろしているので、
9G,12G,15G,17G,20Gあたりの契約をうろちょろすることになるか?
あんまり節約にもなってないかもですが、気持ちだけ。

パターン 総容量 契約額 1Gあたり単価(契約額/総容量)
〇 000 6 2550 425.0
〇 001 9 2690 298.8888888888889
〇 011 12 2830 235.83333333333334
〇 111 15 2970 198.0
× 002 14 3200 228.57142857142858
〇 012 17 3340 196.47058823529412
〇 112 20 3480 174.0
× 003 19 3500 184.21052631578948
〇 013 22 3640 165.45454545454547
〇 004 24 3700 154.16666666666666
〇 113 25 3780 151.2
〇 014 27 3840 142.22222222222223
× 022 22 3850 175.0
〇 114 30 3980 132.66666666666666
× 122 25 3990 159.6
× 023 27 4150 153.7037037037037
× 123 30 4290 143.0
〇 024 32 4350 135.9375
× 033 32 4450 139.0625
〇 124 35 4490 128.28571428571428
× 222 30 4500 150.0
× 133 35 4590 131.14285714285714
〇 034 37 4650 125.67567567567568
〇 134 40 4790 119.75
× 223 35 4800 137.14285714285714
〇 044 42 4850 115.47619047619048
〇 144 45 4990 110.88888888888889
× 224 40 5000 125.0
× 233 40 5100 127.5
× 234 45 5300 117.77777777777777
× 333 45 5400 120.0
〇 244 50 5500 110.0
× 334 50 5600 112.0
〇 344 55 5800 105.45454545454545
〇 444 60 6000 100.0

pythonで、組み合わせを一気につくれる関数が使えるので、それで。

comb = itertools.combinations_with_replacement('01234', 3)

influxdb + grafana + python3 + python-influx データ投入 stringになってしまった。

InfluxDB Error: unsupported mean iterator type: *query.booleanInterruptIterator

というエラーが出た。meanが取れない?何でと思って、influxの中で各種データを見たら、ジャイロ、加速度、温度、気圧、その他全てのデータが 'string'になっていた。 cactiで使っているプログラム(python3)で、redisからデータを取ってきて do.wirte_points で書き込んでるだけだけど、redisで引っ張ってきたデータが文字列処理をしていることもあり、string形式を保ったまま influxdbに放り込まれてたっぽい。 float()とか int()(バッテリーは%の整数値)とcastして放り込み直して解決。

switchbot 温湿度計2つ目

家の中にセンサーを置いていろいろ(安価に)計測するのに、4年前にはテストで CC2650STKを購入して BlueToothでデータの取得とかやってたが、単純に 温度・湿度程度であれば、SwitchBotの温湿度計が良さそうということで購入してみて、データを取り始めていた。Switchbotハブミニと一緒に導入したら nature remo と同様に Cloudにデータが上がり、auth0 の認証で APIを叩くことで温度・湿度のデータが取れる。が、すでに nature remoもあるし赤外線リモコンはもう不要だし、そもそも Bluetooth でローカルにデータは出ている、RSSIとBatteryはAPIでは取得できず、なので、4000円弱出して ハブミニを買うのをためらっていた。
室内の温度とは別に、冷蔵庫(飲み物用の、出し入れ扉がガラス製)が夏にはときどきエラーを出して内部温度が上がってしまうことが月に1度程度発生していたので、それを検知するのに、もう1つswitchbot温湿度計を買って今年の夏に備えることにてみようと考えた。
CC2650だと、2分以内に connect して繋ぎ続けないと BLEの接続が切れてしまう仕様で消費電力が多くなるが connect しながら使い続ける必要があり、そうなると電源(CR2022)の寿命問題があるので外付けで単3x8本(2本直列x4並列)など作ってみたが最長3ヶ月くらいしかもたなかった。もっとうまいハンドリング手法があるのだろうけど、、、と思いながら switchbot を使ってみたら単4電源2本で半年は優に問題なくデータを出し続けていて、かつ、バッテリー表示が100%と本当か?と思えるくらい。温度だけだけど安定してデータが長期間取れるのであれば、まずはこれで冷蔵庫のモニターは必要十分ということで、amazonでもう1つ買ってみた。

ここから時系列で書いてみると、

  • 新Switchbotで接続・データ取得はうまくいく。ただし液晶の温度で数字で2,3カ所表示されないところがあって、これはちょっと何だかな・・・まぁ冷蔵庫の中に入れるので問題ないか。
  • これを冷蔵庫の中に入れたら、データが電波強度が激減。データがraspberyy pi3では取れない。が、同じ場所にいる iPhoneアプリからは取得可能。でかつ過去データの取得もOK.冷蔵庫の扉のガラス、2重でUVカットとかをうたっているのでこれが影響?
  • データを取得するために、タイムアウト対応を強化(取れないときはあきらめる)したプログラムで動かしてみるが、やはり3時間に1度くらいしかデータを拾って来ない。raspberryp pi3の位置・角度を変えたりしてみたがなかなか良いところは見つからない。
  • 電池消耗を抑えるために、BLEの advertisingデータを拾って温湿度等を取っていたが不安定。アプリだとしっかりconnectしてデータ取得しているようなので、公式のgit.hubにあるpython-hostを見て、connect してデータを取得しようとしたら、古いものはデータが来るが、新しく購入した方はデータが取れない。Errorを返す。どうも、GATTを発行しているところで error になる。2つとも firmwareは同じバージョン(2.6)なのに、、、?とはいえ、CC2650STKでもあった話だから、bluetooth機器だとよくある話なのかも
  • ふと思い立って、古いほうの switchbot を冷蔵庫の中に入れて運用してみたら、これも電波強度は落ちているかもしれないが、raspberry pi3でデータは取得している。時に欠損するときもあるが新しいものとは段違いに取れている。これ、同じものとは言えない?
ということで、同一製品とは言えどうも中身が違うのでは?という感じ。
新しいもののほうが劣化版のような気がするので、液晶表示が欠けるのを理由に、返却・交換してもらうことに。新しいものも劣化している可能性はあるが。

certbot on FreeBSD9

なかなかやめられない古いOSで、次は証明書(let's encrypt) を使い続けたくて。。。 運用には certbot を使うのがデフォルトのようで、ports が使えないことを前提にすれば、git clone で持ってくるのがベスト。 ということで、

git clone https://github.com/certbot/certbot

を行ったら、

SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

ということで、gitが tls1.2をしゃべらない!のが問題(古い git clientすぎた)ので、まずはこれをバージョンアップしてみた。ところが、、、直らない。。。見ると gitは裏では curl を使っているようなので、これが tls1.2を使うようにしないといけなかった。ということで、curlも最新版を持ってきて openssl も tls1.2 を使えるバージョンを参照してinstall. でも、今度は git-remote-https.core を吐いて何もすすまない。shared ライブラリ参照が違うとかそこらへんだろうから、ということで、libzも入れ直してみたがやはりおかしい。。。 コンパイラ環境の問題かもと疑ってみると、そこらへんだったみたい。 curl -> /usr/bin/gcc 利用 git -> /usr/bin/gcc 利用は coreを吐く。 ということで環境変数 CC=/usr/local/bin/gcc を設定しコンパイルしなした gitだとちゃんと cloneできた。 libz,libiconv,libintl,libchasetあたりも/usr/local/lib 側をちゃんとリンクしてくれた。 いまどきllvm,clangなんでしょうが、、、、、もうちょい生きながらえさせて。 git cloneでファイルをダウンロードできたが、次にhttps://certbot.eff.org/docs/contributing.htmlを参照して、

python3 tools/venv3.py

なのだが、ここでどうも yaml(pyyaml)のところでエラー。これも gccを利用しているが/usr/bin/gcc を見ているケースと/usr/local/bin/gcc を見るケースがあるのが問題のよう。 .cshrc で /usr/local/bin を優先させることで /usr/local/bin/gcc を先に見るようにしたところ、まずはここはクリア。 bash で
source venv3/bin/activate
run_acme_server &
certbot_test certonly --standalone -d test.example.com
と実行してまずはローカルで動くかどうかを試すのだが、run_acme_server のところで落ちる。うまく webserver が起き上がってくれない。
[venv3] root@host:/usr/local/src/certbot # run_acme_server
=> Starting pebble instance deployment...
ELF binary type "0" not known.
=> Tear down the test infrastructure...
=> Test infrastructure stopped and cleaned up.
Traceback (most recent call last):
  File "/usr/local/src/certbot/venv3/bin/run_acme_server", line 11, in 
    load_entry_point('certbot-ci', 'console_scripts', 'run_acme_server')()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 221, in main
    with acme_server as acme_xdist:
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 96, in __enter__
    self.start()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 62, in start
    raise e
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 57, in start
    self._prepare_pebble_server()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 135, in _prepare_pebble_server
    self._launch_process(
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 205, in _launch_process
    process = subprocess.Popen(command, stdout=stdout, stderr=subprocess.STDOUT, cwd=cwd, env=env)
  File "/usr/local/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/usr/local/src/certbot/certbot-ci/certbot_integration_tests/assets/pebble_v2.3.0_linux-amd64'
なんか、certbot が linuxの実行ファイル(linux binary for amd64)を抱えていてこれが freebsdでは動かない、ということのようだ。linux-compat とか入れればいいのかもしれないがそこまでやるかな。。。ということでこの線はあきらめて、、、 certbot は普通に python(2or3)のコードだったことを思い出して、$src/certbot/の中を見ると、setup.pyがあるので、
python3 setup.py build
python3 setup.py install
で、/usr/local/bin/certbot にインストールされた。
certbot certonly --standalone -d test.example.com
でちゃんと証明書が降りてきた。

certbot on FreeBSD9

なかなかやめられない古いOSで、次は証明書(let's encrypt) を使い続けたくて。。。 運用には certbot を使うのがデフォルトのようで、ports が使えないことを前提にすれば、git clone で持ってくるのがベスト。 ということで、

git clone https://github.com/certbot/certbot

を行ったら、

SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version

ということで、gitが tls1.2をしゃべらない!のが問題(古い git clientすぎた)ので、まずはこれをバージョンアップしてみた。ところが、、、直らない。。。見ると gitは裏では curl を使っているようなので、これが tls1.2を使うようにしないといけなかった。ということで、curlも最新版を持ってきて openssl も tls1.2 を使えるバージョンを参照してinstall. でも、今度は git-remote-https.core を吐いて何もすすまない。shared ライブラリ参照が違うとかそこらへんだろうから、ということで、libzも入れ直してみたがやはりおかしい。。。 コンパイラ環境の問題かもと疑ってみると、そこらへんだったみたい。 curl -> /usr/bin/gcc 利用 git -> /usr/bin/gcc 利用は coreを吐く。 ということで環境変数 CC=/usr/local/bin/gcc を設定しコンパイルしなした gitだとちゃんと cloneできた。 libz,libiconv,libintl,libchasetあたりも/usr/local/lib 側をちゃんとリンクしてくれた。 いまどきllvm,clangなんでしょうが、、、、、もうちょい生きながらえさせて。 git cloneでファイルをダウンロードできたが、次にhttps://certbot.eff.org/docs/contributing.htmlを参照して、

python3 tools/venv3.py

なのだが、ここでどうも yaml(pyyaml)のところでエラー。これも gccを利用しているが/usr/bin/gcc を見ているケースと/usr/local/bin/gcc を見るケースがあるのが問題のよう。 .cshrc で /usr/local/bin を優先させることで /usr/local/bin/gcc を先に見るようにしたところ、まずはここはクリア。 bash で
source venv3/bin/activate
run_acme_server &
certbot_test certonly --standalone -d test.example.com
と実行してまずはローカルで動くかどうかを試すのだが、run_acme_server のところで落ちる。うまく webserver が起き上がってくれない。
[venv3] root@host:/usr/local/src/certbot # run_acme_server
=> Starting pebble instance deployment...
ELF binary type "0" not known.
=> Tear down the test infrastructure...
=> Test infrastructure stopped and cleaned up.
Traceback (most recent call last):
  File "/usr/local/src/certbot/venv3/bin/run_acme_server", line 11, in 
    load_entry_point('certbot-ci', 'console_scripts', 'run_acme_server')()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 221, in main
    with acme_server as acme_xdist:
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 96, in __enter__
    self.start()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 62, in start
    raise e
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 57, in start
    self._prepare_pebble_server()
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 135, in _prepare_pebble_server
    self._launch_process(
  File "/usr/local/src/certbot/certbot-ci/certbot_integration_tests/utils/acme_server.py", line 205, in _launch_process
    process = subprocess.Popen(command, stdout=stdout, stderr=subprocess.STDOUT, cwd=cwd, env=env)
  File "/usr/local/lib/python3.8/subprocess.py", line 854, in __init__
    self._execute_child(args, executable, preexec_fn, close_fds,
  File "/usr/local/lib/python3.8/subprocess.py", line 1702, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
OSError: [Errno 8] Exec format error: '/usr/local/src/certbot/certbot-ci/certbot_integration_tests/assets/pebble_v2.3.0_linux-amd64'
なんか、certbot が linuxの実行ファイル(linux binary for amd64)を抱えていてこれが freebsdでは動かない、ということのようだ。linux-compat とか入れればいいのかもしれないがそこまでやるかな。。。ということでこの線はあきらめて、、、 certbot は普通に python(2or3)のコードだったことを思い出して、$src/certbot/の中を見ると、setup.pyがあるので、
python3 setup.py build
python3 setup.py install
で、/usr/local/bin/certbot にインストールされた。
certbot certonly --standalone -d test.example.com
でちゃんと証明書が降りてきた。

raspberry pi3 で HEMS測定がときどき中断する

原因はよくわかっていないが、マニュアルで接続してデータを見ているときに、python3 + pyserial の組み合わせで
'device disconnected or multiple access on port' のエラーが出るときがある。
複数プロセスでttyを掴むような仕様にはしていないつもりだった(/dev/ttyUSB0 を排他にする)ので
何が原因かよくわからなかったが、https://www.suzu6.net/posts/32/に「原因は、シリアルポートからシェルのアクセスを許しているためです。シリアル通信だけ許可して、シェルログインは許可しない設定に変更しましょう。」とある。なこともあるのか。。。?
とりあえず、このページにあるように、raspi-config で設定を変更して様子みてみる。

raspberry pi3 で HEMS測定がときどき中断する

原因はよくわかっていないが、マニュアルで接続してデータを見ているときに、python3 + pyserial の組み合わせで
'device disconnected or multiple access on port' のエラーが出るときがある。
複数プロセスでttyを掴むような仕様にはしていないつもりだった(/dev/ttyUSB0 を排他にする)ので
何が原因かよくわからなかったが、https://www.suzu6.net/posts/32/に「原因は、シリアルポートからシェルのアクセスを許しているためです。シリアル通信だけ許可して、シェルログインは許可しない設定に変更しましょう。」とある。なこともあるのか。。。?
とりあえず、このページにあるように、raspi-config で設定を変更して様子みてみる。

imap , duplicate なメールの削除

dovecot imap サーバをメインに利用しているけど、フォルダにメールが溜まりすぎ(30000通オーバー)で、思い立ったときにサブフォルダとかにテーマ・カテゴリ別にごそっと(2000通くらい?)移動させると、時に(ちょくちょく?)サーバとの接続が切れてしまいメールが移動前・後のフォルダの両方に残ってしまうことが。。。これを繰り返してしまうと同じメールが10通くらい溜まってしまう。

こういう時には、Thunderbird のadd-on のRemove Duplicate Messagesを使っていたが、これも javascriptで動いているみたいで、メール総数が重いと imapサーバのセッションが切れてしまって使い物にならなくなってきた。
となると、command line で動く、デバッグも見られるようなツールをということで探したら、
Remove duplicate emails through IMAP from shell
gitはこちら
pythonで動くので汎用的、dry-run機能もあるので事前にちゃんと動くか確認できる(option -n)、途中で サーバとのセッションが切れてもそれまでに発見したduplicate mail には delete markをつけてくれるので、何回かトライすればOK,などなど。
80000通あったフォルダに対して実行したら3時間くらいかかって、20000通以下に整理してくれた。

imap , duplicate なメールの削除

dovecot imap サーバをメインに利用しているけど、フォルダにメールが溜まりすぎ(30000通オーバー)で、思い立ったときにサブフォルダとかにテーマ・カテゴリ別にごそっと(2000通くらい?)移動させると、時に(ちょくちょく?)サーバとの接続が切れてしまいメールが移動前・後のフォルダの両方に残ってしまうことが。。。これを繰り返してしまうと同じメールが10通くらい溜まってしまう。

こういう時には、Thunderbird のadd-on のRemove Duplicate Messagesを使っていたが、これも javascriptで動いているみたいで、メール総数が重いと imapサーバのセッションが切れてしまって使い物にならなくなってきた。
となると、command line で動く、デバッグも見られるようなツールをということで探したら、
Remove duplicate emails through IMAP from shell
gitはこちら
pythonで動くので汎用的、dry-run機能もあるので事前にちゃんと動くか確認できる(option -n)、途中で サーバとのセッションが切れてもそれまでに発見したduplicate mail には delete markをつけてくれるので、何回かトライすればOK,などなど。
80000通あったフォルダに対して実行したら3時間くらいかかって、20000通以下に整理してくれた。

HEMS 機器オブジェクトスーパークラス

電力スマートメーターは「住宅・設備関連機器クラスグループ」の「低圧スマート電力量メータクラス」だそうで、クラスグループ"0x02",クラスコード "0x88" になる。その他に取れるデータが無いかと見てみたら、一番上位の「機器オブジェクトスーパークラス」のデータにGetできるものがあるようなので、とりあえず見てみた。

プロパティ名称 EPC 取得データ 内容 備考
動作状態 0x80 30 ON
設置場所 0x81 61 庭・外周 場所番号 01
規格Version情報 0x82 00004600 Release F (?)
識別番号 0x83 ESV=52,読み出し応答不可
瞬時消費電力計測値 0x84 ESV=52,読み出し応答不可
積算消費電力計測値 0x85 ESV=52,読み出し応答不可
メーカ異常コード 0x86 ESV=52,読み出し応答不可
電流制限設定 0x87 ESV=52,読み出し応答不可
異常発生状態 0x88 42 異常発生無
異常内容 0x89 ESV=52,読み出し応答不可
メーカコード 0x8A 000016
事業場コード 0x8B ESV=52,読み出し応答不可
商品コード 0x8C ESV=52,読み出し応答不可
製造番号 0x8D 313233343536373839300000 1234567890
製造年月日 0x8E ESV=52,読み出し応答不可
節電動作設定 0x8F ESV=52,読み出し応答不可
遠隔操作設定 0x93 ESV=52,読み出し応答不可
現在時刻設定 0x97 0C35 12時41分
現在年月日設定 0x98 07E20803 2018年8月3日
電力制限設定 0x99 ESV=52,読み出し応答不可
積算運転時間 0x9A ESV=52,読み出し応答不可

意味があるデータは製造番号くらいで、ほぼ読み出し応答不可が帰ってきた。

excel 2 table にはここを利用

HEMS 機器オブジェクトスーパークラス

電力スマートメーターは「住宅・設備関連機器クラスグループ」の「低圧スマート電力量メータクラス」だそうで、クラスグループ"0x02",クラスコード "0x88" になる。その他に取れるデータが無いかと見てみたら、一番上位の「機器オブジェクトスーパークラス」のデータにGetできるものがあるようなので、とりあえず見てみた。

プロパティ名称 EPC 取得データ 内容 備考
動作状態 0x80 30 ON
設置場所 0x81 61 庭・外周 場所番号 01
規格Version情報 0x82 00004600 Release F (?)
識別番号 0x83 ESV=52,読み出し応答不可
瞬時消費電力計測値 0x84 ESV=52,読み出し応答不可
積算消費電力計測値 0x85 ESV=52,読み出し応答不可
メーカ異常コード 0x86 ESV=52,読み出し応答不可
電流制限設定 0x87 ESV=52,読み出し応答不可
異常発生状態 0x88 42 異常発生無
異常内容 0x89 ESV=52,読み出し応答不可
メーカコード 0x8A 000016
事業場コード 0x8B ESV=52,読み出し応答不可
商品コード 0x8C ESV=52,読み出し応答不可
製造番号 0x8D 313233343536373839300000 1234567890
製造年月日 0x8E ESV=52,読み出し応答不可
節電動作設定 0x8F ESV=52,読み出し応答不可
遠隔操作設定 0x93 ESV=52,読み出し応答不可
現在時刻設定 0x97 0C35 12時41分
現在年月日設定 0x98 07E20803 2018年8月3日
電力制限設定 0x99 ESV=52,読み出し応答不可
積算運転時間 0x9A ESV=52,読み出し応答不可

意味があるデータは製造番号くらいで、ほぼ読み出し応答不可が帰ってきた。

excel 2 table にはここを利用

HEMS スマートメーターからの出力

電灯契約を変えたことで、スマートメータに取り替えられた。
東電にBルートサービスを申し込んで、自宅raspberry pi3に テセラ・テクノロジーのRL7023 Stick-D/IPS を刺して計測し、グラフ化することを目標としてみる。
ほぼ、

スマートメーターの情報を最安ハードウェアで引っこ抜くを大変に参考にさせてもらった。

ECHONETの機器オブジェクト詳細規定の「低圧スマート電力量メータクラス規定」のところを読む。

https://echonet.jp/wp/wp-content/uploads/pdf/General/Standard/Release/Release_H_jp/Appendix_H.pdf

プロパティ名称 EPC 取得データ 内容 備考
動作状態 0x80 30 ON
係数 0xD3 00000001 1 0.1Kwh
積算電力量有効桁数 0xD7 06 6桁
積算電力量計測値
(正方向計測値)
0xE0 00003354 1314.0 (kWh)
積算電力量単位 0xE1 01 0.1 kWh
積算電力量計測値履歴1
(正方向計測値)
0xE2 (194 byte= 48 data) FFFFFFFE (初期設定)
積算電力量計測値
(逆方向計測値)
0xE3 00000015 2.1 kWh
積算電力量計測値履歴1
(逆方向計測値)
0xE4 (0xC2=194 byte = 48data) FFFFFFFE (初期設定)
積算履歴収集日1 0xE5 FF 設定無 (初期値)
瞬時電力計測値 0xE7 0000073C 1852 W
瞬時電流計測値 0xE8 0046006E R相 7.0(A) T相11.0(A)
定時積算電力量計測値
(正方向計測値)
0xEA 07E2071D17000000003354 2018年07月29日
23時00分00秒
1314.0 (kWh)
定時積算電力量計測値
(逆方向計測値)
0xEB 07E2071D17000000000015 2018年07月29日
23時00分00秒
2.1 (kWh)
積算電力量計測値履歴2
(正方向、逆方向計測値)
0xEC FFFFFFFFFFFF01F
FFFFFFEFFFFFFFE
(初期値)
積算履歴収集日2 0xED FFFFFFFFFFFF01 (初期値)

電子レンジを使っているときだったのでちょっと電力量が高いかも。

電力量単位が 0.1kWh、有効桁数が6桁あたりは見落としがちだった。

とりあえずグラフ化するのは、積算電力量、瞬時電力、瞬時電流あたりか?発電・売電はしていないので、逆方向は必要ないと思うが一応モニタしておくか。

HEMS スマートメーターからの出力

電灯契約を変えたことで、スマートメータに取り替えられた。
東電にBルートサービスを申し込んで、自宅raspberry pi3に テセラ・テクノロジーのRL7023 Stick-D/IPS を刺して計測し、グラフ化することを目標としてみる。
ほぼ、

スマートメーターの情報を最安ハードウェアで引っこ抜くを大変に参考にさせてもらった。

ECHONETの機器オブジェクト詳細規定の「低圧スマート電力量メータクラス規定」のところを読む。

https://echonet.jp/wp/wp-content/uploads/pdf/General/Standard/Release/Release_H_jp/Appendix_H.pdf

プロパティ名称 EPC 取得データ 内容 備考
動作状態 0x80 30 ON
係数 0xD3 00000001 1 0.1Kwh
積算電力量有効桁数 0xD7 06 6桁
積算電力量計測値
(正方向計測値)
0xE0 00003354 1314.0 (kWh)
積算電力量単位 0xE1 01 0.1 kWh
積算電力量計測値履歴1
(正方向計測値)
0xE2 (194 byte= 48 data) FFFFFFFE (初期設定)
積算電力量計測値
(逆方向計測値)
0xE3 00000015 2.1 kWh
積算電力量計測値履歴1
(逆方向計測値)
0xE4 (0xC2=194 byte = 48data) FFFFFFFE (初期設定)
積算履歴収集日1 0xE5 FF 設定無 (初期値)
瞬時電力計測値 0xE7 0000073C 1852 W
瞬時電流計測値 0xE8 0046006E R相 7.0(A) T相11.0(A)
定時積算電力量計測値
(正方向計測値)
0xEA 07E2071D17000000003354 2018年07月29日
23時00分00秒
1314.0 (kWh)
定時積算電力量計測値
(逆方向計測値)
0xEB 07E2071D17000000000015 2018年07月29日
23時00分00秒
2.1 (kWh)
積算電力量計測値履歴2
(正方向、逆方向計測値)
0xEC FFFFFFFFFFFF01F
FFFFFFEFFFFFFFE
(初期値)
積算履歴収集日2 0xED FFFFFFFFFFFF01 (初期値)

電子レンジを使っているときだったのでちょっと電力量が高いかも。

電力量単位が 0.1kWh、有効桁数が6桁あたりは見落としがちだった。

とりあえずグラフ化するのは、積算電力量、瞬時電力、瞬時電流あたりか?発電・売電はしていないので、逆方向は必要ないと思うが一応モニタしておくか。