node.jsでラズパイのI2C機器制御してみたが
対象機器はBME280とLCD1602。
BME280は直接、LCD1602は以下の構成。
BME280制御には bme280-sensor を使用した。これは i2c-bus^1.2.0 に依存する。
LCD1602制御に使用するI2Cシリアルインターフェースボードの制御用には i2c-bus で直に操作するのがうまいこといかなかったので lcdi2c^1.0.6 を使用したが、これは i2c-bus^1.0.2 に依存する。
ついでにI2C制御ではないがサーボモータのコントロールには raspi-io を使用しており、これは raspi-i2c^6.2.2 に依存、raspi-i2c^6.2.2 は i2c-bus^4.0.7 に依存。
それぞれ依存関係を満たさない構成ではエラーとなる。
('ω')
ググって得た所感だが、node.jsのI2C関連モジュールには失速感があり、その原因を垣間見た感がある。原因の原因といえば、おそらくKernelアップデートであろう。
さて、これらを個別のdockerコンテナで運用するなら問題ではない。
だが、一つのコンテナで運用したい、例えばBME280で取得した情報をLCD1602に表示したいという要求は特別なものではない。たったこれだけのことで依存地獄と向かい合わざるを得ず、gitを経由して自作モジュールを組み込む必要があったりする。
今回 node.js で作成した機能は、そもそも Python で書いたものをリプレイスしたわけだが。
なぜそんなことをしたかといえば、自宅LANに既存のサーバ機能をdockerコンテナ化し、この機に node.js か GO言語で統一してみようと思い立った。Python でもよかったのだが、dockerと並び立つキーワードとして優位ではなかったので除外。並び立つキーワードとしては node.js が優勢だったので採用したわけだが、一通りやり終えたあとの感想としては、ラズパイでI2C制御は Python が無難な気がする。
Windowsでさんざん揶揄されてきたdll地獄って、当時はUnix（Linux）だったらそんなことは起こらない、Javaはそういうことがないとか声高に謳われたが、それはどこで見た幻想？というのが実情だ。形を変えて人類を苦しめ続けている。そしてそれがあることは当然という風潮になりつつある気もする。
