ESP32でマイクロ波近接センサをロギング

ESP32はしばらく放置している間にすごく使いやすくなっていたので、調子に乗って、以前買ったESP32 DevKitCOLEDモジュールをつけて、ドップラーセンサーモジュールで壁越しに動体検知するのにチャレンジしてみました。

開発はArduino環境で行いました。無線LANの初期化やNTPでの時刻同期、OLEDの表示に関する部分、Webサーバーに関する部分はT-Cameraのソースをベースに不要な部分を削除して用意しました。

今回使用したセンサはUARTで通信します。ESP32にはUARTが3つあり、1つはPC(Arduino IDE)との通信用となっていますので、残り2つが利用可能です。今回はUART1の送信を16ピン、受信を17ピンに割り当てて使用しました。

で初期化しました。

受け取ったセンサ情報は接近時、離別時、停止時の3つのパターンがありますが、それぞれ毎分0秒を境界とした1分毎、毎時0分を境界とした1時間毎に発生数を計数して Chart.js を用いてグラフ化してみました。

 

Google Cloud Print Connectorを設定

これまでAndoidから印刷するのに、わざわざGoogle DriveかGmail経由でLinux Mint側にファイルを持ってきて、それから印刷していたのですが、これが面倒なので、Google Cloud Printが使えるように設定してみます。
プリンタはBrother HL-2240DでLinuxMint19のPCにUSBで接続しています。

1.インストールと設定ファイル生成

まずはSynapticパッケージマネージャで「google-cloud-print-connector」をインストールして、引き続き設定ファイルを生成します。

ローカル印刷は引き続き使うので「Yes」を入力

クラウドプリントを使うので「Yes」を入力

ここでGoogle Chromeを起動して、https://www.google.com/device にアクセスするとGoogleアカウントの認証を求められるので認証ログイン。さらに、コードの入力に移るので、上記のコード(XXXX-XXXX)を入力。入力すると、コンソール画面が進んで、使わせたいユーザーの

Google Cloud Printを使いたいユーザーのメールアドレスをカンマ区切りで入力

入力すると設定ファイルが生成されたことが表示されます。

2.動作テスト

試しに動かしてみます。

Android側では「クラウド プリント」をインストールします。

インストールされた状態でアプリケーションのメニューで「印刷」を選択して、「プリンタの選択」でLinux側でCUPSで管理されているプリンタを選択して、プリンタのアイコンをタップすると印刷できました。

3.自動起動の設定

cloud-print-connector というユーザー/グループを作成します。ホームディレクトリは不要、ログインしないのでログインシェルも不要です。

実行ファイルへのシンボリックリンクを作成します。

設定ファイルを /opt/cloud-print-connector にコピーして適切な権限を付けます。

systemd のサービスファイルをダウンロードしてインストールします。

Google Cloud Print CUPS Connector serviceを許可してスタートします。

停止する場合は、

とします。

静的サイトジェネレータHugoを試してみた

このサイトは編集をいつでもどこでも簡単にできるようにWordPressで作成していますが、内容を固定したサイトの場合には、WordPressで作成すると定期的にアップデートが必要となるので結構管理が面倒です。(それでも、WordPressはセキュリティアップデートは勝手にやってくれるので、だいぶ楽ですが)

また、プラグインやテーマもちょっとマイナーなものを入れると、本体のアップデートについていけず、結構悩むことになります。

で、最近知ったのが静的サイトジェネレータというもので、マークダウン言語で書いた記事をHTMLとCSSに変換してくれるものだそうです。HTMLとCSSだけでデータベースなどはないのでセキュリティ上の心配も少なくて済むようです。で、変換したHTMLとCSSをまるごとサーバ上にアップロードすればOK(実際には同期するのかもしれませんが)ということらしいです。

今回はその静的サイトジェネレータの中からHugoというのを試してみることにしました。

1.Hugoの環境構築

今回は諸般の事情から、素のUbuntu18.04LTS環境に導入してみます。Hugoで検索すると、WindowsかMacOSのものが大部分で、Linux環境の場合にはどういうわけか(探し方が悪いのか)古いものしか見つかりません。どうせなら最新版をインストールしたいところです。そこで参考にしたのは一つ目はこちらの記事です。何はともあれ、参考にしながら最新版をgithubからダウンロードしてインストールしてみます。

