カテゴリー: ノウハウ

コンピュータ関連の問題と対処などノウハウを紹介します

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

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

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

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

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

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

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

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

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


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

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

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

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

Hyper-V上に Ubuntuで開発支援環境を整備する

方針：
　Windows10環境上にLinux（Ubuntu18.04）ベースで開発支援環境を整備する。開発環境のため長期間安定運用できる見込みの18.04を採用しています。

■１．Hyper-Vが使える状態にWindowsを構成しなおします。
PROとか上位エディションでないと使えません。
次を参考に設定する
「Hyper-Vの使い方 Windows 10にWindows 7インストール」
上の手順で特に補足はありません。

■2.Hyper-Vに UbuntuのVMを作成、インストールします。
「Hyper-V で無線 LAN のみの PC でもネットワーク接続できるようにする方法」
補足：上の手順の設定のままやるとメモリが不足する可能性が高い。起動メモリは自分のマシンのメモリサイズに合わせて決めてください。ホストOSにもメモリが必要なので半分程度を基準に、使い方に合わせて調整して割り当ててください。例えば全メモリサイズが8GBなら4GBを割り当てるといった具合に調整してください。

■おまけ：
ここで、VMから無線WiFiデバイスが使えるか確認してみました。
「Hyper-V で無線 LAN のみの PC でもネットワーク接続できるようにする方法」などの情報があります。そりゃそうだ、というか、デバイスはホストOSが管理しているのでゲストOSには直接見えませんよね。つまり、無線WiFiで通信することはできるが、それはブリッジを介して接続するのでUbuntuからはブリッジ接続が有線接続のように見えるということです。よって、やりたいホットスポットとして使用することはできない。 Windows10で起動したホットスポットに対してブリッジ接続することでそれらしい動きはできそうです。しかし、これも Ubuntuからは有線接続として見えるのでUbuntuからはWiFiデバイス操作はできず目的を果たせません。

■3.terminalから ツールを追加インストールする
・まずネットワークの状態を確認するためにnet-toolsをインストールする
sudo apt install net-tools
　　→ ifconfigで IPアドレスなどを確認する
・ホストOSから軽るーくsshで操作したいので、sshをインストールする。
sudo apt install ssh
　→ ここまでの設定で特に追加設定しなくてもホストOSから上で確認したIPに対してSSHで接続ができます。ここから下はsshからの操作でも作業できます。
・Ubuntuのメモリ消費量を削減するためにCUIで起動するように変更する
sudo systemctl set-default multi-user.target
　→VMを再起動すればCUIで起動する
・開発用のツールを導入する
sudo apt install build-essential
　　→これだけで大丈夫そう。さきに下の４つのインストールを実施し後述の問題が発生したので、上インストールも実施、build-essentialのみの動作は未確認
sudo apt install git
sudo apt install make
sudo apt install make-guile
sudo apt install gcc
　　→ここまでとりあえずは構築完了。　以下はビルド確認での問題。

■4.ビルドでの確認
つぎのページを参考にrtl8188eusのドライバをビルドしてみる。
https://ficus.myvnc.com/ja/blog/RTL8188%E3%81%AB%E3%82%88%E3%82%8BOrangePi%E3%81%AE%E3%83%AB%E3%83%BC%E3%82%BF%E5%8C%96Vol.2_b82

$ git clone –single-branch –branch v5.2.2.4 https://github.com/capitalfuse/rtl8188eus.git
$ cd rtl8188eus
$ make

次のようにビルドに失敗


