Archive for the ‘My software’ Category

去年の夏に作った、YL-40の温度センサ(サーミスタ)で室温を測定する仕組みの続き。冬に低温での補正をしたが、予想どおり、その時に調整した範囲を超えたらズレて来た。本物の温度計と比べたら、25.5℃以上で、補正式の想定する温度差より0.3℃くらい低い(→ 温度計からは0.6℃くらい低い)感じだった。合わないのは嫌けど※、測定も調整も面倒なので延期して居たものの、段々差が大きくなったので 仕方なく先月の中頃に着手した。

※とは言え、そもそも、0.6℃くらいの差なんて「誤差の範囲」なんだから気にしなくていいという話(悪魔の声)もあるw

気分ならぬ気温次第でチェック・調整できる温度が決まるので なかなか進まなかったが、近頃は暑い日も出て来て大分進んだ。今日は室温が26.5℃くらいまでチェックできたので、去年の夏の出来上がった頃の温度(室温: 27.5-28℃くらい)まで もう少しだ。

サーミスタの温度の補正に関しては、素子の特性の温度変化(下を参照)以外に、基準として使った温度計(「シチズン大」)と温度センサの応答速度(熱容量)の違い、シチズン大の特性・精度、ADCの分解能や性能※や特性変動、それに、隣にあるディスプレイの熱の影響や空調とそれに伴う室内の気流も関係しているので、なかなか単純ではない。

※当初は、オフセットのグラフ(赤の点線)に見られる、不自然な変曲(屈曲)点はADCの性能(オフセット(上下)、直線性(曲がり)、変換精度(傾き))によると思って居たが、今はサーミスタの特性によるものかと思っている。

それでも、なぜか飽きずに(暇に飽かせて?)温度の測定・差のチェックと補正式の改良を続けて、どうにか満足できる感じになった。

冬には一つの直線で補正したが、(ちょっと前から薄々感付いて居たように、)それではうまく行かず、今は4つの直線で補正している。補正のためのオフセット(センサの温度に加える量)はグラフの赤の点線である。どうも、センサの特性に いくつかの変曲点があるようで、妙な形になっている。

書いてから思い出したが、冬に試行錯誤していた時、どうも19℃辺りに変曲点がある気がして2つの式にしていたが、それは不自然だと却下して1つにした。(グラフ: 黒の点線) 当時は低温だけだったので1つでも何とか合ったが、今となっては最初の勘が当たっていた。

補正パラメタの調整は、補正後の温度の線(グラフ: オレンジの直線)が上下に広がる測定点群の中央を通るように、あるいは、センサとシチズン大の温度差のグラフ(これは補正後の温度の線に沿って上下を拡大したものと等価である)で点群の分布が正負(上下)均等になるように、補正式(オフセット)が通る点を設定している。欲を言えば あと2本くらい増やしたいが、面倒なので しないで済ませたい。プログラムの作りを、直線の本数(実際には、補正式が通る点の数)を任意に増やせるようにすれば少しは手間は減るだろうが、それも面倒だw

まあ、そこまでやるなら、きっと「うまい曲線」があるはずで、補正(オフセット)のグラフは いかにも良く見る形だけど どういう式かは浮かんで来ない。: 3次式を45°の軸でフリップさせた形? → 1/3乗の式? (← 似ては居るが、0付近が垂直になるので違うようだ。 ← 式の構成によっては そうでもなさそうだ。) だとしたらなぜ?

そこで画像検索してみたら、サーミスタのBという定数は温度で変わるので(だから、実際には「定数」ではない)、温度とBの関係を求めて正確な温度を求めている方が居た。だから、理想的な補正式(曲線)のグラフを描けば そういう(温度に対するBから温度の補正値を対応させる)形になるのだろう。※ 実際、参照したページの「図6:出力電圧から「変数B」と「定数B」でサーミスタ温度に換算結果」は僕の補正のグラフと何か関係ありそうな雰囲気だ。

※実際には、上の方法では正確な温度が直接求められるので「補正」する必要はなく、補正式のグラフも意味がない。

ところで、この方は どうやって任意の温度を生成しているのか分からないが(恒温槽?)、僕にはそれができない(実際には、現在と同様に いろいろな室温で測定すればいい)のと、補正式を作り直すのが面倒なので(こっちが大きいw)、とりあえずは現状のままにしておく。

温度域別のグラフでオフセットを比べると、低中温域(21℃くらいまで)は従来(グラフ: 黒の点線)と改良版(グラフ: 赤の点線)の差が小さいので問題なかったのだが、中高温域では差が大きくなって、最初に書いた「温度が合わない」問題と辻褄が合う。実際、23℃以上(→ グラフ)でのオフセットの差は大ざっぱには0.3℃以上で、(最初に書いた)僕の印象に合う。

改良版の補正式を使用したところ、現在のところは、(室温が急激に変化しない状態では、)シチズン大との温度差が概ね(ひいき目に見て)±0.3℃以内※に収まるようになった。

※測温系の分解能(ADCと回路構成に依存する)が約0.24℃なので、これくらいなら許せる。

夏に近づいて室温が28℃くらいまでになれば(、一周回って)、補正の調整は ひとまず終了だ。

が、上に挙げた、サーミスタのパラメタBを温度の関数として温度を求める方法が結構良さそうな気が しつつあるし、センサ類の経時変化や夏の測定方法が今一つだったかも知れないので、また差が出る気もしている。

まあ、その時はその時だ。

なお、Bを温度の関数として温度を求めるにしても、その式は僕の補正式を含めた温度計算式を滑らかにしたものに近いはずであるだろうから、現状からの大きな精度向上は期待できなさそうな気はする。今の温度差は温度計算式以外の要因(特に熱容量の差)も大きいと思うからだ。

 

 

PS. 本題には全く関係ないが、y= x1/3のグラフを探していたら、「y=1/3x二乗のグラフらしんですけど−」という質問(?)があって、僕だったら何を答えていいか分からないところを ちゃんと答えている方が居て感心した。

偉そうだけど、「これの何が分からないのか全く分からない」というのが正直なところだ。その質問を理解して教える教師は偉いと思う。ただ、その教え方(「考え方」)が学校式とか受験用の気がして、本当に実用になるのか疑問はある(もちろん、教師次第だろう)。

 

更に離れるが、上の前か後に、「実はE= mc2の"2"は1.9・・・とかじゃないのか」という質問に、正しいだろうが全然説明になってない、「当たり前のことだ。勉強してないの?」みたいな回答をし、その後、良くある訳の分からない深過ぎる話(δだの数直線だの間隔・連続だの)を書き連ねた人が居たが、そういうのが居るから物理とか数学が嫌いな人間が増えるのだと思う。

実際にグラフを描くと、E= mc2とE= mc1.99は全く違う(値になる)と思うが、式の見た目は近く見える。それに、上の木で鼻を括ったような回答の奴自身も「近似的に証明されている」とも書いているのだから、1.99・・・だったら かなり近いかも知れないではないか。(数学嫌いなので知らんけどw)

 

更に脱線して、別の質問「数学が特異な人たちは、こういう数式が分かるんですか?−」でもやっぱりオタ偉そうな人が多くて苦笑した。数学嫌いの僕は こんな面倒な式は理解する気は全くなくて、必要ならプログラムを書くだけだ。

しかも、この式には間違いがあるではないか(回答を読んで分かった)。なのに、気付かずに したり顔で偉そうなことを書く連中って一体???

あと、回答にあったが、これが誤差を計算するものなら、絶対値でなく2乗の理由が理解できない(全部の回答を読めばいいのかも知れない)。「幾何学的な性質」とか サラッと書かれても「は?? 何ですか?!」だよ!!

だいたい、以下は すごい違和感しかない。

誤差には正も負もあるので、打ち消しあってゼロになったりするのは困る。
だったらを2乗すればいい。
全部プラスの数字にして、それを全部足し合わせて、足した個数で割り算する。
もともと2乗していたんだから、ルートすることでもとに戻せば、1回あたりの誤差として使える

僕にすれば、正負で打ち消し合うのが困るなら、まず、絶対値だ。なぜか2乗して、それを加算したのをsqrtしたって元に戻るとは思えない(ここは すごく強引だと思う。: 2乗は非線形だから、そのあとに加算したものをsqrtして線形に戻るかって話だ。まあ、多くの専門家が何も言わずに使うのだから問題ないのだろうけど、それが本質的に問題ないのか、実用的になのかは重要だ)。それよりは、絶対値を加算して平均したほうが ずっといい(素直だ)と思う(実際、上の回答の2乗に関係する行(2, 4行目)を除けば、絶対値のほうが適しているのに、なぜ2乗なんてして処理を増やすのだろうか)。まあ、きっと何か理由があるんだろう。

僕は(正しかろうがそうでなかろうが、自分の用途に問題なく使えるのであれば、考えるだけ無駄・本質でないので)「そういうもの」として粛々と使うだけだ。

 

と、最後はなぜか 数学(が得意気な人)に対する怨嗟になってしまった。。。

  •  0
  •  0

少し前から気になっていたのだが、バックアップに使っているクラウドストレージの認証情報を平文で保存しておくのは良くないので、ちゃんとしようと思った。

ストレージに限らず、サーバのアプリ(例: 某有名ブログサーバ)では、時代遅れ(そのうえ、恥知らずにも長年弱いままにしている)にもID, パスワードをテキストファイルに平文で保存しておくものが多い。

ユーザの認証情報はDBに暗号化して(実際にそうしているかは不明)格納しても、DBのID, パスワードは平文という間抜けさだ・・・

(5/4 18:34) ブログサーバソフトの設定が暗号化できないか調べたら、やっぱりなさそうだ。それどころか、Stack overflowみたいなフォーラムで、ある人が「設定を暗号化しても使う時は復号化するだろうが。そこをハッキングされたら同じことだから無意味だ」みたいに回答していて苦笑した。

確かに文面としては間違っていないが、そういう1/0の考えをするなら、DBの暗号化どころかキーリング(以下参照)でもなんでも、すべての保護機能・手段が無意味・不要になってしまうが・・・ こういう輩が被害に遭うのではないか。

ちょっと考えたが、(面倒かつ重くなりそうだけど)設定にアクセスするところを改造すれば暗号化できるように思う。誰もやってないのは 不可能なのか興味ないのか。いずれにしても、「鍵をどうするか」(以下に書いている)っていう問題はある。

問題は、そういう情報を暗号化する(それ自体は容易)として、それを使う時には復号する必要があり、その暗号化・復号化のための鍵をどこに保存し、どうやって取り出すかである。誰でもアクセスできるようなところに保存したら、全く意味がない。特定ユーザ(のプロセス)に許可するとしても、それに成りすまされたら駄目だ。

調べてみると、「ログイン」のような操作をしないシステムでは暗号化して保存するのが難しい(復号する鍵をどうするか?)ので、上述のサーバの弱さは どうしようもない面があることが分かった(けど、多くのシステムは「それなりに」ちゃんとしているのではないか?)。

「ログイン」の操作自体が重要なのでなく、そのコンピュータの外(部外者が容易にアクセスできない場所: ログインの場合は、ユーザの頭(注: ポストイットの場合も多いw))に鍵を保管し、そこから鍵を入れることが重要なのだと理解した。

これは推測だが、Windowsは必ず(一度は)ログイン(ログオン)をするので、この辺りが結構うまく行っているのではないか。Windowsサーバは使ったことないが、普通のデスクトップではログイン情報を保存できるから、それに似たような感じなのではないか。ただ、保存したログイン情報の暗号鍵は どうしているのだろうか?

更に推測だが、その辺りはNTの時に苦労していたのかも知れない(昔、そんなことを本で読んだ記憶がある: 内部で抗争しつつ作ってたんだったか?)。

そういう訳で、デスクトップなら、前に書いた(その稿の暗号化の話は、この問題を考えていて思い付いた)GNOME keyringが使えそうだが、サーバでは難しい。

というのは、GNOME keyringは(デスクトップの)ログイン時にキーリングをアンロック(≒ 復号化)するが、ログインせずに動いているサーバではアンロックするタイミングがないからだ。

GNOME keyringの処理を少し調べてみたら随分原始的で、ログイン時に入力したパスワードをそのままアンロックする処理に送り込んでいるだけのようだ・・・

ここはもう少し賢く、パスワードのハッシュを比較するとか、認証サービスに問い合わせた結果でアンロックの可否を判定するとか やりようはあると思うが、遅れているのだろう。その辺りで使われているPAMには そういう上等な機能があるのだと思って居たが、そうではないのか、GNOME keyringが使っていないのか。

ところで、僕のデスクトップは自動ログインでログインする(パスワードを入れる)タイミングがないのに なぜか使えているので、不思議に思って調べたら、自動ログインの場合はキーリングのパスワードがなく(空)、暗号化されていないことが分かった。

実際に確認したら、キーリングは単なるテキストファイルで、普通に読めた。。。: 間抜け過ぎる!

そういえば、忘れて居たが、結構前に、ログイン後にダイアログが出るのが鬱陶しいのでパスワードを空にしたような気がする。 (← 良くやる「馬鹿なこと」そのもの!)

 

結局、デスクトップもサーバも脆弱だったというオチだった。それで(、まずはデスクトップを)どうにかしたくて考えたが、余りいい案はなかった。以下に書く。

  • × GNOME keyring以外(例: gpg)を使う。: 安全に鍵を保管する問題は同じなので無意味。
    • GNOME keyringでもgpgでも、TPM (Trusted Platform Module)の機能を使えばできそう(な気がした)だが、PCもサーバも非対応である。
      • ただ、TPMへのアクセスの許可はどうするのか分からない。それを保存したユーザならできるとかでは余り意味がない。これに認証が要るならログインと同じことだ。
  • △- [デスクトップ] 自動ログインを止める。
    • もしもの時に、家族がPCにアクセスできなくなる。
      • 一応、起動したあとで見るべき場所が分かるようにしているし、PC以外の手段も用意しては居るが、「面倒」とか「分からない」とかでアクセスしない可能性が99.9%と思われる。(その時は僕の手を離れているので、それでも良い。)
  • △+ [デスクトップ] GNOME keyringにパスワードを付けるが、自動ログインのままにし、ログイン後にGNOME keyringを最初に起動した時に入力する(ダイアログが出るはず)。
    • サーバでは、gnome-keyring-daemon --unlock にパスワードを入れればアンロックできるので、どうにかして入れれば良い。
      • なお、Xの動いていないサーバでは、dbus-run-sessionでgnome-keyring-daemonを動かす必要がある。
    • アンロックしない限り、キーリングを使うプログラムは動かなくなるが、(上記の)家族がアクセスできなくなる問題は回避できる(家族がアクセスするファイルは暗号化しないとする)。
  • △ [デスクトップ] 外付けUSBメモリなどに鍵を保管しておき、最初に読み込んでキーリングをアンロックする。
    • 盗難などに弱いが、自動ログインしている時点で脆弱なので良し?
    • サーバでも、最初(再起動後)にデスクトップから鍵を送るようにすれば、同様にできる。ただ、sshでアンロックするプログラムを起動するほうが楽かも。
    • 面倒な割に実効性は少ない?
    • ちゃんとやるなら、生体認証デバイスのようなものを使うのがいいのだろう。
      • 単なる思い付きだが、銀行の認証のようにスマフォで指紋認証できたら便利だがなあ・・・
        • でも、これは既にありそうなので、あとで調べたい。
        • → (既にあるものがなければ、)直接 スマフォの指紋認証を使うのは難しそうだが、スマフォから鍵を送ってアンロックするのはできそうだ(基本部分は自作の画像転送の仕組みが使える)。スマフォは指紋認証で開くので、間接的には指紋認証を通すことになる。PCだけでなくスマフォ、そのうえに この方式までハッキングされなければ、きっと安全だ(要確認)。 (18:31)

 

いつものように僕が間抜けなことを実感した。とりあえずは、GNOME keyringにパスワードを付けて暗号化し、ログイン後にアンロックしようと考えている。

どこまでしっかりすればいいか分からない(おそらく、どこまでやってもキリがない)が、とりあえずは、間違ったり予期せぬ問題で認証情報の入った設定ファイルが流出しても ひどいことにならないようにしたいと思っている。

その点でサーバ(で動かしているアプリ)は頭が痛過ぎるが、根本から駄目なものは(すぐには)どうしようもないから、デスクトップをやってから徐々に何とかしたい・・・

そこにSE Linuxが出て来るのだろうか? (すごく面倒だってことしか知らんけど) それに似たようなものにAppArmorがあり、使っているLinuxに既に入って居るが、どういう関係なのかは分からない。 (やっぱり、面倒だってことしか分かってないw)

 

(5/3 8:21) GNOME keyringにパスワードを付けて暗号化するのを試したら、いくつか思い違い(あるいは細かい情報)が見つかり、やろうとして居たことが容易にはできないことが分かった。

まず、デフォルトのキーリングが暗号化されている場合、ログイン時に自動でアンロックすることはできる。最初に入力したパスワードが保存され※、次回のログイン時にそれを使って自動でアンロックできる。ただし、(上に書いたように、)自動ログインの場合はできず、パスワード入力ダイアログが出る。

※パスワードはloginキーリングに入る。

そして、ログイン時にキーリングをアンロックする時、gnome-keyring-daemon --unlockで解除するのに指定するのはデフォルトのでなくloginキーリングのパスワードで、それはログインパスワードである。 (確かにそうで、都合良くデフォルトキーリングと思い込んでいた。)

 

それで、ログインまたは起動時にデフォルトのキーリングがアンロックできないと、それを使ういろいろな自動起動アプリに支障が出る(例: Evolutionはメール取得できない)ので、ひとまずは自動ログインを解除した。

ログインパスワードを外部から入れてloginキーリングをアンロックするとしても、ログインまたは起動時にタイムリーに入れないと不都合が起こって嫌なので、「スルっ」とできる方法やデフォルトキーリングの解除を保持する方法を考える必要がありそうだ。

本質でないところにも面倒があるな。

(5/3 19:44) 例によってしつこく粘り強く試行錯誤していたら、大分近づいた。: 自動ログインで起動したあとで、そうでない時のようにloginキーリングをアンロックして、デフォルトキーリングのアンロックを自動でできるようにする手順が分かった。以下のようにすれば良さそうだ。

  1. キーリングを使いそうなログイン時の自動起動アプリを停める。: 完全には無理だった(使っていそうなもの(以下に例を示す)を随分停めたが、まだ起動後にログインパスワード入力のダイアログが出る)が、何とかなる。
    • GNOME keyring daemon, seahorse, Vivaldi, Firefox, Spotify, Thunar, Dropbox, Evolution, Seamonkey, Joplin
    • 上の他に、Policy kitとNetwork Managerも怪しかったが、起動しなくなりそうなので試さなかった。
  2. 再ログイン(自動ログインを設定してreboot)する。
  3. 起動後、起動してしまったgnome-keyring-daemonを停める。
    • pkill -TERM -f gnome-keyring-daemon
  4. gnome-keyring-daemonにログインパスワードを入れて起動し、loginキーリングをアンロックする。
    • echo -n LOGIN-PW | gnome-keyring-daemon -r --unlock
      • 注: パスワードの最後に改行があるとアンロックに失敗する(が、エラーにならないので分かりにくい)。なので、キーボードから手で入力するとアンロックできず、うまく行かない。
      • gnome-keyring-daemonのオプション -r は不要だが、念のために指定した。
    • パスワード入力ダイアログを出す例
      • zenity --password | tr -d '\n' | gnome-keyring-daemon -r --unlock
  5. キーリングを使う(自動起動)アプリを起動する。
    • 例: seahorse, Evolution
    • 実際に使う場合はスクリプトで一括自動起動がいいか。

いろいろな落とし穴があって苦労したが、どうにかなりそうな感じだ(いろいろ作るのは面倒だが・・・)。デフォルトキーリングのパスワードは複雑なので入れるのは手間だが、ログインパスワードはsudoコマンドで いつも入れているから、それほど面倒ではない。それに、この方法なら、上に書いたような、スマフォからパスワードを入れるといった複雑な処理が不要になって好都合だ。

結局、最初にログインパスワードを入れるなら自動ログインでない場合と同じではないかと思われるが、そうではない。僕から見れば同じだが、(もしもの時に)家族が起動した時に、パスワードが分からなくてもデスクトップが開けて ある程度のことができる点が違う。できないのは、上の例に挙げたようなアプリを使う作業だが、そういうのは不要だし することもないだろう。

他に分かったこととして、dbus-daemonを停めるとデスクトップが終わってしまうことがある。以前から何度か、突然画面が真っ暗になって「全部終わり」になってしまうことがあったが、これだった(スクリプトの作成・確認中などに間違って停めてしまった)ような気がする。詳しくは分からないが、重要な要素なのだろう。

(5/12 9:03) 上の手順で使う自動起動アプリを起動するスクリプトの詳細を考えたものの、作るのとデバッグが面倒で保留(うだうだ)していたら、何も作らずに済ませる うまい手を思い付いた。

デフォルトキーリングにパスワードを設定して自動ログインで起動すると、デフォルトキーリングを使うアプリが起動した時点でデフォルトキーリングのパスワード入力のダイアログが出るので、それにパスワードを入れれば良い。: ごく当たり前の手順である。

アプリによっては、パスワード入力が遅いとエラーになる可能性もあるが、今のところは問題は起こっていない。

今までは、デフォルトキーリングのパスワードを複雑なものにして覚えられないから、ログインキーリングに(覚えている)ログインパスワードを入れることで済ませようとしていたが、デフォルトキーリングのパスワードを覚えられる・覚えているもの(例: 何かの使い回し)にすればいいのだ。

セキュリティ上は若干弱くなるが、そもそも自動ログインにしていること自体が弱いので、多少は目をつぶろう。

これで、残りはサーバの対処だ。やり方は分かっているものの、やっぱり面倒ではある。

  •  0
  •  0

自分謹製とは言えカードリーダーが今一つ不安なものになってしまったmicro SDの代わりに、非常時のために財布の中に入れておこうとして買ったカード型USBメモリも駄目だったので別のものを探しているうちに、まず、非常用メディア(USBメモリやmicro SD)をどうする(何をどうやって所持するか、データをどう格納するか)のが一番いいのかを考えるほうが重要なことに気付いて、そうした。

そして、当初は財布の中なら いつも持ち歩くから効果的だと考えて居たが、紛失した場合を考えると、その中に入れる情報によっては事態を更に悪化させることに気付いた。

具体的には、財布には免許証、クレジットカード、健康保険証などを入れているので、それだけでも大変なリスクだが(何とかしたいが、利便性を取って危ないままにして居る)、更に非常用データ(例: サーバのssh鍵)が一緒になったら、それこそ「何でもできそう」ではないか。

実際にはssh鍵にはパスフレーズを設定しているので、紛失しても直ちに危険にはならないが、繰り返せば当たる可能性もあるし、sshの設定など、その他のいろいろな情報を合わせると攻撃のヒントになるだろうから、油断はできない。

そこで、非常用メディアを部屋の鍵と一緒に持ち歩くことを考えた。こちらのリスクは、メディアに住所の書かれたデータが入っていた場合、部屋に泥棒に入られる可能性がある程度と考えた。

比較した当初は、財布のほうが住所・氏名が分かるから戻って来る可能性が高い(鍵だと何も分からないから、まず返って来ない)と考えたが、甘過ぎる想定なので却下した。もちろん戻らず、悪用されることを前提にしなければいけない。

そういう訳で、非常用USBメモリを部屋の鍵のキーホルダーに付けて持ち歩くことにした。鍵は財布同様かそれ以上に いつも持つだろうから有効そうだ。そして、格納するファイルには住所を書かない(書く場合は暗号化する)ことにした。同様に、サーバのssh鍵のように流出するとマズいものは暗号化して格納することにした。

キーホルダーに付けるのなら、大抵の(本体が丈夫でストラップ穴があれば良い)USBメモリが使えるようになって選択肢が増える。そして、たまたま(?)、昔 展示会でもらって、micro SDの前に非常用にしていたものがあるので、当面は それで試してみることにした。そして、(今更ながら、)先日のカード型USBメモリのような轍を踏まないように、メディア全体に書き込みと読み出しを行ってチェックしたところ、当然というか意外というか、全く問題がなかった。

このUSBメモリは通販で すごく良く見る、ちょっと柔らかいプラの本体に回転する金属のカバーが付いたもの(→ 。ただし、僕のは容量2GBでアクセスランプはない)で、いかにもいい加減なものだが、中身はちゃんとしていた。が、外見が同じでも中身が違う場合があるので、同じものを買っても大丈夫な保証は なさそうだ。

データの暗号化の方法については詳しくないので、なるべく安全そうで手軽なものを探した。ただ、Linux以外に(その気になれば)Androidでも復号できるようなオープンな仕様のものが良いので、gpgコマンドを使った。gpgは かなりいろいろなことができるが、(初歩的な?)パスフレーズ(パスワード)での暗号化(gpgの-cオプション, symmetric cipher)にした。GPGのキーを一緒に持ち歩いて別のシステムに再設定しなくても、パスフレーズを覚えていれば復号できるからだ。

暗号化アプリなんて山ほどあるだろうが、大抵は自分のことしか考えてない(例: 独自フォーマット)ため、上記のように、全く別のOSで復号するのが不可能なものが多そうだ。あと、アプリの寿命も重要で、知らないうちに消滅してしまって、いざという時に手に入らなかったら目も当てられない。

gpg以外では暗号化ZIPファイルでも同様なことが可能だが、Windowsが起源なのと、使い勝手が(UNIX的でなくて)好きでないので却下した。詳しくはないが、(総当り以外で)ZIPの暗号が破られたという話は聞かないから、実際には ZIPのほうがずっと手軽であろう。"PPAP"と叩かれたけど、使い方が誤っていただけで 仕組み自体に悪いことはない。

なお、gpg(symmetric cipher)で暗号化する時(非常用メディアにファイルを格納する時)にはパスフレーズを入力する必要があるが、定期的な更新時に毎回手で打ち込むのは面倒なので、GNOME keyringに格納しておき(seahorseやsecret-toolコマンドを使う)*、メディアの更新時にsecret-toolで取得してgpgに設定するようにした。※

*secret-toolは初めて使ったのだが、他の鍵(パスワード)と同様に格納するには、attributeとして"service"で種類を、"username"でその種類内の鍵の名前を指定すれいいようだ。以下に実行例を示す。

secret-tool store --label="非常用メディア" service "EmgData" username "ekey"

上を実行すると、パスフレーズを入力するダイアログが出て来る。

格納したパスフレーズを取得するのは簡単で、以下のようにすれば良い。

secret-tool lookup service "EmgData" username "ekey"

※具体的には、以下のようにしてgpgにパスフレーズ($pass_phrase)と圧縮アーカイブ($cmp_arch)を入力している。

( cat << /EOF/
$pass_phrase
/EOF/
cat "$cmp_arch" ) | gpg -c --batch --pinentry-mode loopback --passphrase-fd 0

パスフレーズをechoやgpgの引数で指定するとpsコマンドで見えてしまうので、避けた。ファイルディスクリプタ(--passphrase-fd)を9とかにすれば もっと分かりやすそうだが、すぐには できなかったので0(stdin)にした。

ファイルディスクリプタを変えるのでなく、FIFOを使って渡すのがいいのかも知れないが、煩雑だし、FIFOはファイルだから逆に脆弱になるのかも知れない。

厳密に見れば弱いところがあるが、デスクトップに侵入されて(、自分のメモリ空間を見られまくられて)いる状態を想定し出すと何もできなくなってしまうので、今のところは これで良しとした。

gpgでファイル単位で暗号化することもできるが、煩雑に思えたので、暗号化するディレクトリ全体のアーカイブを圧縮したもの(例: tar+gz)を暗号化するようにした。

この用途にはgpgtarというコマンドがあって便利だが、下記の更新チェックをするために使っていない。

それから、無駄にメディアに書き込まないよう(寿命を延ばすためと、安物のせいか、たまに書き込みが すごく遅いことがあるため)、更新していないファイルを書き込まないようにした。暗号化してないものはrsyncでできるが、暗号化したものは難しい(煩雑な)ので、圧縮したアーカイブ全体のハッシュ(例: MD5)で判定するようにした。メディアを更新した時に そのハッシュも保存し、次回の比較に使う。

なお、gpgで暗号化すると全く同じデータでも毎回中身が異なるので(全然分からないが、時刻でパラメタ(シード?)が変わる?)、暗号化前のハッシュを使うことにした。

 

以上のような処理(+その他細かい いろいろ)をする同期(転送)スクリプトを作り、定期的に非常用メディアを更新するようにし、使い勝手やメディアが壊れないかやその他の問題の有無を見て行こうと思っている。

まあ、このメディアを使うことがないのが一番だがね・・・

 

PS. その後、(上のプログラムを作る時からやろうと思って居たのだが、)スマフォにも非常用データを同期するようにした。

元々、スマフォからカメラなどの画像を自動取得するプログラムがあるので、その「ついで」に非常用データを転送するようにした。転送する部分は、上のUSBメモリへの転送スクリプトを ほとんどそのまま使えた(転送先を指定できるようにしただけ)。

自動取得するプログラムは、カメラ情報に追加同期コマンドを設定できるようにし、それが設定されていたら定期的(例: 8時間)に実行するようにした。その時、転送先として画像取得用にマウントしているスマフォのディレクトリを指定する。

これで、仮に非常用USBメモリがなくても、スマフォがあれば何とかなるようになった(はず)。 (4/26 11:31)

  •  1
  •  0

(溜まったネタを時系列に こだわらず書いている。今回は今までの一連の稿の始まり かつメインとなる話で、このシリーズの最後となる。)

換気扇を間欠運転しているタイマー XY-WJ01にはシリアル(UART)ポートが付いているので、それを使って遠隔制御することができる。システムができた当初は必要ないと思って居たものの、(おもしろそうだから)できるものは試したいし、使っているうちに、例えば「ちょっと(30分くらい)強制的に換気したい」というような場合があり、PCから換気扇をonにできて自動で元に戻れば便利だと思ったので、やりたくなった。

PCとタイマーの繋ぎ方の検討

PCをタイマーのシリアルポートに繋ぐ方法を検討したら、Wi-Fiが良さそうだった。

  • 無線: 線がなくて美しいが、技適の壁のために安価なものは使えない場合がある。
    • Wi-Fi
      • IP通信なので、仕組みとしては ちょっと大掛かりになってしまう。
      • 親機はルーターが使えるので、1台で済む。
    • Bluetooth
      • シリアルポートプロファイルは手軽で良い。
        • こういうのが欲しかった。
      • 2台(1ペア)必要なのが面倒だし、少し高く付く。
        • ただ、最初は片方はスマフォでも良い。
      • 僕には馴染みがない。
    • その他
      • TWILITEシリーズ
        • おもしろいし簡単に使えそうなのだが、独自規格だったり3.3Vだったりして、(僕には)ちょっと面倒・使いにくいのが残念。
          • もしUARTが5V(トレラント)だったら、買ったかも知れない。
        • オリジナル製品のため安くはない(かと言って すごく高い訳でもない)し、開発機器(と言うほど大掛かりではない)が要る場合もある。
          • ここら辺が独自規格・製品の難点だと思う。
        • 2台(1ペア)必要なのが面倒だし、少し高く付く。
  • 有線(UART): 比較的安く、使うのは超簡単だが、コードが部屋を這うのが綺麗でない。
    • タイマーはAC 100Vを扱うので、通信路(タイマー - PC)を絶縁することが必須。

ただ、以前も書いたように、単純にWi-Fi - シリアルができる安い製品(しかも、技適認証済み)は なく、ESP32シリーズを使うのが一番良さそうだった。が、繋いで電源を入れるだけでは駄目で、少なくとも何らかの設定をしなければ使えないのが面倒だし、機能が豊富過ぎて もったいない。

それで、手元にWi-Fi内蔵SDカード PQI Air Card II(以下、Air Card)が眠って居たので使えないか検討したものの、問題・課題が多いので却下した。はずなのだが、前の稿に書いたように ちょっと思い付いて試したら、とんでもなく面倒なことになってしまった。

実は その前に、Air Cardを試すのにも使うのでUSB-シリアルアダプタを買い、タイマーに繋いでコマンドが実行できるようにしていた。

PCとタイマーを繋ぎ、タイマーのコマンドを実行できるようになるまで

まず、PCに適当なシリアルポート(信号レベルはRS232(±12Vなど)でなくUART(0, 5Vなど))がないので、USB-シリアルアダプタ(以下、シリアルアダプタ)を買った。選ぶ時、仮にAir Cardが駄目でもタイマーに直接接続できるように、絶縁型にした。

なぜ絶縁型にしたかというと、仮にタイマーが扱うAC 100Vがシリアルに漏れた場合でもPCを損傷させないためである。絶縁型であれば、仮にAC 100Vがシリアルに漏れてもPCのUSBポートには入らないはずで、タイマーは壊れるものの、PCは安全だ。

シリアルアダプタは、秋月のFT234X+ADuM121N使用絶縁USBシリアル変換モジュールにした。約千円だった。他に必要な部品(3.3V電源レギュレータ(Air Cardの電源にしようと思ったが、結局使わなかった)やXHコネクタなど)も一緒に買った。

届いてから動作確認(Linuxでのデバイスの認識やループバック通信)をしたところ、ちゃんと動いた。

選ぶ時に少し迷ったのだが、アダプタのチップは実績・定評のあるFTDIのもので良かったと思う。当然ながら挿せば動くし、例えば、タイマーへの通信がうまく行かなくて(後述)、転送速度のズレを疑った(実際には問題なかった)時に簡単に微調整(例: ±10%)できたのは良かった。

それからシリアルアダプタをタイマーに接続できるように基板にXHコネクタを付け、タイマーに繋げてコマンドを試したところ、なぜか処理されず、全部"FAIL"になってしまった。

一番まともそうなマニュアル(買った製品には添付されていない)を出しているメーカーらしき会社(そもそもメーカー名が不明なので、単なる商社かも知れない)に問い合わせても、マニュアルの関連箇所のコピーしか来なかった。不良品(ソフトにバグがある)と考えて買った店に問い合わせたが、やっぱりマニュアルのコピー(文章は中国語)を提示するだけで、「物は ちゃんと送った。製品に問題はない」などと無責任極まりない対応だった。更に、製品に問題のない(動作している)証拠を求めたが出して来なかった。

仕方ないので一旦諦めることにして、あとで使う時に壊れにくくなるようにシリアルアダプタをケース(壊れた100円カードリーダーのものを加工した)に収めたり、タイマー基板の入出力の一括接続用のXHコネクタを付けて整理した。

が、その後いろいろ試したら解決できた。: タイマーのコマンドは「一発で」送らなくてはならないのだ。例えば、設定を取得するコマンド"read"をターミナルソフト(例: minicom)で手で"r", "e", "a", "d"と打ち込むのは駄目で、それぞれの文字が"FAIL"になる

一方、プログラム(LinuxのechoコマンドでOK)で一回で"read"と送れば成功する。※ ターミナルソフトでも、(あらかじめクリップボードに入れておいた)"read"をペーストすれば成功する。(: ローカルエコーoffのため、画面には送信文字列(コマンド)が出ていないが、"read", 改行, 改行, 改行, "read"を送っている。)

おそらく、文字の受信間隔が しきい値より長いと、コマンドの区切りとしているのだろう。

※このことに気付いたのは、転送速度が異なるためかと思って微調整の仕方を調べたら、速度設定のあとにechoで文字を送信する例があって、最初なので そのとおりに試したら動いたことだった。本当に速度が違うのかと思って、上下限を調べたら調整なしの速度(9600bps)でも動いて、速度でなく送信方法がポイントだったことが分かった。

ただ、使ってみて分かったが、想像通りクロックが余り正確でないようで、タイマーの継続時間が結構狂う。大体、設定の7%くらい(例: 10分で42秒)短くなる。この調子だと温度でも変わりそうだ。

これはマニュアルに書いてない*ので、「ちょっと普通に」試したら全部"FAIL"になってしまう。※

*もしかして、元々の中国語版のマニュアル(あるのか不明)を読めば、文章の本来の意味から分かるのかも知れないが、全くの無理筋だ。あるいは、(PS1に書いたことに関連するが、)発注元の仕様書には書いてあって そう実装したけど、(テキトーな誰かが作った)マニュアルには書かれなかったのかも知れない。

※メーカーらしき会社の掲示板に、別の製品だが、同じ問題で困った人が居た。それに対しても通り一遍の回答で、「一回で送る」という情報はなかった。だから、その会社も単に売っているだけなのかも知れない。なお、呆れたのか諦めたのか、質問者からの返信はなかった。

Linux(bash)でタイマー XY-WJ01にreadコマンド(設定の取得)を送り、応答を受信する例を以下に示す。

timer_tty="/dev/ttyUSB0"
stty -F $timer_tty 9600 pass8 -cstopb -echo
my_tty=`tty`
tmo_s=1

timer_cmd="read"
bash -c "echo -n $timer_cmd; read -t $tmo_s res; echo \$res > $my_tty" < $timer_tty > $timer_tty

→ 結果: P6,OP:0.0.1.0,CL:0.0.3.5,LP:----

※他のコマンド(例: "P7"(モード7に変更))を実行したい場合は、変数timer_cmdに設定すれば良い。また、タイマーが接続されていない時や電源offの時に待ち続けないようにするため、readにタイムアウト(変数tmo_s, 1秒)を指定している。

(4/4 14:02) sttyに指定する通信設定を修正した。*: 一番重要なのは -echo で、これでエコーバックを停めないと、タイマーから送信された文字列がタイマーに送り返されて、エラーになったり設定が変わってしまうことがある。: 後述の、off時間が0("CL:0000")になってしまう現象の原因は これでないかと推測している。

*実際には他にも指定しているが、上記のものだけで充分である。

また、bashで実行するコマンドのリダイレクトも修正した。: 当初は検索して見つかった例のまま、意味を良く考えずに使っていたが、stderr(fd= 2)をstdout(fd= 1)にリダイレクトすると、Linux側のコマンドのエラーがタイマーに送られてしまうので良くない。

上の例は長くて分かりにくいかも知れないが、肝は一番最後の行のechoとreadだけで、やっていることは以下である。

stty -F /dev/ttyUSB0 9600 pass8 -cstopb -echo
echo -n "read" > /dev/ttyUSB0
read -t 1 res < /dev/ttyUSB0
echo $res

細かいことを書くと、こちらの場合は、(可能性は低いものの、)echoでタイマーにコマンドを送ってからreadを実行するまでに来た応答を取得できない。

そして、細くて長い(15m)電話線(モジュラーコード)※を買い、(長さが確定していないので、)モジュラージャックを切らずに接続するためのアダプタを作り、PCから洗面所まで「仮敷設」し、(コマンドは上のように手で打つものの、)PCからタイマーを制御できるようになっている。

※シリアルアダプタの端子数は4個(電源, 送信, 受信, GND)で、丁度電話用のモジュラーコードの芯数に合うのと細いコードが手頃な値段で売っているので、そうした。なお、15mは基本的にはシリアル通信には長いが、転送速度が9600bpsと遅いので問題ないと考えた。

タイマーの遠隔制御の機能と実装

タイマーの遠隔制御の使い方(ユースケース)を検討し、以下のような機能を実現しようと考え、概ね実装した。

なお、下の指定時間on/offしている間にPCが再起動したりスリープした場合にタイマーの状態が元に戻らない(例: onまたはoffになったまま)のは良くないので、そうならないような方式を考えた。

そのため、「連続on」や「連続off」の機能は作らない。連続on/offしたい場合は、例えば「24時間」のように充分長い時間を指定するようにする。

実際、無限にon/offしたいことは ないし、仮にそうするなら、手で換気扇のスイッチをonにしたり、タイマーの電源を切れば良い。

  • (一時的に、)指定時間(T1)onする。
    • タイマーのモードがP6(on, offの繰り返し)の場合、設定(同じ設定でも可)を書き込むとonになるので、現在の設定をそのまま書き込むことで、設定のon時間(Tonとする)のonにする。
      • XY-LJ02と違い、XY-WJ01には即座にon/offするコマンドがないので、このようにする。
    • 以下の処理でT1のonを行う。
      1. モードがP6でない場合、P6にする。 → 最大Tonのonになる。
      2. 設定の書き込み。 → 最大Tonのonになる。
      3. T1の端数(T1 mod Ton)と繰り返し中の短縮分(例: 20秒x繰り返し回数)のsleepをする。
      4. T1/Ton > 1の場合、以下をT1/Ton-1回繰り返す。
        1. Tonよりわずかに(例: 20秒)短いsleepをする。※
        2. 設定の書き込み。 → Tonのon
    • 仮に上の処理中にPCが再起動したりスリープした場合、最後のonのあとは通常のタイマー動作(on, off)に戻る。
  • (一時的に、)指定時間(T2)offする。
    • タイマーのモードがP6の場合、P7(off, onの繰り返し)に変更するとoffになるので、そうすることで設定のoff時間(Toffとする)のoffにする。
    • 以下の処理でT2のoffを行う。
      1. モードがP7でない場合、P7にする。 → 最大Toffのoffになる。
      2. 設定の書き込み。 → 最大Toffのoffになる。
      3. T2の端数(T2 mod Toff)と繰り返し中の短縮分(例: 20秒x繰り返し回数)のsleepをする。
      4. T2/Toff > 1の場合、以下をT2/Toff-1回繰り返す。
        1. Toffよりわずかに短いsleepをする。※
        2. 設定の書き込み。 → Toffのoff
    • 仮に上の処理中にPCが再起動したりスリープした場合、最後のoffのあとはP7のタイマー動作(off, on)になる。
      • これはP6と位相が異なるだけで、on/offの周期・比率は同じである。
    • 終了後にモードをP6に戻すのが望ましいが、そのままでも次回の制御時にモードを取得して適宜対応すれば良い。
  • 動作パターン(設定)を変更する。
    • 単純に、新しい設定をタイマーに書き込めば良い。
    • 設定のプリセット的なもの(例: 強, 中, 弱)を作り、それをタイマーに設定するようにすれば操作が楽になる。

※タイマーが設定でon/offするより前に それらを継続することで、換気扇のon/off動作を途切れさせないためにそうしたが、実際に使ってみると、多少途切れても実害はなく、そこまで厳密にする必要はないことが分かったので、今は、処理を簡単にするため、スリープ時間はタイマーのon/off時間(TonまたはToff)にしている。

同様に、タイマーのon/off時間の整数倍でない時間で換気扇をon/offする必要性も薄い気がしたので、今は、指定されたon/off時間(T1またはT2)をタイマーのon/off時間(TonまたはToff)の整数倍に丸めている。 (4/16 7:29)

これから(= 気が向いたら)プログラムを作るところだが、大方出来た つもりになってしまって作るのが面倒なので、こうしてブログを書いたりしているw

(3/22 16:43) その後、なぜか やる気が出たので、上の指定時間on/offするプログラムを作った。また、YAD(Yet Another Dialog)というプログラムで とっても簡単なGUIを作った。既に いくつか不満はあるが、使いながら改良して行きたい。

UXWingVentilation Fan Blower iconを使用した。

(3/23 9:30) 更に、Xfceのパネル(Windowsのタスクバーに相当)に入れて※手軽に かつダイアログの場所を取らずに使えるようにした。この部分をクリックすると、上の設定ダイアログが出て、タイマーの設定周期とは関係なく、指定した時間だけ換気扇をon/offすることができる。

※Generic monitorというウィジェットを使った。なお、パネルの空き(場所)が少ないため、CPU温度のウィジェットは止めた。タイマー(パネルの"Timer"のウィジェットのこと。制御対象のタイマーではない)が無駄に場所を食っているのだが、直せないので仕方ない。

 

(3/26 20:57) 換気扇の動作パターンも設定できるようにした。とりあえず、on/off時間を3種類(H= 強, M= 中(標準), L= 弱)から選べるようにした。On時間の割合は、H: 約40%, M: 約22%, L: 約13%としてみた。

 

それから、当初は接続を無線(Wi-Fi)にしようと思って居たが、電話線は充分細くて目立たないし、タイマーのコマンドの機能は少なく※苦労して無線にするほどのものではないので(ただ、GPIO付きのWi-Fi基板なら、タイマーの状態が取れそうだ)、上述の遠隔制御機能ができたら電話線を正式(綺麗)に敷設して、終わりにしようと思っている。

※以下のような惜しいことがある。

  • コマンドで設定の取得や変更はできるが、状態(例: 現在onなのかoffなのか)を取得できない。
    • 例えば通信を絶縁I2C(あるいは、上述のようにWi-Fi)にし、その先にシリアル通信とGPIOの可能な基板を付ければできる気はしているが、そこまでする必要性はないし、やってもon/off程度しか分からない。単なる興味だw
  • 同じシリーズのXY-LJ02(基板のみの製品)のように、即座にon/offするコマンドがあると便利だ。
    • だから、WJ01のstart/stopコマンドはLJ02でon/offになったのかも知れない。

 

タイマーのUARTコマンド・動作で分かったこと (3/26 12:34追記)

  • 現在と異なるモードを設定すると、(当然ながらそのモードになるが、)その時のリレーのon/offは そのモードの最初の状態になる(例: P6ならonになる)。また、時間のカウントはリセットされる。
  • 現在と同じモードを再設定した場合、(パラメタを再設定した場合の動作とは異なり)リレーのon/offは そのモードの最初の状態になる。
    • 時間のカウントの詳細は未確認だが、以下のような感じである。
      • On/offの状態が現在と変わる場合は時間のカウントがリセットされる? (リセットされないこともある?)
      • On/offが変わらない場合はカウントがリセットされない?
  • 上の2つにより、XY-LJ02のように、即座にリレーをon/offすることもできる(ただし、on/offされている時間は設定による)。
    • 例: P6にすればonになり、P7にすればoffになる。
  • 複数のコマンドを , で区切って一括して送れる(要するにreadコマンドの出力と同じ形式)。
    • 任意の順序・数(もちろん上限はある)のコマンドが送れる。
    • ただし、モード(Px)を指定した場合にはLP以外は無効になる。
  • UARTコマンドを実行すると、たまにタイマーの設定が壊れることがある。
    • Off時間が0("CL:0000")になってしまう。
      • この場合、タイマーが停まる。
    • 壊れる契機は不明。
      • コマンド実行後の待ち時間が短いため?
    • そのため、コマンド実行後に設定を取得し、いずれかのパラメタが"0000"になった場合は壊れたと判断して元の設定を再設定するようにした。
    • (4/4 14:20) 上に追記したように、この問題の原因はタイマーコマンドの送受信の仕方の問題だと推測している。
      • 以下に、推測した問題発生の流れを示す。
        1. [コマンド実行プログラム] 起動する。 (起動時にタイマーのttyがopenされる)
        2. [コマンド実行プログラム] コマンドをタイマーのttyに書き込む。
        3. [Linux] コマンドをタイマーに送信する。
        4. [タイマー] 結果をLinuxに送信する。
        5. [Linux] 受信した結果をタイマーにエコーバックする。 (sttyに-echoを指定していない場合)
        6. [コマンド実行プログラム] タイマーのttyから結果を取得する。
        7. [コマンド実行プログラム] 終了する。 (→ タイマーのttyがcloseされる)
        8. [タイマー] エコーバックされた文字列をコマンドとして解釈して、結果をLinuxに送信する。 (→ コマンド実行プログラムが起動していないため、破棄される。)
      • 上の5と6,7の順序が問題で、5の前に7まで実行されれば問題ないが、そうでない場合には、コマンド実行プログラムが終了するまで、受信した結果のエコーバックが行われる。→ 受信した結果の一部がタイマーに送信される。
        • readコマンドを実行する場合、結果は"P6,OP:0.0.1.0,CL:0.0.3.5,LP:----"のような文字列であるが、仮に"CL:0"までしか送信されなかったとしたら、タイマーはCLを0に設定し、問題の現象が起こるのではないか。
        • モードやパラメタの設定コマンド(例: P7)の場合、結果は"DOWN"(成功)か"FAIL"(失敗)で、どちらにしても失敗して"FAIL"が送られて来るだけなので、大きな問題はない。
          • ただ、コマンド実行プログラムが終了するまで この繰り返しが終わらないので、好ましくない。

 

PS1. タイマーの謎と危うさ

以前使ったセンサ基板(YL-40)同様、物自体は ちゃんとしているのに、メーカー名を記載せず ちゃんとしたマニュアルなしで売るのは怪し過ぎるしアンバランスだ。売る店が何も分かっていないのもおかしい。

あくまでも想像だが、ちゃんとした会社の製造発注先が横流ししているのではないか。

流通は置いておくとしても、メーカー名もマニュアルもないものを ちゃんとしたシステムに使うのはリスクが高い。使う側が自分で検証・担保するスタンス(= 「何が起こっても知らないよ」)なのだろう。

だから、僕がAC 100Vをこのタイマーに直接入れず、外部のリレーで制御するようにしたのは正解だった。いくら基板をチェックしたって、本当に安全な作りかは分からないからだ。そんなものを信用するくらいなら、自分で回路や基板を作ったほうが ずっと安心できる。

以前調べたら、このタイマーを車(後付けで、エンジン起動後に何かのボタンを押したかのようにしているようだ)や医療機器(プロト?)に使っている例があったが、結構怖い。そこまで信用していいのかと思う。(だからC国では車両火災などが良く起こる??)

(3/23 14:26) 書いてから気付いたが、このタイマーのon/off時間設定の単位は0.01秒から1分が可能だが、on/offをリレーで制御するのに0.01秒(10ms)って果たして「あり」なのか、大いに疑問だ。そんなに短い間隔で使ったら、あっという間にリレーが壊れるだろう。リレーで音楽でも演奏するつもり??w 代わりに時間の単位を付ければ良かったのに。こういう基本的なところが杜撰なようだ。

PS2. AliExpress(以下Ali)の本体も店も最低、クソ以下なので、もう絶対に使いたくない。Aliのシステムは おかしいところが多いし(例: 設定しても通知メールが来ないことが多いし、来ても英語と日本語で内容が正反対だったりする)、店は無責任極まりない(C国人の悪いイメージどおり、自分に非がないことを証拠もなしに叫ぶだけだ)。レビューの点数が いい店を選んで上のありさまだったので、全く信用できない。

僕の中での店(特に電子部品・モジュール)の信頼性の順位は以下である。

秋月, ヨドバシ >> Amazon > Amazon(マーケットプレイス), 楽天 >>>>>>>>>> Ali

もしヨドバシにあれば一番楽で安そうだし、秋月にあれば(送料は少し高いものの)、店も物も信頼できるから良い。Aliを使うくらいなら、多少高くてもAmazon(マーケットプレイス)から買うほうが、(問題があった場合の)ストレスは1/100、時間は1/10だ。

もう少ししたら、Aliのアカウントを削除するつもりだ。最初から今ひとつ信用できなかったので、クレジットカードの情報を登録しなかったのは、正解だ。

  •  1
  •  0

濁音に苦労した話」の続きである。元の稿に加筆したように、SpotifyのAPIで取れる曲情報でもcombining charactersが使われている(= 本体と(半)濁点が分離している)場合があることが分かった。

確かに、APIとそれ以外で別の情報を格納して別々に出すのは無駄だし、合理的でない。

表示は文字列が綺麗に出ればいいが、APIで取った曲情報は自作の音楽再生履歴記録システム MlhiのDBに格納しているので、今ひとつ良くない。というのは、今はまだ完全でない(イマイチな)ので余り使っていないが、将来は自分が聴いた曲をフレキシブルに(要するに、手軽に思ったとおりに)検索できるようにする予定で、その時に、combining charactersの濁音や半濁音を含む曲が出て来ない可能性があるからだ。

そういえば、以前、なぜか検索出来ない曲があったが、それだったのかも知れない。

(1/27 14:55) ちなみに、DBを調べたところ、曲情報(タイトル、アーティスト名、アルバム名、アルバムアーティスト)のいずれかにcombining characters(濁音、半濁音)が使われているものは、延べ27曲だった。DB全体は約1万曲なので、割合は約0.3%未満と少ない。ただ、僕は洋楽やクラシック音楽を聴くことが多く、曲情報が英語のものが多いから、日本の曲での割合は数%くらいではないか。

これを解決するには、以下の方法が考えられる。

  1. DBに正規化した曲情報を格納する。
    • 今までにDBに格納した内容は正規化する。
  2. 検索時に、検索文字列とDBの内容を正規化して比較する。
    • DBには、取得した情報をそのまま格納する。
  3. × 検索時に、検索文字列として、正規化したものとそうでないものを両方指定する。
    • 正規化された文字を逆変換(分離)するのが面倒そうだが、uconvでできそうだ(本当?)。
    • 曲情報に正規化されている文字と そうでないものが混ざっているので、検索パターンが多くなり過ぎる。

Bが筋が良さそうだが、結構面倒そうだ(そもそも、DBに使っているSQLiteはUnicodeのこういう処理に対応しているのだろうか??※)。一方、前者は やればできそうなので、そうすることにした。

sqlean: All the missing SQLite functionsというソフトがあり、それは限定的なUnicode処理機能(upper/lower, like, unaccent)を持つので、SQLite自体は対応していないようだ。

ここで問題になったことがある。: 前の稿に書いたように、uconvで正規化すると、かな に正規化漏れが起こるのと、漢字の旧字体が新字体に変換されてしまう。前者は自作の処理(テーブル変換)で対応できているが、後者に対応するには、日本語の文字(漢字)を正規化しない必要がある。※

※幸い、日本語の漢字には濁点のような着脱可能な要素が なさそうなので、正規化対象から除外するだけで良い。ただ、例えば「辶」(しんにょう)のように、場合によって個数が違う点のような要素はある(→ 興味深い読み物があった)。が、それは純粋に文字の形の問題と思われ、意味や読みは変わらないので別件としたい。

他には、たまに、富と冨ののような着脱可能っぽい点はあるが、それらは同じ文字らしいし、相互に入れ替えて意味を変えることはないので(しんにょうと同様に)ヨシ、だ。

そもそも、今までに、(遊びをのぞいてw)漢字に かな のように点や丸を付けて意味などを変えたことはないし、そういうことを教わったこともないから、それで良さそうだ。

UnicodeやICUに不慣れなので、日本語を除外して正規化することができるのか分からなかったが、いろいろ調べたら できそうなことが分かった。

Unicodeにはscriptという概念があり、Latin文字(いわゆる英字)、カタカナ、ひらがな、漢字※のようなカテゴリ(Unicodeにはcategoryという概念があるが、それではない)を示すことができる。それを使って、uconvの正規化ルール(日本語除外フィルタのようなもの)を指定すればできそうだ。

※実際には、Unicodeの資料では漢字は"Han"と書かれており、おそらく中・日・韓の漢字を一緒にしたもの(≒ CJK Unified Ideographs)を差していると理解している。

具体的には、以下のコマンドで日本語(正確には、漢字、ひらがな、カタカナ)以外の文字を正規化できるはずだ。

uconv -f utf-8 -t utf-8 -x '::[ [:^Katakana:] & [:^Hiragana:] & [:^Han:] ]; ::nfc;'

処理内容は、-xの最初のルール(最初の ; まで)でカタカナ、ひらがな、漢字を除外し、残ったものに正規化(NFC)を実行する("::nfc")。

実は、上の処理には欠陥がある。おそらく韓国語(ハングル文字)はcombining charactersをバリバリ使っているはずだが、それも除外されるのではないか(ハングル文字がHanに含まれているとした場合: 実際には、scriptには"Hangul"というのがあるから、ハングル文字はHanには含まれていなさそうだ)。

が、僕の好みからして、曲名などが韓国語で書かれた曲は聴かないだろうから、とりあえずは良しとする。あと、中国語には簡体字も繁体字もあるし(それは関係ないのかも知れないが)、どうなのか想像も付かないw

上の処理は、以下のテストパターンで うまく行った。

  • パ が 神: 正規化されずに出た。
  • (A + U+0304: Combining Macron): Ā (U+0100: Latin Capital Letter A with Macron)になった。※

を使ったのは たまたま最初に できた(macronなるものが付いた単体のĀがあった)からである。この文字がどういう意味なのか全く分からないし、実際に使われるのかも知らない。

と、出来そうになって気分がいいところで、「残りはあとで」にしたw

 

参考にしたページは以下である。

uconvに指定するルールの書き方は最初と2番目(特に後者)が参考になった。最後に残った謎(どうやって日本語を除外するか? そうするパターンをどうやって書くか?)を解く鍵になったのは、最後のUnicode Regular Expressionsだった。

それについては最初の2つを丹念に読めば分かったのだろうが、余りにも知らない概念が多いうえに機能が多過ぎてチンプンカンプンだった(→ 読む気が起こらなかった)。一方で、-Regular Expressionsは馴染みの正規表現の話なので良く分かった。※ 更に、Hanが かな を含むという思い違いに気付かせてくれて、上のルールが出来た。

※実際、このページを見付けた切っ掛けは、ICU(uconv)のルールが全然思ったように動かないので諦めて、grepで正規表現で除外しようと思い、「『漢字全部』の うまい指定」があればと思って"Unicode regexp"で検索したことだ。

ちなみに、grepは-PオプションでUnicodeに対応した動作(PCRE)になる。

 

PS. Unicode(ICU)の処理には、カタカナ→ローマ字みたいなものがあって(→ Script Transliterationの表の「キャンパス: kyanpasu」)、「誰が使うの?」と思う。ちゃんと動くのならいいが、正規化みたいに中途半端だったら実装するだけ無駄だし、ほとんどの開発者は知らないので、使われない気が・・・ (いやいや、僕が無知なだけだよね)

PS2. こういう細かい話は嫌いだけど好きだ。: 実装や確認は面倒でやりたくないけど、豆知識的に調べるのは好きだ。発展したのがタモリかw

  •  0
  •  0

夏が来た!
夏が来た!

上下の違いが分かる方は居るだろうか?: 同じに見えるけど違う。ブラウザ(かなり古いもの?)やフォントによっては、分かるかも知れない。

答えは、題にあるように、濁音「が」の造りである。今まで知らなかったのだが、Unicodeのひらがな・カタカナは、濁音や半濁音を半角カナ的に 本体+(半)濁点 のように分離して記述し、なおかつ くっつけて一文字のように表示することができる。Combining charactersとかいって、日本語以外でも そういう処理ができるとのことだ。

上の例の「が」は、最初の行はcombining charactersで 「か」+「”」(← 見にくいのでダブルクォートにした) で、2番目は普通に書いてある。全く区別できない。※ 良く出来過ぎていることに、マウスでコピーする時は1文字として扱われるし、等幅フォントのエディタやターミナル(コンソール)でも くっついた状態で表示される。

※おそらく、フォントの字体としては、本体に濁点を加えたものが濁音の文字になっており、combining charactersの濁点は それを再現するような位置に表示されるようにできているのだろう。ただ、この方式ではすべての濁音で濁点が同じ位置に置かれるが、そこはフォントの 描き方でうまく合わせたのだろうか。

↑ ちょっと確かめたら、そう単純なことではないようだ。というのは、下の左図のように、「ヾ」と「ヷ」では濁点の大きさや形が明らかに違うからだ。ということは、フォントに濁点を付けるための情報があるのか、表示する時に、combining charactersの濁点が付く場合は自動で濁音の字に変換されるのか。見たところ、濁点の形が微妙に違う気がする(特に、線の太さ)ので前者なのかも知れないが、本当に そこまでやっているのかという気はする。どちらにしたって、「余計なところに力を入れ過ぎていないか?」と言いたくなる。 (1/22 5:18)

その後、文字に色を付けて濁点を重ねて比べたところ(下の右図)、同じ文字の濁点の形状は、combining charactersでもそうでなくても同様だが、異なる文字同士では異なっている(この例では、「ヾ」の濁点は「ヷ」のより大きい)ことが分かった。 (1/22 14:19)

僕が見付けた唯一の識別方法は、エディタ(ペーストする)で濁点側から1文字削除することだ。Combining charactersの場合は濁点だけが消えるが、そうでない場合は全部消える。

そして、今回の切っ掛けに関係することは、どういう訳か、Spotifyで出る曲情報(タイトル、アーティスト名、アルバム名)※の中に、本体と濁点・半濁点が分離して記述されたものがあるのだ。全部ではなく、たまにあるのが不思議だ。特定のレーベルという訳でもない気がするが、老舗(例: ビクター、ソニー)や昔の曲に多い気がしている(と書きつつ、1990年代の(一番下の図)もあるので関係ないかも)。

想像だが、レーベルが曲情報を電子形態に登録する際、打ち込む人の癖などで分離してしまったか、それ以前の半角カナも使うシステム(そういうものがあったかは不明)から変換した時に、濁点・半濁点を統合しないままだったのではないか。

※詳しく確認していないのだが、同じSpotifyでも、アプリから取れる情報(Dbusのイベントで取れるもの)とAPIで取れる情報の記述が異なるようだ。前者は分離していることがあるが、後者はそうではない。 ← どちらも同じように分離している場合があることが分かった。例: 飯島真理 「palette(パレット)」(2007)の「パ」。 (1/25 16:31)

それで何も問題が起こらなければ気付かずに過ごせたのだが、自作のSpotifyのミニプレーヤーMinispが駄目だった(これが発端である)。次の左図のように、combining charactersである「が」のあとに空白が出来て、半角カナ的な見苦しさになってしまっている。今見ると、本体(か)と濁点の間隔も少し広い。本来は右側のようになるべきである。

どうやら、表示に使っているTcl/Tk(wish)がcombining charactersに対応していないようだ(調べた限りではTcl/Tkのページの"Unicode combining characters"の項にはコメントだか状況説明が書いてあるだけのようだし、 そういう設定や属性などがなかったので非対応なのではないか)。

これを何とかしようと調べたら、Rubyのソフト(unicode_utils)の紹介が出て来たものの、インストールするのが面倒なので試行錯誤したら、既存のプログラム iconvでは駄目だったものの、既に入っているパッケージ icu-devtoolsのuconvでできることが分かった。

Combining charactersを まとめる(くっついた文字にする)のは「正規化」という処理で、uconvのマニュアルに例(下記)が書いてあった。

uconv -f utf-8 -t utf-8 \
  -x '::nfkc; [:Cc:] >; ::katakana-hiragana;'

上は他の処理も混ざっているので、以下の例のように、曲のタイトル、アーティスト名、アルバム名をそれぞれ正規化してから表示するようにし、上の右図のように解決した。

echo "夏が来た!" | uconv -f utf-8 -t utf-8 -x '::nfc;'
夏が来た!

※正規化処理は、マニュアルではNFKCだが、調べたらNFCのほうが良さそうなので そうした。この辺りは全く詳しくないので手探りだ。また、上のコマンドでnfc前後の :: ; は なくていいようだが、例にならって付けている。

今 上の参照ページを読んだら、NFCでも今ひとつな場合(「例6: 神と神」)があって気に入らないが、仕方ない(レーベルも、旧字体は余り使わないだろう)。一番いいのは、正規化しなくてもwishで綺麗に表示できるようにすることか。

あるいは、(一番最初に考えた方式の、)uconvでなくプログラムで変換するのがいいか。ひらがな とカタカナだけの対応になるが、濁音・半濁音と そうでない音の文字の順序には概ね規則性(元の音のコード= 濁音-1, 半濁音-2)があるので、それでcombining charactersを くっついた文字に置換するのだ。これなら漢字の旧字体は問題ない。

というか、いちいち計算するのでなく、今の追加処理のテーブル方式で全部処理するほうが良さそうだ。濁音・半濁音は多くないから、テーブルを作るのは容易だ。 → 基本的に、uconvを使うのを止めて追加処理だけにすればできるので、早速そうした。

この方式なら、あとから追加変換が必要になことが分かっても、変換テーブルに追加するだけなので容易だ。 (1/21 17:05)

ところがどっこい!w

下の左図の「グ」のように、なぜか、頑固に正規化できない文字がある(図で「ベ」は くっついているので、処理されていない訳ではないことが分かる)。

更に調べたら、どうやらuconv(使っているのは uconv v2.1 ICU 66.1)が正規化しない(素通しする)文字があるようだ。ひらがな・カタカナの濁音・半濁音について調べたところ、以下の文字が駄目だった(正規化されずにそのまま出て来た)。

ど ば べ ぼ ぱ ぺ ぽ ガ ギ グ ズ ゼ ゾ ダ ヷ ヾ

ところで、上の最後のほうにある見慣れない文字、Unicodeにある「ヷ」、「ヸ」、「ヹ」、「ヺ」って実際に使われたのだろうか? どういう読み?? 謎だ。 (→ 4/1に出た、参考になるページがあった。)

その後、PHPの国際化関数のTransliteratorのtransliterator_transliterate()でuconvと同様の正規化処理を試したら、なぜか上の文字も正規化できた。よって、下ではICUやUnicodeのライブラリの問題と書いているが、uconvの問題の可能性が高い。だが、どうしたらこういう抜けが起こるのか見当がつかない。 (1/27 16:08)

実際には、原因はuconvではなく、それが使っているICUやUnicodeのライブラリの問題だろう(日本語に詳しくない人が作った??)から、パッケージを(Linuxディストリビューションのものでない、)オリジナルの最新に入れ替えるか、設定とか調整すれば直せる気はするのだが、パッケージの交換は あとあと面倒になるのでせず、設定・調整はuconvなどのマニュアルを読んでも分からない用語が多くて どうすればいいか分からなかったので、以下のような力技で対応した。

  1. 起動時(初期化)
    1. uconvで正規化できない濁音・半濁音を調べてリストを作る。
    2. それらの正規化後の文字のリストを作る。
  2. 曲情報(タイトル、アーティスト名、アルバム名)を表示する前
    1. uconvで正規化する。
    2. uconvで正規化できなかった文字がある場合は、正規化した文字に置換する。

これなら、将来ICUやUnicodeのライブラリが更新されて、すべての濁音・半濁音が正規化できるようになれば(なんか、永遠にそうならない気が・・・w)、自動的に追加処理が不要になる。

処理を実装し、上の右図のように、駄目だった文字が ちゃんと表示され、(今のところは)一件落着となった。ただ、いつものように、他にも何か問題がありそうなので、表示やログを注視しながら音楽を聴いている。

これ、日本語以外でも あったらお手上げだが、読めなくて気付かないだろうから良し?www

 

PS. 中程("1/21 17:05"の辺り)に書いたように、これを書いたあとで、実は、uconvを使うのでなく一番最初に思い付いた単純なテーブル変換方式が一番良かったというオチだった(今のところは)。Unicodeの考えは基本的には いいと思うが、(何かで必要なのだろうが)複雑な概念をいろいろ作り出して、それが日本語や実際の用途に合わない、あるいは完全な実装ができていないために、いろいろなところで苦労してそうなのが残念だ。

  •  0
  •  0

オーディオ馬鹿の とっても些細な話: 以前も検討した気がするが、その詳細を忘れて再度試したので書く。

Spotifyの音量正規化には、大(loud)、中(normal)、小(quiet)の3種類の音量がある。僕は、ポップ音楽とクラシック音楽両方の音量を手軽に揃え、かつ、他のアプリとも音量を合わせたいので、小にしてPC内部で増幅(7倍)※しているが、増幅するのが馬鹿らしいし音に悪い気がしたので、(他アプリとの音量合わせを諦め、)増幅を止めてボリュームで音量を調整してアンプで増幅するようにしてみた。

※「増幅」とは書いたが、数値演算(乗算)だけで、仮想的なものだ。

何も問題は なかったのだが、昨日くらいから、それは実は音に悪い気がして来た。というのは、PC内部(デジタル)とアンプ(アナログ)での増幅の音に対する影響を比べたら、前者のほうが得策なように思えたのだ。ただ、どのくらい音が劣化するか(データが落ちるか)を検討しないと分からないので した。

まず、PC内部での増幅(7倍)のデータ精度への影響は約1ビット(高々2ビット)で、内部表現(演奏の録音のフォーマットではなく、PC内部の音の処理の話)が20ビット以上なら(おそらく24や32ビットだろう)、DAC(有効精度は20ビット未満)が出す音質には影響がなさそうだ。

次に、更に詳しく検討した。元の演奏の音量(いろいろなものの平均)を1とし、アンプから出す音量をAとした場合のアンプの増幅量を比較した。

元々の(PC内部で増幅する)場合

  • 元の演奏の音量: 1
  • Spotifyの正規化(quiet): x0.45 (-7dB → 約1ビット減少※)
    • 元の演奏の音量を-16 dB LUFS(仮の想定*)、quietで正規化後の平均音量を-23 dB LUFSとして**、-7dB= x0.446とした。
  • PC内部での増幅: x2.24 (7dB)
    • 表現上は約1ビット(1.17ビット)増える※が、実際にはデータの有効数字は増えない。
  • DAC出力の音量: 1.0
  • アンプの増幅量 G1: A

※除算してから乗算するので、内部処理方法によってはデータのビット数が減少しない可能性がある。そうでない場合でも、DACの有効ビット数(20ビット未満)は内部表現のビット数(24または32ビット)より少ないので、実質的には減少分は無視しうる。

*実際には音量は演奏(曲)によって変化するので、これらの値も音量に従って変化する(下の、PC内部で増幅しない場合も同様)。

**Spotifyの情報によれば、quietは-23, normalは-14, loudは-11 dB LUFS。

PC内部では増幅しない(アンプで増幅する)場合

  • 元の演奏の音量: 1
  • Spotifyの正規化(quiet): x0.45 (約1ビット減少)
  • PC内部での増幅: x1 (なし)
  • DAC出力の音量: 0.45
  • アンプの増幅量 G2: A/0.45

A > 0なので、G1 (A) < G2 (A/0.45)となり(比は内部増幅の倍率の約2.2倍, 7dB)、増幅なしの場合はDAC出力が小さく、その分アンプ(ボリュームを含む)での増幅量が大きい。そのため、DACで小さい音量を出すことでの精度劣化(約1ビット分)、アンプまで(コード、ボリューム・アッテネータ)の雑音混入や音質劣化、アンプでの雑音・音質劣化といった負の要因が増える可能性があり、得策ではなさそうだ。

結局、元のまま、PC内部で増幅してDACから出すのが最適そうだということになって、戻した。

いずれにしても、本当にわずかな違い(しかも理論上)の話なので、実用上はどちらでも問題はない。気分の問題である。

と書いたのだが、上記のようにDAC出力の音量が(数値上は)7dB違う(約2.2倍)ので、結構音質に影響がありそうだ。聴いても違いは分からなかった(ただ、何となく音が悪い気がすることがあった。どのようにかは はっきり覚えていないが、音の鮮度が落ちたような気がしたように思う)が、実際にはどうなのだろうか(まあ、「病は気から」的なものだと思うw)。

 

(1/13 8:39) 訂正後に検討したら、Spotifyの音量正規化にquietでなくnormalを使ってPC内での増幅量を減らす(約2.5倍, 8dBに)ほうが得策なようだ。ただ、normalの場合には音量正規化処理で増幅される場合があり、それを増幅するとオーバーフローすることもあり得るので、音質が劣化する可能性がある。が、それは頻繁でなさそうなので、試す余地はある。 → あとで詳しく検討・試行したい。

(1/13 18:01) どうもこの稿は誤りが多い。上記の減らした増幅量は2.5倍でなく約0.79倍(-2dB)である。

  • 元の演奏の音量: 1
  • Spotifyの正規化(normal): x1.3 (+2dB)
    • 元の演奏の音量を-16 dB LUFS(仮の想定)、normalで正規化後の平均音量を-14 dB LUFSとして、+2dB= x1.26とした。
  • PC内部での増幅: x0.79 (-2dB)
    • 当初想定していた音量に合わせるため、Spotifyの正規化で-14dB LUFSになった音量を-16dB LUFSに戻す。
  • DAC出力の音量: 1.0
  • アンプの増幅量 G1: A

これなら、Spotifyの正規化でオーバーフローが起こらない限り、PC内で情報が失われることがないので、音質的には最良だ。

正確には、PC内部での増幅(実際には減衰)をしないのが一番だが、他アプリと音量を合わせたいので、あえてそうする。

さっき この処理を実装して動くようになった。気のせいだとは思うが、音が よりシャキッと(鮮度が上がった)した気がする。もちろん気のせいだ^^

 

(1/13 8:39 Spotifyの音量正規化の音量を訂正し、それに関連する修正・加筆した。; 1/13 12:52 PC内部での増幅ゲインも間違っていたので訂正した。; 1/14 10:55 見にくいので、訂正前の取り消し線の部分などを削除し、補足を追加した。)

  •  0
  •  0

夏に作った、ディスプレイの輝度自動調整システムの明るさセンサの ついでに付けた室温測定機能。冬になってから、朝などに温度センサ(以下、「センサ」)と一般の温度計(以下、「シチズン大」)の差が大きいのが気になって居た。1℃くらい温度センサが高いようだった。合う時もあるので、「たまたま」wか、測定場所が違うせいかと思って居たのだが、そもそも、朝起きた時には ずっと空調が停まっていて室内の温度が ほぼ同じと考えられるにも関わらず違っているのはおかしいし、段々ズレがひどくなって来て見過ごせなくなったので、重い腰を上げて調整した。想像以上に大変だったが、センサと温度計が合うようになったのが気持ちいいし、今まで分からなかったことが分かった(気がする)。

なお、ここでは、シチズン大が「真の温度」を示すと仮定し、センサの示す温度を それに近づけるような補正を考えている。もちろん、シチズン大にも誤差はあるが、市販品なのでセンサよりは正確で安定している(突発的な誤差の変動が起こらない → ほぼ一定のオフセット誤差が長時間続く)と想定する。

ズレの原因は、推定した温度センサ(サーミスタ)のパラメタ(B値, 基準抵抗値, 基準温度)が異なっているのかパラメタが温度依存なのか、温度が下がるにつれてサーミスタの抵抗値から得られる温度が高くなるためだった。そのズレの量は、パラメタが合っているであろう温度からの差に比例しているようだ(簡単に言うと、温度が上がるとズレは減る: 下図の灰色の点線が補正量(= ズレの符号を逆にしたもの)。

YL-40の温度センサを直線で補正した。

今までの測定と調整から、補正の式は以下のようになった。

補正パラメタ:

    • 補正する下限の温度: Ta (実際にはこれより低い温度も可能)
    • Taでの補正量: Da
    • パラメタが合っているであろう温度: Tb
    • Tbでの補正量: Db= 0

→ 補正直線の傾き: k= (Da-Db)/(Ta-Tb)

温度補正式: センサの温度をtとすると、補正後の温度t'は以下である。

t < Tbの場合: t’= t + k * (t – Ta) + Da
t >= Tbの場合: t'= t

実際のパラメタは以下になり、kは0.0905となった。

  • Ta: 14.0 (℃)
  • Da: -1.72 (℃)
  • Tb: 33.0 (℃)
  • Db: 0 (℃)

以下に補正の例を示す。

  • シチズン大: 15℃: 補正前のセンサ: 16.35℃, 補正量: -1.51℃ → 補正後のセンサ: 14.8℃
  • シチズン大: 20℃: 補正前のセンサ: 21.15℃, 補正量: -1.07℃ → 補正後のセンサ: 20.1℃
  • シチズン大: 22℃: 補正前のセンサ: 22.84℃, 補正量: -0.92℃ → 補正後のセンサ: 21.9℃

ズレは結構大きく、しかも、ほぼ全温度(33℃以下)でズレて居たことになり、一体僕は何をしていたんだと、なかなか がっかりだ。確かに、夏に調整していた時も、夕方などに なぜか0.6℃くらいズレたままだったことがあって、当時はシチズン大の「熱・冷え溜まり」と思って片付けたが、実は こういうことだったのかも知れない。※ ただ、温度が高くなると上の補正式からズレてくると思う(実際には曲線なのではないか)ので、春や初夏に再度確認・調整したい。

※今、上の式で26℃での補正量を計算したら、-0.63℃だった。合わない0.6℃の正体は これだったのだろうか? (だったら楽で いいが・・・w)

 

何日間も寒い朝に暖房なしで測定するなどの苦労をして、上の補正式とパラメタを求めてプログラムに適用したところ、概ね合うようになった(下に例)。

YL-40とシチズン大の温度が合っている例。: YL-40の温度は右端下部の"Rm ℃"の下。

上のグラフを説明する。: グラフは補正式が分かってからの数日間の測定・補正結果を示している。横軸は温度センサでの温度、縦軸(左)はシチズン大での温度または補正後の温度、縦軸(右)は補正量(オフセット)である。グラフ中央の斜めの点線は補正前後の温度を示す。測定した温度の点が この直線上にある時※、温度センサ(補正後)とシチズン大の温度が「合っている」状態である(ほとんどの点はセンサの分解能の約±0.25℃に収まっている)。

※正確には、「この直線の近くにあるはずの、センサの温度とシチズン大の温度を対比する線上」であるが、センサの温度とシチズン大の温度を対比させることは正確な補正することであるので、描くことはできない。

下のほうの灰色の線は温度センサの温度に対する補正量(縦軸は右)を示す。

たまにズレが大きいことがあるが、暖房をし始めたり、日が出て来たりして温度変化が急な場合に、温度計とセンサの温度反応速度の違いが影響していると推測している。不思議なのは、なかなか合わない領域があることだ(グラフの20-22℃の膨らんだ部分)。

他におもしろいのは、日によって測定点の直線からのブレ方(上か下か)が違うことだ。センサのADCの特性が長短時間的にブレるためかと想像している。そのため、補正後の値のグラフが そのブレの範囲の中央辺りを通るように調整した。

 

最後に苦労話を書く。

センサとシチズン大の温度差をちゃんと測れるようになるまでが大変だった。そもそも、「同じ温度」を比べていないのに気付かずに惑わされたので、何度も試行錯誤した。空調(暖房)の影響にも惑わされた。一時は、机の下の電気ストーブや日射しや横にあるディスプレイの熱もズレる原因かと思ったが、それらはセンサとシチズン大の両方に効くので、直接の原因ではないことが分かった。ただ、反応速度に差があるので、短時間的にはズレるため、原因と誤解してしまった。

やはり、以前も書いたように、正しい測定・計測が一番重要だ。これを しなければ・できなければ、何もできない・始まらない。

測定ファースト!

それから、電源を入れてからセンサが温まるまで(約10分)は温度が低目に出ることにも惑わされた。夏でもそうだったが、寒い場合はその時間が長引くことに気付かなかった。それが分かるまでは、補正は中央辺りでV字に交わる2つの直線(低温側の傾きは負)なのかと思ったが、そんな器用なものではなかったし、日によって結果が異なった(電源を入れる時刻が違うので、開始時の温度も違うため)ので、そのたびに補正パラメタを変更していた。

あと、センサのケースの通風が悪いのかと思って、側面のほぼ全体を開口にしてみたが、効果があったかは不明だ(温度の精度の点では ないだろう)。まあ、埃が入りやすくなる以外は、通風が良くて悪いことはないのでそのままにしているが、もし、センサ付近に埃が溜まるようなら、狭めたい。

 

PS. センサの温度分解能の0.25℃は物足りない。ちょっとした時に差が大きく見えて、気分が悪い。今はADCの測定可能範囲の半分以下しか使っていないので、フルに使うようにすれば0.1℃オーダー(例: 0.18℃)にできる。のだが、かなりの手間が掛かる(例: 明るさも温度も調整・較正し直し)ため保留している。というか、やりたくないw

そもそも、分解能を上げても それに合う精度が あるかは疑問で、「雑音で ふらついているだけ」ってことになるかも知れない(それでも、平均すれば精度が高められる可能性はある。音や画像のディザーのイメージ)。

分解能以外に、ADCの誤差(オフセット, 直線性)を補正できないかと思って基準電圧源を調べたが、手軽なものではADCの分解能(約14mV)を超えるものは なさそうなので諦めた。また、1個だけでは駄目で、少なくとも2個(高・低電圧)必要なので、なかなか大変だ。

  •  1
  •  0

(突発的に?)光とモバイルのプロバイダを移ったり、窓の異臭漏れ防止シートを正式版に張り替えたりして停滞しているが、Zim+Joplinのシステムは概ね問題なく使えている。

前回から以下を修正・改良して、随分良くなった。

  • 行の(ソフト)ラップがないように振る舞う場合があるのを概ね解消した。
    • ノートに埋め込んでいる画像の表示幅が広過ぎることが主な原因だったので、設定した最大幅※より大きかったら、自動的に縮小するようにした。
      • ただ、設定値が不適切だったり、画像がインデントされていて、画像の幅+インデント量がペーンの幅を超える場合には駄目である。
      • ※本来、ペーンやウインドウの幅から画像の最大幅を求めるべきだが、まだそれらが取得できないので、設定に依存している。
    • また、テキストのラップ方法にも よるようだったので、単語単位から単語+文字単位に変更した。
      • 日本語では単語単位のラップは意味がないので、どうにかして「ちゃんと」したいが、これしか やりようがないのかも知れない。
        • そういう点では、このWordPressのエディタや表示は全く優れものだ。
    • 依然として、問題が起こった場合にHomeキーが思うように効かないので、何とかしたい。
  • ノートを開いた時に、より確実に前回のカーソル位置を復元できるようにした。
    • この処理は元々ハッキング的に実装されていたが、時々動作が不完全だったので、復元するための待ち時間(= スクロールする時間?)を結構長くした。
  • 起動するたびに/tmpにログディレクトリ(zim-xxxxx)が作られないようにした。
    • 特定のディレクトリ(例: /run/user/ID)にログファイルを作るようにした。
    • 以前のログは10個くらい残すようにした。
  • MDへのエクスポートの改良
    • 見出しのMDのタグを標準的なもの(Joplin= gfm?)に合わせた。
      • インポート時も同様な修正が要るようだが、未対処である。
  • ノート名のボタンのラベルの文字サイズを小さくし、なるべく多くの文字を表示できるようにした。
  • (特に書式のエクスポート・インポートのテスト用ノートで)ZimとJoplinの行き来を繰り返すとテストができなくなってしまうので、Joplin→Zimの一方通行だけにできるようにした。
    • 画像のインポート用ノートを無駄にZimからJoplinにエクスポートしないようにも使っている。
  • (以下、書いたあとでの追加: 12/18 12:43) Joplin→ZimとZim→Joplinの変換(エクスポート・インポート)処理を改良した。
    • [Joplin→Zim] コードブロックが正しく表示できない場合があるのを解消した。
      • MDをZimに変換するpandocの仕様で、コードブロックを囲むタグが ~~~の場合、ZimのSource Viewというプラグインを使うようになるが、うまく動かないようで、先頭に"{{{code: lang="(改行)"linenumbers="True""などと入り、ブロックの終わりが認識されず、最悪の場合はZimが強制終了する(ブロックが大きくなり過ぎるため)。
      • そこで、Joplin→Zimの変換プログラムで、MDの2種類のコードブロック(~~~, ```)をどちらもZimのもの(''')に変換するようにした。
    • [Joplin→Zim] 上と同様に、水平線(HR)も、Zimが認識する ---に統一するようにした。
    • [Joplin→Zim] 見出し(##など)に下線が付く場合があって煩雑なので、下線を削除するようにした。
    • [Joplin→Zim] 同様に、見出しの前後に余分な空行が入らないようにした。
    • [Zim→Joplin] ノート先頭に書いた見出しがなくなることがあるので、なくならないようにした。
      • 直すまでは、先頭の見出しの前に . のようなダミー行を入れて しのいでいた。修正も同様にしているが、Joplinにインポートする前に除去している。

それでも、依然として すごく気になる問題や改良したい点は残って居る。特に以下である。

  • 描画の更新がおかしいことがある。
    • 大きいノートを変更すると、その行が上下に重複して表示されることがある。
      • 他のアプリでは見たことがないのに、どうして起こるのか不思議だ。
      • ここにキャプチャを載せようと思って試すと、起こらないw
      • とりあえずは「軽い再描画」(ブラウザのF5のもっと軽いイメージ)ができるようにしたい。
  • 新しい画像が入ったノートのJoplinへのエクスポート
    • Zimで追加した画像をJoplinに取り込めるようにしたい。

前者については、いろいろいじってZimの内部構造やPythonでのグラフィック(GTK)のやり方が分かって来たので、調査・試行錯誤すれば できそうな気はするが、まだ原因が掴めていないので、根本的な対処は難しい。

後者はやり方は分かっているけど面倒なので、純粋に僕のヤル気の問題であるw

逆に言えば、大きな問題は もう2つしかなく、時々イライラはするものの充分実用的(Joplinより10倍以上使いやすい)なので、残った難しい・面倒な問題を片付ける気が なかなか起こらない。まあ、年末の宿題か来年の初仕事だ。

 

(12/18 12:17) Zimならではの良さの一つに、gitなどでバージョン管理できることがある。Joplinにも履歴機能はあるが、指定期間で削除されてしまうため、古いノートの履歴が参照できない。※ そのため、古いノートの変更に失敗して戻したくなってもできないのだ。

※少し前までは最大*日分残ると誤解して古くても残って居ると思い込んで居たが、そうでなくてがっかりした。

Zimではそんなことはなく、履歴は無限に残る(はず)。データ量は増えるが(それほど多くはないはず)、それよりも、確実に復活できることが重要だ。そして、汎用のツールを使っているので、好きなアプリで履歴を見られるのもうれしい。ただ、履歴を記録するのは定期的なので(ノートを保存した時にも記録されると思う)、残らない履歴もある。

それでも、なくなるよりはずっといい。当初はgitのようなものを使うのは安直だと思っていたが、Joplinのように いい加減な機能を内蔵してプログラムとDBを肥大化させるうえに、いざという時に役に立たずにがっかりさせられるよりはずっとマシだし、ずっといい考えだと思う。

 

PS. 意外にオリジナル版も少しずつ(残念ながら、細かいものばかり)修正されているので、まとめて適用したい。あと、僕の改良・改造もオリジナル版に入れてもらいたいが、説明や準備が結構な手間なので、やってもフォーク(分岐)程度かと思っている。いずれにしても、描画の更新がおかしいことがある問題が直ってからだ。

  •  0
  •  0

最初、「首までどっぷり」ってのは"Knee deep in the hoopla."みたいな感じかと思って居たのだが、調べたら ちょっとニュアンスが違うようだ。そのくらい、(全然やりたくなかったのに)Zimに はまってしまっている。

 

(他のノートアプリ同様)Zimも駄目なところが多く、ガッと捨てようと思ったのだが、探しても他にいいものは全くなかった。それで考えて、細かい問題は いろいろあるものの致命的なもの(例: 遅い、メモリの浪費)は ないので、慣れたり発見したり手を加えたりして使っている。前回も少し書いているが、今までに以下のようなことをした(詳細は追って追加したい ← と書いた割には ほとんど書いた気がする)。

  • JoplinからZimへのインポート関連
    • ノート・ノートブック名の変換、正式な(または本来の)ノート・ノートブック名の保存。
      • Zimはノート・ノートブック名に使えない文字が多いので、それらを削除したり別の文字に置換するようにした。
      • 正式なノート・ノートブック名を保存するため、追加ノート情報ファイルに記録するようにした。今のところ、以下を格納している。
        • 正式なノート名
        • 正式なノートブック名
        • JoplinのノートID: Zimで更新したノートをJoplinに戻す(反映させる)時に使う。
    • 書式の修正
      • pandocでZimの形式に変換する時に仕様の差があるので、その対処をした。
        • 具体的には、水平線("-"3個以上)をZim("-"20個)に合わせている。
      • また、ノートにZim用のヘッダ(pandocは付けない)を追加している。
        • そこにノートの作成日時を入れるため、Joplinから取っている。
    • Zimのノートブックの作成
      • Joplinのノートブック名と同じディレクトリを作るようにした。
      • その時、Zimのノートブックファイル(notebook.zim)も作るようにした。
    • インポートを手軽に。
      • Joplinのノートを外部編集を開始する操作で、ノートをZimにインポートできるようにした。
      • インポートが終わったら通知が表示されるので、外部編集を終了する。
  • ZimからJoplinへのエクスポート関連
    • ノート・ノートブック名を戻す。
      • インポート時に保存しておいた正式なノート・ノートブック名に戻す。
    • 書式の修正
      • ZimからMDに変換する時に誤変換のようなものがあるので、その対処をした。
        • Zimから出す時に書式が欠けるため、出す前後に処理を入れないと うまく行かない。
      • 例えば以下である。
        • "// 文字 //": "//"が"*"になってしまうので、"/"をエスケープする。
        • (行頭)"--- 文字 ---" : 水平線ではないので"*** 文字 ***"に変換する。
          • 手でJoplinに入れても問題ないので、Zimが"---"を誤変換してしまうようだ。
        • 行頭のn個のTAB + 文字 (インデント): MDに同様な書式はないので、引用にする。 → n個の">" + 空白 + 文字
          • ただし、TABで始まるものにはインデントされたコードブロックや箇条書き、チェックボックスもあるが、それらは変換しない。
        • 行頭の空白 (+ 文字):  上と同様に引用にする。 → ">" + 空白 (+ 文字)
          • 空白の数で">"の数を増やすと良さそうだが、どうやって数を決めるべきか分からない。
        • チェックボックス: ""と""になるので、MDの"[ ]"と"[X]"に戻す。
    • リソース(画像など)ディレクトリの変換
      • ZimとJoplinで同じファイルを指していても、ディレクトリの表現や階層が異なるので変換する。
    • Zimで作った新規ノートへの対応
      • 正式なノートブック名(あれば)でJoplinのノートブックを作る。
      • 正式なノート名(あれば)でJoplinのノートを作る。
      • Joplinにインポートして割り当てられたノートIDを、追加ノート情報ファイルに保存する。
      • TODO
        • 正式なノート・ノートブック名を手軽に(追加ノート情報ファイルに)設定する手段(例: 入力ダイアログを出す)が必要だが、まだない。
        • Zimで追加したリソース(画像など)をJoplinに取り込み、ノート中のディレクトリを変換する処理が必要。
          • 今は、Zimで普通に追加した画像はJoplinでは見えない。
    • エクスポート(更新・追加)を手軽に。
      • 自動または手動(ツールバーのボタン: 後述)でできるようにした。
      • 自動の場合、約30秒間隔で、ノート(のファイル)の更新時刻が前回のチェック開始時刻から現在時刻の約90秒前までの間のものを探し、それをJoplinにエクスポートするようにしている。
        • 約90秒というのは「ノートを書き終わったかも?」と判定する時間である。
        • ファイル検索が頻繁で効率が悪くて気に入らないが、とりあえずは使えている。
          • 効率を良くするにはinotifywaitなどを使えばいいのだが、変更後に一定時間(今回は90秒)経過するまで保留するのが難しいので、保留している。
      • 自動でエクスポートされるまで待てない場合は、手動でもできるようにした。
  • UIの改良
    • GTKのCSDのようなものを止める。
      • Zim(実際にはGTKの流儀のようで、他にもいろいろなアプリがそうしているが、なんでそんな勝手なことをするのかと思う)がタイトルバーを勝手なUIにしていて、通常あるメニューのボタン(▼)が出なくなるため、僕の場合は最小化(_)と×(ウインドウを閉じる)が隣になってしまって間違って押しやすいので、ソースを改造してウインドウマネージャが付ける普通のボタンに戻した
        • 今のところは、GTKやZimがタイトルバーを変更しないようにしているだけのため、Zimが追加しているボタン(前・後のノートへ移動, ホーム, 編集のon/off, 検索)は出ないが、最初から余計だと認識していて使わないので問題はない。
          • Chromeもこういう感じになったが、今のディスプレイは広いんだからタイトルバーの面積くらいケチらなくてもいいのに、どうしてこういう発想になるのか理解できない。
        • TODO
          • 前・後のノートのボタンは あれば便利な気がするので、あとで付けたい。
    • 正式なノート・ノートブック名の表示
      • ソースを改造して、Zimのファイル名ベースのノート名などの代わりに、上述の保存しておいた正式なノート・ノートブック名を表示するようにした。
        • ごく当たり前のことなので見ても何がいいか分からないとは思うが、例えば、Zimでは使えない"#"や"/"が(代用文字でなく)出ているし、"_"は空白に変換されずに出る。
        • なぜか、図では本来は"-)"の")"がなくなっているが、短縮処理のためだろう。
      • 処理概要: ノートを読み込む時に追加ノート情報ファイルがあればそれを読み、キーと値をノート(Zimでは「ページ」)のメタデータ(Page._parsetree.meta)に追加し、タイトルバーなどのUI部品でページ名などを表示する時に それらがあれば使う。
      • 今のところ、以下で出る。
        • タイトルバー: ノートとノートブック名
        • タブのようなボタン(パスバー(下図の中段), ブックマークバー(下図の下段)): ノート名
      • TODO
        • 左サイドバーのpage index(ファイルマネージャーのようなもの)は作りが違っていて変更すべき箇所が分からないので、まだである。
    • バージョン表示に追加
      • 改造版であることが分かるように、バージョン表示ダイアログに出るようにした。 (: 中央の".B-3"と最下行)
  • 簡単な機能追加とツールバーへの登録
    • 以下の処理をZimのCustom toolとして追加し、Zimのツールバーボタンに登録して手軽に実行できるようにした。
      • 現在のノートのJoplinへのエクスポート(更新・追加) (: 中段左寄りの青い"J"のボタン)
        • 処理内容は上述のとおり。
      • クリップボードをテキストとしてペースト(LibreOffice Calc対応) (: 中段左寄りのペーストのボタン)
        • 前回も書いたが、ZimかLibreOfficeのクリップボードの扱いが変なのか、LibreOffice Calcからテキストをペーストすると画像になってしまうので、xsel(その後、xclip -quietのほうがハングしにくいことが分かった: 11/22 5:26)コマンドでPRIMARYバッファのテキストを取得して、ノートに挿入できるようにした。
          • なぜかCLIPBOARDバッファを取ろうとするとハングするが、PRIMARYで問題はなさそうだ。
            • 調べると、CLIPBOARDはPRIMARYなどと処理が違うようなので、その関係だろうか。
          • (12/1 12:06) その後、LibreOffice CalcからだとCLIPBOARDでないとテキストが取れないようなので、結局、xselを使い、ハング回避のためにタイムアウトさせることにした。
          • 以下にコマンド例を示す。

sh -c 'to_ms=120; to_s=`echo "scale= 3; $to_ms / 1000" | bc -l `; xsel -o -b -t $to_ms < /dev/null & xs_pid=$!; sleep $to_s; kill -TERM $xs_pid'

        • これはボタン以外にショートカット: Ctrl+Shift+Vに割り当てている。
        • TODO
          • なぜか、Zimでコピーしたテキストはペーストできない。Zimとxselが競合しているのかと思うが、今のところは通常のペーストと使い分けが必要で、ちょっと気に入らない。
      • 選択範囲をインターネット(Google)で検索 (: 中段左寄りのGoogleのボタン)
        • 選択したテキストをGoogle検索のURLに追加して、デフォルトブラウザに渡して検索できるようにした。
        • これができるエディタは ほとんどない(知らないだけかも)が、是非欲しかった機能なので付けた。
        • TODO
          • セキュリティホールになりそうな気がするが、個人用なので注意すれば良さそうだ。

 

随分手間が掛かっている(これでも全然終わりでない・・・)が、ソースなどを見れば結構分かり、ツールバーのように簡単にできて効果が大きいものも多いので、ストレスは少ない。そして、今まで仕方なく使っていたMDと違って、Linuxのコマンドやプログラム(`とか~とか-とか*とか#など、MDで特別な意味を持つ記号がバンバン出て来る)を書くのに何も気を遣わなくていい、いや それ以上に、本来の記述とノート(ファイル)が全く同じに書けることが重要・必須だ。まさに、「まだMDで消耗してるの?」だ。

ただ、Joplinに送る時(見る時)にMDに変換されるので、あまりいろいろな記号や書式を入れると、うまく変換されるか心配には なる。そして、運が悪いとバグが見付かって、余計な作業が増えるw

なお、QOwnNotesかZettler(かZimにインポートする時)に書式がおかしくなったノートが結構あって、見付けた時に手で直している。まあ、そんなの可愛いもので、見れば分かるので問題ない。

 

PS. 自分の整理のため、本システムで今分かっている残件・TODO・直したい・やりたいことを以下に挙げる。 (19:54)

  • Zimの不具合・変な点など
    • 描画の更新がおかしいことがある問題への対処。
      • 大きいノートを変更すると、その行が上下に重複して表示されることがある。
      • これを一番先に直したいが、見当が付かない。
      • 直せないなら、デフォルトのフォント(問題が起こらないようだ)の行間や太さを変えて、すっきり見えるようにしたい。 ← デフォルトでも問題が起こったので、駄目。 (11/21 12:35)
    • 行の(ソフト)ラップがない(ように振る舞う場合がある)。
      • これも早く直したいが・・・
      • せめてHomeキーで行頭に戻れるようにしたい。
    • ノートの先頭の見出しがMDに出ない場合がある。
      • 先頭に空行以外があれば、その次が見出しになるようだ。
    • [済] 書式に余計なものがある。 → ソース(pageview/__init__.py)を変更しても反映されないので調べたら、Zimのスタイル設定ファイル(.config/Zim/style.conf)で変更できることが分かって、自分の好みにできた。 (11/22 18:01)
      • 見出しのH1に下線が付き、H3は斜体になる。: 文字サイズだけでいい。
      • 下線は色付きになってしまう。: 下線だけでいい。
  • 機能追加・修正
    • Zimの書式指定タグ関連 (11/24 16:10)
      • 書式指定のタグ(後述の"@"で始まるタグ(ページタグ)とは異なる)に、Linuxやプログラムに良く出て来るもの(例: "__XXX__"(下線), "// YYY //"(斜体)※)があり、インポートしたり貼り付けたりしたあとにコードブロックにし忘れると、次回開いた時に下線(例の場合、"XXX")や斜体(例の場合、" YYY ")になってしまって嫌なので、それらを滅多に出て来ない文字列(例の場合、"⟪_XXX_⟫", "⟪/ YYY /⟫")に変更した。
        • ※本文の「"// 文字 //": "//"が"*"になってしまう」はこれが原因だった。 WYSIWYGなので、中身までは気付かなかった。
        • 似たようなものは、他に"** ZZZ **"(太字)や"~~ WWW ~~"(取り消し線)もあるが、同様に変更可能である。
        • この関係で、インポート時に本来のタグを変更したものに変換するようにした。
      • ページタグも同様にしたかったが、書式が異なるうえに処理が分散していて完全に変更するのが難しいので、ひとまず無効にした。
    •  エクスポート関連
      •  Zimで追加した画像のJoplin向けの処理
        • 本文に書いたとおり。
      • コードブロックのインデントをMDに反映させる。
        • 今はコードブロックが引用になってしまう。
      • 未更新の全ノートを手動で更新(エクスポート)できるようにしたい。
      • Joplinの新規ノートブックを階層も含めてちゃんと作成する。
    • インポート関連
      • インポート時の誤変換などの修正・対処
        • [外部] 空行を挟まない改行が繋がることがある。: pandocの問題? → Zimで書いた場合は繋がらないので、以前のエディタ(Zettlr?)の仕業だろう。 (11/22 18:01)
        • [正常] "@"+文字がZimのタグ(ページタグ)になることがある。 ← Zimの仕様だった。ただ、こういうところがMDみたいになっているのが気に入らない。が、シンプルなテキストファイルなので こうするしかないのも分かる。 (11/22 18:01)
          • とはいえ、ノートにはヘッダ部があるので、そこにタグを書けばいいのにとも思う。そうすれば、タグに空白や記号も含められる。 (11/22 18:27)
          • 逆に、Zimのタグを付ける方法が不明。。。 ← "@"+文字で付ける。(11/22 18:01)
          • → 結局、これの良くない点は、良く使う@をタグのマークとして使っていることだった。上述のように他にもそういうことがあったのでマークを変更したが、このページタグの変更は難しいので、ひとまず無効にして、意図せぬタグができないようにた。僕はタグを使わないので、当面は問題ない。 (11/24 16:10)
        • [外部] IPv6アドレスの一部が記号になる。 ← 再現しないので、以前のエディタの仕業だろう。 (11/22 18:01)
          • 例: ":b:"が"🅱️"(色は黒)になる。
          • 以前のエディタがおかしくした?
      • Joplinでのノートの変更をZimに反映できるようにする。
        • スマフォで更新することもあるかも知れないので。
        • → ひとまず、エクスポート時にJoplinとZimの変更が競合したら、Joplinのノートのバックアップを作り、Zimのノートを上書きし、メッセージを出すようにした。 (11/22 18:01)
          • また、インポート時(Joplinから操作)も同様にした(Zimのバックアップを作る)。
      • ノート中のscheme(例: http://)に見える記述やリンク(パスがリンクになる)の無効化または正常化? → ノートを読んでからフォーマットするため、指定箇所の無効化は無理そう(もちろん、その部分の書式をコードにすれば可能だし、全部を無効にすることはできそうだ)。 (11/22 18:01)
        • Joplinからインポートした時に変なノートができるのを防ぎたい。
        • また、変なリンクがあると、Zim自身でノートをペーストできない場合がある。
        • これに関連して、不正な"file:"のURLがあるとfs.pyがAssertionErrorになってエクスポートできない問題があったので、assertしないように修正した。 (11/22 18:01)
    • UI
      • 正式なノート名などの表示の追加(例: page index)
      • 正式なノート名などの入力UIの追加
      • ツールバーの箇条書き, 番号付きリスト, リンクなどの書式設定ボタン(: "x2"の右の箇条書きとその右の"H"の右のボタン)で出るメニューの要素を独立させて横に並べる。
        • プルダウンメニューは面倒なので。
        • ただ、多過ぎると邪魔になる。
      • カーソルの点滅を止める。
      • CSDを止めてなくなった前・後ページボタンを付ける。
    • その他
      • Zimでコピーしたテキストも、追加したテキストのペースト機能(本文に記述)でできるようにしたい。
      • 起動するたびに/tmpにログディレクトリ(zim-xxxxx)を作らないようにする。
      • アイコンが超ダサい。これだけで随分損しているのでは?
        • でも、そんなことは僕にはどうでもいいので放置w
  •  1
  •  0