実家の猫のこと

先週実家の猫が死んだ。19歳7ヶ月。半外猫にしては大往生だったと思う。
死期を察した猫はそっと姿を消すという話は多々あるが、彼はその例に反して家の中にこもるようになって最後は家族に看取られて苦しまずに逝ったらしい。
ある日突然帰ってこなくなったり、家の近くで事故にあったりといった形で生を終えるといったことがなくほっとしている。半外猫の場合だと可能性としては大いにありえるし、飼い主からすると控えめに言って最悪の形での別れだ。死んでしまったのはもちろん悲しいが、その点だけはよかった。

彼は概ね温厚で賢く小心者な猫で、自分より小さな子猫や人間の赤ん坊を怖がって家の中で隠れて回った。そのくせ半外猫なので外で地域猫に縄張り争いで負けてボコボコにされて怪我をして帰ってくることも多々あった。自然はきびしい。
体はちょっとした小型犬より大きく、ふわふわの白い毛は抜けやすく家族の服をいつも毛だらけにした。
人間に抱き上げられるのを嫌がってくねくねと暴れる割に、家族を見かけると寄っていったり、寝る時は人にくっついて寝たりもした。
キャットフード以外に猫草とたまにチートスを食べた。猫にとってチートスはおそらく体に悪いからあげるのをやめろと言ったが、同居している家族から見て害にならない程度の適切な塩梅があったのであろう。現に彼は室内飼いの猫の平均寿命を超えて生きたし、上の兄弟が独立した後の我が家の三男坊として愛情を注がれて大切にされていた。

ちょっとした小型犬より大きい (2019/06)

妹の誕生日に我が家にやってきた彼は両手におさまるくらいの大きさで、人によく懐き家族の後ろをついて回った。
当時の実家は縦に長い3階建ての建物で、階段がスケルトン階段になっていたため彼はしばしば踏み板の間から下の階に落下した。今になって考えると子猫には相当に厳しい構造だったし、勾配が急だったためか私を含め兄弟全員階段でコケて下の階まで転げ落ちるということは何度も体験した。そもそも人間にも厳しい。人も猫も大事がなかったのは単に運が良かっただけだろう。
一度目の引っ越しの後で裏に藪だらけの空き地があるアパートに引っ越したときは、外でノミをもらってきて家中にばら撒いて家族総出でノミ駆除をすることになったりもした。どうやらノミに噛まれると蚊に刺されるより痒いというのと、ノミがいる猫をお風呂に入れると水から逃れるためにノミが顔の方に集まってくるといった、あまり積極的に知りたいと思えない種類の知見が得られたのは彼のおかげだ。

彼が我が家に来た翌年、私は全寮制の高専に入学した。その後そのまま一人暮らしをしたり就職をしたりと家を離れてしまったため、彼と一緒に暮らす期間は短くなってしまったが、実家に寄った際はそれこそ過剰な猫可愛がりをしてちゃんと嫌がられて爪や牙で咎められるというフィジカルなコミュニケーションをとっていた。このコミュニケーションは彼がおとなしくなる晩年まで続いた。

玄関で迎える三男 (2022/06)

帰省の度にそのようなふれ合いを続けていたが明確に様子が変わったと感じたのは彼が15歳を迎えた2020年頃からだった。かつてふわふわだった白い毛は少しずつ固くなり、体の大きさも重さも現状維持からコンパクトになる方に転じた。年と共に落ち着いているのではなく、どちらかというと単に元気の総量が減っているような印象を受けた。もちろん家族を見ると鳴いて歩いて寄っていくが、興味のある何かを見つけてネコ科らしい瞬発力で走っていったり、湧き上がる理不尽な怒りとともにすれ違いざまに人間の足首に噛みついてきたりといったこともしなくなった。

最後に直接会ったのは2023年2月。2024年の春にも帰省したが、実家の全員がコロナにかかってしまい実家に寄るのを遠慮したところ結局それっきりになってしまった。彼が弱っている話を聞いていたし、次は夏に帰るか秋に帰るかと思案しているうちにこのようなことになってしまった。つらい。連絡を受けたのは平日の昼だったがその時間以降はぼんやりとしてしまった。

