2016年2月6日

ソーラー発電を設置することにした

いくつかの事情で我が家の家計予算に余裕ができたので、念願だったソーラー発電を導入することにした。

我が家の年間電力消費は約13~14MWh。月平均なら1.2MWhで電気料金は月$300少々。一時は年間1.5MWh、月$500を超えていたが、照明のLED化や家族の教育に加えて、「E6 Time-of-Use Smart」という、毎月の積算使用量、季節、時間帯、曜日によって、最低と最高の差が6倍程度にもなる24段階のkWh単価(約$0.15~0.90/kWh)で変動する料金プランに変更した結果、この数字になっている。

アメリカの家庭用電力は公称240V60Hzの中性線(ニュートラル)付きで、普通の電気機器は片方の「ホット」とニュートラルの間の120Vを使うが、消費電力の大きな機器、例えばランドリードライヤとかオーブンは240Vを使う。我が家の引込みブレーカは少々変わっていて、安全ブレーカ(15~20A)のたくさんついた別の配電盤に行く100Aと台所のオーブン・クックトップに行く40Aが独立していて、それらを束ねたところにリアルタイム・テレメトリで使用量を電力会社に送信しているスマートメータがある。合計140A×240Vで33.6kVAにもなるが、我が家は30年前の建築で、最近の家は200Aの引込みが主流だそうだから48kVAにもなる。確か日本の家庭用電力の引込みは100Vで60Aが最大契約容量で200Vは例外的だったと記憶するから6kVA、アメリカのわずか1/8~1/6で、これはこの国に30年近く住んでいる小生としてはアメリカが大食らいと言うより、日本の容量でよく生活できるな、というのが本音。

もっとも、我が家は節電に努めているので、テレビジョンを見たり食事をしたりするぐらいなら平均1.2~1.5kW、これにセントラルヒーティングの送風やヘアドライヤがそれぞれ1kWほと加わり、 洗濯物を乾燥させると5kW、オーブンで調理すると3kWほどが追加になるが、全部一緒に動作させても10kWを少々超えるぐらいだからブレーカが落ちたことはない(それでも電力会社から電力使用量が多いので最高段階の料金になると警告メイルを毎月受け取る)。しかし、やっぱり日本の6kVA(≒6kW)では心許ない。

実はRaspberry PiとArduinoを使って、スマートメータからZigbee経由で読み込んだデータを使ってリアルタイムで電力消費量と課金額を表示するガジェットを製作しもう半年以上使っているのだが、それらの紹介は別記事に取っておく。

我が家はかなり急峻な傾斜地に建っており、また二つの直方体が150度ぐらいの角度で扇型に合体しているようなレイアウトなので、公称二階建てだが床のレベルは踊り場を除いても5段階もあり、従って屋根の形も複雑。幸いなことに扇の開いた方が南側だからソーラーパネルの設置には有利だが、それでも配置には工夫が必要。特に問題なのは、数年前に制定された火災対策状の規制で、屋根の左右端と尾根から3フィート(約90cm)、谷から両側1.5フィートづつはソーラーパネルを設置できない。多分、火災時に消防士が屋根の上を歩き回る通路を確保するためだろう。

ソーラーの業者4社から見積りをとったが、どの提案もも凡そパネル12~20枚で名目発電量は4~6kWDC。あらかじめ我が家の昨年1年間の月ごとの消費電力と料金のデータを送っておいたが、どの業者も初回コンタクト時にぐぐるの衛星写真から起こしたかなり正確なパネルの配置図を持参してきたのには時代を感じた。発電量は消費の40~50%を賄う見込みで、日本と違い売電価格は消費価格と1対1で同じ、また年間消費を超える分の売電価格はkWh当たりわずか数セントなので必要以上の設置は損だが、我が家は現在のところエアコンなしなので真夏の日中は高い単価で電力会社に売電が見込め、初期買取り投資は4~5年で回収の見込み。

ソーラー設置に併せて築30年の天然木の屋根をアスファルトシート(シングル、shingles)に換装するすることも決めて、そちらの業者も手配したが、現在は雨期なので工事はできず数ヶ月待つことになる。

