最近ちょっとOAタップの意識が高まってしまって、常用するOAタップはできるだけパナソニック製品 (できが良い) にしようという気概が生まれてきてしまった。

それはともかく、パナソニックはOAタップに「コードなし」モデルをラインナップしている。つまりユーザ側で任意のコードを取り付けられるようになっている。

必要なのは以下の通り。

• コードなしOAタップ
• 3心ビニルキャブタイヤ丸形コード（VCTF）2.0mm^2
• プラグ (2P接地極) 2P
• (オプション。あったほうが綺麗にできる) R2-3.5 裸圧着端子

ちなみに、価格的には普通にコード付きのを買ったほうが多少安い。作業コストも含めるとカスタム長コードはかなり高くつくことに注意されたい。

自分でコードをつける利点は

• 任意コード長にできる
• あとから部分的に構成を変えられる
• OAタップ側は接地極付きにするがプラグは2極にする、みたいな変な構成のタップが作れる

あたり。特に最後のやつは地味に便利だと思っている。一般家庭だとまず接地極が存在していないので、3極タップに対しては余計に変換プラグが必要になったりするんだけど、それをなくしてコンセント付近をスリムにできる。

ref.

• http://www2.panasonic.biz/es/densetsu/haisen/tap/oa_tap/2468.html

1. トップ
2. tech
3. カスタムコード長OAタップを作る

例えば以下のようなメトリクスがあったとします。みての通り、名前は一緒でラベルだけが異なるメトリクスです。

• mqtt_topic{instance="127.0.0.1:9981",job="mqtt",topic="/home/sensor/temp"}
• mqtt_topic{instance="127.0.0.1:9981",job="mqtt",topic="/home/sensor/humidity"}

これらを演算しようとして以下のようにしても no data になります。

 mqtt_topic{topic="/home/sensor/temp"} *  mqtt_topic{topic="/home/sensor/humidity"}

Vector Matching に書いてある通りですが、デフォルトではこのようなベクター同士の演算の場合、左右でラベルが全て一致するメトリクス同士のみが結果に出力されます。

SQL の INNER JOIN でラベル全ての一致が ON 条件に入ってるのをイメージするとわかりやすそうです。

この条件を変更するには、ignoring() または on() を使います。今回のケースでは以下の2つの結果は同じです。

 mqtt_topic{topic="/home/sensor/temp"} *  ignoring(topic) mqtt_topic{topic="/home/sensor/humidity"}
 mqtt_topic{topic="/home/sensor/temp"} *  on(instance,job) mqtt_topic{topic="/home/sensor/humidity"}

ignoring() は JOIN の条件から指定したラベルを除くように働き、on() は JOIN の条件を明示的にすべて指定するように働きます。

(0.81 * mqtt_topic{topic="/home/sensor/temp"})
  + ignoring(topic) (0.01 *  mqtt_topic{topic="/home/sensor/humidity"})
  * ignoring(topic) (0.99 *  mqtt_topic{topic="/home/sensor/temp"} - 14.3)
  + 46.3

1. トップ
2. tech
3. PromQL でラベル違いのメトリクス同士を演算して no data

最近はこう

ssh-keygen -t ecdsa -b 521

最近の raspi イメージはデフォルトで弱い暗号方式を無効化してあるのでさっさと ecdsa 鍵に乗り換えましょう……

1. トップ
2. tech
3. ssh-keygen

クランプ式電流計は回路を切断せずに電流計測ができるので便利なのだけど、ホット側かコールド側いずれか一方だけをクランプする必要があるため、ほとんどの場合では実際には切断せずに計測というのは難しい。

ということで、写真のように短い延長ケーブルをつくった。線が分離しており、片方だけを挟める。前もって接続しておくことでいつでも計測できるようになる。100均で割けるタイプの延長コードがあればそれでいいけど、最近は二重絶縁のものが主流なのがかえって作りにくくなってしまった。

• VFF2.0×2C
• 裸圧着端子 MR2-3.5B
• Panasonic WH4615B メス
• Panasonic WH4021B オス

詳しい施行方法はパナソニックのサイトの「仕様」を見るとわかる。(備考：この延長ケーブルを作るのにあたっては特段なんの資格もいりません)

しかしまだ使えてない。特に冷蔵庫に使いたいんだけど、冷蔵庫の電源を落とすには若干の手順が必要なので面倒 (内容物の確認 → 電源オフ→ 7分間は再度電源入れないこと)

1. トップ
2. tech
3. クランプ式電流計用にホットコールド分離ケーブルをつくる

MQTT のトピックを subscribe して一時的に保持し、prometheus 向けに exporter として働くデーモンを書いた。要は pushgateway の MQTT 版のようなもの。

• https://github.com/cho45/mqtt_topic_exporter

