クルマのバックライトと前ポジションのLEDを差し替えた

正月休みにクルマのバックランプをT10の明るいLEDに変更した。それで光り方は明るくはなったが、期待したほどは後ろが照らされるものではなかった。T16ソケットにT10が挿さるとはいえ、T10ではバルブが細いので光らせるLEDチップを沢山は積めない。そこで改めてT16(実際はT15)のLEDを購入した。

4014チップが45SMD(LEDチップが45個)というT15のLEDバルブ。T16ではないが、ほぼ同じ。AliExpressの商品ページには900lmと書かれている。それは1つで900lmなのか2個セットでなのかは不明。片面18個のLEDが付いた2枚の基板の間にヒートシンクが入っていて、一応は放熱も考えられてはいるみたい。
2個セットで200円ちょっと。

T16 LED 1
全長40mmなので写真の印象ほどは大きくはない。基板はそんなに綺麗ではない感じ。1個100円程度というのは納得。

T16 LED 2
スマホで撮ったら色が飛んだ。スミマセン
ソケットに挿さる側。厚すぎず薄すぎずでソケットに負担をかけずにグラグラしないでしっかり挿さりそう。

T16 LED 3
ソケットの端子を起こしてしっかり挿した。基板がソケットに当たった部分の縁が少しひび割れた。劣化してるのかな。

バックランプ 電球時
バックライトを純正の電球に戻して撮影した。その純正球の光り方。
ここから3枚はカメラの設定は同じ。夕方の日没前に撮影しているので周囲が真っ暗ではない。

バックランプ T10 LED時
この前挿したT10のLED。目で見ると純正球より明るいが、この写真では何故か明るくなった様子は見えなくて色が白になっただけの感じ。

バックランプ T16 LED時
今回購入したT15のLED。光り方が明らかに強烈になっている。夜にこのバックランプを見ると爆光に近い眩しさではないだろうか。ただし、眩しくはなっても周囲を照らしてくれるのかは不安。バックランプユニットの形状が周囲を照らす用になってないように思えるのよね。

さて、これで正月休みにバックランプ用に挿したT10の明るいLEDが余った状態になってしまった。フロントのポジション球は正月に挿した3030チップ1つのLED T10バルブで満足してたが、そういえばバックランプにしていた明るいT10バルブはポジション球としては一度も挿していなかった。そこで試しに交換することにした。

明るいT10 LEDバルブはこれ。白は6000Kで12V/5Wで550lmということになっている。(本当かどうかは不明) ちょっとお高くて2個で300円超えで、この記事最初のT15のLEDの1.5倍もする。使わないのはもったいない。

ポジションLED交換 1
手前がフロントのポジションランプ用に挿していた3030チップ1つのT10 LED(とソケット)。奥側が明るいT10 LEDバルブ。
ちょっと長い上に全体がアルミで重いのでヘッドライトユニット内で抜け落ちると困るが、これもソケットの端子起こしをしたらしっかり挿さった。なので今回は抜け落ち防止のアルミテープは使わないことにした。

ポジションLED交換 2
ヘッドライトユニット内で光らせるとこんな感じ。純正球と比べるとだいぶぴょこっと飛び出ている。ちなみにこの写真はシャッター速度を速めて暗く写している。

ポジションLED交換 3
目で見るとこんな感じに見える。もはやポジション球ではなくヘッドライト。バックライトとしてはそんなに明るいとは思わなかったけどヘッドライトユニット内では爆光。商品説明ページに書かれた550lmが本当ならヘタな小型バイクのハロゲンのヘッドライトより光量が多いということになる。そして、ヘッドライトから80cm離れた壁にヘッドライトのロービームを点灯するとポジション交換前はカットラインがはっきり見えていたのが消えた(笑) つまり、カットラインの影が消えるほど光っている。ポジションの光が水平より上方向にだいぶ飛んでいるということなので対抗車のドライバーに眩しがられるかも。離れるとそうでもないのかな?

予想はしてたけど、ポジションとして「点灯を認識できる」レベルを通り越して眩しすぎるので普通に使うのはどうかしら。正月に挿した3030が1つのLEDの方がポジションには良さそう。ヘッドライトロービーム時にポジションが消灯してくれたら問題ないんだけどなぁ。

USBリレーモジュールの警告灯をブラウザで制御

警告灯をブラウザで制御

FreeBSDではUSBシリアルデバイスは/dev/ttyU*と/dev/cuaU*として認識される。 認識されたデバイスはパーミッションが600になるのでそのままでは使いにくい。そこで/etc/devfs.confでパーミッションを変更する。