次の帰省からは玄関で出迎えられたり、帰りの荷造りの邪魔をされたりすることがなくなると思うととても寂しい。
会いたい人がいたり、やりたい事があるならすぐ行動した方がよい。思い立ったらすぐ行動、言い古された言葉だけど本当にそう思う。

遠慮なんてしなくていいからたまには夢に出てきてくれ。すれ違いざまに足首を噛んでもいいから。長男より。

JJUG CCC 2024 Fall 発表してきた

直近業務で対応しているPCI DSS関連でContent Security Policy(CSP)を試していて、それをもとにCfPを書いたところ運良く採択されたので発表してきた。 ふわっと内容を決めてタイトルはChatGPTで案を出して決定、CfPや発表の構成については前回同僚氏が登壇したものを大いに参考にして作成したので、半分は氏の功績。どこかで酒をごちそうしなければという思いがある。

speakerdeck.com

CSP導入して数年経ってゴリゴリに分かってますみたいな人から見ると物足りなさそう(だし情報量的にも実際そう)、国内大手のサイトでも入れてるとこ少ないし認知を広げる方向に振り切って資料作ったけど反応は概ね好評だったので一安心。

以下、書きたかったけどあえて落とした内容。 認識はしているのだけれどもこの話をちゃんと盛り込むと時間的に説明しきれないし参加者が持ち帰れる情報として発散しちゃうので除外した。

• script-srcの深堀り
  • strict-dynamic, nonce, hash周りを説明し始めると、なぜこれが必要かの理由であったりnonceとSPAとの相性の悪さみたいなところに触れなければ…となってしまうため除外
  • 各ディレクティブでの指定リストが無限に伸びてホワイトリストだとやれんかもしれんな、となってから気づいて調べても遅くないかなという判断
• CSP Level2, Level3のギャップと両方への対応
  • 実践としてはもちろん必要になる項目なのだけど、概要を説明する際に細部に立ち入り過ぎると参加者を振り落としてしまいそうだったので除外
    • 昔のIE向けのスターハックみたいなの思い出すよね
  • 調査時に出てきたClassiさんのブログ記事はかなりよかった
    • Strict CSP を Content Security Policy Level 3 に対応したブラウザに絞って適用する - Classi開発者ブログ
• 実際の普及率
  • Web Almanacというところが数値を出しているもので最新版は2022年度版で2024年度版が出るのを待ってたけど出なかったため除外
    • セキュリティ | 2022 | HTTP ArchiveによるWeb Almanac
  • 2022年時点だとCSPは14.6%の普及率とのこと

---

登壇までのタイムラインとしては

• 2024/08/中旬 プロポーザルの案を考え始める
• 2024/08/31 (土) プロポーザル投稿
• 2024/09/09 (月) プロポーザル採択の連絡
• 2024/09/25 (水) 自社カンファレンス
• 2024/10/11 (金) 休みとって資料作成着手
• 2024/10/21 (月) 社内での発表練習
• 2024/10/27 (日) 発表当日

資料は構成を途中で大きく変更するために初稿を一回捨てたり、発表練習しながら違和感あるスライドを捨てたり足したりでほぼ前日まで調整していた。
慣れてきたら資料準備にかかる時間は短縮されるだろうけど、流れの最終調整は発表練習と並行した方が違和感なく仕上がるかなという気がする。できなかったのは資料自体の作り込みで、図表をいい感じにしたりスライドデザインみたいな部分でもう少し改善できただろうなという反省。良かった点は、流れをスムーズにするために前日ちゃんと時間をとって通しで練習したのと、1週間前に社内で発表練習できたのもとてもよかった。台本無しでやると多分練度が上がりきらないだろうなと思って、Google Slideのプレゼンター表示をフル活用したのもよかった。

もうちょっと早く着手して全体感を早めに掴もう、というのはそれはそう。次回はもう少しゆとりもって進めたい。

---

発表資料作成にあたって流れを作るときはChatGPTをガンガン使いつつ、裏取りにはちゃんとMDNやW3Cの原典にあたったためかMDN側の資料がおかしくない？ということに気づいて本家ドキュメントにコントリビュートできたのもよかった。ちゃんと深堀りするの大事。

