Linuxホットスポット検証のため USB WiFiデバイスをいくつか動作検証してみました

・ホットスポットの動作確認した環境はつぎのとおりです。これはLinuxで最初に動作確認できたLenovoのノートPC G570での操作をベースにしたGUI操作のみのチェック手順です。
HW:
・ Intel(R)   USB 3.1
・USB2.0
OS:
・ Windows10 バージョン 1903 OSビルド 18362.295
・ Linux Ubuntu 19.04

以下にそれぞれの仕様と各OSでの動作状況をまとめました。動作確認はインストール
[表中の記号の意味]
〇:上記OS で ドライバ等の追加インストールなしで利用可能
×: 上記OS で ドライバ等の追加インストールなしで利用不可
△: 上記OS で ドライバ等の追加インストールで利用可能。ドライバ無は×
▼: 上記OS で ドライバ等の追加インストールしても利用不可。 ドライバ無は×

型番TL-WN725NWDC-433DU2HBK802.IINPT-N330multibyte
写真
メーカTP-LINKELECOM Cangad Saikogoods
pinTOP
参考AmazonAmazonAmazonAmazonAmazon 写真と違う
金額700円
(送料630円)
2,389 円
(送料 0)
299円
(送料300円)*6
480円
(送料0)
¥398
(送料0)*6
インターフェイスUSB2.0USB2.0USB2.0USB2.0
周波数2.4GHz2.4GHz
5.2,5.3,5.6GHz
2.4GHz2.4GHz2.4GHz
伝送方式11b/g/n11ac,11a,
11b/g/n
11b/g/n11n? 11b/g/n
送信出力10mW/MHz以下
Win10 子機 〇 *7× *3
Win10 HotSpot〇*b〇*b 〇 *7*b× 〇 *b
Ubuntu 子機△ *2
Ubuntu HotSpot× *1▼ *2 *5〇*bx *4〇*b
Ubuntu hostapd×? *8×? *8
Ubuntu
使用ドライバ(チップ)
RTL8188euRTL8812au(RTL8188CU) Ralink MT7601U(RTL8188CU)

*1:HotSpot起動時にエラーが発生し、正常にHotSpotを起動できない。
*2: USBデバイスとは認識するが、WiFi機器と認識しない。(メーカサイトではLinux未対応) ドライバをmake インストールすることで認識
*3: mini-CDつき、インストールすれば使えるかもしれないが、保留。
*4: WiFiのHotSpotのメニューがグレーアウトされている。
*5:HotSpot起動操作で WARNログ( device (デバイス名): Activation: (wifi) Ad-Hoc network creation took too long, failing activation)を出して、起動に失敗する。
*6:配送に非常に時間(2、3週間)がかかった。発送元は台湾。
*7: mini-CDつきだが、使用しなくてもWin10で動作した。
*8:ドライバが未対応?

参考:以下はUSBモジュールではありませんが、参考のため動作確認した結果です。

型番G570
写真
メーカLenovo
周波数2.4GHz
伝送方式11b/g/n
送信出力? (比較的弱い)
Win10 子機
Win10 HotSpot〇 ※b
Ubuntu 子機
Ubuntu HotSpot〇 ※a
Ubuntu hostapd〇 ※b
Ubuntu
使用ドライバ
AR9285

※a:Ad-Hocモードで動作する。
※b:Infraモードで動作する。

スマートスピーカーがあればいらなくなるもの

一気に普及が進みそうな気がしていたスマ―トスピーカーだが、あまり普及が進んでいない感じがする。利用方法や活用方法がまだまだ整備できていないことが原因かもしれないが、なんといっても使い方があまり知られていないことが原因ではないだろうか。

今回は、スマートスピーカー単体で既存製品の機能を代替できるものについて書きます。つまり、スマートスピーカーさえあれば必要でなくなる既存製品のことです。そしてそれぞれのメリット・デメリットと既存製品が生き残るために取りうる選択肢を考えてみます。

 まず、スマートスピーカーが代替可能な領域です。最近はディスプレイ (タッチパネル) 付きのものも出てきているのでそれも対象にします。スマートスピーカーのインターフェイスの出力は音のみです。ディスプレイ付きのものは映像出力も可能です。入力は、音、タッチパネル操作、そしてインターネット上の情報です。インターネット上の情報はあまりにも広く絞り切れないので、入力側は考慮しないことにします。それから出力先としてインターネットが可能と考えることもできます。これは、あとで考慮することにします。
 出力が、音か、音と映像のみの既存製品とは何があるでしょうか?それらが、スマートスピーカーによって置き換えられる可能性がある既存製品です。ざっと上げると、タイマー、時計、ラジオ、などです。

■タイマー、時計
 ・ スマートスピーカー のほうは複数同時にタイマーが設定できるとか、スケジュールに連携とか可能です。
 ・「タイマー」については特にメリットが思いつきません。電源がなくても使えるというくらいです。スマートスピーカーの「xx分タイマー」の使い方を体験すると、時間を指定したうえでスタートボタンを押すなど操作が煩雑と感じるでしょう。