これ以上の詳細は退屈なので書かないが、小生は条件の合わない見積りをいちいち公表することは普通はしないところ、見積りをとった4社の中で1社、却下された提案について複数回メイルで反論してくるという非常に奇妙なセールスウーマンがいたのでYelp.comに書いた感想の日本語訳を挙げる。

ジャナ・コイル(Jana Coyle、以下JC)という、驚くほど積極的でしつこいセールスウーマンは私に圧力をかけ、数々の多分嘘か少なくとも誤解させる説明で、時代遅れの機材を使った、業者がもっとも儲かるシステムを高額で売りつけようとしたように思えます。

4軒の業者から見積りをとりましたが、ソーラーシティ(SolarCity)のJCは以下の二つのプランを持ってきました。
  1. 買取り: システムを買い取って、南南西と西南西に設置された合計12枚の260Wのパネルとセントラルインバータ(確立された古典的な技術)で消費量の41%を発電
  2. PPA(電力買取り契約) : 初期投資なしで南、南南西、西南西、北北東、東北東に設置された合計28枚の260Wのパネルとセントラルインバータで消費量の96%を発電
PPAとは一種のリース契約で、毎月固定額ではなく、発電量に応じて電力会社から買う場合の最低単価よりほんの少し高い固定単価($0.162/kWh)の料金を業者に払い、残りは従来どおり電力会社から買うものです(消費を超える余剰電力は売電)。初期投資がゼロですぐに正味の節約が得られますが、買取りの場合の正味節約の累積も10年程度で同等になり、その後は買取りの方が節約になります。

慎重に比較検討した結果
  1. 買取りの予算はあるし長期的にはPPAは不利なので、PPAは多分我々には最善ではないだろう
  2. セントラルインバータは全パネルの発電した直流を1台のインバータで一括して交流に変換するので、我が家のように方角の異なる複数の屋根面に設置する場合は個々のパネルごとに変換するマイクロインバータ(比較的最近の技術)の方が効率的だろう
  3. JCの見積り価格は一番高い
  4. JCは技術的な設置の実現性(可能なアンペア数)についてまったく言及・評価していない
などの理由から、彼女の提案は却下しました。

これに対してJCは数通のメイルで反論してきたので、私は以下のように返答しました。

JC: 「REC社の260Wのパネルを使って…」

- 他の業者は280Wまたは327Wのパネルを提案してきました。JCは旧製品の在庫を売りつけようとしたのかもしれません。

JC: 「なぜPPAは最善の節約法でないと感じるのですか?…PPAはより節約できます。…あなたの場合、消費電力の40~50%ではなく、95~100%を発電できます。」

- これはまったくの嘘に聞こえます。彼女のPPAの提案の28枚のパネルを使って96%節約、買取りでは12枚のパネルで41%という主張は、すべてのパネルが同量の発電をするという仮定に基づいているからです(96/28==41/12)。彼女のPPAの提案は半分以上のパネルを北側の屋根に設置するので、これらのパネルの発電量はずっと少ないはずです。それ故、「96%の節約」はまったく非現実的です。加えて、もし仮に実現不可能なほど多数のパネルを設置して消費電力の100%を発電し電力会社からの購入がゼロだったとしても、PPAでは現在の我が家の電力会社からの平均購入単価$0.28/kWhを考えると、金銭的な節約は0.28-0.16=$0.14/kWhまたは約43%に留まり、買取りの場合の41%とほぼ同じです(料金の段階制度や毎年の値上げ効果を無視)。

JC: 「あなたの場合、屋根を影が移動することはないので個々のパネルは独立に動作する必要はありません。セントラルインバータはマイクロインバータを5年ごとに交換しなければならないのに比べて屋根の損傷が少なくて済みます。」

- 確かに我が家の屋根を影が移動することはありませんが、異なる方角を向いたパネルはそれぞれ異なった日の当たり方になり、そのような場合はマイクロインバータが有利と考えられます。JCはマイクロインバータが5年ごとに故障するがセントラルインバータはそうはならないという統計的な証拠を見せてはいません。もし両タイプのインバータが同じ故障率なら、5年ごとにセントラルインバータも故障し、修理されるまでの数日間または数週間まったく機能しませんが、マイクロインバータを使ったシステムなら、発電量は少々低下するものの全体は動作・発電し続けます。これはJCが知らないかもしれない「単一点の故障が全体の故障になる」という工学的な常識です。