github.com

毎月登壇あると準備で死ぬけど半期に一回くらいはこういう経験を積みつつ深堀りができるとよさそう。
引き続き精進しましょうね。(沖縄方言でのしましょうねの用例)

CloudWatch Logs Insightsのみで指定期間について日付を無視した時間帯毎の頻度をグラフ化する

久々に技術ネタ(小粒)。

CloudWatch Logs Insightsでは指定したロググループのログイベントを専用のクエリ言語で検索したり視覚化することができる。
検索結果は明示的に可視化を利用しなくとも、時系列順に下図のような形でヒストグラムで表示される。
(データは適当に生成した雑なデータ)

3日分のログの発生分布

stats句を利用したクエリでは簡単な集計を行うことが可能で、ドキュメント内でもbin関数を利用した時系列データの視覚化と
フィールド別にグループ化されたログデータの視覚化が取り上げられている。

これらの機能は直感的で利用しやすく強力で、例えばアクセスログを対象とした視覚化の場合
前者では例えばAPIに対する5分毎アクセス数を視覚化したり、後者ではHTTPステータス毎の割合を視覚化したりなどが行える。

一方で少し加工した時間情報を利用した集計を行いたい時はひと手間が必要になる。
時系列データの集計に利用されるbin関数では対象とする値は@timestamp固定となっているため、例えばタイトルで示したような指定期間について日付を無視した時間帯ごとの頻度を見たい、といった場合には自前でstats句に渡すfieldを定義する必要がある。

生の@timestampはTimeStamp型として扱われており、そこから日や時間や分などのフィールドを指定して取り出すことはできないため、stats句に渡すfieldとしてtoMillis関数でエポックミリ秒に変換して1日のミリ秒数で剰余を取ったものを1時間のミリ秒数で割り、最後にfloor関数で切り下げたものをhourとして定義する。

fields floor((toMillis(@timestamp) + 9 * 3600000) % 86400000 / 3600000) as hour , @message
| stats count(*) as access by hour
| sort by hour asc

(JST変換のために 9 * 3600 * 1000を加えている。)

3日分のデータを日付を無視して1時間毎にまとめた

下記は15分単位の棒グラフとして出力したケース。
アプローチとしては大きく変わらないが、hhmmを4桁の数字として扱うために時と分で分けて計算した上で加算している。

fields (floor((toMillis(@timestamp) + 9 * 3600000) % 86400000 / 3600000) * 100 + 
floor((toMillis(@timestamp) + 9 * 3600000) % 86400000 / 36000 % 100 / 25) * 15) as hhmm , @message
| stats count(*) as access by hhmm
| sort by hhmm asc

3日分のデータを日付を無視して15分毎にまとめた

stats句での視覚化で使える棒グラフでは表示数の上限が100件のためこの用途だと24*4=96でこれが最大の分解能。
この用途において、これ以上細かな単位で見たい場合はCloudWatch Logs Insights上の視覚化は利用できないため
素直にデータを吐き出して別で視覚化する必要がある。

また、追加の注意点として対応する単位時間にデータが存在しない範囲については棒が表示されない。
そのため、例えばアプリケーションログを対象としてシステムの動作時間帯を把握する用途か、最低でも15分に1度はアクセスがあるようなシステムのアクセスログを対象として利用するなどの前提が必要。
(後者はヘルスチェックがあるようなシステムであればクリアできるはず)

---

書いててかなり限定的な用途っぽいことに気づいたものの、誰か使うかもしれないので放流

2021年私の上を通り過ぎていったお酒たち

この記事は泥酔アドベントカレンダー31日目の記事です。
昨年に引き続きステイホームアンド酒をやっていたので、2021年に飲んで印象に残ったお酒をまとめておく。

ウイスキー

ザ・グレンリベット 12年

2021年はウイスキーに色々手を出した一年で、中でも王道系をちゃんと抑えていった。
味の分解能はそんなに高くないけどグレンフィディックは洋梨でこっちは青りんごみたいな印象。
ロックでもいいしハイボール要員としてもよい。 item.rakuten.co.jp

十年明 Seven