■ラジオ
 ・電波状態を気にすることなく明瞭な音で聞くことができます。録音に相当するタイムフリー機能が提供されていないことと、他の都道府県の局は受信制限がかかっている点は何とかしたいところですが、ラジオでも他県の電波を良質な音で聞けることはあまりないことを考えると不便とまでは言えないでしょう。

■以下にざっと挙げて、色分けしました。
青:すでにスマートスピーカー単体で代替できているもの。
黒:すでにスマートスピーカーと外部機器が連携して機能提供しているもの
赤:形を変えて対応しているもの

●楽器
●ウォークマン
●テレビ
●オーディオ製品、音響機器
●温度計、湿度計

●鏡
●カレンダー
●写真立て、フォトフレーム

●ゲーム、将棋盤
●新聞

●血圧計、体温計
●図鑑、本、辞書、電話帳、地図
●スキャナ
●ストップウォッチ
●スピーカ

●双眼鏡、望遠鏡
●そろばん
●体脂肪計、体重計
●タイプライター
●カメラ
●アルバム
●手帳
●電卓
●電話機

●投影機
●トランシーバー、無線機
●ノート、紙

●メガホン
●ラジオ、ラジカセ

上でざっと洗い出してみましたが、つぎのように漏れているものを見つけました。とくにスマートスピーカーで置き換えできそうなものです。まだまだピックアップし漏れたものがたくさんありそうです。電気製品の中に多いと思います。
・インターホン
ちなみに、インターホン相当の機能は私がグーグルに機能強化提案し2週間後くらいに密かにリリースされていました。私は、そのまえに「google home→googleアシスタント→IFTTT→node.js→google home」の流れでインターホン機能を実装できていました。

まだ十分とは言えませんが、スマートスピーカー単体で代替可能そうな機能はほぼ実装されています。使いにくいところは改善依頼をだして強化していけば、スマートスピーカーだけでのシンプルライフを送れそうです。

本格的なスマートホームへの移行までの対応例、SwitchBotでテレビをリセット

今回、紹介するのは取り付け作業に電気工事士などの資格が不要な製品です。物理的にスイッチ操作を行います。接着テープで貼り付けて、小さなサーボ機構でスイッチ部分を上下するので、 電灯のスイッチをON,OFFくらいならできます。コンセントなどにある電源スイッチの操作は厳しいでしょう。 しかし、資格が必要な作業が不要なので誰でも手軽に利用できます。まだまだ国内メーカ製のスマートスイッチは機種が少ないので、現状はSwitchBotを活用するシーンは多いでしょう。今後スマーススイッチが一般化していくことを考えれば、SwitchBotは過渡期の製品といえるでしょう。

SwitchBotは1回の操作で押すだけの操作、ONとOFFの動作、つまりワイドハンドルのスイッチの動作と、波型スイッチ(トグル)のON/OFFの動作の2つの動作モードがあります。工夫次第で、いろんな使い方ができそうです。

 テレビがハングアップしてしまいリモコン操作を受け付けなくなる事象が頻繁に発生して、そのたびにリセット操作をしていたので、SwitchBotにリセットボタンを押させるようにしてみました。下の写真がその取り付け例です。

SwitchBotのスイッチ部分にグルーガンで5mmほどの突起を作成して、リセットボタンを押せるように位置調整して取り付けました。
これに加えて、IFTTT連携、Google home連携も行いました。これにより、「ねぇ グーグル テレビをリセットして」というと、リセットボタンを押してくれます。

 SwitchBot自体はBluetoothで通信するので、SwitchBot単体ではスマートホンとかタブレットがないとうごきません。そこで、下のSwitchBotハブと組み合わせて使用します。

次のような構成で動作します

SwitchBot
  ↓ Bluetoothで通信
SwitchBotハブ
↓ WiFiで通信
無線LAN ルータ
↓ 光ケーブルや有線LANなど
インターネット

SwitchBotのサーバ ←→ IFTTTのサーバなど

最近は、SwicthBotハブプラスなども提供されているのでIFTTTの他のサービスと組み合わせるなどの工夫でもっと色々使えます。


 それから、気が付かないうちに録画機能だけハングアップしていて予約録画できていなかったこともありました。そこで、まず視聴や予約録画していなさそうな午前4時に毎日自動的にリセットするようにIFTTTのルールを作成しました。これにより、ハングアップ状態でずっと録画できないままという事象も回避できました。

話は、SwitchBot自体に戻りますが、 SwitchBot は内蔵の電池で動作します。最初は蓋の隙間から横に飛び出している絶縁ビニールを抜いて電源をいれます。電源を切る仕組みはありません。もちろん電池を抜けばよいのでしょうが普通に使うならそんなことはしないので入れっぱなしです。1日に1回か2回くらいの操作をして、1年くらいで電池が切れました。ちなみにほとんど使っていなくても1年くらいで電池が切れました。

中に入っている電池はつぎのようにCR2 Lithium Battery CR15H270 3Vです。電池が切れたときはこれを交換します。近くのホームセンターで1個 448円で交換用の電池を購入しました。

使うときは、電気交換のことも考えながら使ったほうがよさそうです。接着テープは一度剥がすと接着力が落ちるので、手が届きにくいとか、一度SwitchBotの本体をとりだす必要があるなど、いちど接着テープを剥がさないと電池交換できないような場所には不向きです。
  ただ、そういう場所にこそ使いたいかもしれません。