hbox@hbox-Virtual-Machine:~$ git clone –single-branch –branch v5.2.2.4 https://github.com/capitalfuse/rtl8188eus.git
Cloning into ‘rtl8188eus’…
remote: Enumerating objects: 1173, done.
remote: Total 1173 (delta 0), reused 0 (delta 0), pack-reused 1173
Receiving objects: 100% (1173/1173), 3.71 MiB | 1.44 MiB/s, done.
Resolving deltas: 100% (693/693), done.
hbox@hbox-Virtual-Machine:~$ cd rtl8188eus
hbox@hbox-Virtual-Machine:~/rtl8188eus$ make
make ARCH=x86_64 CROSS_COMPILE= -C /lib/modules/5.0.0-25-generic/build M=/home/hbox/rtl8188eus modules
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ に入ります
CC [M] /home/hbox/rtl8188eus/core/rtw_cmd.o
CC [M] /home/hbox/rtl8188eus/core/rtw_security.o
CC [M] /home/hbox/rtl8188eus/core/rtw_debug.o
CC [M] /home/hbox/rtl8188eus/core/rtw_io.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ioctl_query.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ioctl_set.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ieee80211.o
CC [M] /home/hbox/rtl8188eus/core/rtw_mlme.o
CC [M] /home/hbox/rtl8188eus/core/rtw_mlme_ext.o
CC [M] /home/hbox/rtl8188eus/core/rtw_mi.o
CC [M] /home/hbox/rtl8188eus/core/rtw_wlan_util.o
CC [M] /home/hbox/rtl8188eus/core/rtw_vht.o
CC [M] /home/hbox/rtl8188eus/core/rtw_pwrctrl.o
CC [M] /home/hbox/rtl8188eus/core/rtw_rf.o
CC [M] /home/hbox/rtl8188eus/core/rtw_recv.o
CC [M] /home/hbox/rtl8188eus/core/rtw_sta_mgt.o
CC [M] /home/hbox/rtl8188eus/core/rtw_ap.o
CC [M] /home/hbox/rtl8188eus/core/rtw_xmit.o
CC [M] /home/hbox/rtl8188eus/core/rtw_p2p.o
CC [M] /home/hbox/rtl8188eus/core/rtw_tdls.o
CC [M] /home/hbox/rtl8188eus/core/rtw_br_ext.o
CC [M] /home/hbox/rtl8188eus/core/rtw_iol.o
CC [M] /home/hbox/rtl8188eus/core/rtw_sreset.o
CC [M] /home/hbox/rtl8188eus/core/rtw_btcoex_wifionly.o
CC [M] /home/hbox/rtl8188eus/core/rtw_btcoex.o
CC [M] /home/hbox/rtl8188eus/core/rtw_beamforming.o
CC [M] /home/hbox/rtl8188eus/core/rtw_odm.o
CC [M] /home/hbox/rtl8188eus/core/efuse/rtw_efuse.o
CC [M] /home/hbox/rtl8188eus/os_dep/osdep_service.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/os_intfs.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/usb_intf.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/usb_ops_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/ioctl_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/xmit_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/mlme_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/recv_linux.o
CC [M] /home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.o
/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.c: In function ‘rtw_get_systime_us’:
/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.c:354:2: error: implicit declaration of function ‘get_monotonic_boottime’; did you mean ‘getboottime’? [-Werror=implicit-function-declaration]
get_monotonic_boottime(&ts);
^~~~~~
getboottime
cc1: some warnings being treated as errors
scripts/Makefile.build:284: recipe for target ‘/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.o’ failed
make[2]: *** [/home/hbox/rtl8188eus/os_dep/linux/ioctl_cfg80211.o] Error 1
Makefile:1606: recipe for target ‘module/home/hbox/rtl8188eus’ failed
make[1]: *** [module/home/hbox/rtl8188eus] Error 2
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ から出ます
Makefile:1911: recipe for target ‘modules’ failed
make: *** [modules] Error 2
hbox@hbox-Virtual-Machine:~/rtl8188eus$

同様に別のページを参考に他のドライバをビルドしてみたが別のエラーで失敗した。

$ make
make ARCH=x86_64 CROSS_COMPILE= -C /lib/modules/5.0.0-25-generic/build M=/home/hbox/rtl8188fu modules
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ に入ります
CC [M] /home/hbox/rtl8188fu/core/rtw_cmd.o
In file included from /home/hbox/rtl8188fu/include/osdep_service.h:41:0,
from /home/hbox/rtl8188fu/include/drv_types.h:32,
from /home/hbox/rtl8188fu/core/rtw_cmd.c:22:
/home/hbox/rtl8188fu/include/osdep_service_linux.h: In function ‘_init_timer’:
/home/hbox/rtl8188fu/include/osdep_service_linux.h:273:8: error: ‘_timer {aka struct timer_list}’ has no member named ‘data’
ptimer->data = (unsigned long)cntx;
^~
/home/hbox/rtl8188fu/include/osdep_service_linux.h:274:2: error: implicit declaration of function ‘init_timer’; did you mean ‘_init_timer’? [-Werror=implicit-function-declaration]
init_timer(ptimer);
^~~~~~
_init_timer
In file included from /home/hbox/rtl8188fu/include/drv_types.h:35:0,
from /home/hbox/rtl8188fu/core/rtw_cmd.c:22:
/home/hbox/rtl8188fu/include/wifi.h: At top level:
/home/hbox/rtl8188fu/include/wifi.h:1009:0: warning: “IEEE80211_MAX_AMPDU_BUF” redefined
#define IEEE80211_MAX_AMPDU_BUF 0x40