5千円以下の国産ウイスキーを色々買ってた時期がありその中で見つけた1本。
どちらかというとピーティー系。春頃に出会って今年でもう3,4本飲んでいる。
46%と度数が高くハイボールにしてもおいしい。
item.rakuten.co.jp

グレンモーレンジ アルタ

ちょっといいウイスキーが飲みたくてオークションで購入したもの。1万円前後。
発酵過程で野生酵母を一部使ったウイスキーで、パンみたいな香りがした。
いいウイスキーは少しずつ飲むので開栓してからの味の変化も楽しめてよかった。
product.rakuten.co.jp

古めのジョニーウォーカー(赤,黒,Swing)

特級時代(1989年以前)のものが結構好きでちょくちょく買っている。
流通量が多いのでうまいことやるとオークションで一本1500円くらいで手に入る。
商品の写真から当たり外れを推測したり、実際飲んでみて確認する試行錯誤も楽しい。
蓋が金属のキャップなのでオールドボトル初心者にもおすすめできる(栓がコルクだと引きが悪いと開栓時に死ぬ)
page.auctions.yahoo.co.jp

ビール

Lupulin Nectar (YMARKET)

ビールに強い酒屋でまれに取り扱われている。
アルコール度数は7.5もあるものの、これでもかってくらい柑橘っぽくて飲みやすい。
美味しすぎて買い占めようとしたけど700円/本だったので3~4本にとどめた。
item.rakuten.co.jp

ELVIS JUICE (BrewDog)

原料としてホップ以外にグレープフルーツ、オレンジエキスが利用されている。
一口目からグレープフルーツのパンチがすごい。味が濃い目のつまみに合う。
同じBrewDogだとPUNK IPAはよく飲んでたもののこっちは知らなかった。
item.rakuten.co.jp

ねこぱんち (VECTOR BREWING)

社の人が買っていたのを見て気になって購入したけど、どれも軽くさっぱりしてて美味しい。
定番のねこぱんちに加えて何種類かレパートリーがあるセットを何度か購入している。
あとラベルがかわいい。
vectorbrewing.shop

日本酒

仙禽雪だるま

酸味と甘味のバランスがとれていて飲みやすく微発泡でするする行ける(そして死ぬ)
毎年11月12月1月の期間限定なのでそのタイミングを逃すと1年買えない。
日本酒好きな後輩に一升瓶送りつけたら一晩で半分飲んで死んでたらしいのでやはり危険。
item.rakuten.co.jp

紅熟 月桂冠

これまで飲んだ日本酒の中で一番甘かった。甘さの系統としてはリンゴ系なんだけどとにかく甘い。
オフィスにあったやつを飲んで感動して自分でも買い直した。限定ということもあって少し値が張る。
www.gekkeikan.co.jp

焼酎

天狗櫻 ジョイホワイト

薬品瓶みたいなカッコいい瓶に入った焼酎。
芋焼酎はあまり得意じゃなかったものの、甘く爽やかで飲みやすく芋焼酎に対する印象がガラリと変わった一本。
nomiyama-shuhan.shop

---

ビールはヘイジー系とか爽やか方向のものをかなり知ることができたのと
ウイスキー・焼酎でも自分にとって定番に近いものを見つけられたのがよかった。

肝臓と仲違いしない程度に来年も楽しく飲みたいですね。おわり。

1万円台で作れるIoTセンサでCO2と気圧をグラフ化する

温度や湿度の変化は変化を自覚してから不調が来るものの、気圧やCO2濃度の変化は不調が来てから(能動的に調べて)変化を知ることが多い。
去年2月から丸1年とちょっとフルリモートで働いているのだけど、やることは明確なものの何故か手が動かない時は内因として水分補給や血行の問題、外因では低気圧や部屋の換気が原因となっているケースが多かった。

進捗悪くなってきたら水を2口飲んで換気してスクワット20回する、みたいなことしたら集中力がそれなりに回復することに気がついた。

— しろめ (@uskey512) 2021年1月5日