Windows10のリモートデスクトップのキーボード配置が変わった→これはWin10のバグ? とりあえず、暫定回避できました。→根本対処もできた??いやまだだめ,さらに暫定回避策

Windowsのバージョンアップで変わった?

Windows10のバージョンやOSビルド番号の確認方法はリンク先のサイトなどで確認してください。
Windows10はバージョンアップで、期待しない変更がときどきおこりますが、最近の変更では、使えなくなっていた機能が復活したものもありますが、期待しない動きをしているものもあります。

■対象バージョン
ローカル環境Win10;      バージョン1903 (OSビルド 18362.267)
リモートデスクトップ環境Win10;バージョン1809 (OSビルド17763.615)
リモートデスクトップ; バージョン10.1.1098.1000

■ 使えなくなっていた機能が復活したもの
 Windows8からWindows10にバージョンアップしたときは機能していたデバイスキャストの機能ですが、気が付かないうちに機能しなくなっていました。先日(2019年8月初旬?)のバージョンアップを契機にデバイスキャストの機能が復活したようです。
下のように、エクスプローラーで動画ファイルを右クリックして「デバイスキャスト」をポイントすると(多少時間がかかりますが)キャスト先のハードウェア下の場合はテレビが選択肢に現れます。テレビを選択すると動画をキャストできます。

■期待しない動き
対象の組み合わせで利用したときに、ローカルマシン上では、キーボードの配列を正しく認識しているが、リモートデスクトップ上のマシンでは異なるキーボード配列として認識されている状態に変わりました。きっかけが何かははっきりしませんが( 2019年8月11日の夜から12日 の間に発生)、Windows10のバージョンアップではないかと推測しています。タイミング的には、Windows10のバージョンアップによりリモートデスクトップの実装が変わったことと一致しています。以前は昔ながらのリモートデスクトップの画面でしたが、現在は下のようにWin10らしいアイコンに変わり、操作性もWin10のアプリケーションらしく変わっています。その辺は良いのですが問題はキーボード配置です。

”[”を入力したつもりなのに”@”だったり、”「”のつもりが”‘”だったり、主にアルファベットキーの右側のキー配列が変わっていました。これは”Microsoft Japan Windows Technology Support Windows 10 RS4 へのリモート デスクトップ接続時に、UWP アプリへの入力時のみキーボード配列が異なる事象について”とはとは事象が違うようです。 [Shift] + [2] キーを押した場合、Chrome上では ” (ダブルクォーテーション) が入力されます。この部分は正常だがアルファベットキーの右側部分たとえば、Lの右側は本来 ; (セミコロン)ですが、^ が入力されます。
ただこのページにヒントがあるような気がします。リモートデスクトップをウインドウ表示にして、キー入力モードを確認してみました。

上は、ローカルマシン上のエディタを操作しているときの画面で、IMEが有効な状態です。ここからリモートデスクトップを操作すると下のように、ローカルマシン側のIMEが無効状態に変わります。これが原因かどうかわかりませんが、確認中です。

■解決編(回避策)→下のほうも参照 8/15この回避策も使えなくなった
キーボード配列の認識状態は。MOOVOOサイトの確認方法ではローカル、リモートともにどちらも同じ”日本語キーボード(106/109キー)”です。この状況から問題は接続元の”リモートデスクトップ”と推測しています。と思ったらやっぱり、これまで使っていた”リモートデスクトップ接続”の実装は残っていました。

下のメニューからWindowsアクセサリ→”リモートデスクトップ接続”をクリックすると昔ながらのインターフェイスでリモートデスクトップ接続できます。この手順で接続するとリモートデスクトップのアイコンは上の緑のように昔ながらのアイコンで接続できます。これにより、キーボード配列も期待通りの動作ができます。

★この挙動からすると、Win10の新実装のバグというか、去年も発生した問題に類似していて、上で指摘したようにIMEの認識が絡んでいるように思われます。古い実装のリモートデスクトップにポイントすると下のようにIMEの部分が隠蔽されます。見ようとし”^”をクリックするとローカル側にフォーカスが当たるのでリモートデスクトップにフォーカスがある時にローカル側がどのような状態になっているかはわかりません。しかし、明らかに動きが違うので、ここが問題事象に絡んでいるのは間違いなさそうです。

お盆の時期なので、MSの調査や対処もとまっているかも、アメリカはお盆内から動いてうごいてほしいが…。 セキュリティパッチなら仕方がないが、この時期に機能変更のパッチを出さないでほしい。ま、とりあえず古い実装で回避できたので何とかなりますが、早く新しい実装を修正してほしい。そして、このままの状態で古い実装を消すなんてことをしないでほしい。

■根本対処も完了??(2019/8/14夜時点)
 Windowsがまた更新されました。下のとおり、リモート側のWinodws10が更新されていました。ローカル側は変更ありません。この環境でキーモード配列の問題は解消していました。

更新前;
リモートデスクトップ環境Win10;バージョン1809 (OSビルド17763.615)
    ↓
更新後;
リモートデスクトップ環境Win10;バージョン1809 (OSビルド17763.678)  

■またダメになった。今度は回避策も効かない(2019/8/15 10:00ころ)
2019/8/14夜時点
ローカル環境Win10;      バージョン1903 (OSビルド 18362.267)
リモートデスクトップ環境Win10;バージョン1809 (OSビルド17763.678)
リモートデスクトップ; バージョン10.1.1098.1000
  ↓
2019/8/15 10:20ころ
ローカル環境Win10;      バージョン1903 (OSビルド 18362.295)
リモートデスクトップ環境Win10;バージョン1809 (OSビルド17763.678)
リモートデスクトップ; バージョン10.1.1098.1000


酷すぎます。なんてことをしてくれるんでしょう。もっとちゃんとテストしてから修正パッチをリリースしてほしい。
今度は、2018/9と同じ症状に見えます。 2+shiftでダブルクオーテーションになるべきところ@アットマークになるパターンで、キー配列が入れ変わっています。 この挙動は新しいリモートデスククトップ、古いリモートデスクトップの両方で発生します。今のところ回避策ない。。。 私の場合、左に置いてあるiPadの英語キーボードを見ながら脳内キー変換するしかなさそうだが、めちゃくちゃ効率が悪い。何とかならないか?
面倒ですが、なんとか回避策を確認できました。 ”Microsoft Japan Windows Technology Support Windows 10 RS4 へのリモート デスクトップ接続時に、UWP アプリへの入力時のみキーボード配列が異なる事象について” に記載がある「レジストリの値を “KBDJPN.DLL” から “kbd106.dll” に変更 」して、なおかつ古いリモートデスクトップの実装を使用することで回避できました。 
 

位置情報を利用するサービスと位置偽装

現在、自分がいる位置(個人情報)を利用しているサービスが多数あります。この個人情報の位置づけと位置偽装?とそれぞれのサービスについて書きます。

まず、自分がいる位置は個人情報にあたります、よってこれを利用するサービスは事前に位置情報を利用する旨のメッセージを提示します。この位置情報はいろいろな方法で取得されたもので、その精度や正確性に違いがあります。

1)GPS
3つ以上のGPS衛星からの電波をもとに高度もふくむ位置を特定する仕組みです。 空がある程度の範囲で見える場所であればどこでも位置特定することができます。 利用するにはGPS受信機を内蔵している必要があります。受信モジュールの値段は1000円ちょっとくらいです。それなりの値段の端末なら搭載しておいてほしいところですが、GPSが搭載されていない端末もあります。そのような端末やGPSの電波が届かない場合は、後述の方法を組み合わせて位置特定をしています。