In file included from /home/hbox/rtl8188fu/include/osdep_service_linux.h:84:0,
from /home/hbox/rtl8188fu/include/osdep_service.h:41,
from /home/hbox/rtl8188fu/include/drv_types.h:32,
from /home/hbox/rtl8188fu/core/rtw_cmd.c:22:
./include/linux/ieee80211.h:1444:0: note: this is the location of the previous definition
#define IEEE80211_MAX_AMPDU_BUF 0x100

cc1: some warnings being treated as errors
scripts/Makefile.build:284: recipe for target ‘/home/hbox/rtl8188fu/core/rtw_cmd.o’ failed
make[2]: *** [/home/hbox/rtl8188fu/core/rtw_cmd.o] Error 1
Makefile:1606: recipe for target ‘module/home/hbox/rtl8188fu’ failed
make[1]: *** [module/home/hbox/rtl8188fu] Error 2
make[1]: ディレクトリ ‘/usr/src/linux-headers-5.0.0-25-generic’ から出ます
Makefile:1679: recipe for target ‘modules’ failed
make: *** [modules] Error 2



エラー内容をもとに調べてみると、
https://forum.manjaro.org/t/solved-error-with-rtl8812au/24066/2
https://github.com/smlinux/rtl8723de/issues/13
ドライバーのソースとカーネルバージョンの不一致が原因と言っている。
そこで、カーネルバージョンを確認する。→「カーネルバージョンの確認方法」

$ uname -a
Linux hbox-Virtual-Machine 5.0.0-25-generic #26~18.04.1-Ubuntu SMP Thu Aug 1 13:51:02 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

対象のカーネルバージョン用のドライバソースをビルドしてみます。
https://github.com/FreedomBen/rtl8188ce-linux-driver
→このソースは4.20にも対応しているとコメントがあるのでこれで試します



$ git clone https://github.com/FreedomBen/rtl8188ce-linux-driver.git
$ cd rtl88188xce-linux-driver/
$ make

ビルドに成功しました。　やはり、ドライバーソースが対象のカーネルバージョンに対応していなかったことが原因でした。

USBメモリにパーティションを作成する手順とツール （EaseUS Partition Master編）

先にUSBメモリにPCにインストールすることなく利用できるLinuxを構築しました。この際にUSBメモリ上にパーティションを作成して手順を紹介します。今回はパーティション管理ソフト「EaseUS Partition Master 13.5」を使用して作成する手順を紹介します。
下では「EaseUS Partition Master」を使用していますが「 EaseUS Partition Master Free」でも同様に使用できると思います。 またこのツールはデータリカバリやバックアップの機能もありディスク管理ソフトの色合いもある製品です。

目的；
　「インストールせずにUSBから起動するだけで動作するLinux環境を構築する」これを目的に、次の構成でパーティションを切ります。

パーティション1
　ファイルシステムFAT32
　パーティションサイズ 8GB（Linuxのインストール＋Persistentのサイズ）
パーティション２
　パーティションラベル Persistence （この名称のパス名でマウントされる）
　ファイルシステム Ext3 (ツールがExt4未対応のためExt3としています)
　パーティションサイズ USBメモリの残り全部

●0）準備
　easeus.comのサイトからファイルをダウンロードしてインストールします。
 下では「EaseUS Partition Master Pro 13.5」を使用しています。ダウンロードしたファイル名は「epm_trial_installer」でした。これ実行すると下のようにインストーラ本体をダウンロードしインストールします。

インストールが終わるとデスクトップにつぎのアイコンができます。これをクリックして起動します。