一度気づいてからは定期的に対策するようにするのだけど、障害対応とか不具合調査で下手にフローに入ってしまうとそれも難しい。
なのでまずは検知しづらい生産性低下の外的要因を確認できるようにしたい！というモチベーションで気圧計やCO2濃度計を調達しようと思って1月頃から調べ始めたのだけど、業務用のCO2濃度計がとにかく高い。
わざわざ業務用で調べたのはAmazonで調べると怪しげな海外メーカーのCO2濃度計が投げ売りされていたりして不安になったのと、下記の記事を読んだから。

何　も　測　っ　て　い　な　いhttps://t.co/hFJSPYa0dc

東京理科大の倉渕隆教授…測定器10種類以上を実際に購入してCO2濃度を測定し、精度を調べた。その結果、現状では「1万円以下の製品は買うべきではない」と指摘…実際の濃度と2千ppm以上も差があり…「おそらく何も測っていない」

— 五番町睦十(うしHK) 🍀📒🐱🎨🌙♠️ (@mutsuju) 2021年1月25日

どうせ買うならちゃんと動作するものがほしいし、もちろんできれば安くで欲しい。
ということで無ければ作るの精神で自作することを決めた。

必要なもの

Raspberry Pi 4b 4GB ¥6,490
後々設定を変更したりしやすくするためにWifiがついてたらなんでも良いと思う。(長いので以下RPiと呼称する)
他の用途で遊ぶかもしれないなと思って少しスペックが高めのRPi4b 4GBモデルを買ったけど、今回の用途だけで利用するならスペック的にはRPi Zero WHくらいで良さそう。
入出力インターフェースは減るものの、Rpi Zero WHだと¥2,500くらいで入手できる。
https://www.amazon.co.jp/gp/product/B087TM3VRX

RPi用電源 ¥1,139
本体購入のときと一緒にAmazonでまとめて購入。多分もっと安く入手できそう。
https://www.amazon.co.jp/gp/product/B07DN5V3VN

microSD 32GB ¥851
本体購入のときと一緒にAmazonでまとめて購入。容量とかこだわりたい人はお好みで。
https://www.amazon.co.jp/gp/product/B06XSV23T1

ジャンパワイヤ(メス-メス) ¥380
半田付け無しで電子部品とRPiを接続するのに使う。
電子部品側もピンが用意されているものを買う必要があるので注意。
https://www.amazon.co.jp/gp/product/B01A4DDUTA

MH-Z19C (CO2センサ) ¥2,480
今回の重要部品その1。
値段がRPi Zero WHと同じくらいする。
https://akizukidenshi.com/catalog/g/gM-16142

SSCI-023238 (BME280 温湿度気圧センサ) ¥2,178
今回の重要部品その2。
この電子部品であれば温湿度も同時に取れるので採用。ピンを自分で半田付けする前提なら半額くらいで買える。
BME280で調べればSSCI-023238でなくとも同様のデータが取れる電子部品が大量に出てくるのでそちらでも代用可。
https://www.amazon.co.jp/gp/product/B07XYZZB5Q

必要に応じて

HDMI-microHDMIケーブル
RPiの初期セットアップに画面をつないで操作するために利用。
持ってたので今回の費用計上からは除外。初期セットアップを画面接続無しでやるなら不要かも。
https://www.amazon.co.jp/gp/product/B00HQY7XIU

microSDリーダー
RPiの起動イメージを書き込むために必要。
持ってたので今回の費用計上からは除外。
https://www.amazon.co.jp/gp/product/B0829KGK2F

この構成だとここまでで¥13,500前後。
RPi 4bをRPi Zero WHに変えたり、センサ系の部品をピン無しのものを買って自分で半田付けすれば¥8,000くらいにおさまるはず。
(その場合一番高い部品はCO2センサになる)

半田ごてとか道具が揃っていて、その辺の作業に抵抗ない(楽しめる)人はコスト的にそっちの方がよさそう。

セットアップ

RPi上で動作させるOSのセットアップ

Raspberry Pi Imagerという公式のツールがあるのでそれを利用する。
OSには色々種類があるものの、定番ぽいRaspbian Fullを選んで書き込み。

下記がとても参考になった。
dev.classmethod.jp

初期設定

モニタとUSBマウス/キーボードを繋いで、初期パスワードの設定。
後から調べたら最初からsshで起動できるように設定を編集することもできるらしい。