2)携帯電話基地局
  携帯電話が通信している基地局から場所を特定する仕組みです。携帯電話がつながる場所であれば位置特定できるため部屋の中などGPS電波が届かないような場所でも利用です。ただし携帯電話の契約がない場合は利用できません。また、位置特定の精度は1つの基地局でカバーする範囲のどこかとまでしかわからないので、GPSよりも精度は落ちます。

3)WiFi
GPS等で特定した位置情報とその場所で取得したWiFiのMACアドレスがマップ化されています。現在位置で検出されたWiFiのMACアドレスから位置を特定します。特定のWiFiアクセスポイントに接続可能な範囲は携帯基地局に比べて比較的狭いのでその分精度が高くなります。また、複数のWiFiのMACアドレスを使用することでさらに精度を高めています。1)、2)はほぼどこの場所でも利用可能ですが、町から外れるなど民家がなくWiFiがない場所では位置特定できなくなります。また、位置特定できても一見なぞのように感じられる位置の誤認識が発生することがあります。そして、MACアドレスは公のものではありません個人所有の機器に付随した情報です。該当機器は自由に持ち歩くことができ、別の場所に配置することは何の問題もありません。よって、WiFiで提供される位置情報は正しいとは限りません。

4)プロバイダ局
インターネットプロバイダがIP紐づけしている場所が位置として認識されます。どのような仕組みで特定して(決めて)いるのかはプロバイダによって違うものと思われます。以前、私が契約していたプロバイダの場合は、数百キロ離れた東京のある場所にいるものとして扱われていました。今は、すぐ近くですが800mくらい離れた場所が現在位置として扱われています。以前に書いた”空の状態”の位置です。
これは携帯端末とは関係なく有線で利用しているインターネット上で位置特定するものです。前述の通り精度はプロバイダ依存ですがはっきり言って適当な固定位置が返却されると考えたほうが良いでしょう。

 1)2)はほぼ間違いがない位置を特定できますが、4)は適当、3)に関しては誤認識や偽装が起こりそうで、認証など確実に位置特定する目的で利用するのは問題がありそうです。

上記のような位置情報ですが、次はこれを利用しているアプリケーションやサービスの側から見てみます。

■便利にするために利用しているもの。

地図情報や、乗り換え検索などの初期の位置に利用している。
→ 正しく動作するかどうかだけで、機能すれば便利に使える
カーナビなどナビゲーションなどリアルタイムでの現在位置を利用している
→現在位置を取得するべき機能なので正しい現在位置が取れないと意味がない

マップ

→ 現在位置でないと不便なアプリケーション

ナビゲーション

現在位置が取れないと意味がないか役に立たたないアプリケーション