●1)「 EaseUS Partition Master 」が、つぎのように起動します。

●2)起動した画面でUSBメモリのディスク番号を確認し、下の操作対象の領域を確認します。

●３）操作した領域にパーティションがすでに確保されている場合は、パーティションを削除して、”未割り当て”状態にします。対象のパーティションを右クリックして”削除”を選択します。
→補足２参照

●４）つぎに「パーティション１」を作成します。対象の領域を右クリックして”作成”を選択します。

●５）「パーティション１」としてファイルシステムをFAT32、プライマリ、パーティションサイズを8GBに指定してパーティションを作成します。

●６）”作成”で「OK」をクリックすると、つぎの注意ダイアログがでます。「OK」をクリックして継続します。
→補足１参照

●７）つぎにパーティション２を作成します。
　　パーティションラベルに”persistence”、ファイルシステムは”Ext3”、プライマリを指定し、パーティションサイズは残りすべてを割り当てます。

※この時点では、右側のパーティションは削除されように見えていますが、操作に登録されているだけで、まだ実際には削除などの操作はされていません。

●８）操作内容と構成イメージを確認し、問題なければ左上の”操作を実行する”をクリックします。

●９）つぎのダイアログが表示されるので、「適用」をクリックします。※ここで”適用”をクリックしてしまうと後戻りできません。間違いないことを確認してください。

●１０）操作の適用中は下のダイアログで進行状況を表示します。
　USB 2.0の64GBのUSBメモリの構成で完了までに1時間47分かかりました。

●１１）適用が完了するとつぎのように「完了しました」のメッセージが表示されます。

●１２） 「EaseUS Partition Master 」を終了した後、USBメモリを取り外します。

以上で、USBメモリのパーティション構成が完了します。 いくつか補足がありますが「EaseUS Partition Master 」でGUIでの簡単な操作のみでパーティションの操作が行えます。
　下に主に 「 EaseUS Partition Master 」 の開発者向けのコメントを書きます。

■補足１
「Windowsはリムーバブルデバイス上の最初のプライマリパーティションのみ識別します。もしプライマリパーティションがない場合は最初の論理パーティションが識別されます。続行しますか？」
→正しいのかどうか判断が難しいほど情報量が多いです。
　１） もう少しわかりやすい説明をしたほうが良いですが、そのためには図を使うなど別のページに記載して、このダイアログではそのページをポイントするなどして参照してもらうようにしたほうが良いでしょう。
　２）Windows10では1つめ２つめともにパーティションを下のようにFAT32でフォーマットすると認識できました。 下の画像ではH:とX:の２つのドライブで認識しています。 このため、「 最初のプライマリパーティションのみ識別します。 」は不適切ではないでしょうか。旧バージョンのWindowsでは認識できないのなら、”WindowsXX以前では”のような表現を追加したほうが良いです。

■補足２
「パーティションサイズ調整/移動」や「削除」のメニューが非表示となる事象が発生しました。この 件について原因と回避策について現在（2019/8/16時点）EaseUSにて調査中です。
この事象は別のツールにてパーティションを再構成することで解消しました。ただパーティション削除の操作だけでは未割り当て状態には変わらなかったので何らかの異常な状態になっていたものと推測します。今のところ同じ事象を再現できていないので確認することができませんが、いったんパーティションを復旧させる操作をすることでパーティション削除できる状態に復旧できると推測しています。

USBメモリにパーティションを作成する手順とツール

先にUSBメモリにPCにインストールすることなく利用できるLinuxを構築しました。この際にUSBメモリ上にパーティションを作成して手順を紹介します。

目的；
　「インストールせずにUSBから起動するだけで動作するLinux環境を構築する」これを目的に、次の構成でパーティションを切ります。

パーティション1
　ファイルシステムFAT32
　パーティションサイズ 8GB（Linuxのインストール＋Persistentのサイズ）
パーティション２
　パーティションラベル Persistence （この名称のパス名でマウントされる）
　ファイルシステム Ext4
　パーティションサイズ USBメモリの残り全部

●USBメモリにLinuxを構築する際にUSBメモリのパーティションを切る手順

いくつか方法がありますが、まずWinodws10とUbuntuのISOのみでの作業方法をざっと書きます。

