Delphi/C++BuilderでFireDACによるデータベースアクセスが遅いと感じたときはUnidirectional=Trueにしてみる
FireDACはハイパフォーマンスデータアクセスライブラリと言われているのですが、データベースから取得したデータをコードで処理する場合に、あんまり速く感じないことがあります。
そのような場合に FDQuery の FetchOption を調整して、読み取り専用アクセスにするとパフォーマンスが改善する場合があります。FireDACはデフォルトで双方向データセットなのですが、読み取り専用にすることで select クエリ実行時の性能を上げる、というアプローチです。
下記ページでは CursorKind, Mode, RowsetSize, Unidirectional の４つを設定するという説明がありますが、割と効き目が強そうなのは Unidirectional だと感じました。
今は手元は数万件オーダーの試験データしかなく、実測値のよいサンプルがないのですが、Unidirectional がデフォルト（False）の場合は dbExpress に比べてパフォーマンスが悪く、Unidirectional = True に設定すると dbExpress よりも良いパフォーマンスが出るように感じます。
これについては David Intersimone の下記記事も参考になると思います。
ただし、この方法が有効なのは、あくまでデータをコードで処理する場合です。でータセットを TDBGrid などで扱う用途向けではありません。
テレビやエアコン、照明器具を自動コントロールするためにSwitchBotを導入する
スマートリモコンがあるといろいろ便利になりますが、なにがどのように便利になるかは、案外イメージしづらいような気がします。
実は1年前から自宅にSwitchBot製品を導入し始めたのですが、自分的にはとてもニーズに合っていたので、使用感を含めてまとめてみようと思いました。
自分がやりたいと思っている制御
基本的には、こういうことを実現したいと考えていました。
- 帰宅したら音声コントロールで部屋の照明やテレビを自動でつける
- 部屋の照明を朝の起床時につけて家を出る時刻に自動で消す
- 帰宅前に室温が暑すぎたり寒すぎたりしたら自動でエアコンを点ける
- 防犯対策として、長期不在のときに指定時刻で照明をOn/Offして、在宅のように見せる
SwitchBot導入前に買っていたデバイス
2018年6月までに以下の組み合わせを揃えていました。
- eRemote mini の海外版
- TP-Link スマートプラグ HS105
- Amazon Echo dot
- Kindle FireHD 10 (2017年モデル)
eRemote miniは赤外線リモコン対応機器を操作するためのスマートリモコンで、比較的早い時期にスマートリモコン導入を考えた方の選択肢の一つだったと思います。 TP-Linkは壁コンセントと機器の電源ケーブルの間につけるタップ型のスマートプラグで、機器のOn/Offが制御できます。これはエアコンを使うまでもない時期に換気扇のOn/Offで空調コントロールをさせることを考えて導入しました。
ただし、この組み合わせは、最低限の要件が満たせるだけでした。当然、個別のデバイスは制御できますが、タイマー連動させるのがやりにくい。
さらにeRemote mini で温度センサー連動させようとすると、単体のセンサーのお値段が高価すぎるし、温度センサーを内蔵した上位モデルのeRemoteはリモコンの場所の温度は測れるけど、どちらかというと温度調整したい場所の温度を知りたいので、センサー一体型は必ずしもニーズに合わないような気がしました。
また、そもそも eRemote mini の海外版を購入費用をケチって買っていたので、アプリを日本語で操作しようとすると、海外版は操作できないとか、本質的ではない問題もあって、この組み合わせはイマイチだなあと考えていました。
なぜ、Switchbotに変えることにしたのか？
もっとも大きい理由は「物理スイッチでしかOn/Offできない機器を制御したい」というものです。
今の自宅で使っている照明器具はリモコンがなく、壁スイッチでのOn/Offか、または引きひもを引っ張る必要があります。しかしSwitchBotスイッチは壁スイッチをOn/Offできる仕組みがあるので、照明器具を買い換えることなしに操作できます。
そしてSwitchBotスイッチ単体ではBluetoothでの制御に対応していますが、AlexaやGoogle Homeなどとの対応をさせるための装置としてSwitchBot HubやSwitchBot Hub Plusが用意されていました。この2つの違いは、スマートリモコン機能の有無です（なお、2019年夏以降に、SwitchBot Hub Plusの外形をシンプルにしてライト機能を廃止して価格もお安くなったSwitchBot Hub miniがリリースされているので、これから買うならSwitchBot Hub miniでよいと思います）。
そこで SwitchBotスイッチと、スマートリモコン機能を持つSwitchBot Hub Plusをます購入して、壁スイッチによる照明の制御ができるようにして、テレビのOn/Off、エアコン制御を eRemote mini からリプレースしました。
この時点で実現できていないことは、温度に応じたエアコンの連動操作だけです。
2019年にSwitchBotから温湿度計、スマートプラグが順次リリースされたので追加購入した
SwitchBotスイッチとSwitchBot Hub Plusだけでは温度制御が行えないものの、壁スイッチ軽油の照明制御ができるようになったので、これだけでも相当に満足していました。
しかし、温湿度計とスマートプラグが2019年になって順次リリースされたので、こちらも早速導入しました。
これで、自分がやりたいと思っていることは、すべて実現できるようになりました。
温湿度計のメリットは、いうまでもなく、温度や湿度に応じて機器を操作できることです。
室温が高い、または低い時にエアコンのスイッチを入れることができれば、それだけでも大変便利ですね。例えば、朝起きる1時間前くらいに室温が適温じゃないときだけエアコンを付けられれば、朝起きたときに暑すぎたり寒すぎたりせず、いい感じに1日をスタートできます。
また、帰宅時間が概ね一定している場合は、帰宅の1時間前くらいに室温に応じてエアコンを制御しておけば、帰宅時には室温が快適な状態になっているはずです。
また、スマートプラグも地味に便利です。エアコンをつけるまでもないけど、空気くらいは循環させたいときに、温湿度計と連動して換気扇をOn/Offさせるようにしたり、あるいは扇風機自体のタイマーでは対応できないようなタイミングでのOn/Offができます。これだけならTP-Link HS105でも可能ですが、SwitchBotスマートプラグには消費電力量を集計する機能があり、1日単位の消費電力量がわかるようになっています。電力を無駄遣いしないということを考える時に、機器がどれくらい電力を消費しているかがわかるのは結構大事な気がします。個人的には1時間単位の積算値が見れたり、データをCSV形式などでエクスポートできたりするとワットチェッカーの代わりにも使えて良さそうな気もしますが、それは製品の本来の目的とは違いますね。。。
そんなわけで、結果的に eRemote mini, TP-Link HS105 で行なっていたことはSwitchBotの製品ラインナップにすべて置き換えることになりました。
すべてをSwitchBotにまとめたときのメリットとは？
スマートホーム化するときにさまざまなベンダーのものを組み合わせても悪くはないのですが、SwitchiBotですべてをまとめると、つぎのような点がメリットになると思います。
- スマートフォンからの操作は1つのアプリから完結できる
- 機器同士の連携がとりやすい
これらはもちろん、他のスマートリモコンでも言えることですが、そこそこ妥当な価格の温湿度計で機器制御できるのは、メリットが大きいと思います。
例えば、温度制御は室温だけではなく、外気温も考慮に入れて制御したい場合があると思います。室温だけでエアコン制御していると、外気温が適温な状態に入ったときにエアコンを切ることができませんが、温湿度計を屋外にもつけておけば、エアコンが不要な状態になったら切るような制御もできます（ただしSwitchBot温湿度計は屋外での利用を想定していないと思うので、これは自己責任で風雨の影響を受けないように設置する必要がありますが）。
設置の注意点は？
SwitchBotスイッチはBluetoothLEでスマートフォンやSwitchBot Hubと通信しますが、出荷時設定ではSwitchBotスイッチの制御にパスワードが設定されておらず、だれでも操作可能な状態です。このため、設置したら最初にパスワードを設定して、自分以外が操作できないようにしておきます。
SwitchBotに限らず、スマートホーム系の機器は設定が甘いといろんな問題が起きますので、普段使いのスマートフォンとは別のデバイスにも操作用のアプリをインストールしてみて、第三者が操作可能な状態になっていないかどうかを確かめておくと安心です。
ffmpegで動画ファイルのビットレートを落としてファイルサイズを軽くする
ある手順で発生する事象のエビデンスを動画キャプチャで作成したのですが、無駄にビットレートが高すぎてファイルサイズが大きいため、切り詰めるための加工を ffmpeg で行うことにしました。
とりあえず、こういうスクリプトにしてみました。
#!/bin/bash filename=$1 ffmpeg -i "${filename}" \ -c:v libx264 \ -b:v 1000k \ "${filename%.*}.stripped.mp4"
これをたとえば clbrv.sh のような名前にして clbrv.sh 動画ファイル名.mp4 のように実行すると 動画ファイル名.stripped.mp4 という名前でビットレートを下げた動画が生成されます。
ffmpeg に渡しているパラメータは以下の2つだけですのでいろいろ調整の余地はありますが、今のところは目的が達成できていて困っていません。
-c:v libx264 は出力動画のコーデックをH.264にする指定です。 -b:v 1000k は動画のビットレート指定。数値を小さくすれば出力ファイルサイズも当然小さくなりますが、その分品質も下がるので目的に合わせて要調整。
一組のキーボードとマウスでデスクトップPCとMacBookを操作するためにUSB2BT ADU2B02Pを試す
普段の作業ではデスクトップPCとMacBook Proを併用しているのですが、デスクトップPCのキーボードとマウスでそのままMacBook Proも操作できたら便利だなあと思い、USB2BT ADU2B02Pを試してみることにしました。
USB2BTシリーズには、接続先切替機能のない旧モデルADU2B01Pもありますが、今回試しているのは旧モデルではありません。
USB2BT ADU2B02Pの特徴
旧モデル同様に、キーボードやマウスなどの入力用デバイスをBluetoothで任意のPCやスマートフォン、タブレットに接続できるようにする変換アダプタです
旧モデルとは違い、3台までのデバイスに接続できるようになっています。
USBパススルーなどの接続形態もサポートしているため、デスクトップPCに接続していたキーボードやマウスにこれをつけるだけで別のPCやスマートフォン、タブレットも操作できるようになります。
どういう方に向くツールか？
間違いなく向いているのはこういう方向けです。
iOS, iPadOS アプリ開発のためにMacBookも使っている開発者
デスクトップPCをメインで使っているけど開発用にMacBookも使っているようなケースでは、iOS, iPadOS向けの作業を行うためにデスクトップ用キーボードから手を離してMacBookに向かうのは案外めんどくさいと思います。
でも、USB2BT ADU2B02P を使えば、普段使っているデスクトップ用キーボードとマウスでMacBookが操作できるようになります。
また、作成したiOS/iPadOSのテストのために文字入力を行う際にも、そのままUSB2BT ADU2B02Pが使えます。
実際の使用感
とりあえず、USBハブ経由でキーボードとトラックボールを接続した上で、MacBook, iPhone8plus (iOS13)、iPad Pro 12.9 (iPadOS 13)の3つに接続してみました。
軽く試した範囲では、大きな問題なくMacBook, iPhone8plus, iPad Pro 12.9 を操作できました。
ただしキーボードの切替（英数、日本語）のような操作がそれぞれのOSでサポートされる方法が違うので、そこは慣れが必要な感じです。
USB2BT ADU2B02P を使わない場合の解決方法
既存のキーボードやマウスをBluetoothで他デバイスに接続することが目的なら、他の解決策はあんまりなさそうです。Raspberry Pi Zero W をUSB-Bluetooth変換ブリッジにするという方法も一応あるようですが、日本語で見つけた情報はキーボードまたはマウスのどちらかをBluetoothで他デバイスに接続する、という話だったので、キーボートとマウスの両方をサポートできるかどうかは不明です。
WindowsとMacBookでのキーボード共有だけができれば良いなら、英語キーボードをお使いの方はhttps://symless.com/synergyが使えると思います。日本語キーボードだといろいろ行き届かない部分が多いので、いまいち使えないかもしれません。
あるいは、J5 create の Wormhole Switchという選択肢もあります。
Sufrace Go 64GB を出荷時構成に戻す
Surface Go でWindows Updateの適用やWindows 10のバージョンによる挙動の違いを確認する必要が出たので、出荷時構成に戻すための方法を調べました。
出荷時構成に戻すために必要なもの
Surface Go 向けの回復イメージがマイクロソフトのウェブページで配布されていますので、これを入手します。 2019年9月時点ではWindows 10 1803, 1809 の２バージョンの回復イメージが入手可能でした。
ハードウェアのシリアル番号を入力すればダウンロードできます。
https://support.microsoft.com/ja-jp/surfacerecoveryimage
USBメモリに回復ドライブを作成する
- 16GB以上のUSBメモリを準備する
- Windows 10 が動作するPCで「回復ドライブ作成ツール」を実行する
- 「システムファイルを回復ドライブにバックアップします」のチェックを外して回復ドライブを作成する
- 作成した回復ドライブのUSBメモリに対して、ダウンロードした回復イメージのzipファイルの中身を上書きコピーする
https://support.microsoft.com/ja-jp/help/4023512/surface-creating-and-using-a-usb-recovery-drive
Surface Go をUSBデバイスから起動する
次の方法でブートオーダーを変更できます。
- 電源OFF状態で「音量を上げる」ボタンを押したままで電源ボタンを押す
- 電源が入ったら電源ボタンだけ離す
- WIndowsロゴが表示されなくなったら「音量を上げる」ボタンを離す
- [Boot configuration] より [USB Storage] を一番上にする
- [Exit] より [Restart Now] を選択する
より正確な方法は、下記のページで案内されています。
https://support.microsoft.com/ja-jp/help/4023511/surface-boot-surface-from-a-usb-device
Delphi/C++BuilderのFireDACでPostgreSQLを利用するためにodbcドライバをインストールする
FireDACでLinux上のPostgreSQLに接続する必要が出て、エンバカデロのオフィシャルなドキュメントを見てみたのですが、ドライバの入手方法が明示されていないのですね。
ドキュメントによると、たとえば 9.0 向けの場合は以下のファイルが必要、みたいなぼんやりした説明しかなされていない。
libpq.dll ssleay32.dll libeay32.dll libintl-8.dll libiconv-2.dll
そこでウェブ検索で調べてみると、ソースからビルドするだとか、個人の方のウェブページからのダウンロード方法が紹介されていたりとかで、いまいちオフィシャルなバイナリが見当たらないようでした。
しかし、もっとよく調べてみると、postgresql.org の下記ページで PostgreSQL 向けの Windows 向けODBC ドライバが配布されていることに気がつきました。
今回欲しいのはあくまで必須のDLLだけなのですが、このODBCドライバをインストールすると必要なDLLがインストールされるようです。これで、出どころが明らかなバイナリで PostgreSQL への接続が行えそうです。
Windows10のタブレットモードのときにアプリからタッチキーボードを強制的に表示させる
とりあえずのメモ書きです。
Surface Go で利用するアプリをDelphiでプロトタイプ的に作成していたら、タブレットモードのときに強制的にタッチキーボードを表示させたくなったのでしらべてみた。
ソフトウェアキーボードは２種類ある
昔ながらのオンスクリーンキーボードは osk.exe で起動します。
しかしWindows10 のタブレットモードではosk.exeではなくTabTip.exeが動作しているようです。
TEdit などの imeMode はosk.exeとtabtip.exeでは挙動が違うようだ
osk.exeの場合はimeModeによる制御は物理キーボードと同じように効くようだ。
しかしtabtip.exeの場合はimeDisableとそれ以外しか受け付けないように見える。
ソフトウェアキーボードを表示させたくなったらどうすればよいのか？
アプリケーションフォームへの onFocus でosk.exe と tabtip.exe のどちらも起動していないときに、使わせたいソフトウェアキーボードを起動すればよさそう。
WPFでの実装例がここにあるので、これを参考にしつつ実装すればよさげ。
