【Monitoring】 ZabbixからESXiホストに刺さってるMegaRAIDの状態をLLDで動的に取得して監視する 
2023, March 6, Monday, 16:00 - Other, SoftWare
投稿者 @xmms
　個人でESXiを動かしていると、何かとLSIのRAID情報を取得したいと思うことがありますが、LSAではなくて既存のZabbixからデータを取得したいと思うことがあります。ありますよね(同調圧力)。
　何かいい方法がないかと見ていたらstorcliがjsonでデータを出力できることに気がついたので、ZabbixのLLDと組み合わせていい感じにデータを監視する方法を作りました。先にテンプレートのJSONを置いておきます。

Template_LSI-storcli.json


 storcliが動けばLinuxであっても情報を取得できるので、agentのsystem.run形式で作ったものも同梱しておきます。storcliの実行にroot権限が必要になるので、storcliにスティッキービットをつけたりsudoを許可したりagent自体をrootでうごかしたりしていい感じに対応してください。
　system.runは悪だ!!!!!という方は、最終的にjsonが取れればいいので、userparameterにしたりrootのcronでstorcliを実行して結果をテキストデータとして出力してログ監視するなど、linuxであればやりようはいくつもあるのでいい感じに工夫してください。
　まあ、linuxでエージェントが入っているようであれば/var/log/kernelなどをmegaraid_sasといったようなキーワードで監視していれば大体のイベントが取得できますが…。

　ESXi用のテンプレートはSSHで接続してstorcliの実行結果を取得するので、Zabbix-agentが入っていないLinuxを監視したい場合にも使えます。

前提条件


　利用するにあたり、以下の前提条件が必要になります。

Zabbixのバージョンが6系であること
監視対象上でstorcliが動かせること
作成したLDに対して名前がついていること
ssh接続が有効になっていること
ESXiホストの/etc/ssh/sshd_configのPasswordAuthentication が yesになっていること


　注意点としては、LLDとJSONのクエリの関係で、作成した論理ディスクに対して名前が必要になります。デフォルトではついていないので、storcliで監視対象全てで被らない一意な名前をつけてあげてください

/opt/lsi/storcli/storcli  /call/vall show all #一覧を確認
/opt/lsi/storcli/storcli  /c0/v0 set name=myhost01-boot #/c0/v0に対して名前を付ける


 ESXi側のSSHに関しては共通鍵認証でもいいですが、テンプレートの変更が必要なのでそのへんの設定は今回は省きます。デフォルトのkeyboard-interactiveになっていても動きそうな気がしますがテストしてません。
　また、テンプレートの形式がZabbix6形式になっているので4系では入らない気がします。LLDのためにJSONpathとカスタムスクリプトでJSを使っているので、これを元に一から作る場合であっても、Zabbix側のカスタムスクリプトでJSの拡張がされていないと動かない気がします。

　いずれにしても、4系の環境がもうないのでテストしてないですが、JSONpathは4系でも使えたはずなのでなにかのヒントにはなるかと思います。

利用方法


　まず、Zabbixに監視するためのホストを作ります。ESXiの場合はSSHで接続するので、インターフェースは参照しないので127.0.0.1のままでOKです。ホスト名だけ入れてください。



　次に、マクロに色々仕組みます。利用しているマクロは以下になります