１）前準備として暫定版のLinux環境を作成します。Windows10上でUniversal-USB-Installerを使ってUSBメモリをFAT32でフォーマットして、UbuntuをUSBメモリに書き込みます。
　※フォーマット対象を間違わないように注意してください。間違うと自マシンのHDDが消されます。
　　→この部分はUSBメモリでなくDVDでもよいかもしれません。
２）作成したUSBメモリを使ってUbuntuを起動します。起動時のメニューでいくつか選択肢がでます。
つぎのいずれかを選択します。”safe graphics”でない場合、私の環境では２画面でディスプレイ表示できましたが、HDMIのほうがチラつきが激しく不安定でした。
・Try Ubuntu without installing (safe graphics)
・Install Ubuntu (safe graphics)

”Try Ubuntu without installing ”で起動した場合は、起動後に”Ubuntuインストール”を実行します。

上のメニューのどちらでもよいはずですが、左側のメニュー有無の差異により”Try Ubuntu without installing ”で起動したインストラーでは、一部のメニューが画面下にはみ出して動作できない事象が発生しました。”Install Ubuntu”で起動するほうがよいでしょう。

「アップデートと他のソフトウェア」画面では特に設定は何でもよいです。ここで構築するのはパーティションが目的なので、、。
「インストールの種類」画面で、”その他”を選択してください。間違うと自マシンのHDDが消されます。※

インストール先の指定でUSBメモリにパーティションを作成してそこにインストールします。
未フォーマットのUSBメモリの場合はパーティション作成を実行できます。
しかし、一度パーティションを作成すると、この画面の操作では再度パーティションを切りなおすことができませんでした。

インストール先の指定では、USBメモリを選択してください。間違うと自マシンのHDDを上書きし消されます。※

以上の通り、Ubuntuからパーティション作成をすることは可能ですが、パーティションを切りなおせないパターンがあるなど、いろいろかゆいところに手が届かないところがあります。

■どうしても、パーティションを切りなおしたくなったので下のようにツールを利用しました。
■無償版「MiniTool Partition Wizard Free 11」を使ってパーティションを切りなおします
https://www.partitionwizard.com/free-partition-manager.html

●0）準備
　MiniToolのサイトから無償版のファイルをダウンロードしてインストールします。
ファイル名は「pw11-free.exe」でした。インストールするとデスクトップなどにつぎのアイコンができます。これをクリックして起動します。

●1)「 MiniTool Partition Wizard 」のメニューで”ディスク＆パーティションの管理”を選択します。

●2)起動した画面でUSBメモリのディスク番号を確認し、下の操作対象の領域をポイントします。

●３）操作した領域にパーティションがすでに切られている場合は、このパーティションを削除します。対象のパーティションを右クリックして”削除”を選択します。

※この時点では、右側のパーティションは削除されように見えていますが、左下の保留中の操作に登録されるだけで、まだ実際には削除はされません。左上の”破棄”をクリックすると次のようにダイアログが表示されるので「はい」をクリックすることで 、保留中の作業を破棄することがきます。

●４）つぎに「パーティション１」を作成します。対象の領域を右クリックして”新規作成”を選択します。

●５）「パーティション１」としてファイルシステムをFAT32、パーティションサイズを8GBに指定してパーティションを作成します。

●６）”パーティション新規作成”で「OK」をクリックすると、つぎの警告ダイアログがでます。「はい」をクリックして継続します。
→補足１参照

●７）つぎにパーティション２を作成します。
　　パーティションラベルに”persistence”、ファイルシステムは”Ext4”、パーティションサイズは残りすべてを割り当てます。
→補足２参照

●８）作業内容（保留中の操作）と最終イメージ（右側）を確認し、問題なければ左上の”適用”をクリックします。
→補足３参照

●９）つぎのダイアログが表示されるので、「はい」をクリックします。※ここで”はい”をクリックしてしまうと後戻りできません。間違いないことを確認してください。

●１０）保留中操作の適用中は下のダイアログで進行状況を表示します。
　USB 2.0の64GBのUSBメモリの構成で完了までに約２時間かかりました。
→補足4参照

●１１）適用が完了するとつぎのダイアログが表示され作業が完了します。