下記手順で素のUbuntu18.04LTSに対してアップデートとVirtualBoxのGuest Addtionsのインストールを行った後、Hugoのバイナリパッケージをインストールします。
※今後の再テストを短時間で行うため、VirtualBoxのディスクイメージのスナップショットも採取しています。

2.新しいサイトの作成

3.新しいページの作成

以下の方法で新しいページを作成します。

実際にやってみます。

として、contentディレクトリの下のpostディレクトリの下に記事を生成します。生成したら、自動生成されたファイルcontent/post/test-page.md を編集します。冒頭の draft: の行は削除します。(この行があると、記事が生成されません)

4.テーマをダウンロード

テーマをダウンロードします。ここでは試しに mainroad というのを使ってみます。

mainroadというテーマを使うために、config.toml に

を書き足します。

5.サイトを生成してみる

で、publicというディレクトリが生成されて中にデータが生成されます。

で組み込みサーバーが起動するようです。http://localhost:1313/ でインデックスページにアクセスできますが、かなり質素です(mainroadというテーマはこんなに質素じゃないはずなので要調査)。Ctrl+C で停止できます。

このまま、

として、もう1ページを作成、content/post/sample.md を編集します。冒頭の draft: の行は削除しつつ適当に内容を作成すると、自動的にブラウザで開いていた記事のリストが更新されます。

記事を一通り作成したら、publicディレクトリを丸ごとWebサーバにアップロードすることで、公開完了、ということみたいです。(実際には rsync などで同期を取る形で運用するのが楽なのだと思います)

6.参考になりそうなもの

WordPressのテーマ変更

これまで、このサイトのテーマは初めてWordPressを使った際に選んだテーマをPHPのバージョンアップに伴う不具合とかを手直ししつつ使ってきたのですが、さすがに今の世の中、スマホやタブレットでサイトを見る機会が増えてきていて、レスポンシブデザインへの対応をしたいなー、と思うようになりました。

しかし、元のデザインを自力でレスポンシブデザイン対応させるようなスキルもないので、ついにテーマ変更することにしました。で、新しいテーマはできるだけ長くサポートされるであろう、標準のテーマのうち、レスポンシブデザインに対応しているもの・・・ということで、TwentySeventeenにしました・・・が、TwentySeventeenはそのままだとアクセスするとどどーんと画像が表示されてしまうので、こちらのサイトを参考に控えめに表示されるようにしました。

変更箇所は、テーマの中のfunctions.phpの最後に、以下の記述を追加して UTF-8 で保存しました。もう少しデザインはカスタマイズすると思いますが、とりあえずレスポンシブデザインになったのでよしとします。

・・・が、何も考えずにテーマ自体のfunctions.phpを編集してしまうと、テーマがバージョンアップしたときに元に戻ってしまうようです。なので、子テーマを作って、そちらの funcions.php を編集しました。

子テーマは、サーバ上のテーマディレクトリと同じ階層に子テーマのディレクトリ(twentyseventeen-child)を作って、そこに必要なファイルを置きます。

一つは、functions.php で、以下の内容です。実際には、上記の内容も後ろに書き足して、UTF-8で保存しました。

もう一つは、style.css で、以下の内容です。

ここに、こちらのサイトの記事の内容そのまま(ありがとうございます!)ですが、

を後ろに書き足して元のテーマでは狭くて読みにくい記事の幅を広げてみました。

さらに、記事の見出しと記事内の見出しがともにh3で同じサイズで表示されてして醜いところがありましたので、あちこち参考にさせてもらいながら、style.css に

を追加して記事のタイトルに装飾をつけてみました。

今しばらくはデザインがいろいろ変わるかもしれませんが、ご容赦を(笑)

サイトのSSL対応化

さくらのレンタルサーバの資料をみていたら、Let’s Encryptを使ったSSL化が簡単にできることがわかりました。

・・・といっても、本当に簡単で、マニュアルに沿って作業するだけです。CLIも必要なく、GUIだけで適用できました。

1.SSL設定の有効化と確認