{$IP}　接続先IP
{$PASS} SSHの接続パスワード
{$STORCLI} Storcliの配置先　ESXiデフォルトは/opt/lsi/storcli/storcliのはず
{$USER} SSHの接続ユーザ




 今思うと{$IP}はホスト作るときにIPで作って{#HOST.IP}でも良かったのでは??という気がしますが、作ってしまったのでそのままにします。また、PASSについてはデバッグが終わったあとであればSecret textに変更可能ですが、最初はクリアテキストでデータが取れるかを見たほうがいいです。

　作成したホストに今回のテンプレートをリンクさせ、LD Data from StorcliをExecute nowで実行します。正しく設定されていれば、LLDが発動してアイテムが増えるはずです。LDが増えない場合、上記の制限事項にある手順のstorcli /cx/vx set name=uniquename で名前をつけたか確認してください。Latest dataでデータが取得できているのにLDが増えない場合おそらくこれが原因です。
　同じくPD Data from Storcliを実行すると、刺さっている物理ディスクの一覧が取得できると思います。

　Latest dataが取れない場合、ZabbixからESXiにSSHが届くか、storcliのパスが合っているかなどを確認してください。

制限事項


　物理ディスクの監視ですが、ディスク、HBAのファームウェアのバージョンによっては取得できない項目があります。BBM Error countやShield State Countなどはある程度のクラスのディスクでないと値を持っていないので、ディスクによっては取得できないかもしれません。その場合は取得不可のマークが付きますが、影響がないのでそのままにするかLLDで作成されたアイテムから監視の無効化をしてください。




　また、物理ディスクの監視のために実行しているstorcli /call/eall/sall show all jで応答するJSONがかなり大きいため、搭載ディスク本数が24本などの巨大なマシンの場合はうまく取れないかもしれません。

　Zabbix6系ではTEXT型アイテムの場合、history_textテーブルに格納され、使っているDBがMariaDBであればmediumtext型で格納されるため1回のデータ取得で16MBまでは入りますが、使っているDBの種類によっては入り切らない可能性があります。参考までに、ディスクを8本搭載したマシンでstorcli /call/eall/sall show all jを実行すると22KBのJSONが出来上がります。

　調べた限り、Zabbixは1つのセッションで1GBくらいのデータを流せるようなので、おそらくSSHからのデータ取得で問題になることは少ないかと思いますが、場合によってはタイムアウトの時間を伸ばす必要があるかもしれません。　

　storcli /call/eall/sall show all jの結果については依存アイテムを分解するために実行しているだけなので、Zabbixが6系であればヒストリを「Do not keep history」にしてもLLD分解後のデータ取得は可能です。
　もともとデバッグのために1時間しか保持していませんが、コマンド実行に問題がなさそうであればstorcliの履歴については取得しない設定でも問題ないです。
→テンプレートの微調整の際にデフォルトではstorcliの実行結果を保存しないようにしました。storcliのコマンド実行結果を眺めたい場合は PD Data from Storcli のアイテムヒストリをnoneから適宜変更してください


技術的内容(うらみつらみ)


　今回、JSONとLLDを使うにあたってかなり多くの問題にあたりました。まず1つめはstorcliの返すJSONの作りが悪すぎること、そして2つめはZabbix側のJSONの処理がイケてないことです。両方じゃねーか!!!

ZabbixのJSONの扱いが微妙


　ZabbixでJSONを扱うときに2つの問題がおきます。まず1つ目は、LLDでJSONを扱う場合、見つかったキーが["LLDNAME"]とダブルクオートとブラケットに囲まれた状態で取得します。中身だけ見つけてくれ…と、せめてどうにか値に対してtrimやiregsubなどが使えないか試したのですが、どうやらここをどうにかする方法はないようです。

　そのため、アイテム名を整形するためにTemperture of {{#MR_PD_NAME}.iregsub("\[\"(.*)\"\]", \1)}というような正規表現をところどころで書く必要がありイケてないです。
　LLDで見つかったアイテムのキーについてもmrstat.pd.temp.["[\"/c0/e252/s0:WDC WD1005FBYZ-01YCBB1:WD-WMC6M0F4M8WN\"]"]というような状態で入ってしまうのですが、どうせこれは他では使わないしもういいや…と諦めました。

　2つ目は、LLDを実行するときにJSONから複数の値が見つかった場合、それぞれ[{"key": "value"},{"key": "value"}]で返答する必要があり、["value","value"]だとイテレータが動いてくれないという点です。
https://www.zabbix.com/forum/zabbix-help/419391-utilizing-jsonpath-to-setup-an-lld-macros
　これもハマりましたが、上記のスレッドのカスタムスクリプトに助けられました。なおしておいてくれ～～～～～

storcliのJSON構造がカス


　storcliのJSONの構造で苦労したのは物理ディスクの応答内容がカスなことです。一例としては以下のようになります

{
  "Controllers": [
    {
      "Response Data": {
        "Drive /c0/e252/s0": [
          {
            "DG": 0,
            "DID": 14,
            "EID:Slt": "252:0",
            "Intf": "SATA",
            "Med": "HDD",
            "Model": "WDC WD1005FBYZ-01YCBB2",
            "PI": "N",
            "SED": "N",
            "SeSz": "512B",
            "Size": "931.000 GB",
            "Sp": "U",
            "State": "Onln",
            "Type": "-"
          }
        ],
        "Drive /c0/e252/s0 - Detailed Information": {
          "Drive /c0/e252/s0 Device attributes": {
            "Coerced size": "931.000 GB [0x74600000 Sectors]",
            "Connector Name": "Port 0 - 7 x1",
            "Device Speed": "6.0Gb/s",
            "Firmware Revision": "RR07    ",
            "Link Speed": "6.0Gb/s",
            "Logical Sector Size": "512B",
            "Manufacturer Id": "ATA     ",
            "Model Number": "WDC WD1005FBYZ-01YCBB2",
            "NAND Vendor": "NA",
            "NCQ setting": "Enabled",
            "Non Coerced size": "931.012 GB [0x74606db0 Sectors]",
            "Physical Sector Size": "512B",
            "Raw size": "931.512 GB [0x74706db0 Sectors]",
            "SN": "WD-WMC6M0J95THT",
            "WWN": "50014EE0AF2FC003",
            "Write Cache": "N/A"
          },
          "Drive /c0/e252/s0 Policies/Settings": {
            "Certified": "No",
            "Commissioned Spare": "No",
            "Connected Port Number": "7(path0) ",
            "Cryptographic Erase Capable": "No",
            "Drive position": "DriveGroup:0, Span:0, Row:0",
            "Emergency Spare": "No",
            "Enclosure position": "1",
            "FDE Type": "None",
            "Last Predictive Failure Event Sequence Number": 0,
            "Locked": "No",
            "Multipath": "No",
            "Needs EKM Attention": "No",
            "PI Eligible": "No",
            "Port Information": [
              {
                "Linkspeed": "6.0Gb/s",
                "Port": 0,
                "SAS address": "0x4433221107000000",
                "Status": "Active"
              }
            ],
            "SED Capable": "No",
            "SED Enabled": "No",
            "Sanitize Support": "Not supported",
            "Secured": "No",
            "Sequence Number": 2,
            "Successful diagnostics completion on": "N/A",
            "Wide Port Capable": "No"
          },
          "Drive /c0/e252/s0 State": {
            "BBM Error Count": 0,
            "Drive Temperature": " 32C (89.60 F)",
            "Media Error Count": 0,
            "Other Error Count": 0,
            "Predictive Failure Count": 0,
            "S.M.A.R.T alert flagged by drive": "No",
            "Shield Counter": 0
          },
          "Inquiry Data": "7a 42 ff 3f 37 c8 10 00 00 00 00 00 3f 00 00 00 00 00 00 00 20 20 20 20 57 20 2d 44 4d 57 36 43 30 4d 39 4a 54 35 54 48 00 00 00 00 00 00 52 52 37 30 20 20 20 20 44 57 20 43 44 57 30 31 35 30 42 46 5a 59 30 2d 59 31 42 43 32 42 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 10 80 00 40 00 2f 01 40 00 00 00 00 07 00 ff 3f 10 00 3f 00 10 fc fb 00 00 5d ff ff ff 0f 00 00 07 00 "
        }
      }
    }
  ]
}


　各情報について、なぜ変動する値がキーになっているのか、微妙に違うキーに値を入れるのやめろ、と言いたくなります。例えば、ディスクの温度とシリアルを取りたい場合のデータの位置は以下になります。

json.Controllers[0]["Response Data"]["Drive /c0/e252/s0 - Detailed Information"]["Drive /c0/e252/s0 State"]["Drive Temperature"] = " 32C (89.60 F)";
json.Controllers[0]["Response Data"]["Drive /c0/e252/s0 - Detailed Information"]["Drive /c0/e252/s0 Device attributes"].SN = "WD-WMC6M0J95THT";


　なぜ以下のようにしなかったのか…

json.Controllers[0]["Response Data"]["PhysDrive"][0]["Path"]= "/c0/e252/s0";
json.Controllers[0]["Response Data"]["PhysDrive"][0]["SN"] = "WD-WMC6M0J95THT";
json.Controllers[0]["Response Data"]["PhysDrive"][0]["Detailed Information"]["State"]["Drive Temperature Celsius"] = 32


　もともとディスクのシリアルと型番を元にクエリを投げて温度を取ろうと思い、上記のような構造であればJSONだけでクエリが完結したのですが、このような構造のためLLDのキーに色々仕込む必要がありました。
　内容としてはカスタムスクリプトに正規表現でパスを取り出すものを仕組み、LLDの名前として取得して、LLDのアイテムプロトタイプで正規表現で取り出す、という内容です。

　LLDのカスタムスクリプト

var array = JSON.parse(value)
var drives = []
for (var a in array) {
for (var ar in array[a]){
if ( ar.indexOf("Detailed Information") != -1){
prefix=ar.replace(/(Drive\s\/[\w\/]+)\s.*/,"$1");
path=ar.replace(/Drive\s(\/[\w\/]+)\s.*/,"$1");
detail=prefix+" Device attributes";
drive=path+":"+array[a][ar][detail]["Model Number"].trim()+":"+array[a][ar][detail].SN
drives.push(drive)
}
}
}

var len = drives.length;
var x = 0
output = "{ \"data\" :["
for (; x < len - 1; x++){
output += "{\"Name\": \"" + drives[x] + "\"},"
}
output += "{\"Name\": \"" + drives[x] + "\"}"
output += "]}"
return output


　上記のカスタムスクリプトでこのような名前が取れるので、これをLLDで見つかったディスクとして認識させます。




 そして、LLDのアイテムプロトタイプにて、JSONpathでデータを取得する際に.iregsub("\[\"([0-9a-z\/]+):.*\"\]", \1)}で一番最初のスロットナンバーの情報を切り出してJSONのキーに埋め込んでいます。

$.Controllers..["Response Data"]..["Drive {{#MR_PD_NAME}.iregsub("\[\"([0-9a-z\/]+):.*\"\]", \1)} State"]["Drive Temperature"]


　イケてねえ…。まあイケてないものをイケてない方法でどうにかしようとしているので汚くなるのは必然ですが…。

まとめ


　Zabbixは仕事でもプライベートでも使うことが多く、いろいろな意味で一番柔軟性が高い監視方法だと感じています。特定のログを検知しても水曜日の6-7時だけは検知を除外する、というような要求でも、Zabbixであればそれなりに複雑なトリガーの条件式で対応できますが、他の監視方法だとかなりキツイ、もしくはそんな方法はない、という事なりがちで、良くも悪くも使い込めば使い込むほど他のものが使えなくなります。

　Zabbixは以前の仕事でそれなりに使っていたつもりだったのですが、今回やった内容は全く知らず、「え、そんなことできたの…」という発見もかなりありました。Zabbixはパズルですが、どうにかする方法はあるのでみんなで沼に沈みましょう。

　おそらく、今回の方法ももう少しスマートな方法がある気がしますが、とりあえず動いたので参考にはなるかと思います。

追記:
　その後実際に役に立ってしまったので動作については問題ないと思います。また、storcliのデータについてはデフォルトではヒストリを取らない設定に変更し、ディスクのステータスの追加のデータを取るように変更しました。何が起きてるかを知りたいときには手動でヒストリの取得を有効にしてください。
　また、コントローラーが複数存在する場合に、2台目以降のコントローラーのデータが上手くパースできていない問題も修正しました。




[ コメントを書く ] ( 277 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 244 )  |  
【その他】BlogをホストしてるVMを新しくした 
2019, August 3, Saturday, 02:03 - Other
投稿者 @xmms
　なんだかんだ長くこのブログも動いているのですが、中のOSが古くなってきたので新しくしました。もともとは物理マシンでDebian 6(の超初期版)が動いていたのですが、VM環境ができあがりつつあったのでイメージをddでVMに持ってきて、その後式年遷宮(新規VM作成後にコンテンツコピー)でDebian7に移行しました。その後dist-upgradeでDebian8までは持ってきたのですが、OSデフォルトのPHPのバージョンアップ等の絡みでそのまま塩漬けになっていました。

　しかし、7から移行した関係でApacheのバージョンが2.2のままだったので(果たして8になったと言えるのか…)いい加減新しくしたいと思っていたのですが、家で動いているZabbixも7から9に移行しようとして失敗したのでdist-upgradeはやめ、環境が古すぎてなんで入っているのかわからないパッケージやもはや使ってないDBなどもあり、この辺をきれいにする意味も兼ね、今年7月に出たDebian10の評価を兼ねてまた式年遷宮しました。

　ちなみにZabbixマシンもMySQLのダンプを吐いてまっさらなDebian9のVMにインポートし、Zabbix-server周りの設定だけよしなに変えて式年遷宮しました。MySQLからMariaDBに変わったり、昔から残ってるinitスクリプトとsystemdの関係がうまく行かなかったりしてdist-upgradeで色々つらい感じになりました。

　ただ、Debian10のマシンにそのままコピーだと(シンプルな作りのこのブログシステムであっても)いくつかPHP7で廃止された関数を使われていた関係で500が帰ってきてしまい、それを直したりデザインを少し変えたりしたらなんだかんだで丸2日くらいかかってしまいました。


　とりあえず表面上は動いているのですが、何が問題が出そうで怖いです…

[ コメントを書く ] ( 506 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3.1 / 796 )  |  
【その他】スマホが死んだ/USBハブ付きGibEケーブル買った 
2017, April 22, Saturday, 17:10 - Other, HardWare
投稿者 @xmms
　自分は1-2世代前の安くなった中古のスマホを買って適当なSIMを挿して使っているのですが、去年の2月くらいに買ったSOL25 (Xperia Z2)が車に轢かれて死にました。手元に来て享年1年でした。




　顛末としては､

雨が降っていたので、出ようとしたバスに駆け乗る→帰宅→1時間後、直前まであったスマホがないことに気がつく→Ggoogleのデバイスマネージャからもオフライン→駅前の交番までいき、遺失物届け出がないか確認→遺失物には来てないのでとりあえず紛失届を出す→帰り際、ちらっと見たら道端に転がっている見覚えのあるフォルム→死体発見→5分前に出した紛失届を取り下げ

　といった感じでした。 割と気に入っていたのにあまりにも悲しい別れでした。まあ、盗まれてデータ抜かれるよりはマシなので見つかってまだ良かったというべきでしょうか…

　発見当初は電源も入らない状態だったので、とりあえずUQMobileのSIMとマイクロSDを摘出したところ、マイクロSDは生きていたのですが、SIMはマイクロSIMが刺さる機種が手元になかったので生死が不明でした。
　手元のゴミ箱を漁ったところ、4000円だったのでとりあえず買ったSHL24が見つかったので､SIMを切って差し込み､動くかどうかだけみてみました｡
　結果は､APN設定は必要でしたが､SIM自体はそのまま動いたので､しばらく代替としてSHL24を使う事にしたのですが､さすがに今となってはちょっと動作が厳しいです｡

　その後､Zeonfone GoとButterfly 3(HTV31)を入手したのですが､ZenfoneはSIMサイズがマイクロなので 再度変換が必要になり､HTV31はVoLTE対応のSIMが必要(手持ちの物は非対応)になったので､どちらを使うにしてもそのままでは使えないのでしばらくはSHL24にルーターになってもらう必要がありそうです｡｡

　Xperia Z2の方は､バッテリへのダメージに依る爆発におびえながら、しばらく電源に繋いでいたところ電源は入るようになったので、いくつか欲しいデータがあったので何とか取得できないかあれこれしました。幸い?カスタムファームを入れていたので電源+VolDownでTWRPのリカバリシェルに入り､ADBドライバが通じたので何とかデータをサルベージで来ました｡





　まあ､画面が見えないので多分リカバリシェルが立ち上がってるだろう､なのですが｡｡ちなみにリカバリ画面だとMHLケーブルを繋いでも何も出力されません。こういった事態に備えて何かしらの方法でリモート接続を出来るようにしておいても良いかもしれませんね…。



　閑話休題､最近のUltrabookのような薄型PCだとUSBポートが枯渇したり有線イーサネットポートが無かったりして不便なので、秋葉原PCネット地下の何とも怪しげなUSB3.0+GibE搭載ハブ?ハブ付きNIC?を買ってみました。




　前情報は何もありませんでしたが、開けてみるとKY-688というモデルで、中身はVIAのスイッチチップ+Realtek RTL8153という当たり障りのない構成でした。

　ネットワークパフォーマンス的には、iperfで940Mbps/上り下りが出て、USB3.0のスピードも200MB/s程度まで出ることは確認しましたが、手元にそれ以上速いデバイスがないのでどこで飽和するかは謎です。
　Surface3ProとL2的に繋がっているVM(AX3650S-48T4XW経由で10Gスイッチ接続)との計測結果です。

$ iperf -c Surface3Pro -i 10 -t 60
------------------------------------------------------------
Client connecting to Surface3Pro, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local 172.20.1.66 port 60313 connected with 172.20.1.211 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 10.0-20.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 20.0-30.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 30.0-40.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 40.0-50.0 sec 1.10 GBytes 941 Mbits/sec
[ 3] 50.0-60.0 sec 1.09 GBytes 935 Mbits/sec
[ 3] 0.0-60.0 sec 6.57 GBytes 940 Mbits/sec


　クライアントとサーバを逆転しても変わらないので逆は省略

　RTL8153チップは最近のLinuxカーネルやWindows10ならそのまま認識できるので、軽作業用途には癖が無くておすすめです。ヘビーユースに耐えられるかは謎ですが。

以上です。



[ コメントを書く ] ( 698 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1531 )  |  
【その他】ごみスクリプト置き場 
2014, April 11, Friday, 01:08 - PC, Other, SoftWare
投稿者 @xmms
　某所にいたときに不毛な作業を少しでも楽にしようと足掻いた時に作ったゴミを置いておきます。たまにこれをベースに何かを作ったりするので主に自分のためのメモですが。
　内容としては、Expectで複数サーバに対して同一コマンドをsuして実行するだけのゴミと複数のサーバから一か所にファイルをSCPで集めるか送るだけのゴミです。

もっと読む...

[ コメントを書く ] ( 2220 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1820 )  |  
【その他】Nexus7の充電ケーブルを作る 
2012, November 11, Sunday, 03:55 - Other, Mobile
投稿者 @xmms
前に書いたメモが出てきたのでせっかくなので掲載します。

　会社の開発用としてnexus 7が来たのですが、ふと充電をしようとしたところ、何故か純正のACアダプタ以外のAC-USBやモバイルブースターでは充電が開始されないのです。




　電圧/電流のどちらかが足りていないのかと最初は思いましたが、amazonで売っている5V/2.1A出せるという格安バッテリでも充電が開始されませんでした。このバッテリは過去にipadも充電できた実績があるので、どうやらそれ以外に要因がありそうでした。

　そんなことを言っているとツイッターで「結線が特殊なのでは？｣と言われ、そういえば、古くはW-03es、IS02/01やSH09Cなどでも「PC以外から充電するには充電専用ケーブルでないと認識しない｣ということがあったので、充電用のケーブルを試してみました。秋葉原の三月兎やあきばおーあたりで100円程度で売っています。




　これに差し替え充電すると、しっかり認識されました。




　これの違いは何か、と以前に調べたところ、どうやらUSBの2番と3番がショートしているようです。
　今まで作ったことはありませんでしたが、自分でも作れるのでは？というか本当にそれだけなの？と思い、作ってみました。

　上がmicro（スマホ）側で、下がA（充電器）側です。このスマホ側を撚ります。間違えた結線をしたら危険なので、真似する場合はA側はオープンで絶縁してください。（あるのか
　当たり前ですがPCとのデータのやりとりには使えなくなります。




　AC側が結線されていなければスマホ側を間違えても大丈夫ですが、間違えて電源のラインを剥いて、それがシールドのアルミ泊やヒゲに接触してショートするなんてことも…。
　まあこのブログ読んでる人はそんなことはわかっていると思いますが。

　幸い、このケーブルは一般的なケーブル色でしたが、一応テスターなどで調べてから結線してください。以前に被覆を剥いたら中のケーブルが全部黒色一色で片っ端から剥いて結線を調べたなんてこともありましたが…。

そしてつないでみると、無事に充電が開始されました。実験なのでセロテープ絶縁です。汚いですが気にしない。




　A側のショートを解除してみると、やはり充電されません。「放電中」ではなくて「充電していません」とでるのがケーブルが断線しているときとの違いです。




　こんなことせずに、おとなしく100円の充電ケーブルを買えばいいだけの話ですが、出先でnexus7を充電しようと思ったら社外製AC-USBとデータ通信用のMicroBケーブルしかない！というときなどには自作する必要があるかもしれません。（ねえよ

　ちなみに、充電専用ケーブルを使うと、AndroidをPCから充電したときにUSBデバイスとして認識させずに充電できるので、通常より早く充電できます。なので、どのみち充電専用ケーブルは1本くらい持っておいた方がいいかもしれません。


[ 1 コメント ] ( 1992 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3.1 / 2006 )  |  

<戻る | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 進む> 最後へ>>