■サービス範囲を制限するもの
radiko
     → エリアフリーなどの有償サービスとの差別化の1つの手段として利用しているもの。確実に差別化?仕分けしたいなら、GPSで取得した位置情報の場合にのみ利用可能にすればよい。しかし、GPS電波が届かない場所など利便性を考えればほかの方法で取得した位置情報も許容するほうが良いかもしれない。しかしそうすると、意図せず発生した位置偽装状態のものを許容するしかなくなる。この挙動を活用することで、前述の方法で位置偽装によりサービス利用が可能となる。  

■AR/VR ゲーム

PokemonGO 

位置情報をアイテム取得などの要素に取り込んだゲームアプリケーションです。位置偽装によりゲームを有利に進めることが可能なため、位置偽装を行うアプリケーションが多数あり、PokemonGOのメーカではその不正を見つけてアカウントの無効化を行ったり、位置偽装アプリケーションを使えないようにしたるするなど、偽装とその対策のいたちごっこが起こっています。

魔法同盟 (ハリーポッター)
 

→PokemonGOとマップは同じような感じです。同様に位置偽装とアカウント無効化のいたちごっこが起きそうなアプリケーションです。

■GPSアート
 →どういう分類にするのが良いか微妙ですが、自己満足?のためなので現在位置でないと意味がなく、たぶんGPSでの測地でないと対応できない場所が多いはず。なので、ここでは取り扱う対象外です。

■その他

GPS鬼ごっこ
→ このアプリケーションの場合、位置偽装の組み合わせでチートなど面白いことができそうですが、さらにこのアプリケーション自体でなにかできそうな気もします。

アプリケーションによりいくつが分けられますが、位置偽装したくなるアプリケーションは多数あります。位置偽装ならぬ位置誤認識を利用して位置偽装をすることもできそうです。上述の通りすでに実績もあります。偽装なのか誤認識なのかサービス側では区別できないように思います。区別できるくらいなら誤認識しないようにしてほしいです。


いろいろ設定変更前の事前確認と設定変更で発生した問題調査について

今回、WiFi周りの設定変更をした際に事前に影響範囲を想定してWiFiの設定変更と同時に必要な対処したはずでした。しかし、あとから太陽光発電のデータがアップロードされていないことに気がついて事後対処しました。そこで、この問題の対策と、今後の検討事項について書きます。

まず、本件の発生に至るまでの経緯です。7年ほど前に太陽光発電システムを導入しWiFi接続の設定をしました。このとき、太陽光発電システム側のボックスのふたを開け箱の中にあるLAN端子にPCとクロスケーブルを使って接続し、ログインパスワードやWiFi接続設定をした覚えがあります。通常の環境ならそのようなことをする必要などないはずですが、ルーティングの構成か固定IPか何かの理由でそのような対処をした覚えがあります。

 上の状況で1年ほど使用した後、屋内ネットワークの強化のため古い無線LANはそのままで、新しい無線LANを導入しました。そして、その後購入したスマホ、タブレット、IoT機器類は新しいルータのほうに接続して使っていました。そのような状況で各端末の設定はすべて新しい無線LANを使用していると認識していました。

 そして、3年ほど前に20mほど離れた場所にWiFi端末を配置にすることにしました。その際にWiFi接続できるようにするために古い無線LANを20mほど離れた場所に移設しました。この状態でも太陽光発電システムのデータアップロードは正常に行えていました。このため、この時点で太陽光発電システムは新しいLAN経由でアップロードしているもの誤認していました。その後、20mほど離れた場所の端末の更新や設定変更など行いましたが問題なく使えておりました。

今回、20mほど離れた場所の無線LANの設定を変更しました。このときWiFi端末今回、20mほど離れた場所の無線LANの設定を変更しました。このとき20mほど離れた場所のWiFi端末の設定も変更したので、これについては問題ありませんでした。しかし、この無線LANの設定変更後、太陽光発電システムのデータがアップロードされない状態になっていました。

この問題に関して原因と対策について考えます。まず、原因のほうからです。直接的には太陽光発電システムのアップロードが該当の無線LAN経由となっていると認識していなかったことです。それに関して、どこを経由して通信しているのかを設計、記録しておくことで解決できそうですが、実際には設置時に記録していていました。配置を更新した際には更新を行うべきですが、今回は更新していないので更新した記録がありません。さらに、配置を変更したが、記録を更新していなかったものと誤解もしています。また、有線LAN・無線LANのどちらも構成変更が容易に行えます。その変更が容易なところは便利でもあり、記録があいまいになる原因でもあります。このため、記録にだけ頼るのは無理がありそうです。それから、事前の調査については、記憶と不十分な状況証拠に頼って判断したことが、原因と考えるのが妥当でしょう。

つぎに対策です。問題の検知については、本件においては対策済みなので問題ないと判断します。そこで、事前検出と、事後対処に分析します。先に事後対処の進め方です。いくつかやり方があります。1つは、正攻法で、発信源(起点)から順番に正常に動作しているかどうか順番に追っかける方法です。また、問題点を想定して順に情報採取していく方法があります。今回は、問題発生のきっかけが分かっているので問題ポイントがあらかじめ絞られているので、別のアプローチが良いでしょう。原因と想定される変更箇所をピックアップして順に元に戻す方法です。今回はこの方法を採用しました。本来使用していると想定していた無線LANの設定は変更していなかったので最初は謎でしたが、想定される範囲を順に広げていき比較的早く問題個所を特定できたと思います。この点も問題ないでしょう。