JC: 「当社の価格は競争力があります。もし他社が少々低価格を提案してきても、それは当社の提供する価値と保証とは比較にならないものの可能性が高いです…。」

- JCの見積り価格は4社中最高額で、私が最終的に選択した業者の見積りより発電量当たりの単価は36%も高いものでした。また100%確信を持っているわけではありませんが、長期的な保証は結局パネルやインバータの製造業者から来るので、多分どこの設置業者でも大差ないと思います。JCは器具のブランドをまったく明かしませんでした。さらに、私は自分自身と家の所有の平均余命を考えたとき、保証期間が20年でも25年でも大差ないと考えます。また、技術の進歩により、それほど遠くない将来には現在の機材が時代遅れになるもっと効率的な機材が開発されているとも思います(それまで私が生きていればの話ですが)。

もう何点か挙げます。

私はJCにPPAに関する懸念、すなわちもしPPAの満了以前に家を売ることになったときには、契約の承継を引き受ける買い手を探すか、若しくはPPAを業者の「査定額」で買取りに変換しなければならず家の売却に不利になる、ということを表明しましたが、JCは「あ~ら大丈夫よ、買い手はPPAの契約審査に合格するから」と論点をすり替えようとしました。

築30年の我が家は、電力会社からの受電ブレーカの構成如何によっては発電・送電量が制限されるかまたは多額の費用で改修しなければならない可能性があることを他の業者は指摘しましたが、JCはまったくそのことには触れませんでした。

他の業者は事前に詳細な提案書をPDFで送ってきましたが、JCは我が家で面談の後に私の要求でようやく数枚のプレゼンテーションスライドのような画像ファイルを送ってきただけで、奇妙なだけでなくプロっぽくないと感じました。

総合的に言って、JCは不適切な製品とサービスを不適切な方法で手っ取り早く売りつけようとしたという強い印象を抱かせました。これが、私がソーラーシティとは契約しないことに決めた理由です。

2014年11月13日

また余計なことを… セキュア・ブート

日本に設置するために構築中のテレビジョン録画サーバのカーネルを 3.16.7 にアップデートし、放送キャプチュアカードのドライバを再コンパイルしてロードしようとしたらエラーになった。

root@h-rn312:~# insmod pt3_drv.ko
insmod: ERROR: could not insert module hello-1.ko: Required key not available

このドライバはクロス環境でビルドしているので、カーネルのバージョンを再確認して作り直してもダメ。

ぐぐってみたら、「Secure Boot」と言う機能で、要するにWindowsでマルウェアのドライバをインストールさせないために、Microsoftが「Windows 8 互換」を称するための必要条件としてBIOSで実現するように要求しているらしい。以前の 3.16.6 のカーネルではこの現象は見られなかったから、3.16.7から実装されたようだ。

マザーボード(ASUS)のBIOS 画面に行き、「Advanced」から「Secure Boot」を「Windows 8」から「それ以外のOS」に変更して回復した。

Secure Linux と言い、大多数のユーザには何の恩恵もない代わりに無用の混乱を引き起こすセキュア機能を黙ってデフォルト仕様にするのは如何なものだろうか?

2014年11月12日

GPT・EFI・RAID1 にHDDを追加

GPT

最近のPC用オペーレーティングシステムでは、大容量HDDに対応してGPT(GUID Partition Table)と言うパーティション方式が使われている。それまでのMBR(Master Boot Record)は1980年代のDOSの時代に設計されたもので、元々CHS(シリンダ、ヘッド、セクタ)というHDDの物理パラメタを使っていたが、のちにLBA(論理ブロックアドレス)を使うようになったものの、アドレスが32ビットなので2TiB(512バイト/セクタ×2^32セクタ)までしかディスク上の場所を記述できない(2TiBより大きいディスクにも使えるが、2TiBを超える部分はパーティションテーブルに記述できない)。また、MBRは元来4個のパーティションしか想定していなかったので、5個目以降のパーティションは「物理パーティション」の一つを更に複数の「論理パーティション」に分割するなどのつぎはぎで対応してきた。

GPTはMBRの制限を克服して、より柔軟性・拡張性のある新設計のパーティションシステムで、それぞれに誤り検出を備えた二重のパーティションテーブルをディスクの先頭と最後尾に記録して堅牢性を高め、事実上無制限のパーティション数(Widowsは128個に制限)、最大8ZiB(=2^73≒8×10^21)まで記述できるなど優れたパーティション方式である。