うちではセンサーデータの一部を MQTT サーバに送りつけるようにしてあるので、それを面倒なことなしに prometheus に登録していきたい。

mqtt_topic_exporter --mqtt.server=mqtts://user:pass@mqttserver:8883 --mqtt.topic="/home/sensor/+"

mqtt_topic{topic="/home/sensor/temp"} 30.0

./mqtt_topic_exporter --help
usage: mqtt_topic_exporter --mqtt.server=MQTT.SERVER --mqtt.topic=MQTT.TOPIC [<flags>]

Flags:
  -h, --help                     Show context-sensitive help (also try --help-long and --help-man).
      --web.listen-address=":9981"  
                                 Address on which to expose metrics and web interface.
      --web.telemetry-path="/metrics"  
                                 Path under which to expose metrics.
      --mqtt.retain-time="1m"    Retain duration for a topic
      --mqtt.server=MQTT.SERVER  MQTT Server address URI mqtts://user:pass@host:port
      --mqtt.topic=MQTT.TOPIC ...  
                                 Watch MQTT topic
      --log.level="info"         Only log messages with the given severity or above. Valid levels: [debug, info, warn, error, fatal]
      --log.format="logger:stderr"  
                                 Set the log target and format. Example: "logger:syslog?appname=bob&local=7" or "logger:stdout?json=true"
      --version                  Show application version.

1. トップ
2. tech
3. MQTT のトピックを prometheus に登録する

電工ペンチ (圧着とかストリップとか一通りできる便利道具) を捨てて、ちゃんとした圧着ペンチとストリッパーをそれぞれ買った。

もうほんと、全然使い勝手が違う。最初からこの2つを買うべき。

電工ペンチのストリッパーは全然切れなかったけど、専用ストリッパーは無理矢理ひっぱらなくても綺麗にストリップできる。

圧着ペンチはもう全然違う。電工ペンチではいくら力を入れても一定以上圧着できないうえに、端子を噛みこんでしまって外すのが大変だったけど、ホーザンのこれだと全然力は必要ないし、綺麗にはずれる。電工ペンチで圧着したものを再度新しいもので圧着してみたけど、力はそれほど入れてないのに、さらに強く圧着できた。

1. トップ
2. tech
3. 電工ペンチを捨て、専用ストリッパーと圧着ペンチを買った

cpuinfo に含まれる Revision を見る。

$ cat /proc/cpuinfo  | grep Revision
Revision        : a01041

RPi HardwareHistory - eLinux.org に書いてある通りに表を参照する。

上記の例では

a01041	Q1 2015	2 Model B	1.1	1 GB	(Mfg by Sony)

1. トップ
2. tech
3. 起動中の Raspberry Pi のモデルを調べる

(写真は練習の別の候補問題のもの)

日曜日が試験日だった。どうやら筆記試験と違って、試験会場が県あたり1つしかないようで、試験会場の最寄りのマイナー駅がものすごい混雑だった。こんなに受験者がいるのかーとびっくり。

候補問題が13問なので2週間ぐらい前から1日1問ずつ消化していった。練習してみると結構欠陥 (不合格) を出してしまう。特に電線の種類・長さを間違えると、他の欠陥に比べて取り返しがつかないことになる。ということで当日は特にこのへんを気をつけようという心掛けをした。

出題問題は候補問題7の4路スイッチを含む回路だった。

あんまり好みの問題ではなかったけど一通りやるだけやったという感じ。電線色が任意の箇所が多いので逆に不安になる。約15分ほど残して終わり。見た目的には教科書通りという感じだけど、一通りチェックはしても細かい欠陥があるかどうかは、勘違いとかもあるのでよくわからない。合格発表は8月20日。合格していなかったら下期に再受験。

1. トップ
2. tech
3. 第二種電気工事士 技能試験

今更ながらいまいち理解できてないポイントがあったので、いっかい自分でまとめてみることにする。当たり前のことではあるが……

1. トップ
2. tech
3. L2スイッチとルーター

• これまで採用されていた輻輳制御アルゴリズムの多くはパケットロスベースであった
  • CUBIC / (New) Reno など
• しかし実際はパケットロスと輻輳は厳密に対応しない
• 輻輳はネットワークの処理能力の限界を超えたときに発生する
  • 処理すべきデータ容量が処理可能なデータ容量を超えると発生する
• パケットロスは瞬間的なトラフィック増加や、電気的ノイズなどネットワーク処理能力以外の要素でも発生する現象
  • 無線ネットワークのように原理的にパケットロス率が高いことも多い

BBR では通信先との間の実際に使える帯域を推定し、パケットロスが起こっていても、あるいはパケットロスが起こらなくても、輻輳しない程度に最大のスループットを出す。

実際のアルゴリズムは解説してるサイトを見るほうが早い。

1. トップ
2. tech
3. BBR 輻輳制御アルゴリズムの考えかた