/etc/devfs.conf (ファイル末に2行追加)
perm cuaU0 0666
perm ttyU0 0666

認識されたUSBシリアルデバイスが/etc/cuaU0と/etc/ttyU0の場合。


devfsサービスを再起動する。
# service devfs restart

警告灯のUSBリレーモジュールをFreeBSDに接続する。

前回の記事で、USBリレーモジュールの操作方法は判っているのでFreeBSDでもそれで動作することを確認する。違うのはデバイス名くらいな筈。

#初期化
% echo '50 51 0f' | xxd -r -p > /dev/cuaU0

#消灯
% echo '0f' | xxd -r -p > /dev/cuaU0

#緑点灯
% echo '0b' | xxd -r -p > /dev/cuaU0
#黄点灯
% echo '0d' | xxd -r -p > /dev/cuaU0
#赤点灯
% echo '0e' | xxd -r -p > /dev/cuaU0

ここまで、正常に使えることが確認できたら次はウェブブラウザで警告灯を制御できるようにする。

HTMLファイルの核心部分

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
<!-- ボタン部 (formタグは無し) -->
<button type="submit" value="0">消灯</button><br />
<button type="submit" value="1">緑点灯</button><br />
<button type="submit" value="2">黄点灯</button><br />
<button type="submit" value="3">赤点灯</button><br />

<!-- 結果表示部 -->
<div id="result"></div>


<!-- Javascript -->
<script>
$('button').click(function() {
    var val = $(this).val();
        mgrAjax(val);
    }
});

function mgrAjax(val){
    $.ajax({
        url: 'control.php',
        type: 'POST',
        data: {
            mgr:val,
        },
        //frequency: 0.5,
        success: function(response) {
            $('#result').html(response);
            exit;
        }
    });
}
</script>

だいぶ省いていて最小限が動くだけにしている。もちろんこれだけではHTMLファイルとして成立しないのでHTMLヘッダなど必要なものを書く。

制御用のphpファイル
control.php
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
<?php
if(isset($_POST['mgr'])) {
    $change = filter_var($_POST['mgr'], FILTER_VALIDATE_INT);
    switch ($change) {
        case 0:        
            $cmd = 'echo "0f" | xxd -r -p > /dev/cuaU0';
            exec($cmd);
            echo '<img src="/images/off.png" alt="警告灯 消灯" />';
            break;

        //中略(1,2,3で緑,黄,赤の点灯)
            
    }
}
?>

まぁ、本当はいろいろ書いてるんだけど、このページでは徹底して省いているし短くするためにベタ書きな汚いスイッチになっている。スミマセン
あと、普通ならモジュールにコマンドを送ったらモジュールからステータスを取得するような処理を入れる筈(でないと確実な動作が期待できない)だが、このUSBリレーモジュールはリレーのステータスを取得できないのでその手の処理は全く無い。コマンド(というかコード)を送信しっ放しで、それでリレーが操作できたであろう期待を結果として出力するようになっている。つまり実際にはリレーが動いてなくても「赤が点灯した」とか「消灯した」と表示する。

動作の様子
Semantic UIでメニューやボタンを表示させている。

関連記事:

Prometheus2とGrafana6によるシステム監視 GrafanaのAlertを使う

PrometheusとGrafanaの組み合わせでシステム監視している方々はアラートをどうしてますでしょうか?
「とりあえず」な感じでわかり易い方でやるならGrafanaのAlertingで、設定作るのが取っ付きにくいけど細かく指定したいならAlertmanager、または組み合わせてというのもアリかしら?まぁ、この2つは同じ機能だが全くの別物ってのを理解していればOK.

Grafana Alertingの設定

GrafanaのAlertingの設定は殆どGrafana上でできるが、一部の基本的な内容だけはテキストファイルで行う。アラートの通知にメールを使うならSMTPの設定は必要。
ファイル名は/etc/grafana.confか/usr/local/etc/grafana.conf、grafana.confではなくgrafana.iniも?Grafanaのメインの設定ファイルなのでGrafanaをインストールした時に触っている筈。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
[smtp]
enabled = true
host = mx.example.com:587
user = alertuser@example.com
password = hogehoge
;cert_file =
;key_file =
;skip_verify = false
from_address = alert-from@example.com
from_name = Grafana

上は外部SMTPサーバを使用する場合。ローカルのSMTPが使えるならlocalhost:25など。その場合はuserとpasswordは不要だと思われるので行頭に ; を付けてコメントにする。SMTPの設定は簡単そうで意外とハマるので気をつける。

設定ファイルを変更したらGrafanaを再起動する。
FreeBSDの場合。
# service grafana restart