さて、最後に事前検出についてですが、これはいろいろ検討するべきネタがありそうです。現状は対処方法を用意できていません。何か良い方法を準備したほうがよさそうです。※ これは、今後の検討課題として検討していくことにします。

個人情報流出?で作られた現代の(電波)灯台 その2

WiFiのMACアドレスと位置情報をもとにしたWiFiベースのGPSの件です。GoogleにMACアドレスが登録されているかどうか、登録されているとすると具体的にどの場所にあると登録されているのかを調べてみました。
 まず、確認するサイトについて書かれているページがありました。 このページにMACアドレスと3つないし2つ入力することで、位置情報を確認できます

”空の状態”、「 00:00:00:00:00:00」で、確認できる位置は、アクセスしている自分の位置がどこなのかをプロバイダ経由で所得された場所と思われます。ここにMACアドレスを色々入れて確認してみました。
まず、あるアクセスポイントで取得した干渉候補の無線LANの情報一覧を利用してみます。この情報には一覧には36個のMACアドレスがありました。このうち6個は自分のAPのものでした。そのほかの30個の中にはMACアドレスとSSID名から同一APのMACアドレスと判断できるものが、4セットありました。このセットをそれぞれ入力するとばっちりどの場所にあるのかを特定できてしまいます。
 

それぞれ入力すると最も遠いところは500mほど離れていました。かなり強力な電波を発しているAPもあるようです。それから、2個入力しても、”空の状態”と同じ位置を示す組み合わせが出てきます。これは位置情報をMACアドレスから取れていないこと、つまりこの組み合わせのどっちかのMACアドレスの位置情報が登録されていないことを示します。これもMACアドレスがどのように登録されているのかの検証に利用できます。
 このような検証を通して、確認できたことは次の通りです。
・「_optout_nomap」をSSIDに付加しても、すぐにはMACアドレスと位置の情報は無効にならない。
・ MACアドレス と紐づいている位置はだれでも簡単に参照することが可能である。つまりMACアドレスは住所と同じ個人情報に相当する。
・MACアドレスが1個しかわかっていなくても、ある程度近い位置にある位置を特定済みのMACアドレスと組み合わせることで、位置を特定することができる。500mくらいの精度で場所が分かればと特定はできそう。
・マルチSSIDや、2.4GHzと5GHzの複数チャンネル利用などを利用しているAPが3割程度ある。その情報から位置を特定できるMACアドレスが多数ある。

代替仕組みはわかりました。そこで、無線LANメーカへのコメントです。 個人情報流出につながるおそれがあるので、マルチSSIDやマルチチャンネルで使用するMACアドレスは連番ではなく容易に想定できないものにするべきです。


個人情報流出?で作られた現代の(電波)灯台

私のiPadはGPSを内蔵していないにもかかわらず、位置をかなり正確に認識している。ただ、PocketWiFiを使って遠くにお出かけするとGPSを見失ってしまうことがあります。どんな仕組みで認識しているか、任意の位置を(誤)認識させることができるか実験してみましょう。

まず、どのような仕組みでiPadが位置情報を取得しているのかを調べてみました。マイナビサイトに情報「 iPod touchやiPad、GPSなしでも正確な位置情報がわかるのはなぜ? 精度は? 」がありました。GPSがある端末で位置情報を特定し、その場所で受信可能なWiFiの情報をセットで取得して、マップ化しているそうです。パスワード無で取得可能なWiFiの情報を利用することで、それなりにWiFiが使われている場所なら位置が特定できるというわけです。ただ、元の情報を収集する際にパスワードを使って繋げたWiFiの情報を収集されているような不安を覚えます。
 

 それでは、どれだけの情報を使って位置情報を取得しているのか見てみましょう。
 iPad WiFi設定で見えるWiFiは8個ありました。10個になるときもあります。これだけの数が見つかればかなり精度よく位置情報を特定できるのも納得できます。” 遠くにお出かけするとGPSを見失ってしまう ”は、民家が存在しない、つまりWiFiを利用されていない場所で発生していて。上で紹介されている仕組みで説明がつきます。
 また、もう少し詳しくパスワード無で取得できる情報を見てみましょう。

iPadでは、SSIDの名称しか見えていませんが、WiFi Analyzerを使うと、productor(機器のメーカ名)、MACアドレス、セキュリティ方式、周波数、受信強度を参照できます。SSID名以外の情報をどこまで使っているのか気になることころですが、それにしても、こんなに沢山の電波が飛び交っているとは、情報はダダ洩れ状態ですね。自分が管理している無線LAN以外に思わぬものがWiFiのSSIDを送信していることが分かりました。 それはプロジェクタと家電リモコンです。どちらも、WiFiは起動来ていなくても問題ないのでWiFiをオフにしておきます。プロジェクタのWiFiをオンにしたままにしていたのは今回 WiFi Analyzerを使って探索するまで完全に忘れていて、強い電波が外からきているのかと家の中、外をうろうろしてしまいました。そして、電波の強い場所(部屋)とメーカー名から目的のプロジェクタにたどりつきWiFiの設定をオフにしました。

