再起動後、録画直後にmotionが落ちる

再起動した後、気づいたらカメラの動作ランプが消えていて、サービス無効化したっけか？とsudo service motion statusで確認すると、Activeの表示。（topとかでプロセスの状態を確認すればよかったかも…）問題がなさそうなので、ログを見てみることに。

/var/log/motion/motion.log

が存在していたので、起動したのは確実。理由はこのraspberry piはほとんどのlogはtmpなので再起動で消えてしまいます。

中身を見ると、確かに[ERR]がいくつかでててそこで終わっています。

特に考えもせずにsudo service motion restartで、motionを再起動。

そしてカメラを動作させて様子を見ると…普通に動いてます。ですよねぇ…今まで動いていたし。

思い起こせば、マスクをかけていたのを外したからムービーファイルが巨大になって落ちたのかな？とか。でもそんなことはないと思うのでちょっと納得いかない。

しばらく放置しても落ちそうになかったので、再度再起動してみる。

カメラの動作ランプが点灯して、motionを反応させて録画させてみると、保存のタイミングでカメラのランプが消えてしまいました。落ちたか…。

sudo service motion restartで再起動させて、しばらく様子を見ると普通に動作している感じです。

原因がさっぱりわかりません。

再度ログをみてみると、

[1:ml1:F] [NTC] [EVT] [Jul 11 01:38:03] event_newfile: File of type 8 saved to: /tmp/20200711013802F-01.avi
[1:ml1:F] [NTC] [ALL] [Jul 11 01:38:03] motion_detected: Motion detected - starting event 1
[1:ml1:F] [ERR] [ENC] [Jul 11 01:42:20] ffmpeg_avcodec_log: Too large number of skipped frames 235812 > 60000
[1:ml1:F] [ERR] [ENC] [Jul 11 01:42:20] ffmpeg_put_frame: Error while writing video frame: No such file or directory
[1:ml1:F] [NTC] [ALL] [Jul 11 01:42:20] preview_save: different filename or picture only!
[1:ml1:F] [NTC] [EVT] [Jul 11 01:42:20] event_newfile: File of type 1 saved to: /tmp/20200711013809F-01-01.jpg
[0:motion] [NTC] [ALL] [Jul 11 01:56:05] motion_startup: Using log type (ALL) log level (NTC)
[0:motion] [NTC] [ALL] [Jul 11 01:56:05] become_daemon: Motion going to daemon mode
設定は結構変なことをしていて、一旦tmpに動画を作らせてからそのあと保存用のディレクトリに移動させてたりするので、出力が/tmpになってたりします。

原因の一端にその辺もありそうですが、エラーメッセージで検索をかけたところ、

ffmpeg_avcodec_log: Too large number of skipped frames => segmentation fault #508

を見てみると、timelapse設定をオフにしてみると対処できるらしい。が、そんな機能使ってないんですが。

まぁそれはそれとしてmotion.confを見てみると、timelapse関連の設定は、

ffmpeg_timelapse 0
ffmpeg_timelapse_mode daily

の２つありました。ffmpeg_timelapseが0なのでオフのはずなのですが、エラーメッセージから推測すると、ファイル名を変更しようとしているのでffmpeg_timelapse_modeも影響がありそうなので、

ffmpeg_timelapse_mode manual

と設定変更してみました。

変更後、とりあえず落ちることは無くなりました。

motion -hで表示されたバージョン情報

motion Version 4.0, Copyright 2000-2016 Jeroen Vreeken/Folkert van Heusden/Kenneth Lavrsen/Motion-Project maintainers

パッケージバージョン

4.0-1

サンワサプライのマウス

サンワサプライから発売された無線2.4GHz/bluetoothのマウスがちょっと気になりました。

カッコいいかと言われれば微妙ですが、使い心地が気になります。

結局今使ってるマウスは軽くて、電池で使用できるただのホイール付きのマウスで、利点としては内蔵バッテリーではないので電池切れを起こしたときに即座に入れ替えて使い続けられること。

bluetoothヘッドフォンで結構痛いのが、内蔵バッテリーの欠点はバッテリー切れの時の復帰時間が必要になってしまうこと。これを補うために、ヘッドフォンは最低でも２つ無いとかなり不便です。

ヘッドフォンは軽くするためにバッテリー内蔵させた方が軽くなるので選択肢が無かったりしますので諦めざるおえない部分です。

細かい記載が無かったのでサンワダイレクトのページにあった取扱い説明書によると、USBケーブルで接続しても直接マウスデバイスとはならないものの、充電中もマウスの操作は可能と書いてありました。

結構欲しいかもｗ

グラフのセンスが無さすぎる

センサーごとのアジャストを行ったり、色の調整を少ししたら、

そういえば温度のメモリも１℃刻みでほしいよなとか、

温度、湿度、気圧と表示は気温しか出していなかったので、温度と湿度の軸を揃えてみようかなとか、

：

：

まずは温度の刻みを直してみると、グレーの濃さが微妙だなとか、、、きりがないｗ

私以外見ることが無いマイグラフなのでとにかく把握しやすいものということであえてｙ軸は温度、湿度、気圧と分けていたわけですが、phpのスクリプトは単純にそれぞれ独立して上限下限を決めてプロットしているだけなので、軸を揃えたければ単純に一致させてあげるだけでグラフも簡単にそろう作りになっていたので試しにやってみたところ

高湿度のこの時期はこんな感じに。温度の波が今までの半分程度になってしまうので結構寂しい感じに。

元々、温度を中心に考えて、湿度と気圧はおまけ的に表示させていたのですが、改めて見てみると、やっぱり軸を揃える意味は少ないようです。