マニュアル(『【無料SSL】サーバコントロールパネルからの導入手順』)に沿って作業するだけです。気をつけるとすると、マニュアル内にも書いてありますが、発行完了のメールが来るのに多少時間がかかります。15分くらいかかったでしょうか。ま、そんなレベルです。

2.WordPressでの常時SSL有効化プラグインの導入

さくらのレンタルサーバ専用の常時SSL有効化プラグインを導入して有効化します。これも、マニュアル(『【WordPress】常時SSL化プラグインの使い方』)に沿って作業するだけです。
これだけでサイトがSSL対応できちゃいました。

サーバのPHPのバージョンを推奨バージョンに戻す

WordPressの引っ越しを行った際に、PHPのVer7系だと記事が表示されない現象があり、Ver5系に変更したのですが、その後調べてみるとWordPress自体はPHPのVer7系に対応していることがわかりました。さらに調べていくと、テーマやプラグインがPHPのVer7系に対応していないケースで発生することがわかってきました。

セキュリティ面では最新のバージョンを使うに越したことはないので、なんとかならないか調べていたところ、PHP Compatibility ChekerというWordPressのプラグインを使うと問題点のチェックができることがわかったので、インストールして確認してみました。

その結果、やはりテーマやプラグインに問題があるものが見つかりました。プラグインの出力するレポートにどのファイルの何行目がNGが記載されていますので、これを順に見ていくことにします。

テーマについては、式の評価の部分がPHPのバージョンによって差があるところが検知されましたので、これをPHPのバージョンに関わらず同じ評価になるように{}を追加しました。具体的には、

という記述をすると、PHP5では、

と解釈されるのですが、PHP7では、