※上の状態で。Windows10のエクスプローラーでUSBメモリの”取り外し”をすると、次のダイアログが表示されます。 「MiniTool Partition Wizard 」がUSBメモリをロックしている状態になっています。

●１２） 「MiniTool Partition Wizard 」を終了した後、USBメモリを取り外しします。

以上で、USBメモリのパーティション構成が完了します。 いくつか補足はありますが「MiniTool Partition Wizard 」 無料版は十分使えると考えます。
　下に主に 「MiniTool Partition Wizard 」 の開発者向けのコメントを書きます。

■補足１
「Windowsがリムーバブルディスクの一番目のパーティションのみを識別できるだめ、この新規作成されたパーティションはWindowsで使用できません。」
→この部分だけでもいくつかコメントがあります。
　１） つぎのようにメッセージの日本語表現が不適切な部分があります。「Windowsが 」の”が”は、”は”のほうが適切です。「 識別できるだめ 」の”だめ”ではなく”ため”です。メッセージリソース全体にわたってスペルチェックをかけるか日本語がわかる人にレビューしてもらうことをお勧めします。
　２）それから機能的に不適切なところがあります。Windows10では1つめ２つめともにパーティションを下のようにFAT32でフォーマットすると認識できました。ドライブ文字にX:指定することで正しくX:に割り当てられました。 下の画像ではH:とX:の２つのドライブで認識しています。 このため、「 この新規作成されたパーティションはWindowsで使用できません。 」は不適切ではないでしょうか。
　３）旧バージョンのWindowsでは認識できないのなら、”WindowsXX以前は使用できません”のような表現にしたほうが良いです。

■補足２
「パーティション新規作成」ダイアログで、「パーティションのラベル」を入力した後、ファイルシステムをExt4に変更すると「パーティションのラベル」の文字がクリアされます。ファイルシステムによってはパーティションラベルが入力できないものがあるのはわかりますが、入力枠には上から順番に入力したがるものです。クリアするなら本当にクリアするべき条件に合致しているときだけクリアするようにしたほうが親切です。

■補足３
　「保留中の操作」の番号ですが”2.5”とかは何を意味しているのか分かりにくい、すべて整数で処理順に番号を振ったほうが理解しやすいです。なにか意味を持たせるのであれば、利用者が直感的に分かる表現にしたほうが良いです。

■補足４
「 保留中の操作を適用しています… 」の　％の意味は、それぞれの進捗％なので、それ以上でもそれ以下でもないのですが、利用者が一番知りたいのは「あとどれくらい時間がかかるのか」ということです。 現状の％表示ではあとどれくらいかかるのか わかりにくいです。
　　FAT32からExt4にフォーマットしなおすのに2時間ほどかかりましたが、FAT32にフォーマットしなおすのに10秒ほどしかかかっていません。Ext4にフォーマットしなおすのに２時間もかかるのは何か余分なことをやっているのか、FAT32にフォーマットするのに必要かもしれない何かを省いているように思われます。工夫することでもう少し早く処理を終わらせることができるように思います。

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

インストールせずにLinuxを使うならUSBメモリは USB3.xで

LinuxでWiFiのホットスポットの機能を検証するためにインストールすることなく利用できるLinuxを構築してみました。
※下の手順より簡単な方法を → こちらに記載しました

前提条件
　ターゲットマシン：Intel Core i7-2600
NVIDA GeForce GTX560だが障害あり。Winでは640×480のモードかリモートデスクトップでの利用で運用回避中
おもにWin10で利用しておりインストールはしたくない。

　　別のマシン：Intel Core i7-8700など２台のマシン
ネットワーク：有線LANあり
Linux：2019/7/30時点で最新（Ubuntu19.4を使用）

参考情報
　Linux環境構築にあたり、つぎのサイトの情報を参考にさせていただきました。
・LinuxをUSBメモリへインストールする

ターゲットのマシンではなく正常に動作するPCでUSBメモリにLinux環境を構築します。上のサイトに書かれている作業でほぼ実現できます。ただ Ubuntuのバージョンが上がっているので、すこし異なる手順のところはありました。今思えば、より簡単に変わっているイメージですが、上のサイトの記載に引っ張られてすこしいらないことをした感触はあります。その辺の手順は差っ引いて、以下に、上のサイトと異なるポイントを書いておきます。