起動後、インターフェイスからSSH(VNC), I2C, シリアルポートを有効にする。
SSH(VNC)はRPiに画面を接続せずとも外部PCからアクセス出来るようにするため。I2C、シリアルポートは電子部品とのやりとりのため。
SSHで接続するには接続するPCとRPiが同じWifiに接続していれば ssh pi@raspberrypi.local で接続できる。

より具体的には下記の記事が参考になった。
パブリックなネットワークだと危険な気がするものの、家庭内LANなので一旦問題なしとしてすすめる。

dev.classmethod.jp

配線

RPi [番号] と書かれたものはRPi上のGPIOピン上でのマッピング(参考)。
配線失敗すると基盤が死ぬこともあるらしいので注意する。
各ピンと電子部品間でどのような通信が動いてるか把握するのは後回し。
ネットを調べると先人達の知恵があるのでそれを元に配線を行う。

二酸化炭素センサ (MH-Z19)

取れる情報 : CO2, 気温(低精度)

RPi - MH-Z19間の接続
RPi 04(5V)  <-> Vin
RPi 06(GND) <-> GND
RPi 08(TXD) <-> RXD 
RPi 10(RXD) <-> TXD

Pythonから利用するためのスクリプトが存在していてpipからインストールできる。
(ソースは下記)

github.com

GithubのREADMEを眺めているとドキュメントされていない機能として気温が取れる、とのことなのでどうせなのでその値も取得してみる。

GPIOを利用するにはroot権限が必要になるためsudoをつけて実行する。
下記のように実行して値が返ってきたらok。

$ sudo pip install mh-z19
$ sudo python -m mh_z19 --all
{"SS": 0, "UhUl": 7936, "TT": 73, "co2": 688, "temperature": 33} 

室温がだいぶ上振れしていて精度が悪いように見えるものの気にせず進める。　　

温湿度/気圧センサ (SSCI-023238 BME280)

取れる情報 : 気温, 湿度, 気圧

RPi - SSCI-023238間の接続
RPi01(3.3V) <-> Vio
------       <-> VCore
RPi 03(SDA)  <-> SDI
RPi 05(SCL)  <-> SCK
RPi 09(GND)  <-> GND
RPi 17(3.3V) <-> CSB
RPi 20(GND)  <-> SDO

メーカーのスイッチサイエンス社からPythonでデータを取得するサンプルプログラムが提供されているのでそちらを利用する

github.com

同様に下記のようにして動作確認をして値が返ってきたらok

$ wget https://raw.githubusercontent.com/SWITCHSCIENCE/BME280/master/Python27/bme280_sample.py
$ sudo python bme280_sample.py
temp : 22.23  ℃
pressure : 1009.89 hPa
hum :  35.11 ％

サンプルプログラムのままだと入力待ちを続けたり、出力が扱いづらいのでjsonで返すようにするなどよしなに整形する。
センサからデータを取得するスクリプトをPython2系で進めてしまっていることに気づいたが、後から差し替えもできるので一旦作りきってから改修することにして前に進める。

グラフ化

ここもスクリプト同様に外部のサービスを利用する。
IoT系のデータをいい感じに表示するサービスは複数あるものの、今回は無料で利用できて簡単なAmbientを利用する。

ambidata.io

ユーザー登録後、チャネルを作成してID, ライトキーを保存しておく。
また、Python用のモジュールが用意されているので導入しておく。

$ sudo pip install git+https://github.com/AmbientDataInc/ambient-python-lib.git

Ambientに保存するデータ量・更新頻度の制限については公式のspecに記載があり

- 1ユーザーあたり8個までチャネルを生成できます。
- 1チャネルあたり8種類のデーターを送信できます。
- 送信から次の送信まではチャネルごとに最低5秒空ける必要があります。それより短い間隔で送信したものは無視されます。
- 1チャネルあたり1日3,000件までデーターを登録できます。平均すると28.8秒に1回のペースです。
  - bulk_send()やnode.js、Pythonで複数件のデーターを一括登録する場合、APIのコール回数は1回ですが、データー登録は複数件とカウントされます。
  - 件数のカウントは0時に0クリアされます。
  - チャネルデーターを削除しても1日の登録件数のカウントは0クリアされません。