ここまでで、受信しているWiFiは5個か6個です。見えているのは、いずれも自分で管理している無線LANのSSIDです。マイナビサイトに「位置情報を取得されたくない場合は?」の記事によると、 アクセスポイント名の最後に「_nomap」 とか 「_optout」を書くことで、 Wi-Fi位置情報収集をやめるそうです。iPadで検証するのでアップルの動作を優先して 「_optout_nomap」 という文字列をSSIDの後ろに追加してみます。影響がある端末がため 大変です。

まず1台目を変更します。手元のPCから無線LANのSSID名設定変更は成功し、iPadのWiFi設定の変更も完了しました。つぎに排水ポンプを接続しているスマートコンセントのところまで行ってリセットとWiFi設定のやり直し、設定名も変わってしまったのでスケジュール設定もやり直しです。それからIFTTT設定も再確認します。とりあえず、利用頻度の低い1台の設定変更のみ完了です。この設定変更の効果を検証してみます。問題の無線LANのアクセスポイントの方向にアクセスポイントを通り過ぎて突き進んでみました。 SSID名に 「_optout_nomap」 を付加したアクセスポイントは見えるがこれまで見えていたアクセスポイントは見えなくなる位置まで移動しました。これまで見えていなかった他の家のSSIDが見えている状態になりましたが、ほとんど位置は移動していません。よく見ると 「_optout_nomap」 を付加したID以外にもう一つSSIDがあり、それが効いているようです。それは使用していないマルチSSIDの一つでした。

 そこで、不要なマルチSSIDは停止して、端末側のパスワード設定変更をあまり行わなくてもよい無線LANのSSIDには 「_optout_nomap」 を 付加することにしました。 これにより、位置特定に使用するSSIDはかなり少なくなっているはずです。
最初8個見えていたSSIDは、2個は機能停止、2個はマルチSSIDの停止、2個は 「_optout_nomap」 の付加で見えない状態となり、現状1台の無線LANの2.4Gと5Gの2つのSSIDだけが見えている状態となりました。
さてここで、残った1台の無線LANを停止してどうなるか検証してみます。電源を切ると、この無線LANに接続していたgoogle homeと家電リモコンのSSIDが見える状態になりました。そして、認識している位置は変わりません。 Google homeと家電リモコンのSSIDが 効いているのかと思いそれぞれの電源を切りましたが効果はありません。WiFi AnalyzerでみるとiPadでは見えていなかった微弱な電波が5つ拾えています。2つは別の階の機器で、3つは隣家のものと思われる電波です。ただ、この情報だけでビッチっとほぼ誤差なく位置特定しているとするのは無理があるように思います。

再度、位置情報を特定する仕組みと元情報を再検討します。 「_optout_nomap」 を付加したID の情報をリポジトリに登録していないというのは事実としても、それは登録しないだけで、すでに登録している情報は何かを再考します。位置特定精度が変わっていないことを考慮すると、今回の設定変更で変更されていない情報を利用していると考えるのが妥当でしょう。SSID名はリポジトリに登録するかどうかの条件に利用しているだけでリポジトリには登録しておらず、MACアドレスと位置の情報を登録していると仮定してみます。すると、今まで観測した挙動と一致します。またこの方法だとリポジトリに登録するデータ量を抑制することにも効果がありそうです。では、検証に移りましょう。

現状、iPadのWiFiには 「_optout_nomap」 が付加されたSSIDが4個しか見えていません。それぞれの SSIDに紐づくMACアドレスをWiFi Analyzerで確認します。以下、説明するために符号化した名称と下3バイトのMACアドレスを使用します。 WiFi Analyzerで確認したMACアドレスはそれぞれ、つぎのとおりでした。
P2: c5 7f 2a
TM: c5 69 64
2G: fe c9 92
OL: 8e 18 95
これを変更できるか調べてみました。無線LANの設定画面でこのMACアドレスを参照できましたが、変更する方法は見当たりませんでした。無線LANのWAN側のMACアドレスを指定する機能がある機種はあるようですが、無線LAN側はなさそう。MACアドレスを設定変更できれば、リポジトリに登録された情報から解放されるのですが。 また、マルチSSIDを使用すると最後の1バイト分が変わったMACアドレスが付加されていました。オリジナルのMACアドレスを無効化できればよかったのですがこの機種ではできませんでした
 SSIDのステルス化の機能もあります、これを使えば他人の端末が勝手にリポジトリ登録してしまうことはなさそうです。しかし設定するとその無線LANに接続する設定が少し面倒になります。最初の1回は手作業でSSIDを入力しなければなりません。そのSSIDを入力した端末が位置情報のリポジトリ登録に行くので、ステルス機能だけではリポジトリ登録の無効化には効果がないでしょう。
 それから、アップルの場合はSSID,MACアドレスと位置情報を登録されないようにする方法はないそうです。よってiPadについては、無線LANの電源を落として検証してみました。自前の無線LANが見つからなくなると、これまで、しっかり維持情報を把握していたものが、”GPSが見つかりません”を連発するようになりました。ときどき隣家のWiFiの電波が入るので、その瞬間は位置情報を把握できます。ここまでの確認結果から、位置情報を確認する際は、MACアドレスだけを使用していると推測されます。
 また、Google homeについては、現時点 リポジトリ登録されている情報が古くなって無効化されるまで検証待ちとします。そういえばGoogle homeが以前400km以上離れた別の県を所在地と誤認識していたことがありました。