温度に関しては、気温は0℃～40℃、Raspberry pi の温度が～60℃として考えても、20目盛ぐらい助長になっています。

軸の状態を元に戻してみると、、

高湿度なのでRaspberry piの温度と重なってしまう感じになっていますが、数字の重なりさえなければ実用的に問題ないかなぁ…グラフとしては上下に踊ってくれた方が楽しいし。

やはりほとんど波が無いグラフは面白くない。

正直、グラフなんてこだわったことがことがほとんどないのでセンスも何もないのが一番悲しいｗ

DHT11とBME280の差異は上下に数値を補正しただけで波形はほぼ一致しました。試しに湿度や温度をエアコンで変えてみましたが振れ幅も一緒なのでこの温度、湿度下ではいい感じです。冬場までこのままセンサーをつなげたままの状態を維持すれば少し違った結果が得られそうな感じはします。

ただ、驚くべきことに、安価なDHT11の湿度の方が反応が良いようです。温度の反応速度はどちらも一緒のような雰囲気です。

意外と変なところに躓く…

グラフの表示をかなーり低レベルで自前で折れ線グラフを書いているわけですが、いろいろと引っかかってきました。

設定ファイルとしてiniファイルを使ってみたところ、phpではコメントに2byteコードを書いても無視してくれるのですが、python3だとコードページが違うだとか結構面倒な感じに。

Windows10のメモ帳でもUTF-8が扱えることを考慮すると、すべてUTF-8で揃えてしまうのが幸せになれそうなのですが、iniファイルといえばシフトJISとか変なプライドが邪魔してしまい、shft-jisファイル形式のままアップロードしています。

昔はクライアント内ではクライアント側のファイル形式や文字コードで管理してftpで変換し、サーバー側ではサーバーのファイル形式、文字コードという考え方でよかったのですが、最近はやってもファイル形式（とはいっても改行コード変換程度）で文字コードはそのままというかなりアバウトな感じで管理していました。

その一つにphpが結構いい感じに文字コードや改行コードを無視してくれるというのがあったのですが、これがpython3になると、スクリプト内の文字コードも結構厳しかったり、パーサーなどもしっかりとコードページを意識しているので簡単に処理が通らなくなってきます。

一番最悪だったのがiniファイルをsift-jisのままアップロードして、サーバー側のテキストエディタでコメントまでコピペして保存するとそのファイルはsift-jisとUTF-8が混在した不思議なファイルが出来上がってしまうと、python3のiniパーサーで直接扱うことができなくなってしまいます。

サーバー側で直接触らなければいいのでしょうけど、設定ファイルだし直接触りたい欲求はあるわけです。

で、python3でiniファイルを扱うときは予めコメントをカットしてパーサーに渡してあげれば…とか考えたんですけど、そこまでしてオーバーヘッド増やすなら、いっそのこと全部UTF-8でいいんじゃ？的なｗ

phpのiniファイル絡みでもう一つ。

iniファイル上のセクション名などに関して数字で始まる文字は数値になるとかいう仕様があってこれが値に対しても行われるのかな？と思ったら行われていなかったという。

色の設定を行いたくて、

name=0xF0F000

みたいな設定を行ったら、結果としてiniパーサで、文字列として取り込まれていたのですが、これが分かるまでに結構四苦八苦しました。

結果としてデバッグ用に if (php_sapi_name() == 'cli') とか判断して色々出力するようにしておきました。これで今後はかなり複雑怪奇な形になっても内部が目で見えるようになるので便利かな？

センサー類の情報、そして個人的なセンサーに対する結論

センサーについて何かないかと検索してみると、見知らぬ型番が出てきて少し気になっていました。そもそも出発点は電子部品セットの中にあったDHT11とBMP180の2つの温度センサーからなので、それ以外の系統の部品やメーカーは知りもしませんでした。

その一つとしてSHT11という型番。

メーカー特性としては精度は高いが、部品も高いという感じらしい。

視野が狭すぎると感じたので他にも温度系のセンサーはない物か？と検索し続けてみましたが、デジタル部品としては主にこれらの３社系統がメジャーな雰囲気です。

でそんな中、似たような趣旨の記事を発見！

Arduino温湿度測定ロガー・湿度センサーの比較

ようやく複数のセンサーを比較している内容を見つけた感じです。言語を広げればもっと良かったのかな？

同じ型の部品も複数比較していたり、かなり突っ込んでいると思います。

上のブログ記事にも書かれていますが他のブログ記事にもDHTシリーズの湿度は実際の値より少し高めになってしまうようです。

デジタル部品を見回すと、メーカーや型番によりかなり差があることは当たり前のようで、絶対的な温度、湿度の精度を求めるのならアナログ部品を使って直接値を加工した方がよさそうな気がしてきました。

寝る前にはその気になるセンサーを入手して使ってみようかとも考えていたのですが、どうせ個体差があるならこれ以上細かいことを気にしても用途（ただ室内の温度を知りたい）的に意味がなさそうです。

デジタル部品であっても基準を決めて補正するとか、複数の種類のセンサーを組み合わせて補正するしかなさそうですね。

最後に昨日の夜からDHT11とBME280を1分間隔でロギングしたグラフを残しておこうかな。

温度に関してはDHT11は少数なしの整数値なので矩形波っぽくなっていますが、温度に関してはDHT11が30℃、このBME280とはほぼ一致している感じです。目視の温度計は29.0℃ぐらいなので、まぁ誤差範囲でもいいとおもいます。

湿度は、DHT11では70%、BME280では58%と、数値として12程度ずれています。このBME280は湿度が異様に低くなっていますねぇ…

(2020/08/03追記) 大きな訂正となりますが、DHT11の気温は小数点第一位まで出力しますが、この時点では整数しかもっていないものと勘違いしていました。