更に、GPTはMBRしか理解できない旧来のユーティリティによる事故を防ぐため、ディスクは依然としてMBRのパーティションデータを維持しており、MBRとして見るとGPT全体が一つのMBRパーティションに見えるなどの下方互換性も考慮してある。

EFI

EFI(UEFI、Unified Extensible Firmware Interface)はGPTと関連があり、PCの黎明期の資源(記憶容量)の節約が再重要課題であったMBRの時代に発案された先頭の512バイトセクタにブートローダを収めると言う現代の肥大したソフトウェアには完全に時代遅れとなったブートローダの格納方式を改め、GPTの最初のパーティション(FAT)にブートローダのファイルシステムを格納する方法である。512バイトのブートローダ笑ってはいけない。小生が最初扱ったCP/Mでは当時の単密度FDの先頭の128バイトセクタがブートローダだったから、それよりも4倍も大きかったのだ!

当然のことながら、EFIのブートシステムを使うためには、ハードウェア側のファームウェア・ブートローダがEFIブートローダを認識できなければならない。今日売られているPCのマザーボードはほぼ全てそのような仕様になっていると思われるが、MBRしか理解できないBIOSでも、MBRにもブートローダかかれており、このMBRブートローダがEFIのブートローダに引き継ぐようになっているので心配はない。

システム管理側から見ると、 ブートローダがファイルシステムとしてOSから見える空間にあることには大きな意味がある。ここで構築するRAIDシステムでも、その見通しのよさは利点となっている。

UUID

UUID(Universaly Unique IDentifier)またはGUID(Globally -)は、世界中で唯一絶対無二(と見做せる)のラベルであり、通常は計算機で発生された他数桁(代表的には16桁)の疑似乱数である。特定のオブジェクトを指定する方法として広い用途に使われており、例えばGITのバージョンなどにも使われるが、ここで関心があるのはディスクのUUID、特にパーティションのUUID。

パーティションには通常少なくとも二つのUUIDがつけられる。下は、今回のプロジェクトで生成したディスクとパーティションのUUID。

root@dvr3:~# blkid /dev/sd[ab]*
/dev/sda: PTUUID="32e9ab11-f4f9-429f-ba2a-2152b1e0c6de" PTTYPE="gpt"
/dev/sda1: SEC_TYPE="msdos" LABEL="BOOT_EFI" UUID="E6C8-88B4" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="9fa9a19d-edfa-4547-acdd-28a447847b8b"
/dev/sda2: UUID="e895041e-5b45-28e3-48f9-f6b95a9a7c1c" UUID_SUB="d37916fe-8ff6-ab8e-be2e-2be61513ce77" LABEL="dvr3:swap" TYPE="linux_raid_member" PARTUUID="f76213c2-06fa-4cce-8389-0dfd330cfb7c"
/dev/sda3: UUID="1e1befdc-8c1c-0df3-e6ff-fae3365c40dd" UUID_SUB="397fd84b-884d-ff9b-39a2-dee11c305fca" LABEL="dvr3:boot00" TYPE="linux_raid_member" PARTUUID="d574fbe7-7536-4f95-9192-d9383c682221"
/dev/sda4: UUID="ce81f465-4304-e57f-3ca5-cdc9e894e5b3" UUID_SUB="f65ff449-2a51-ac83-0a51-8bd871d01c2b" LABEL="dvr3:pv00" TYPE="linux_raid_member" PARTUUID="4ea40149-9100-41d5-98e5-ba7fa5a98512"
/dev/sdb: PTUUID="c4f133d4-4ae2-4fb7-bce5-f6eb9256887a" PTTYPE="gpt"
/dev/sdb1: SEC_TYPE="msdos" LABEL="BOOT_EFI" UUID="0085-40A4" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="93c20ab9-d77b-4ca8-8f58-f0127f7e0e82"
/dev/sdb2: UUID="e895041e-5b45-28e3-48f9-f6b95a9a7c1c" UUID_SUB="1ccd67c3-326c-2a42-8353-136e119fa651" LABEL="dvr3:swap" TYPE="linux_raid_member" PARTUUID="0df80d4a-86ad-49db-bc41-e79e5f546704"
/dev/sdb3: UUID="1e1befdc-8c1c-0df3-e6ff-fae3365c40dd" UUID_SUB="f54b5a8f-fd50-f281-0e13-5f2e76a8dc8c" LABEL="dvr3:boot00" TYPE="linux_raid_member" PARTUUID="44a25a01-c4a1-4b2b-a242-d7d93c949418"
/dev/sdb4: UUID="ce81f465-4304-e57f-3ca5-cdc9e894e5b3" UUID_SUB="47e97367-2f77-1d04-8402-91eb001271a2" LABEL="dvr3:pv00" TYPE="linux_raid_member" PARTUUID="b6842bbf-6018-430b-9177-fce9c1af7f94"