以下はGrafana上で。

Grafana AlertingとAlertmanagerの設定 1
Grafanaの左列のメニューの(Alerting)を押してからタブでNotification channelsを選択する、または(Alerting)にポインタを合わせて表示されるサブメニューからNotification channelsをクリックする。

Grafana AlertingとAlertmanagerの設定 2
Alertingの設定自体が初めてであれば[Add channel]ボタンだけが表示される。既に何かを登録していればリスト表示される筈。新しく通知チャンネルを登録するので[Add channel]をクリック。

Grafana AlertingとAlertmanagerの設定 3
Typeの項目が通知方法の選択。アラートをメールで通知するならEmailを選択する。Nameは通知する内容について何か書くようだが、メールの本文になる項目で、正直要らない。アラート状態から復帰した場合にはメールを送信しないならDisable Resolve Messageのスイッチをオンにする。
設定したら[Save]で保存。正しく送信されるかは[Send Test]をクリック。アラート関係なしのテストメールが送信される。(次)

Grafana AlertingとAlertmanagerの設定 4
指定したメールアドレス宛にこのようなテストメールが届けばOK。メールが届かないならSMTPの設定が間違っているかもしれないのでgrafana.conf(grafana.ini)の設定を見直す。

Grafana AlertingとAlertmanagerの設定 5
メールではなくwebhookを使いたいということはよくある(筈)。メールと同時にwebhookで通知というのもアリだし。
別途Notification channelの追加画面でTypeをwebhookにする。

Grafana AlertingとAlertmanagerの設定 6
webhookなら通知先のURLが重要。あと、POSTかGETかくらい?Nameはメールの時と同じで正直要らない。 [Save]で保存。[Send Test]でテスト通知を実行。もちろん、webhookを受け取る側が用意されていなければならない。(後述)

アラート発報条件の作製

既存のパネルにアラートを追加という方法もあるが、パネルによってはアラートを追加できなかったり意外と制限が多いので今回はアラート用に新しいダッシュボードとパネルを作製する。(ダッシュボードはどうでもいいけど)

Grafana AlertingとAlertmanagerの設定 7
左列のメニューのCreateからダッシュボードを追加する。

Grafana AlertingとAlertmanagerの設定 8
[Add query] [Choose Visualization] [Convert to row]のボタンが表示されるので今回は[Choose Visualization]をクリック。
次にパネルの種類の選択画面。今回はGraphを追加する。

Grafana AlertingとAlertmanagerの設定 9
参照元としてのQueryはPrometheusを指定。 監視対象のメトリクスを指定する。ここでは、とりあえずロードアベレージあたりを表示させる。Node Exporterを使用しているのでjobはnode_exporterとする。なのでMetricsには node_load1{job="node_exporter"}とした。今回はインスタンス(ホスト)は指定しないことにした。(全インスタンスが対象になる)

Grafana AlertingとAlertmanagerの設定 10
Visualizationの設定は普通で。

Grafana AlertingとAlertmanagerの設定 11
Generalの設定はTitle欄にパネル名を指定するだけで良いかと。ここまでは普通のパネル作製と変わらない。

Grafana AlertingとAlertmanagerの設定 12
Nameで任意のアラート名を指定する。
閾値を決めるConditionsが重要。上の例だと5分平均が1(100%)を超えたら発報という条件。IS ABOVEをクリックすると範囲指定なども可能。Send toには通知チャンネルを指定する。先に作製したメールとwebhookの例ではDefault(send on all alerts)のスイッチをオンにしたので登録済みのチャンネル(Emailとwebhook)が最初から入った状態且つオフにできない。
設定ができたら画面上部の保存アイコンで保存する。

これで、指定した条件が発生するとアラート通知が行われる。メール通知であればメールで、webhookならそれで通知が届くことを確認する。通知チャンネルの設定でDisable Resolve Messageのスイッチをオフにしていれば、アラート条件から回復した際にもそれぞれ通知が届く。

次はGrafana上でアラートの発生状態を確認できるようにする。

Grafana AlertingとAlertmanagerの設定 13
ダッシュボード画面でパネル追加アイコンをクリックする。
[Add query] [Choose Visualization] [Convert to row]のボタンが表示されるので[Choose Visualization]をクリック。
Visualization選択画面でAlert Listを選択する。
OptionsでState filterのスイッチを変更する。スイッチオンでそのステータスがAlert Listに表示されるというものなので、基本的にはok状態を非表示にする。アラートが1,2種類であれば表示でも良いが、たくさんあるならOK状態が表示されると邪魔。また、軽微な警告レベルのアラートであるなら非可動のインスタンス(ホスト)は非表示にするのが良いのでNo dataもオフ。

