数年前に作ったw2uiを使ったWebツールに変更の依頼があったので、ついでにw2uiをバージョンアップすることにしました。
ツール作成時は、15.rc1で、現在は1.5となっています。
とりあえずw2uiをダウンロードし、htmlを適合させます。
で、動かしてみてChromeの開発者ツールで様子を見てみます。
エラーが１つ、お知らせもあるようです。
お知らせの方は、caption項目をtext項目にすればよいとの事。
エラー方は致命的で画面がまともに動かなくなります。
w2ui-1.5.js を開発者ツールで追ってみて、グリッドのカラムグループでspan: 8 と指定している箇所でエラーが起きている模様
カラムの個数とは一致しているのだが、、spanの値を減らしたら解消しました。表示項目のグルーピングがちょっと変わりましたが。
何となく更新を続けていた情報処理安全確保支援士ですが、3年目となったので実践講習を先月受けてみました。
このご時勢なので、今はオンラインでのリモート講習になってます。それまでは両国とかに集まって実施していたそうです。
講習はWebexを使って30人程が参加し、5人づつチームを組んで課題について討議し発表を纏めるという進め方で、課題は事前に資料が配布されており、とある企業で発生したセキュリティインシデントの初期対応や、事後予防策を検討するというものです。
チームでは予め、進行、書記、発表と３つの役割をローテーションで担当するよう決められており、中でもWebで共有されたドキュメントに、意見を聴きながら発表に向けて書き込んでいく書記役は結構疲れます。
講習自体は、主に社内CSIRTの責任者という立場を意識した形なので、どちらかといえば社内SE向けの内容でした。筆者としては現状の実務とは関係がないし、受講費用も高いですが、まあ受講して良かったかなという印象です。ただ、講習の内容が１つなので、セキュリティ人材を増やしたいという国の目論みにあっているように思えません。役割に応じて複数から選択出来ればよいのですが。
とりあえず3年経って1回目の更新をしてみましたが、正直なところ、相変わらず知名度が低すぎて更新するメリットが見いだせない資格です。特に毎年のオンライン講習は内容に対して受講費用が高すぎるので、何とかして欲しいものです。支援士という名称も含め制度として見直して欲しい所は沢山ありそうですが。。
講習後、更新資料を書留で送って３週間くらい経ってから受理した旨のメールが来てましたが、そのあとは更新期限の10月になってからなのか、何の音沙汰もありません。
日曜に県知事選挙があったので荒天の中、所有する傘の中で一番頑丈そうなのを選択して投票所へ行ったのですが、圧倒的な瞬間風速にあっさりと傘が損壊、無理して行かなくてもよかったような・・と思ってしまいましたが、そもそも今の時代になんでオンラインで投票できないのかと考えました。
メリットやデメリットの話ではなく、現行法の制約等は考えず、純粋にただ実現させる為には何を決めるべきなのでしょうか。
まず、最初にオンライン投票への移行方法です。従来の方法を廃止してオンラインのみにするというのをいきなりやる事はあり得ないとして、オンライン投票の併用期間をどの程度の長さで設定するかという事があるかと思います。選挙自体が年数回あるかないかなので、運用に慣れるには当面は期限を設けず併用し続けるか、または数十年レベルの期間を経た後、コスト削減の為に従来方法を廃止しオンラインのみに移行させた方がよさそうです。
併用期間では、従来方式とオンラインの整合性をいかにとるかという課題がでてきますが、オンラインは期日前投票のみとした方が仕組み上簡単そうですね。エストニアはそうしているようです。
次に認証方法です。
現時点ではマイナンバーカードが有力ですが、筆者のように毎年e-Taxで使っているような人は少ないと思いますので、これでは当面普及しないでしょう。他に、投票券にQRコードを印刷してスマフォで投票とかもありそうですが、マイナンバーのX桁目とX桁目とかを入力させるといった他の認証と組み合わせた方がよいですね。
あと、既存の投票券発送データを使うでしょうから、自治体とオンライン選挙システム間でどう連携するかという箇所は何等かの調整が必要そうですが、それ以外は、合意形成が必要そうな箇所はあまりないのでなるようになるでしょう。やると決まってしまえばあまり時間を掛けずに出来そうなのですがどうですかね。
何かシステムを作ろうとなったときによく感じるのが粒度問題です。
簡単に言うと要件を出す立場の人側は、森を見て木を見ず、開発する立場の人側は木を見て森を見ず、そんな違う立場の間で起きる認識のずれ、コミュニケーションギャップ問題です。前者は対象を大きな範囲で捉えており、１本１本の木々には関心が無かったりします。後者は、個々の木を構成した結果の集合としての森なので、木々の方に着目する傾向があります。たまに木が大好きな前者もいたりはしますが、実は木でも「松」にしか関心が無かったり、、と関心の対象が異なるので話が噛み合わないのは当然です。しかも、当事者はそのような状況になかなか気がつけません。さらに開発工程で担当者が違うような体制の場合、さらに別の面で同じような問題になったりします。
このような状態が続くと、当たり前ですが、最終的に良い結果にはならないので、早い段階で手を打ちたいですよね。でも、双方の意識を変えるという難しい問題なので、簡単な手はなかなか見つかりません。
結局、言葉だけで伝えられない事は、一旦紙、ドキュメントという形に落とす意外無いように思います。まずは森である大枠をいろんな角度で対象を分類し、徐々徐々にドリルダウンしていきます。このフェーズの落とし所として意識するのは、そのドキュメントを見る人たちが意識している粒度の粗さと細かさのちょうど真ん中辺りの粒度レベルまでに抑える事です。話が進むにつれてドキュメントに結果をフィードバックし、仕様書的な物に変えていきます。
人の意識を変えるのは難しいけど、少しずつ対話しながら双方が歩み寄るという、ここで言うところの粒度問題も、長年続く領土問題も平和に解決するには結局同じ方法しか無いないんだろうなあ。
最近、地元の図書館で見かけてたまたま借りたのですが、「ペーパレス時代の紙の価値を知る」という本を読みました。
認知科学？の実験結果報告部分が多く、途中かなり斜め読みになりましたが、紙の本を読むほうが読解が深い、手でページをめくる動作の優位性等、紙の本には電子書籍に対する優位性がまだあり、電子書籍だけでなくPC等含めた電子デバイスとは用途によって使い分けるのがよいだろう的な内容でした。
確かに筆者も図書館にたまに行くくらいなので、紙の本は気持ち集中して読みやすいような気がしますし、Kindlewhitepaperを持ってはいるけど、最近は殆ど手を付けてなかったりなので、紙派といえばそうかもしれません。
とはいえ、数千年ある紙の本の歴史をここ２０年くらいしか経ていない電子書籍が超えるのは時期尚早なだけで、将来的には置き換わるとは思います。あと１００年くらいたてばですが。
最も、既に紙の本より電子メディアに慣れた世代が大きくなれば、もっと早い段階で置き換わる可能性もあるかもしれません。最終的には個々人の慣れの問題だと思います。主に紙の本と紙のノートをベースに学習してきた世代と、電子デバイス前提の世代間の優位性なんて、時間を掛ければ測れるのかどうかも怪しいものだし、重要なのは中身のコンテンツで、メディアそのものでもありません。教育の現場では過去の実績が乏しい方式に短時間でドラスティックな変革をするのは難しいですよね。でも、筆者のような昭和生まれ世代が受けてきた教育が、当時としても、まあ多少なりともベターだったんだろうとは思いますが、今の時代ならベターどころかただの時代遅れになっている可能性は十分あります。
本の話になると一番の問題は、世界的に汎用的で共通した紙メディアを、１企業が開発した電子書籍が置き換えていくという所な気がします。ページ操作等含め、紙レベルで世界的に共通仕様の本のようなフォーマットが電子デバイスで実現できるかというと、、なさそうです。
書くという要素については、例えばプログラムを今の時代に紙に書いている人は居ないでしょう。結局ファイルにならないと動きませんし。書いた後の活用、または一度書いたものの変更しやすさ等、こちらは既に大部分の作業が紙からPC等の電子デバイスに置き換わっているのが現状では無いでしょうか。
ただ、マウスでウインドウを操作するような時間は結構無駄なので、特に２画面以上使ってる時にマウスで画面を跨いで行ったり来たりするのは、もうちょっとスムーズな操作は無いものでしょうか。
水遣り自動化を進めていたところ、作物がアブラ虫にヤラれてほぼ全滅。。
ただ、今回は、コロナ禍最中に自宅で出来る事として、ビオトープを構築しメダカを飼いつつ水遣りを自動化するという、水遣り制御自体は元々ビオトープの子タスクでした。下記がiPadで描いた当初のラフデザインです。
親タスクであるビオトープ構築に向け、プラ船、棚、ポリタンクを用意、プラ船にドリルで穴を開け、棚板にも穴を開けてポンプでポリタンクとプラ船を循環、ポンプの電源用にとソーラーパネルまで導入してしまいました。
ソーラーパネルには、コントローラーが付属しており、バッテリーに充電しつつ、直流電源が使えるようになっています。バッテリーは車用でヘタって交換したブツが余っていたので、それをソーラーコントローラーに配線し、直流電源からポンプを稼働させます。
ただ、このソーラーパネルはポンプを２４時間付けっぱなしにしているとバッテリー充電量が足りず（コントローラーの消費電力も侮れない）、いつの間にかポンプが止まっているようなケースがありました。しかも、ポンプからの逆流対策をしていなかったので、プラ船からポリタンクへ逆流して水が無くなり、あわや、メダカ全滅！という危機に。
これはいかんという事で、ポンプのホースに逆流弁を付け、暫くコントローラーに表示されるバッテリー残量（いまいち信用できないが）を見ながら動かしたり止めたりしてましたが、これこそ自動化すべき案件ですね。リレースイッチでポンプを定期的に動作させる事にしました。
今後の水遣りも電磁弁を使用する予定なので、余裕を持って４チャンネルのコチラを購入。ラズパイのGPIOピンに接続するのは基盤に書かれているので簡単です。リレー自体に極性は無いようなので、動作させるポンプとコントローラーの直流電源に繋ぐ途中にリレーをかます形になります。リレーには接続口が３つありますが、基盤上で繋がっているように書かれた左側と中央を接続すると常時ONでスイッチするとOFF、右側と中央を接続すると常時OFFでスイッチするとONになるようです。
単純にリレースイッチをON・OFFするPythonコードは下記のような感じです。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
import RPi.GPIO as GPIO import time PIN = 4 GPIO.setmode(GPIO.BCM) GPIO.setup(PIN, GPIO.OUT, initial=GPIO.LOW) # ON GPIO.output(PIN, False) time.sleep(60*8) # OFF GPIO.output(PIN, True) GPIO.cleanup() |
せっかくなんで、既に記録をするようになっている照度センサーの値でスイッチを制御するようにしました。
ホテイアオイが凄い勢いで水面を覆っていきますが、メダカも、コケ対策で導入したミナミヌマエビも子供が生まれていい感じになってきました。子供たちの何匹かはポリタンクに落ちてしまったので、頃合いを見て救出予定。
でも、照度次第で動かすだけなら、ポンプとソーラーパネル直接繋げるでもよくない？
前回の続きです。
AWS IOTで、ラズパイで取得したセンサーのデータを定期的にPublishするようにしていましたが、実際のベランダに各センサーを配置してみました。
いろいろ考えた結果、ベランダに電源を引いてラズパイを置くのでは無く、ラズパイは室内に配置、長いリボンコードをエアコンホースの口からベランダへ引くという形になりました。
リボンコードの加工が面倒でしたが、これならエアコンホースのふたを加工したりしなくても一応大丈夫そうです。
で、折角データを取得しているんですから、データを可視化してみたくなるものです。AWSにも色々BIサービスがあるようですが、趣味の範囲なので、コストを掛けず導入が容易そうなMetabaseでやってみます。
MetabaseにAthena用のドライバーは標準では含まれていませんが、有難い事にこちらからJarを取得してプラグインのディレクトリに配置するだけで、簡単にAthenaにアクセス出来るようになりました。
グラフになると入ってくる情報が違いますね。左軸は温度、湿度、右軸は照度、土壌水分です。温度・湿度センサーの値が取れずゼロになるのが回避できていないのが解ります。照度は明るいと数値が小さく、真っ暗で255になっています。また、湿度は夜高くなり、温度は朝の直射日光で40度になる時間帯があるようです。土壌水分は水やりの都度だいぶ数値的にはぶれるようで扱いが難しそうです。
Metabaseは簡単に起動させられますが、メモリが１Gは無いと動かない模様、EC2等クラウドで動かすにはコストがネックになるので、結局、ラズパイ自身で動かす事になってしまいました。４Gメモリのラズパイ４なので早くは無いですが、十分動作します。
こうなると、AWS IOT使っている意味無い気もしますが。。
前回の続きで、今度はKEYESTUDIOスターターキットに含まれていた各センサーを試してみます。
まず、温度湿度センサーですが、キット付属のセンサーはDHT11というモノ、サイトのコードはパット見pythonに変換するのが面倒なので、下記を参考にしました。
次は土壌水分センサーです。キットのサイトを参考に、I２Cを有効にし、Cのソースをそのままpythonに置き換えてすぐに値が取れるようになりました。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
import wiringpi Address = 0x48 BASE = 64 A0 = BASE + 0 A1 = BASE + 1 A2 = BASE + 2 A3 = BASE + 3 wiringpi.wiringPiSetup() wiringpi.pcf8591Setup(BASE, Address) while True: value = wiringpi.analogRead(A1) print("A１:" + str(value)) wiringpi.delay(500) |
キット付属の照度センサーとかも指定するpinを変えるだけで取れました。ただ、照度センサーの場合はキット付属の３種の抵抗から１つを使用するのですが、３種の違いが見た目で解らず、配線が厄介です。
使えそうなセンサーの値が取れるようになったので、これらを定期的にAWS Iotにpublishする事で最適な水やりタイミングを分析出来るようにしてみました。データはCSV形式でこんな感じです。
2020-04-19 00:05:11.97121800,19.3,49.0,134,254
データは、日時、温度、湿度、土壌水位、照度をAWS Athenaのクエリーで取れるようにしておきます。
Athenaでは、日時をtimestamp型にする場合、ミリ秒を8桁にしないとデータとして認識しないようなので、無理やりゼロを付けてます。ただ、AthenaではタイムゾーンをJSTとして扱うのが面倒な感じなので、無理にtimestamp型にしなくてもよかったかも？
なお、AWS IOTからS3バケットへの格納するキーは、
${clientid()}/${parse_time("yyyyMM", timestamp(), "Asia/Tokyo")}/${parse_time("dd", timestamp(), "Asia/Tokyo")}/${timestamp()}.csv
のように年月と日付をディレクトリにして、あとでログ管理をしやすくしておきます。ま、この程度ならS3もAthenaも当面コストほとんどゼロでいけるでしょう。
これで各センサーの値によって水やりを制御する形が大体出来てきました。が、最後に肝心な水やり制御方法をどうするかについては、まだ検討中です。。
自動水やりを目指して購入したRaspberryPi4ですが、今回の目的に使えそうな下記のキットを購入しました。
LABISTS Raspberry4のケースには合わないですが、とりあえず、GPIO-PCF8591 Shieldを取り付けて、使用するパーツを指してみます。
最初に、サーボを試してみます。KEYSTUDIOのサイトですが、C言語ですね。。お久しぶりです。pythonでやりたいところですが、まずは動作確認でキットのサイトにあるコードをそのままやってみます。下記はMakefileです。
Servo:Servo.o
gcc Servo.c -o Servo -lwiringPi
Makefileのタブが曲者ですね。
pi@raspberrypi:~/lesson/19 $ ls
Makefile Servo.c
pi@raspberrypi:~/lesson/19 $ make
cc -c -o Servo.o Servo.c
gcc Servo.c -o Servo -lwiringPi
pi@raspberrypi:~/lesson/19 $ ls
Makefile Servo Servo.c Servo.o
コンパイル出来たようです。
pi@raspberrypi:~/lesson/19 $ sudo ./Servo
、、、うんともすんとも動きませんね。。。
pi@raspberrypi:~/lesson/19 $ gpio readall
Oops - unable to determine board type... model: 17
gpioが使えていないようです。インストールはされているようですが、
pi@raspberrypi:~/lesson/19 $ dpkg -l wiringpi
要望=(U)不明/(I)インストール/(R)削除/(P)完全削除/(H)保持
| 状態=(N)無/(I)インストール済/(C)設定/(U)展開/(F)設定失敗/(H)半インストール/(W)
|/ エラー?=(空欄)無/(R)要再インストール (状態,エラーの大文字=異常)
||/ 名前 バージョン アーキテクチ 説明
+++-==============-============-============-===================================
ii wiringpi 2.50 armhf The wiringPi libraries, headers and
どうやら、バージョンが対応していないようです。コチラを参考にさせて頂き、バージョンアップしてみます。
pi@raspberrypi:~/lesson/19 $ gpio readall
+-----+-----+---------+------+---+---Pi 4B--+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| | | 3.3v | | | 1 || 2 | | | 5v | | |
| 2 | 8 | SDA.1 | IN | 1 | 3 || 4 | | | 5v | | |
| 3 | 9 | SCL.1 | IN | 1 | 5 || 6 | | | 0v | | |
| 4 | 7 | GPIO. 7 | IN | 1 | 7 || 8 | 1 | IN | TxD | 15 | 14 |
| | | 0v | | | 9 || 10 | 1 | IN | RxD | 16 | 15 |
| 17 | 0 | GPIO. 0 | IN | 0 | 11 || 12 | 0 | IN | GPIO. 1 | 1 | 18 |
| 27 | 2 | GPIO. 2 | IN | 0 | 13 || 14 | | | 0v | | |
| 22 | 3 | GPIO. 3 | IN | 0 | 15 || 16 | 0 | IN | GPIO. 4 | 4 | 23 |
| | | 3.3v | | | 17 || 18 | 0 | IN | GPIO. 5 | 5 | 24 |
| 10 | 12 | MOSI | IN | 0 | 19 || 20 | | | 0v | | |
| 9 | 13 | MISO | IN | 0 | 21 || 22 | 0 | IN | GPIO. 6 | 6 | 25 |
| 11 | 14 | SCLK | IN | 0 | 23 || 24 | 1 | IN | CE0 | 10 | 8 |
| | | 0v | | | 25 || 26 | 1 | IN | CE1 | 11 | 7 |
| 0 | 30 | SDA.0 | IN | 1 | 27 || 28 | 1 | IN | SCL.0 | 31 | 1 |
| 5 | 21 | GPIO.21 | IN | 1 | 29 || 30 | | | 0v | | |
| 6 | 22 | GPIO.22 | IN | 1 | 31 || 32 | 0 | IN | GPIO.26 | 26 | 12 |
| 13 | 23 | GPIO.23 | IN | 0 | 33 || 34 | | | 0v | | |
| 19 | 24 | GPIO.24 | IN | 0 | 35 || 36 | 0 | IN | GPIO.27 | 27 | 16 |
| 26 | 25 | GPIO.25 | IN | 0 | 37 || 38 | 0 | IN | GPIO.28 | 28 | 20 |
| | | 0v | | | 39 || 40 | 0 | IN | GPIO.29 | 29 | 21 |
+-----+-----+---------+------+---+----++----+---+------+---------+-----+-----+
| BCM | wPi | Name | Mode | V | Physical | V | Mode | Name | wPi | BCM |
+-----+-----+---------+------+---+---Pi 4B--+---+------+---------+-----+-----+
Cのサンプルが動くようになりました。
Cのコードをそのまま、pythonに書き換えます。
|
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 |
import time import wiringpi as w #Define INPUT=0 OUTPUT=1 HIGH=1 LOW=0 w.wiringPiSetup() w.pinMode(1,OUTPUT) while 1: for i in range(50): w.digitalWrite(1,HIGH) time.sleep(1000 / 1000000.) w.digitalWrite(1,LOW) time.sleep(19 / 1000.) time.sleep(1) for i in range(50): w.digitalWrite(1,HIGH) time.sleep(2000 / 1000000.) w.digitalWrite(1,LOW) time.sleep(18 / 1000.) time.sleep(1) |
pi@raspberrypi:~ $ sudo python3 Servo.py
Traceback (most recent call last):
File "Servo.py", line 2, in
import wiringpi as w
ModuleNotFoundError: No module named 'wiringpi'
ライブラリが足りてませんでした。。
pi@raspberrypi:~ $ pip3 install wiringpi
Looking in indexes: https://pypi.org/simple, https://www.piwheels.org/simple
Collecting wiringpi
Downloading https://files.pythonhosted.org/packages/06/bf/7c4ec17172f72917707dddeacfa02eae80b56ad3b7b5674a4258e62b2f5a/wiringpi-2.60.0-cp37-cp37m-linux_armv7l.whl (285kB)
100% |????????????????????????????????| 286kB 495kB/s
Installing collected packages: wiringpi
Successfully installed wiringpi-2.60.0
実行してみます
pi@raspberrypi:~ $ python3 Servo.py
お、カチャカチャと動きだしました。細かい制御は難しそうなので後回しに、、
次は温度・湿度センサーです。
ここ数年、ベランダで育てている野菜等を今年こそまともに収穫したいなあと、水やり自動化を検討していました。
いろいろネットをみていると、arduinoやRaspberry Piで実現している例が多数あり、拡張性が高そうだし、仕事ではあまり使う機会が無いPythonの学習にもなるかとRaspberry Pi4でやってみようと、こちらがちょっと安くなっていたので買ってみました。
到着後、ボードをケースにねじ止めし、ヒートシンクを張り、OS入りのSDメモリを指し、USBキーボードを接続、有線LANを指し、HDMIでテレビに接続、電源を入れただけで簡単にデスクトップが表示されました。
普通にサクサク動くパソコンです。ただ、ファンのピンの指し方が間違っているのか壊れているのか動きません。。
今回の目的としてはベランダにラズパイを置く事になるのですが、残念ながらベランダにコンセントはありません。そこで、まずモバイルバッテリーでどの程度稼働するのかを確認してみました。デスクトップから無線LANの設定をして、BluetoothはOff、デスクトップは使わないのでCLIのみに設定し、VNCサーバは起動しないようにして、以後は別のPCからSSHでログインして操作する形にします。
適当に10分おきにログ出力するpythonを書いて、何年も使っているダンボーのモバイルバッテリー 10400mAh で確認した結果、750分＝12時間30分でした。HDMI出力オフ（tvserviceコマンド）すると、さらに100分持ちましたが、これではどうにもなりません。水やりが自動化されても、毎日バッテリー変えていたら本末転倒ですし、、
色々調べましたが、モバイルバッテリーでラズパイをほぼ常時動作させるのは、ほぼ無理っぽいです。素直にベランダへコンセントを通すしか手は無いですね。