まず、各パーティションにはそのパーティションの内容に係わらず唯一絶対無二の「パーティションUUID」がつけられる。パーティションシステムはこのUUIDしか問題にしない。

/dev/sda1/dev/sdb1は問題のEFIパーティションだが、これらのパーティションにはmkfsでフォーマット・ファイシステムを作成したときに生成された、ファイルシステムごとのUUID(4バイト)が付けられている。4バイトという短さはFATのディスク構造の制限であり、ext[2-4]やBTRFSなどの近代的なファイルシステムは16バイトのUUIDがつけられる。

/dev/sda2/dev/sdb2は同じUUIDを持ち「唯一絶対無二」ではないが、これはこれらのパーティションが同じRAIDのメンバーであることを意味している。メンバー間の「個体認識」は異なるUUID_SUBで区別される。

実際には、上記の/dev/sda2/dev/sdb2からなるRAIDの上にLVMのUUIDがあり、その中の各ボリュームは固有のUUIDを持ち、更に各ボリューム上のファイルシステムのUUID、とそれぞれの階層でUUIDが付けられるが、ここでの関心はパーティションレベルまで。

OSのインスタレーション


FC20のインストーラAnacondaは、以前の版(FC5、FC13など)に比べて使いにくい。最近のこの手のソフトウェアの傾向として、Windowsを真似るだけでなく、「ソフトウェアはそれを使うユーザ自身より賢く、ユーザが究極的に何をしたいかをユーザ自身よりもよく知っている」という誤った思い込みで作られており、操作・結果の詳細をできるだけユーザに操作させない、あるいは少なくともユーザに見せないようになっており、ユーザの実行したいことがソフトウェアが想定するモデルに従わない場合は最悪の場合必要な操作が実行できない。FC20版のAnacondaもずいぶん困惑させられた。

加えて、AnacondaとEFIはRAIDと相性があまりよくない。後日、試行錯誤の末、気がついた点を述べる。

2014年9月29日

php.ini にタイムゾーンを設定する

PHPスクリプトの中で date() などの日時に関連した関数を使うと

It is not safe to rely on the system's timezone settings.
Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function.
In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier.
We selected 'UTC' for now.

のような小うるさい警告がでる。

幾つかのサイトで /etc/php.ini にタイムゾーンを設定するように書かれている。
[Date]
; Defines the default timezone used by the date functions
date.timezone = Asia/Tokyo

しかしこれは上手く行かなかった。 で、上手く行ったのはこれ。
[Date]
; Defines the default timezone used by the date functions
date.timezone =
Japan

PHPのサイトのサポートされているタイムゾーンのリストの中に「Japan」はあるが、「Asia/Tokyo」はなかった。 ごちゃごちゃ言わずに、走行しているホストの現在のタイムゾーン(/etc/localtime)をデフォルトにすればよいのにと思う。

ちなみにPHPのバージョンは 5.5.16。

2014年9月27日

今度はUSBドングルが熱にやられた。

7年前に会社からもらったラップトップの延命策として802.11nのUSBドングルを挿したら目に見えて速くなった。

で、気をよくしていたら、どうもこのドングル経由のWiFiが不安定である。長くても数時間、短いときは10分程度で接続が切れてしまい、大抵の場合、デバイスをリセットしないと元に戻らない。

大変困っていた。Windowsのドライバが壊れているのかとか、ドングルが不良かと思い、 802.11acに買い換えることまで考えた。