と解釈されるようです。(参考:http://php.net/manual/en/migration70.incompatible.php)
そこで、この$$が2つ続く箇所については{}を追加して、常にPHP5と同じ解釈になるように修正しました。

他には、

  • Throws SPAM Awayというプラグイン
    セキュリティ上の課題で変更になった関数(spilt() ⇒ preg_split())の単純な置き換え
  • WP SyntaxHighlighterというプラグイン
    MySQLサーバのバージョン取得の関数(mysql_get_server_info() ⇒ mysqli_get_server_info())の単純な置き換え

を行いました。
また、使用していないプラグインについては停止・削除を行いました。

一通りの整理を行った後、再度チェックをかけるとエラーはなくなったので、PHPのバージョンをさくらのレンタルサーバで標準の7系にしたところ、それでもきちんと表示できるようになりました。

これとは別に、Crayon Syntax Highlighterというコードをきれいに表示してくれるプラグインが入っていたのですが、停止していました。その理由は、記号が化けてしまうからだったのですが、今回、ぐぐってみたところ、Crayon Syntax HighlighterのSettingの中のCodeのセクションにある「Decode HTML entities in code」にチェックを入れると治ったので、逆に有効化してあります。

WordPressの引っ越し&ドメイン変更作業

これまでドメインキングとさくらのVPSの組み合わせで運用してきた当ページですが、元々VPSの運用が面倒臭くなっていたし、CentOS6.5もサポート終了があと2年半くらいまで迫っていたのでどうしようかなー、と思っていたところにドメインキングの大幅値上げ(確か100円/月⇒500円/月)の話が来たので、この機に環境を一新することにしました。ドメインキングの値上げは Plesk の一方的な値上げという話だったと思いますが、さすがに5倍となると看過できません。12月の次回支払い時期の前に移行することにしました。

で、元の構成はドメインキングでドメイン(+Webサーバもあるけど使ってない)取得、サーバはさくらのVPS(1Gプラン)上にCentOS6.5という組み合わせでした。

移行後の構成は、新しいドメインを .tokyo ドメインで取得、サーバはアップデート管理の手間を省きたいので共用レンタルサーバ(さくらのレンタルサーバスタンダード)としました。まあ、CentOS6.5でも自動アップデートを有効にしていたので、それほど手間ではなかったのですが、移行後の構築の手間も考えるとレンタルサーバでいいか、ということにしました。

で、移行自体は半日くらいで終わったのですが、せっかくなので作業手順のメモを残しておきたいと思います。

1.Wordpressのデータバックアップ

旧サーバー(VPS)上でWordPressのデータのバックアップを取ります。

2.データベースのバックアップ

次に、phpMyAdminを使ってデータベースのバックアップを行います。バックアップの方法は『【WordPress】さくらインターネットに移転(引越し)する方法』を参考にさせていただきました。

3.さくらのレンタルサーバ(スタンダード)の契約

契約できたら、サーバパスワードの変更を行います。メールで仮パスワードが送られてくるので、これを変更。変更後は、初期ドメイン名でsshログインできるようになります。

4.お名前.com で新ドメインの契約

手順は・・・・省略。whois代行があるのがいいですよね。あと、インフレ気味ですが、いろんなドメインがあるとことか。

5.お名前.comで取得したドメインをさくらのレンタルサーバで使用する設定を行う

基本的な流れとしては、さくらのレンタルサーバのサーバコントロールパネルで、「新しいドメインの追加」を行い、新しいドメインとレンタルサーバ上のディレクトリとの紐付けを行います。紐付けるディレクトリは別途作成が必要です。
その後で、お名前.com側のドメインNaviで対象のドメインで使用するネームサーバーをさくらインターネット側で指定されたネームサーバに変更します。
実施にあたっては『お名前.comで取得したドメインをさくらサーバーで使用する』を参考にさせていただきました。

6.さくら上でデータベースの復元

データベースの復元はサーバにログインしてシェル上で行いました。シェルが使えるなら、その方がずっと楽で簡単で一瞬で終わります。

方法は、『MySQL/MariaDB コマンドを使った復元』を参考にさせていただきました。

7.ドメイン変更に伴うデータベースの修正

今回はドメインの変更を伴っていますので、WordPressの中のデータも修正しないといけません。そのためのツールがあるようで、『WordPressのサーバー移行_ドメイン変更の手順』を参考に、Search and Replace for WordPress Databases を使って新サーバー上でURLの置き換えを行いました。

8.PHPのバージョンを5系に下げた

アクセスしてみると、記事の本文が表示されない現象に悩まされました。ぐぐってみると、PHPのバージョンによって起きることあるらしいことが判明。確かに旧サーバは5系、新サーバーはデフォルトでは7系になっていました。さくらのサーバコントロールパネルでバージョンを7系から5系に下げたところ、本文が表示されるようになり、一通りの問題は解決したようです。

9.バックアップ用のシェルスクリプトの作成

データとデータベースのバックアップをするスクリプトを書いておきました。時々走らせようと思います。

10.旧サーバーからのリダイレクトの設定

旧サーバーはドメインキングのDNSサーバー設定でさくらのVPSのIPアドレスを返していました。
できれば、さっさとさくらのVPSは解約したいので、ドメインキングのサーバ上に .htaccess を置いて、リダイレクトさせることにしました。

<.htaccessの内容>

.htaccessを設置したら、DNSの設定を変更します。設定の中から

のレコードを削除します。

あとは、DNS情報が行き渡るのを待ちます。

MongoDBについて調べてみた

いろいろあって、MongoDBについて調べてます。

調べた結果をメモしておきます。

WordPressでログインできなくなった!

WordPressでログイン認証のセキュリティ強化にCAPTCHAを入れようと、プラグインから「SI CAPTCHA Anti-Spam」をインストールしてみました。

設定でログイン画面にキャプチャを入れて、ログアウトしてログインしなおしたらCAPTCHAが表示されていません(!)。

しかも、ログインできない!!

で、調べてみると、「SI CAPTCHA Anti-Spam」には、GDというライブラリが必要なので、

としてインストールを試みるも、さくらのVPSにインストールしたPHPのバージョンが合わずphp-gdがインストールができません。

で、四苦八苦した挙句の解決方法は、「プラグインディレクトリの名前を一時的に変更する」という方法でした。

/home/(ユーザー名)/public_html/wordpress/wp-contents/plugins にカレントディレクトリを変更して、プラグインの名前の付いたディレクトリの名前を一時的に変更してやると、無事にログインできました。

ログインしたら、ディレクトリの名前を元に戻して、プラグインを停止・削除しました。

いや、焦りました・・(^^;