Grafana AlertingとAlertmanagerの設定 14
上部がAlert Listパネルで下部が先に作製したロードアベレージのパネル。
アラート条件に当てはまって暫く(指定時間)はPENDING(黄色)になるのでまだ通知はされない。アラート該当パネルはタイトルの(ハート)が黄色になる。

Grafana AlertingとAlertmanagerの設定 15
PENDINGを過ぎて解決されなければアラート発報になる。アラートリストのその項目が赤になるのはもちろん、アラートが発生しているパネルが細い赤枠になる。パネルタイトル部分の(割れハート)が赤になる。

Grafana AlertingとAlertmanagerの設定 16
画像作成用にアラート解消させるために閾値を変更した。本来は閾値を変えるのではなく問題そのものを解決させる。
アラート状態が解消すると、Alert Listからそのアラートが消える。(OK状態の表示をオフの場合)
アラートが発生していたパネルの赤枠が普通に戻る。(ハート)が緑になる。

Grafana AlertingとAlertmanagerの設定 17
アラート発生時のメール。モザイク部はアラートが発生したインスタンス名(複数)。同じ内容のアラートは発生インスタンスが増減しても追加通知は行われない。

Grafana AlertingとAlertmanagerの設定 18
アラート状態が解消したことを通知するメール。こちらはアラートが解消したインスタンス名は表示されない。また、複数のインスタンスで同じ内容のアラートが発生した場合は、全てのインスタンスでそのアラートが解消されるまで通知されない。

webhookの受け取り

webhookはどこかに用意したウェブサーバに受信用のスクリプトなりを置くだけ。ネットワーク的にGrafanaから到達できること。
下は簡単な受信用PHPスクリプト。

1
2
3
4
5
6
7
8
9
<?php
$logFile = __DIR__ . '/webhook.log';

if($_SERVER['REQUEST_METHOD'] == 'POST') {
  $data = file_get_contents('php://input');
  $json = json_decode($data);
  file_put_contents($logFile, print_r($json, true), FILE_APPEND);
}
?>

$jsonが配列として取り出したもの。あとは煮るなり焼くなり好きにするだけ。上の例ではログファイルに出している。もちろんログにしたところで犬の糞ほども役にも立たない。取得した情報の確認用ね。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
stdClass Object
(
    [evalMatches] => Array
        (
            [0] => stdClass Object
                (
                    [value] => 100
                    [metric] => High value
                    [tags] => 
                )

            [1] => stdClass Object
                (
                    [value] => 200
                    [metric] => Higher Value
                    [tags] => 
                )

        )

    [message] => Someone is testing the alert notification within grafana.
    [ruleId] => 0
    [ruleName] => Test notification
    [ruleUrl] => http://localhost:3000/
    [state] => alerting
    [tags] => stdClass Object
        (
        )

    [title] => [Alerting] Test notification
)

これはNotification channelの設定画面のテスト送信のデータを受信したもの。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
stdClass Object
(
    [evalMatches] => Array
        (
            [0] => stdClass Object
                (
                    [value] => 1.36397879464286
                    [metric] => node_load1{instance="192.168.41.158:9100", job="node_exporter"}
                    [tags] => stdClass Object
                        (
                            [__name__] => node_load1
                            [instance] => 192.168.41.158:9100
                            [job] => node_exporter
                        )

                )

            [1] => stdClass Object
                (
                    [value] => 1.11364397321429
                    [metric] => node_load1{instance="192.168.41.239:9100", job="node_exporter"}
                    [tags] => stdClass Object
                        (
                            [__name__] => node_load1
                            [instance] => 192.168.41.239:9100
                            [job] => node_exporter
                        )

                )

        )

    [message] => 何かメッセ
    [ruleId] => 1
    [ruleName] => System Load alert
    [ruleUrl] => http://localhost:3000/d/GTd9zVyZk/alert-manager?fullscreen&edit&tab=alert&panelId=2&orgId=1
    [state] => alerting
    [tags] => stdClass Object
        (
        )

    [title] => [Alerting] System Load alert
)

上で作成したロードアベレージのアラートはこんなの。

webhookでの通知を書いといてなんだけど、webhookで受け取るようにするとアラートの状態を管理する何かを作らないとアラート状態からの復帰時の処理が大変かもなので、webhookを受け取ったらGrafanaから curl http://grafana_user:grafana_password@grafana_server:3000/api/alerts/ でアラートのステータスを受け取る方が処理は簡単になるかも。(grafana_user, grafana_password, grafana_serverは自身のものに置き換え)

関連記事: