2020年7月19日日曜日

[ラズパイ] タスク バーを復旧する

Windows でいうと「タスク バー」になりますが、Raspberry Pi だとデフォルトの「パネル」になります。

パネルを削除していないユーザ、もしくは別の環境から設定ファイルをコピーして再ログインすれば、元に戻ります。
設定ファイルは以下

$HOME/.config/lxpanel/LXDE-pi/panels/panel
時刻:

2020年6月30日火曜日

[Oracle] VIEWのSQLを出力する

Oracle のビュー定義は、データ・ディクショナリ・ビューを検索することで確認できますが、SQL*Plus で出力する場合は、システム変数の調整が必要です。

SET PAGESIZE 2000（SQLの行数、ヘッダの繰り返しを防ぐ）
SET LINESIZE 500（１行に表示するバイト数、途中での改行を防ぐ）
SET LONGCHUNKSIZE 500（これも１行のバイト数として必要）
SET LONG 10000（SQLのバイト数）

SELECT TEXT FROM USER_VIEWS
WHERE VIEW_NAME = 'view name'
時刻:

2019年9月8日日曜日

[Python ] Flask + Blueprint で no attribute 'name'

サンプルを参考に Blueprint を始めてみたところ、エラーが発生した。

if blueprint.name in self.blueprints:
AttributeError: module '...' has no attribute 'name'

どうやら、同じエラーに直面した人も多い様子。

https://flask.palletsprojects.com/en/1.1.x/blueprints/

simple_page.py
simple_page = Blueprint('simple_page', __name__)

Flask側
app = Flask(__name__)
app.register_blueprint(simple_page)

このサンプルに限らず、同じ識別子の使いまわしのサンプルが多くて、誤誘導気味です。
register_blueprint() の引数に使っている simple_page は、モジュール名などではなくて、変数名です。

違和感ある設計ですね。。。
時刻:

2019年8月12日月曜日

yum で https 接続エラー

yum で https のファイルをインストールできない場合の対処について。

IUS Community のリポジトリ追加で問題が発生した。
yum install https://centos7.iuscommunity.org/ius-release.rpm

■ 今回の状況
  1. 環境：CentOS7 64bit (DTI VPS)
  2. エラーメッセージ：
    Cannot open: https://centos7.iuscommunity.org/ius-release.rpm. Skipping.
    Error: Nothing to do

■ 問題を調査したところ、
・wget だと https に接続できる。
・curl だと https に接続できない。

yum の内部では curl を使っているため、https への接続が失敗していた。

■ 今回の対策
シンプルに対処するには、curl をアップデートすると解消する。
yum update curl
時刻:

2019年7月28日日曜日

Raspberry Pi の USB 電源を ON/OFF

Raspberry Pi 3 Model B+ の USB 電源をオフにする方法です。手順としては、事前にUSBデバイスを解放、次に電源OFF となります。

１．USBデバイス を unbind する。

単なる電源用のUSBデバイス（USBライト等）でなければ、USBデバイスを解放します。

（※もし USB フラッシュドライブ等なら、その前に umount する）
（※解放せずに下記の電源OFF をしても、モノによっては直後に再認識／電源ON となって、電源が落とせないケースあり。例えば、バッテリーを持っている USB デバイス等を USBポート2 に接続すると発生）

USBのポート番号は以下の図（内部的には、LAN ポートも USB 扱い）


今回は、iPod mini を USBポート2 へ接続している。
pi@raspberrypi:~ $ ls /sys/bus/usb/drivers/usb
1-1 1-1.1 1-1.2 bind uevent unbind usb1

この名称 A-B.C の様式は、
  • A：USBバス
  • B：バスのポート
  • C：USBハブのポート

この状態から、Raspberry Pi 3B+ のハードウェアとしては、こうなっている。
・USB の4ポートは、USBハブとして提供されている
・LANポートが USBハブのポート1 として管理されていた

さらに追加でUSBハブ等を挿していると、この名称も長くなる。追跡するにはカーネルのメッセージなら探しやすい。
pi@raspberrypi:~ $ dmesg | grep usb
[11002.555034] usb 1-1.2: Product: iPod mini
[11002.555042] usb 1-1.2: Manufacturer: Apple

iPod mini は 1-1.2 だと判明


lsusb コマンドでも番号を追跡できるが、確認できるポートは「バスのポート」なのか「ハブのポート」なのか分かりにくい。
pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 05ac:1205 Apple, Inc. iPod Mini 1.Gen/2.Gen
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

pi@raspberrypi:~ $ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
        |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
状況的に赤字が「ハブのポート」である様子。lsusb と lsusb -t の関係は Device番号 で紐づけできる。これまでの調査から USB デバイスの正体は、
  • usb1：Linux Foundation 2.0 root hub（コネクタは無い）
  • 1-1：Standard Microsystems Corp. SMC9514 Hub（コネクタは無い）
  • 1-1.1：Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
    （有線LAN コネクタ）
  • 1-1.2：Apple iPod mini（Pi 3B+ の USBポート2 へ接続中）

これで操作するデバイスが確認できたら、以下のコマンドで unbind します。
pi@raspberrypi:~ $ echo 1-1.2 | sudo tee /sys/bus/usb/drivers/usb/unbind
※ファイルの変更権は root のみなので、単にリダイレクトするのは無理です。


２．USB コネクタの電源OFF

USBハブのポート毎に電源管理できる製品でないと、ポート毎に電源OFF できない。Raspberry Pi 3B+ 基盤にあるUSBは、完全にはできないタイプなので、USBの4ポートを一括で電源OFFすることになる。（per-port power switching に対応するスマートHub 製品が必要だが、希少）

利用できるツールを２つ挙げる。
  1. 産総研のお偉いさんが提供しているツール（これはコンパイルするだけなのでコンパクト）。個人用のページのうち、「6. Implementation」にある、C もしくは Python 実装

    もしくは githubサイト（簡単なリファレンスあり、上と同じ C のプログラム）
    https://github.com/codazoda/hub-ctrl.c
  2. 上記の派生ツール（これはmake install が必要）
    https://github.com/mvp/uhubctl

今回は、hub-ctrl.c を使用する。github の説明の通りにコンパイルする。
wget https://www.gniibe.org/oitoite/ac-power-control-by-USB-hub/hub-ctrl.c
sudo apt-get install libusb-dev
gcc -o hub-ctrl hub-ctrl.c -lusb

使用方法は github にもあるが、番号のつけ方が分かりにくい。
hub-ctrl -b [Bus Num] -d [Device Num] -P [Port Num] -p [off:0/on:1]
この Port は Bus のポートでなく、USBハブのポート番号が該当する。
pi@raspberrypi:~ $ lsusb
Bus 001 Device 004: ID 05ac:1205 Apple, Inc. iPod Mini 1.Gen/2.Gen
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

pi@raspberrypi:~ $ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
        |__ Port 2: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
USBハブとして機能しているのが、「（Bus 001 Device 002）Standard Microsystems Corp. SMC9514 Hub」なので、このハブのポートの電源を切る操作となる。
  • Bus Num：1
  • Device Num：2
  • Port Num：1～5（USBハブのポート番号）

LANコネクタの電源OFF（ハブのポート1）
pi@raspberrypi:~ $ sudo ./hub-ctrl -b 1 -d 2 -P 1 -p 0
USBコネクタの電源OFF（ハブのポート2）
pi@raspberrypi:~ $ sudo ./hub-ctrl -b 1 -d 2 -P 2 -p 0

※電源管理が完全ではないので、ポート2の電源を切るとUSB全ポートの電源が切れる。ポート3～5 は個別に電源管理できない。


もしくは USBハブの番号を指定して操作する、ハブの番号は hub-ctrl ツールの中で連番を付けているだけなので、そちらで確認する。
pi@raspberrypi:~ $ ./hub-ctrl
Hub #0 at 001:002
INFO: individual power switching.
WARN: Port indicators are NOT supported.
Hub #1 at 001:001
INFO: ganged switching.
WARN: Port indicators are NOT supported.

この様式は、Hub #[Hub Num] at [Bus Num]:[Device Num] となっているので、今回ではUSBハブとの対応はこのようになっている。
  • Hub #0：（Bus 001 Device 002）Standard Microsystems Corp. SMC9514 Hub
  • Hub #1：（Bus 001 Device 001）Linux Foundation 2.0 root hub

上記より、電源を切るのは Hub #0 になる。（Hub #1 を電源OFFしちゃうと、この後の電源管理が全くできないうえ、このハブの再電源ONすらできず、OS再起動することになる。）

LANコネクタの電源OFF（ハブのポート1）
pi@raspberrypi:~ $ sudo ./hub-ctrl -h 0 -P 1 -p 0
USBコネクタの電源OFF（ハブのポート2）
pi@raspberrypi:~ $ sudo ./hub-ctrl -h 0 -P 2 -p 0

※同じく電源管理が完全ではないので、ポート2の電源を切るとUSB全ポートの電源が切れる。
時刻:

2019年7月26日金曜日

東芝gigashot の ZIF HDD からデータコピー

東芝gigashotが起動しなくなったので、内臓ハードディスクからデータをバックアップする。内臓HDDは、東芝 1.8インチHDD（MK4009GAL ZIFコネクタ）でした。

データを転送するのに、2つの変換アダプタを組み合わせた（千石電商秋葉原本店 の隣にある２号店で購入）。パソコンはWindows10です。

GROOVY HDD-USB UD-301S  
IDE接続3.5ドライブ
TFTEC JAPAN (変換名人) IDE-ZIFB35A
ZIF HDD → 3.5"HDD変換


まず、変換名人には、マニュアルなんて無いです。
ZIFコネクタは、フラップを上げてケーブルを挿します。フラップは写真（下記）の赤矢印

黒色のフラップ（分かりにくい）
 黒色のフラップ

ZIFケーブルは、変換名人側にはケーブルの青が挿せる。
東芝（青）日立（白）と区別があるが、東芝HDDなのに青が挿せない（コネクタが狭い）



ZIF（Zero Insertion Force）名前の通り「挿す力ゼロ」のはずなので、ねじ込む必要は無い。厚みが違う（青：厚め、白：薄め）ので、白だと挿せて、正常に動作した。



他に気がついた点では、
  1. 変換名人の赤ランプは、電源ケーブルを繋げばHDDの有無に関わらず点灯する。
  2. 変換名人の緑ランプはアクセスランプのはずだが、データ転送中も一切点灯しなかった。
  3. IDE変換ケーブルのUSBをパソコンに挿せば、電源もしくはHDDの有無に関わらずWindows側で一時的にディスクが認識されて消える挙動をする。
時刻:

2019年7月16日火曜日

(IFTTT)Webhooks - Beebotte 連携でエラー

今回は IFTTT を利用して
  1. トリガー：Mail（Send IFTTT any email）
  2. アクション：Webhooks（Make a web request）
    Webhooks の通知先は、Beebotte
というアプレットを作って、発生した障害を調査した記録です。

Webhooks の設定は以下
URLhttps://api.beebotte.com/v1/data/publish/[Channel]/[Resource]?token=[Channel Token]
MethodPOST
Content Typeapplication/json
Body{"data":"{{Subject}}"}
URL の根拠がリファレンスから探せなかったが、cURL の json 送信を参考にした。
https://beebotte.com/docs/publish


問題はメールの件名（Subject）でなく、メールの本文（Body）を使うと発生する。
（例）上記のBodyを変更する {"data":"{{Body}}"}

トリガーとなるメールを送信すると、このアプレットの View activity log で、エラーが確認できる。メールで送った本文（Body）の内容も併せて確認できるが、特に問題は見当たらない。

＜View activity log の表示＞
Applet skipped
Unable to make web request. Your server returned a 400



検証として、cURL を使ってメールの本文を json 送信してみる。

（１）Beebotte の Console 画面を開く
「Secret Key」と「Subscribe」の項目を埋めて、「Subscribe」ボタンをクリック
黒い Messages 枠に結果の表示あり。（これで json の受信を待機している状態）

（２）Beebotte の Console 画面で、以下のパターンを実施した結果を確認する。

[パターン１] メールの件名（Subject）を使う設定の状態で、IFTTTのトリガーとなるメールを送信

[パターン２] メールの本文（Body）を使う設定の状態で、IFTTTのトリガーとなるメールを送信
 → エラーの場合は、Console 画面に表示されず。

[パターン３] メールの本文の内容を、cURL を使って json 送信
curl -i -H "Content-Type: application/json" \
-X POST -d '{"data":"テストメッセージ"}' \
https://api.beebotte.com/v1/data/publish/[Channel]/[Resource]?token=[Channel Token]

直接状況を確認できないが、これだと問題見当たらず。Webhooks でメールの本文（Body）を使うと、何か余計な改行などで json の様式エラーとなってしまうのではないかと推測します。
（cURL のメッセージ文を途中で改行すると、「HTTP/1.1 400 Bad Request」になった。）
時刻:
登録: 投稿 (Atom)