１）「USBメモリ上にパーティションを作成」のところで、「ラベルはcasper-rwとします」とありますが、persistenceにします。　最悪は、何も名前を付けなくてもUbuntuが起動時に勝手に適当な名前を付けてマウントしてくれます。そのあとUbuntuからExt4のパーティションラベル名を変えることも可能です。
２）パーティション作成は最初UbuntuをUSBで起動してUbuntuのインストールの際に動くパーティション分割で構成しました。これでも十分に分割は可能です。しかし、一度分割したものの再構成し直すなど痒いところがどうしても実行できませんでした。そこで MiniTool Partition Wizard  を利用して対処しました。このパーティション作成については別ページで紹介しています。また、EaseUS Partition Masterを使う例も紹介しています。
３）「 Persistent fileのサイズは0に設定します。 」これはやりません。取れるだけ確保します。このため、第1パーティションは少し大きめに設定しておきます。もちろん第2パーティションも１）に書いたように Persistent storage に自動的に割り当てられます。
４）上のようにUbuntuの仕様変更？の影響もあって、「パーティションをPersistent storageとして割り当てる」のところの作業は不要です。

ここまでで、正常に動作するPCではUSB でLinuxを起動できるようになります。
これに加えて、最初の課題の”ディスプレイアダプタ問題”の回避をします。そのためにはグラフィックを使用しないように設定変更します。

\boot\grub\grub.cfg　を編集します
既存の menuentryをコピーしてメニュー名を “Try Ubuntu without installing with TEXT” などに変更します
boot=casper xxxの部分を、”boot=casper text nomodeset —”に変更します

この変更により、上の写真のように起動時にテキストで起動ログが表示されるように変わりますが、起動し終わるとGUIが起動します。そこで、Ubuntuが起動した後、terminalなどを使ってつぎのコマンドでCUIモードに切り替えます。
sudo systemctl set-default multi-user.target
これにより、CUIで起動できます。
　※記載しているサイトが見当たりませんでした。デフォルトのubuntu アカウント のパスワードは””つまりエンターのみ。sshからは空文字をうけつけないなどリモートからログIDでのログインが面倒です。別途アカウントを作ってsudoグループに追加して使用します。ここまでで、Linuxを利用するベースの環境ができました。

64GB USB2.0仕様と 32GB USB3.0仕様の２種類のUSBメモリを使用して起動確認を行いました。それぞれの起動、停止時間は次の通りでした。

　　　USB2.0USB3.0
起動からログイン画面まで4分45秒50秒
起動パスワード入力後、ログイン完了まで5分1秒
シャットダウンから電源が切れるまで5分50秒20秒

表中の「ログイン画面」は上の画面です。

上表の「 ログイン完了 」とは上の画面の状態です。


上記のようにUSB2.０でも動作はしますが、かなり処理速度が遅いのでちょっと使いづらい。USB3.0は比較的早い、もう少し早いほうが良いのですが…。今なら、USB3.0以上を使うしかないでしょう。

さて本題の障害のあるPCで確認します。このPCはWindows10が何と起動して、利用することができるが、起動時のロゴやデスクトップのアイコンが崩れて見えるとうレベルの壊れ具合です。以前は２画面使えていましたが、HDMIでつないだディスプレイには表示できず、古いディスプレイBL-191A-Bで表示が崩れながら使うか、リモートデスクトップで別マシンから使うかしています。リモートデスクトップの場合はディスプレイアダプタを使わないので障害の影響を受けにくいのでしょう。

上の写真をよく見ると、微妙な濃淡ですが妙な横線が何本もあるのが見えます。こんな感じで微妙な壊れ方をしています。


このマシンでUSB Linuxを起動してみました。

普通に起動できたかと思い蒔いたが、一切動きません。 キーボードを認識していない のかユーザー名を入力できません。最後の確認としてキーボードのUSB端子を抜き差ししてみました。すると、次のようにメッセージがでました。

”usb 3-1.3: device not accepting…”　USBになにか差し込まれたことを認識はしたが、デバイスを受け付けていません。