で、ある時閃いた。それまで何となく気になっていた、ドングルを触ったときの熱さ。このラップトップはボディに左右にUSBポートがついていて、左側のポートにドングルを入れていたのだが、そのすぐ隣に電源コネクタがあり、従って多分中には電源回路があり、ここら辺がやたら熱くなるのだ。

右側のUSBポートにドングルを差し直したら、何日も安定して動作するようになった。また熱にやられた

詰まらない間違い。でも重要な影響だった。

2014年9月5日

ロックされているPDF文書にテキストを書き込む

無料のAdobe Readerを使ってPDF文書にテキストや署名を書き込むことができる。「書き込む」と言うのは正確ではないかもしれない。「描き込む」と言った方がよいかもしれない。PDFの所定の用紙に住所氏名などを電子的に記入できるので重宝する。

ところが、セキュリティとして書き込み禁止になっているPDFには描き込めない。

これを回避するのは比較的簡単。件のPDF文書を一度PDFファイルを生成する仮想プリンタで「印刷する」とできあがった新しいPDFファイルはセキュリティロックが解除されている。PDF出力プリンタも一応「法的に問題ないだろうな?」と確認してくることもある。

小生はWindows用PDF出力プリンタとして「Bullzip Printer」をずっと使っている。

2014年8月26日

ファイアウォールサーバがまた死にかけた

仕事場から家のLANをVPN経由でアクセスしているが、突然遮断された。仕事場のインターネットが全面的あるいは部分的に使えなくなることはそう珍しいことではないので静観していたら、約30分後に復旧した。ただし、LAN上のほとんどのホストの状態をPINGで監視しているメインサーバの報告によれば、少なくとも10分以上応答がなかったので電源再投入でリブートしたらしい。

サーバのフリーズはそう頻繁にあることではないが、全くない訳ではないから「数年に」一度の事故と考えたが、その後がよろしくない。約2時間後にまた同じ現象が起きた。今度も約30分後に生き返る。明らかに何かがおかしくなっているが、もうリモートで分かることはない。多分ハードウェアの異常だろうという推測は3回目の遮断ではっきりした。

このサーバは、その先代がやはりハードウェアの異常でフリーズを繰り返すようになった後、約1年前に新調したCeleronベースの比較的軽いもの。1年でまた壊れるとは納得が行かないが、ファイアウォールなのでこれがないと我が家のインターネット接続がすべて使えない。新しいものにリプレースするとして、症状から言ってCPUの不良は考えにくくマザーボードの可能性が高いからマザーボードだけ交換するか。しかしこのマザーボードはIntel 1155なのでだんだん入手し辛くなってきている。1150にするとCPUごと替えなければならない。Amazonからメイルオーダで買ったり実験を繰り返す時間的余裕はないから、即交換するとして余った部品をどこで再利用するか、などと考えながら帰宅を急ぐ。

帰宅途中にふと思いついたのは、電源故障もおおいに可能性があるというより、マザーボードの新しさから考えてそちらの可能性が高い。

帰宅してみると4回目の自動リブートでサーバは動作している。とりあえず自動リブートを禁止して様子を見る。

インターネットへのアクセスが遮断された。二階のサーバルームに行ってみる。サーバの電源が落ちている。決まった。電源ユニットに異常がある。

別のPCの構築作業中だったので、早速そちらから正常に動作することが確認されている電源ユニットを外して付け替える。復旧した!

取り外した件の電源をテストしてみる。ACを繋ぎ、得意の24(20)ピンATX電源コネクタの緑・黒ショートで電源を入れると、内部で電源の入るプスっと言う音が聞こえるものの、ファンが回らない。ファンを触ってみると非常に固くて回らない。ファンのベアリングがダメになっているようだ。

幸いなことに部品ストックに同じサイズのファンがあったので交換すると、動いた。件のサーバも順調に動作している。修理した電源ユニットを作業中の別のPCに装着しても平然と動作している。

結局、電源その物は生きていたが、ファンが死んでいたために数十分動作すると内部が温度上昇して保護回路が動作して電源を遮断し、その後我が家の監視システムが異常を検出して電源再投入するも内部が十分冷えるまでは再動作しなかったものと結論された。

教訓というほどではないが、トラブルシュートはセオリーどおりまず大元から疑うべし。そしてスペアの電源ユニットは必ず手元にいつも備蓄しておくべし、となった。