アップル、Googleともに一度別の場所で位置情報を登録した無線LANを置くことで、位置を誤認識させることができそうです。


大雨で自動での排水起動頻度が不十分なので音声起動を追加

雨が降り出したら自動排水するようにIFTTTのAplletを追加しましたが、その対処では不十分なくらいに大雨になっています。これまで頻度がそれほどでもなかったので手動で起動していましたが、そうもいっていられないくらいの雨になってきたので、音声で起動で指定するAppletを追加します。

IFTTTのサービスを使って、雨が降り出したら排水ポンプを動かすAppletをGoogle homeとEchoそれぞれについて設定します。まずIFTTTで「New Applet」すると次が表示されます。

「+this」をクリックして実行する条件”トリガー”を設定します。ここでは「Google Assistant」もしくは「Alexa」を使っています。検索枠にサービスの名称の頭から数文字”As”や”Al”を入れると選択肢が表示されます。
” Google Assistant”や”Amazone Alexa” をクリックします。

次に起動ワードを指定します。起動したいだけなので、”Say simple phrase”を選択します。

起動ワードに は「排水」を、指定します。「Create trigger」をクリックします。

「+that」をクリックして、何を実行するかを指定します。

実行する処理をサービスの中から選択します。ここでは、利用するスマートコンセント”Meross”を指定します。

”Turn on”(電源オン)を選択します。

登録した”排水ポンプ”のスマートコンセントを選択し、「Create action」をクリックします。

設定した内容を任意の名前を指定します。 「Finish」をクリックしIFTTT設定を完了し保存します

以上で、「雨が降りだしたら自動で排水」することができます。排水ポンプを止めるほうはスマートコンセントのスケジュール設定で「1分後にオフ」を登録しているので、1分後に自動的に排水ポンプは停止します。

いいね 家電リモコンのセンサー機能

ちょっと前に試しに設定していて忘れていた機能が動作して、やっぱりいいねと思いました。
それは、センサーで取得した明るさの情報をもとに家電を操作する設定です。次のように設定しました。

1)IFTTT連携の設定を行う。

2)IFTTTでつぎのようにAppletを作成する。

 2-1)then に RATOC remoconを選択する
2-2) リモコン明暗 (照度) を指定する
2-3) 基準値1(100Lx)より低いを選択する
2-4) Create Triggerを押す
2-5) that に RATOC remoconを選択する
2-6) エアコンの操作を設定する
2-7)エアコンの操作で 停止 を指定する。
2-8)Create Actionを押す

以上で設定は終わりです。

この設定で、電灯を消して部屋が暗くなれば自動的にエアコンが切れるので、エアコンの切り忘れを防げます。 逆にエアコンをつけたままにしておきたければ電灯を点灯したままにしておく必要があります。その場合でも離れたところからオンになっていることを気が付けます。エアコンの消費電力に比べれば電灯のほうはそれほど多くないので、消費電力的にも無視できるでしょう。
 RATOCの仕掛けに改善してほしい点を言うとすると、「 基準値よりxx 」という条件だけでなく、「xxx以上からxxx以下に変わった」など、条件をきめ細かくしてほしいところです。 現状の「 基準値1(100Lx)より低い 」の条件だと、電気を消した時点だけでなく、暗い時間帯に複数回”エアコン停止”の操作が行われることになります。エアコンの動作的には何も起こりませんが、リモコン操作がおこなれたのと同じで”ぴっ”という音がします。

そんな感じで、現在の状況に合わせて動作する仕掛けは、うまく使えばなかなか便利です。その点は、Amazon EchoとGoogle homeの音声アシスタントにも当てはまります。今の状態を認識したうえでそれに合わせてより期待に近い動作をさせるというものです。今の時刻、現在の場所、などです。「今日の天気は?」と聞くだけで、現在地の天気を教えてくらますよね。現状はGoogleのほうが状態認識しているものの情報量が多く、的確な動作をしていると感じます。

たとえば、つぎのようなものです。

・テレビがついているかどうか
  → リモコンボタンの電源操作は、ON/OFFどちらも同じ信号が送信されます。このため、テレビの状態を認識できていないと「テレビをつけて」の操作の結果として”テレビを消して”しまうことがあります。
Google home(Chromchast)の場合はリモコン操作でないので機能するのですが…

・誰が操作したか
  → 誰が操作したのかを認識してその人の設定で動作する。
   カレンダーなど個人アカウントと紐づいている情報にアクセスして動作します。

・今、何をしているか

ということ、スマートスピーカーは、その機器で認識した5W1H?を条件にして、それについて前置きする音声入力することなく機能するので違和感なく使えます。このレベルまではふた昔前のAIのレベルです。今どきのディプラーニング技術をこの5W1Hの管理に組み込めば、スマート何とかはさらに進化できるはずです。