本格的なスマートホームへの移行までの対応例、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の本体をとりだす必要があるなど、いちど接着テープを剥がさないと電池交換できないような場所には不向きです。
  ただ、そういう場所にこそ使いたいかもしれません。

太陽光発電の経年劣化による発電量の減少とメーカー保証について

前回の解析に続いて、経年劣化の状況を整理しておきます。最初に実際のデータです。7月の発電量のうち発電量が最大だった日のデータを年ごとにプロットしたものです。3つとも劣化していることが分かります。変更の影響を受けている部分はありますが、全体的な傾向から劣化していると言ってよいでしょう。

このような経年劣化に関連した保証しているメーカーもあります。まずはその辺から、保証内容にまとめたサイトもありますので全体像はそちらを参考にしてください。ここでは、経年劣化に関する保証内容のみをまとめます。

メーカ名10年保証11年以降
パナソニック JIS C 8918の7.1(性能)に示された公称最大出力に対して、10年で81%未満 25年で72%未満 ※1
シャープ JIS C 8990で規定するAM1.5、放射照度1,000W/m2モジュール温度25℃、最大出力の90%を基準にしてその90%11-15年 85%
16-20年 80%
京セラ公称最大出力の81%10-20年 72%
東芝 JIS C 8918の7.1(性能)に示された公称最大出力に対して、10年で81%未満 25年で72%未満
長州産業 CIC JIS C 8918 に示された公称最大出力に対して、81%未満 11年目から15年間 :72%未満※1
ソーラーフロンティア 公称最大出力の交差範囲内の最小許容値に対して10年で10%以上低下 20年で20%以上低下

※1:手続きをいろいろしておかないと保証書も発行されない仕組みになっている。みんなちゃんと手続きをしているのだろうか?

上の通り81%未満のメーカが多い。公称最大出力を基準としているところが多いが、実際の発電量と見比べたとき、何パーセントになったときに保証されるものなのか非常に分かりにくい。上の実際のデータで見てもわかるように10年で初期の発電量の80%程度になることは当たり前のように推測されます。

 そして、どうなったら「保証の対象」つまり保証の基準を下回っていると判断されるのかをメンテナンス会社に聞いてみましたが、判断基準や確認方法についての返事は帰ってきませんでした。 80%とか70%の微妙な数字では、「天候や太陽高度の影響により変わる」というごく当たり前のことをいって保証の対象外とされています。たぶん出力が初期の50%以下になるとか極端な数値にならないと保証されないでしょう。

2013年7月
発電量(1日分)
2019年7月比率
劣化度
site154.0kWh45.584%
site232.027.686%
site365.655.785%

上表のように発電量は10年で初年の80%程度の発電量となるので、発電収入などを見積もるときは平均的にこの程度の劣化があるものとして見積もったほうが良いでしょう。

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

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

■1.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
  →これだけで大丈夫そう。さきに下の4つのインストールを実施し後述の問題が発生したので、上インストールも実施、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

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

台風直撃、風も雨もそれほどひどくなかったが収穫直前のトウモロコシはほぼ全滅

あと10日くらいで収穫できそうだったトウモロコシでしたが、台風の風でほぼ全滅しました。さすがに2メートル越えの背丈だと耐えきれないのでしょう。

台風の目に入ったほど直近を通過した台風でしたがこの場所の雨量は30mmほどとほとんど降りませんでした。風もそれほどひどくはなかったのですが上の写真のようにトウモロコシはほとんど倒れてしまいました。近くの気象台のデータでは最大瞬間風速が11m/s台で、台風でなくても時々ありそうな数値です。ちょうどトウモロコシの背丈や実の付き具合で弱い状態になったところに風が吹いたので倒れてしまったと推測できます。残念ですが完全に倒れたものは諦めて収穫しました。まだ実はほとんど入っていませんでした。

 トウモロコシを取り除いた後には台風来襲に備えて植え付けを先送りしていたナスを植えることにします。

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のサイズ)
パーティション2
 パーティションラベル Persistence (この名称のパス名でマウントされる)
 ファイルシステム Ext3 (ツールがExt4未対応のためExt3としています)
 パーティションサイズ USBメモリの残り全部

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1)前準備として暫定版のLinux環境を作成します。Windows10上でUniversal-USB-Installerを使ってUSBメモリをFAT32でフォーマットして、UbuntuをUSBメモリに書き込みます。
 ※フォーマット対象を間違わないように注意してください。間違うと自マシンのHDDが消されます。
  →この部分はUSBメモリでなくDVDでもよいかもしれません。
2)作成したUSBメモリを使ってUbuntuを起動します。起動時のメニューでいくつか選択肢がでます。
つぎのいずれかを選択します。”safe graphics”でない場合、私の環境では2画面でディスプレイ表示できましたが、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メモリのディスク番号を確認し、下の操作対象の領域をポイントします。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■補足4
「 保留中の操作を適用しています… 」の %の意味は、それぞれの進捗%なので、それ以上でもそれ以下でもないのですが、利用者が一番知りたいのは「あとどれくらい時間がかかるのか」ということです。 現状の%表示ではあとどれくらいかかるのか わかりにくいです。
  FAT32からExt4にフォーマットしなおすのに2時間ほどかかりましたが、FAT32にフォーマットしなおすのに10秒ほどしかかかっていません。Ext4にフォーマットしなおすのに2時間もかかるのは何か余分なことをやっているのか、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/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” に変更 」して、なおかつ古いリモートデスクトップの実装を使用することで回避できました。 
 

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

LinuxでWiFiのホットスポットの機能を検証するためにインストールすることなく利用できるLinuxを構築してみました。

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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