テキスト起動であればグラフィックに多少の問題があっても使えると考えていたのですが、上の状態となりだめでした。残念、この状況からLinuxはまだまだハード障害に弱いと感じましたというか、Windowsがこの状況に耐えているのがすごいという感じでしょう。

とりあえず、正常に動くPCで、検証進めます。

活動量計 T-PRO Lifesense band2の電池の持ちと電池が切れるまでの挙動

以前に8/1ころにと書きましたが、本日（7/30） T-PRO Lifesense band2の 電池が切れました。その、 スマートウォッチ T-PRO Lifesense band2の心拍計オフとオンのパターンでの電池の持ちのチェック結果です。

結果は次の通りです。1回のフル充電で心拍計オフなら21日間、心拍計がオンなら4日間使えます。後半に電池の減少ペースの変化が激しかったのは利用方法によって発生しているのかと思いましたが、製品の動作をそのようにして使えない状態が発生しないように工夫しているような気がしてきました。詳細は下に書きます。

40％を切ったあたりから電池の減りが急になり、10％のところで長時間滞留しました。実際にはありえなさそうなくらい長時間10％だった、つまり通常1日あたり4から5％消費されていたのに、ほぼ1日10％で維持されていました。　また、10％のところでバイブレーション機能が動作しました。1秒くらいの振動が３回ありました。どこかで設定したのか、設定できないのかはわかっていません。アラーム設定では15秒と設定したので、その数値とは違うようです。
この振動による通知があるように、利用者に電池切れを早めに提示して電池切れを回避するように工夫されているのではないかと推測されます。　訂正・補足(2020/1/27追記)：字消し線で消した部分は間違いでした。このバイブレーションは電池残量とは関係ありません、設定した目標の歩数を達成したときに動作するものでした。


それから、9％の段階では操作もでき、歩数の計測など各種機能は機能していました。
その後、電池が切れている旨の表示となり、残量が何パーセントなのか確認できない状態に移行します。その状態では時刻しか確認できません。歩数の確認ができないため、この時間帯に歩数カウントができているのかどうかは確認できていません。心拍計オンの時は10％を切った後も歩数カウントをしていたように見えていましたが、再度確認する予定です。
そして、電池が切れて時刻表示もなくも表示できない状態になります。この状態で1時間ほど放置した後に充電してBluetooth連携を行いました。

最後に。電池が切れてしまったら、どこまでのデータを回収できるのかみてみました。電源が切れる5日前から Bluetooth連携していません。この状態からBluetooth連携して、前回連携していた後の続のデータから、電池が切れるまでのデータ少なくとも時刻表示のみのモードになったところまでのデータを回収することができました。

購入前から、他の製品（Newpower とかitDEAL 活動量計）では2日くらいしか電池が持たないとか約2~6日間（anemos fit　AW-002 山佐、GanRiver ）というレビューなどの情報があったので、気にしていました。3週間持つという結果から電池の結果による製品寿命も長くなるので安心して使えそうです。

全く話は変わりますが、6年前に買った携帯電話は1回の充電で1週間ほど持ちます。いまでも問題なく使えています。充電池は充電を繰り返すことによって劣化していくので、1回の充電でどれくらい長く持つかはどれくらい劣化せずに使えるかに直結すると考えています。そんな感じで気に入ったものを長期間使いたいので電池の持ちは重要ですね。

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

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

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

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

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

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

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

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

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

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

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

マップ

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

ナビゲーション

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

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

■AR/VR ゲーム

PokemonGO　

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

魔法同盟 （ハリーポッター）
　

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

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

■その他

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

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


活動量計その後

以前に書いた、 スマートウォッチ T-PRO Lifesense band2の電池の持ちのチェック結果ではなく途中経過です。心拍計をオフにした状態での測定中で、まだ電池は持っています。

前回の4日目までの結果から21日くらい持ちそうとしておりましたが、16日目までの電池消費状況から推測するやはり21日くらい持ちそうです。近似直線を下回る波が多少あります。このときに何をしていたかというと運動はほとんどしていません。Bluetooth接続もしていませんでした。通常あまりしない態勢をとっていたくらいです。このためスマート ウォッチ のディスプレイはオンになる頻度が高くなったのではないかと推測します。

つぎは、どこまで持ったかを書きます。8/1ころになりそうです。

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

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

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

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

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

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

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

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

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