- 1チャネルあたり8個までチャートを生成できます。
- データーの保存期間は1年間です。

とのこと。

一回の書き込みAPIアクセスで1セット8種類のデータを送信することが出来るため、一度に送信するデータの種類を増やすと送信可能な回数が減るかと思ったものの、実際には1日3000データではなく1日3000セットが制限だったため今回のセンサ分(5種類)は問題なし。
無料でこれだけ使えてデータが1年残るのはかなり太っ腹だと思う。

Ambientに登録する処理の実装

MH-Z19, BME280からデータを取得してAmbientに登録する下記のようなスクリプトを作成する。
channel_id, write_keyは先程登録した際に保存しておいたものを利用する。 (import bme280 としているものは先のサンプルプログラムをいい感じに修正したもの)

import datetime
import mh_z19
import ambient
import bme280
  
mhz19res  = mh_z19.read_all();
bme280res = bme280.readData();
  
if 'co2' in mhz19res :
    am = ambient.Ambient(channel_id, write_key)
    status = am.send({'d1' : mhz19res['co2'], 'd2' : mhz19res['temperature'], 'd3' : bme280res['temperature'], 'd4' : bme280res['pressure'], 'd5' : bme280res['hum']}, 60)

データの登録に成功しているとAmbientのチャネルでは下記のように表示される。

それぞれのデータに対してはまだ名前がついていないため、適切な名前をつけたりチャート表示の変更を行う。

定期実行

スクリプトからAmbientへのデータ登録の確認ができれば、いよいよ時系列グラフ描画のために定期実行の設定をしたい。

先程のスペックから''平均すると28.8秒に1回のペースです'' とのことなのでその制限に触れない30秒毎にデータを送信する。
(crontabでは指定できる最小単位が分なので、即実行するものとは別に30秒待ってから実行する設定を行う)

$ crontab -e

* * * * * sudo python ~/monitor.py
* * * * * sleep 30; sudo python ~/monitor.py

正しく動作していればAmbient側で下記のようにグラフ表示が行われる。
(データやチャネルへの名前設定などは別途設定済み)

このボードは設定によって全体公開にすることも可能で、試しに全体公開した家の作業部屋のボードが下記。

https://ambidata.io/bd/board.html?id=23516

人間が部屋にいて作業をしているとCO2がじわじわ上がっていったり、エアコンをつけると気温/湿度が周期的に変化したりなど様々な傾向が見て取れて面白い。
また、RPiの電源が落ちているなどの要因でデータの登録に間隔が空くとその部分は直線になるのでわかりやすい。
(MH-Z19から取れる気温は小数点以下の精度が無く、20℃を超えると誤差がすごい(5℃以上上振れする)のであまり当てにしてはいけない。仕様書に載ってない機能なのでそれはそう。)

まとめ

学生時代は半田付けが苦手だったり、自作したLANケーブルが自分のものだけ疎通しなかったりと散々だった(特別研究の担当職員に「しろめ君はそこそこプログラム書けるのに手先不器用だねえ！」と爆笑された記憶がある)ものの、センサ類からの値の読み出しはに手なりで書けるPythonを使えたり、処理の定期実行にcrontabが使えたりと普段仕事でLinux環境を利用している人ならなんとなくで利用できちゃうので電子工作に抵抗感がある人でもそんなに気合を入れなくても構築出来て満足感が高い。
(セットアップから最初のセンサをつないで値を読み出すまで1時間もかからなかった)

クソ雑電子工作(30分) pic.twitter.com/hMwTOs2TIP

— しろめ (@uskey512) 2021年3月5日

ちょっとお金を出してよく出来た既製品を買ってもデータを簡単に外部連携出来るモデルはあまりないし(しかも業務用だとべらぼうに値段が上がる)、少しでもプログラミングの経験があればとっつきやすいためエンジニアリングが好きな人にはおすすめ出来そう。
一方で、ちゃんとしたケースを作る。電源をバッテリ駆動にする。などを考え始めると沼にハマりそうなので一定の注意が必要。沼を覗いてる時沼もお前を覗いている。

他にも色々できそうなので時々やっていきたいですね。
おわり。