投稿者: muller

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

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

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

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

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

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

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

●楽器
●ウォークマン
●テレビ
●オーディオ製品、音響機器
●温度計、湿度計
●鏡
●カレンダー
●写真立て、フォトフレーム
●ゲーム、将棋盤
●新聞
●血圧計、体温計
●図鑑、本、辞書、電話帳、地図
●スキャナ
●ストップウォッチ
●スピーカ
●双眼鏡、望遠鏡
●そろばん
●体脂肪計、体重計
●タイプライター
●カメラ
●アルバム
●手帳
●電卓
●電話機
●投影機
●トランシーバー、無線機
●ノート、紙
●メガホン
●ラジオ、ラジカセ

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

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

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

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

前回の解析に続いて、経年劣化の状況を整理しておきます。最初に実際のデータです。７月の発電量のうち発電量が最大だった日のデータを年ごとにプロットしたものです。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％程度の発電量となるので、発電収入などを見積もるときは平均的にこの程度の劣化があるものとして見積もったほうが良いでしょう。

関連記事

太陽光発電の軌跡：個人導入のリアル ～運用実績から見る2025年Solarの投資回収と総所有コスト～

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

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

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

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

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

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

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

先に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メモリにパーティションを作成する手順とツール Linux利用
利用開始までの準備
ライセンス、購入方法

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

先に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にフォーマットするのに必要かもしれない何かを省いているように思われます。工夫することでもう少し早く処理を終わらせることができるように思います。

関連記事
USBメモリにパーティションを作成する手順とツール （EaseUS Partition Master編）
利用開始までの準備
ライセンス、購入方法

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回の充電でどれくらい長く持つかはどれくらい劣化せずに使えるかに直結すると考えています。そんな感じで気に入ったものを長期間使いたいので電池の持ちは重要ですね。