実家のウォシュレットをSC TCF6210からSB TCF6223へ自力で交換、完了

以前、といってももう10年前になりますが、自宅のウォシュレットを交換した話を投稿しました。
今度は実家のウォシュレットが、電源ランプはいつも通り着いているのに水が出ない、という故障で、また交換することにしました。
一度経験済みなのでもう何も迷うことはありません。

型番に関しては当然ながら既に当時のものは製造完了しているので、TOTOのCOM-ET https://www.com-et.com/jp/ のサイトで検索して、[取替品] ボタンを押すことで現行機種の型番がわかります。

TOTOウォシュレットには、一般向けにカタログに載っている機種と、施工業者や量販店向けの機種があり、後者は価格が1/2くらいです（5万円前後と2万円前後）。
仕様の違いはほとんどないのですが、今回は実家へAmazon（購入リンク）で送付して確実に取り替えられる安全性をとって、一般向け機種を選びました。
元の機種が一般向けだと、TOTOのサイトで取替品として表示されるのも一般向けしか出てきません。

さて、今回の交換時間は約30分でした。
道具は、しっかりした（細めじゃない）プラスドライバとマイナスドライバ、それにモンキーレンチだけです。
取り替えた部品は、ウォシュレット本体、T字分岐菅、それと便座に本体をパチンとはめ込むためのプレートの3つです。
新機種は前に少し長い作りになっていますが、使用上は問題ありませんでした。

滅多に交換するものではないですが、慣れていれば、それほ難しい作業ではないと思います。

QMKのkeymap.cを変更をしてファームウェアを書き込んでも、キーマップに反映されない現象は、VIAの影響だった [自キ沼#13]

セルフメイドの分離型Alice配列ポインティングデバイス搭載のLilithキーボードの作成を続けています。

その中で、QMKのkeymap.cを書き換えて、キーマップをいじって、ファームウェアをビルドする作業を何度もしています。
出来上がった .hex のファームウェアをQMK Toolboxでキーボードに書き込むのですが、いじったキーマップが反映されない現象が出なかったり、出たり、出始めるとずっと出てどうしようもなくなる、という現象でここ数日悩んでいました。

わたしの自作キーボード遍歴は、最初、Sparrow62 v2でして、これはQMKではなくてRaspberry PI PcoのKMKなので、QMKの経験は今回のLilithキーボードで初めての状態です。

色々と調べてもそのものズバリの解決策が見つからず、試行錯誤を繰り返していたところ、VIAの影響では、と思い当たりました。

ファームウェアは現在SU120のものをもとにして書いているのですが、rules.mkでVIA_ENABLE=yesの設定になっていました。
これをコメントアウトしたところ、すんなりとキーマップの変更が反映されるようになりました。

VIAのキーマップはおそらくファームウェアとは別の場所で管理されていて、何らかのタイミングではファームウェアのキーマップが反映されるのですが、別管理なので当然VIA側へ常に反映されるわけではない、というのが理由のようです。
VIAを有効にしたときに即座にキーマップを反映させる方法は、まだわかりませんが、自作キーボードの初期開発段階の設定としてはVIAをOFFにするのが良いようです。

なお、QMK Toolkitのバージョンは少し古い 0.12.16 での話です。

この投稿は、セルフメイドの自作キーボードLilithを使って書きました。
（ジョイスティックの動作はいまだチューニング途上です。）

 

[2023-01-27] 少し遠慮して、タイトルの「変換しない問題」を「変化しない現象」に変更しました。
さらに「反映されない現象」へ変更。

[2023-08-21] 多少慣れてきたので、改めて QMK Firmwareのソースコードを少し覗いてみました。
やはり、次のような動きになっているようです。

1. QMK FirmwareでVIA_ENABLEをしていると、
2. キーボードの電源投入時やリセット時に、既にEEPROM上のVIAデータが初期化されているかどうかをチェックし、
3. 初期化されていなければ、keymap.cのキーマップをVIAデータに書き込む
4. 初期化されていれば、前回のVIAデータをそのまま使用する、つまり keymap.c で設定したキーマップは使用しない
   

該当箇所は quantum/via.c の中の via_init() 関数です。
EEPROMの初期化処理の本体は eeconfig_init_via() 関数と、 quantum/dynamic_keymap.c の dynamic_keymap_reset() 関数です。
必ずここを通るかどうかの確認まではしていませんが、おそらくキーボードの起動時にこの処理が毎回行われます。
これで、keymap.c のキーマップを変更してファームを書き換えても、実際のキーマップが書き換わらない謎がようやく解けました（単純なキーマップ書き換え以上の keymap.c の変更をしてファームウェアのサイズが変わる場合には、おそらくEEPROMのレイアウトが変わることで(運が悪くなければきれいに)VIAデータが無効化されます）。

なので、keymap.c の中でキーマップや追加処理などいろいろな変更を試行錯誤している最中には、次のいずれかの対応が必要ということです。

• 根本的に VIA_ENALBE を無効化する
• keymap.c で QK_CLEAR_EEPROM（短縮名 EE_CLR、古いQMKでは EEPROM_RESET）をキーにマップしておいて、キー操作でVIAをクリアする
• VIAで QK_CLEAR_EEPROM をキーにマップする場合は、Special にある「Anyキー」で16進数の 0x7C03 を指定すれば定義可能（これは最新のQMKでの値、quantumキーコードに属するので古いQMKでは構成によって値が変わるのかも？）、
  VIAなら設定したらすぐに効く（設定を残したいならJSONでSave）
• QMK Toolbox で Clear EEPROM する（私の環境ではなぜか Clear EEPROM ボタンが有効になりません）
• Remap に対応しているキーボードなら、[・・・] メニューの Reset Keymap でクリアする
  

自作キーボードの先輩方には常識なのかもしれませんが、根本原因が分かってスッキリした気分です（これもオープンソースのおかげ）。

やっと組み上がったLilithキーボードの秘密をあれこれお教えします [自キ沼#12]

ここ2週間ほどは本業で多忙が続いて、自作キーボード活動に時間を使えなかったのですが、やっとこの週末にハンドメイド（セルフメイド、オリジナル設計）のLilithキーボードを組み立てられました。

キーマップやジョイスティックのファームのチューニングはまだですが、現物を実際に見て触れるとまた新たな欲が出てきたり。。。

いったんここで、わたしがLilithキーボードに詰め込んだ内容をお披露目しておきたいと思います。

• まず、キー配列に関して、カラムスタッガードではどうしてもCのキーが人差し指で押しにくく、かと言って単純なロースタッガードだと小指の運指が忙しすぎ、かつ小指の可動域を超えているのではと考えました。そこで、短い小指担当のキーを手前に寄せて置けるAlice配列を試してみようと決めました。さらにトラックパッドなどを中央に置きたかったのでAliceでも分割キーボードにしました。（蛇足：標準キーボードでは、上段から下段に向かって行の配置が一様に右にズレていますが、それを使う手の方の構えは、右手は右ズレで合っているのに、左手は左ズレなので、わたしはＣのキーは右手中指よりも人差し指でどうしても押したいのです。ブラインドタッチの教科書では右手も左手も各指が右ズレでキーを担当する、となっていますが、改めて考えるとおかしいと気付きました。）
• はじめて全体を組み上げてみると、8層のFR-4の積層ボディーはずっしり重く、変な振動も抑えられているように思います。プレートの上もケースで囲んでいるのも効果ありのようです。もちろん机に当たる面はデスクマットやゴムシートで和らげてやる必要はあります。
• 回路基板はリバーシブル使用しています。カラムスタッガードで左右対称の場合にはリバーシブル基板は一般的ですが、行方向にズレているAlice配列では珍しいと思います。このためにひとひねりしていて、ジョイスティックがあって配線が多い右手側を基本にして、左手側は2行目と3行目の間でカットして、裏返しして0.25uずらして配線接続することにしました。小指ブロック以外ができるだけ通常のロースタッガード配置に近くなるようにしました。右手側はI-JKLを逆Tカーソルで使いたいので、この間の行のズレはあえて0にしました。切り取ってズラすことで、うまい具合にリバーシブル化でき、基板発注の無駄も減らせたと思っていますす。
• 右手側のいわゆるBの位置にアナログジョイスティックを埋め込んでいます。パーツは非常に多く出回っているNintendo Switchの保守パーツです。基板を切り抜き式にして、このパーツが基板に沈み込むようにすることで、ジョイスティックがchocのキーの高さにほぼ合うようにしました。（この部分、Cherry MXスイッチ前提だと、逆に高さの嵩増しが必要で、プレートの上にジョイスティックパーツを載せることになりそうです。）
• アナログジョイスティックの動きはPro Microのアナログ入力で読み取るのですが、パーツを接続していないオープンな状態では信号が安定しなくて、ポインタが勝手に少しずつ動く現象が出ていて最初とても心配しました。実際にパーツを接続すると信号が安定して大丈夫になりました。パーツなしでも安定するように大きめの抵抗を入れ、未接続でも電圧をかけるようにしたほうが何かのトラブルの時のことも考えると良いかもしれません。
• スイッチプレートの厚みを1.2mm、ミドルプレートを1.0mmにして、chocスイッチのツメがきっちり引っかかるよう、かつプレートと基板の隙間をなくすようにしました。ただし、スイッチソケットの足が1.2mmあることを考慮せず基板を1.0mmにしてしまったので厳密には0.2mmの隙間が残っているはずです。次回は基板を1.2mmにします。
• スイッチプレートとボトムパーツを共有しています。プレートに開いているスイッチの14mmの角穴が、ボトム側でちょうどソケットの出っ張りを逃がすのに都合よい大きさだからです。ソケットはスイッチの中央にあるわけではないので、ボトム側で重ね合わせる位置は0.25uくらいずらします（写真でボトムが前面にはみ出しているのはそのせいです）。ソケットの高さは2mmくらいあるので、プレートとミドル（これも上面と共有パーツ）を基板の下に置いてちょうど良い高さになります。実際に組み立ててみたところ、ソケットのパッド部分が思ったよりも長くて収まらなかったので、少しやすりで削ってはめ込みました。
• 全体として、下から1.2mmのボトム、1.0mmのミドル、1.0mmの基板、1.0mmのミドル、1.2mmのプレートと来て、プレートの上に1.6mmのフレームケースを3枚の、合わせて8枚10.4mmのFR-4積層になります。これ全体をM2ネジで固定しています。がっちりソリッドな構造に、プレートも基板も含めて全体が一体化しています。これって何マウントと呼べばよいのでしょうか、よくわかりません。
• このケースで、あとは、キーキャップが約4mm上に出るので、キーボード全体で約15mmの高さ（低さ）です。Sparrow62キーボードの74thさんの目指した低さと同じ水準になります（74thさんの記事「自作キーボードでキーボードの低さを目指した話」）。
  
• 使用した黒色のM2低頭ネジは長さが10mmまでしかなかったので、最上層とその下をハンダで固定し、最上層に六角の穴を開けてナットを埋め込むようにしました。こうすることで、ネジの先やナットが上に出なくなります。これはSU120の作者のe3w2qさんの「霞襲(かすみがさね)」マイクロキーパッドのアイデアを真似させていただきました（e3w2qさんの記事「着せ替えできるキーパッド、霞襲を作りました」とビルドガイド）。
• ケースを構成するフレームパーツとミドルパーツはコスト安の100mm x 100mmに収まるように分割したものを組み合わせることにしました。なので、切り離し、ヤスリがけ、組み立てと、とにかく手間がかかりましたが、コストは最小限に抑えられたはずです。
• アナログジョイスティックはファームを調整中です。画面上のGUIボタンにスッと移動して押せるくらいの自然な動きが目標です。さらに画面上に丸を描けるくらいに滑らかだと究極ですね。実はそもそもジョイスティックは斜め移動が苦手のようで、さらにこのパーツでは斜めにスティックを倒した時に出力される信号が水平垂直に比べてなぜか弱めにしか出ません。

（写真を交えて説明すればいいのは分かっていますが、まずは手間をかけずに思いを吐き出してしまいたく、よろければこのブログのコメント欄またはTwitter @taka8aruにメッセージをいただければ補足説明いたしますし、大きな励みにもなります。）

この投稿は、Sparrow62 v2＋片側だけLDSAロープロファイルキーキャップ、を使って書きました。

iPhone 14 ProのDynamic Islandはノッチよりもすこし下にはみ出でているけれど、アプリの表示エリアが狭くなる心配はない

iPhone 14 Proでハードウェアとソフトウェアを融合した新しいユーザインターフェースの「Dynamic Island」が追加されました。
このためだけにiPhone 14 Proを買ってみたくなるような機能です。

iPhone X～iPhone 14のノッチと比べて、よくよく見てみると、Dynamic Islandの方が文字半分くらい下に下がってはみ出していることに気付きました。

もしかして、このせいでアプリの表示エリア（セーフエリア）が狭くなるのではと、はげしく心配になりました。
細かく調べてみると、下記のように、よく練られていて、大丈夫なことが分かりました。

• iPhone 14 ProはiPhone 14に比べてボディーサイズがほんの少し長くなっています（0.8mm）。
• さらに、ガラス面のベゼル幅はおそらく同じですが、ボディー側面パーツの厚みが写真でもわかるくらい、約0.5mm薄くなっています（ボディー側面の材質はProがステンレス、無印がアルミ）。
• この合計1.3mmだけ、Proの方がディスプレイの縦方向が長くなっています。
• これは、ちょうどDynamic Islandとノッチの高さの差を吸収する、うまい具合のサイズになっています。

こんなところにまでこだわって、パンチホールに変更による影響を払拭し、さらにDynamic Islandという新しい機能で、必要悪で邪魔者にされてきたフロントカメラを意味のある楽しいもの（さらに欲しくなるもの）にしてしまえるなんて、久々にAppleマジックを見たような気がします。
これもハードウェアとソフトウェアの両方を開発しているからこそできることですね。

ところで、私の記憶が確かなら、iPhone Xでは、ノッチをいじって表示を変化させたり、ノッチを隠すようにステータスバーだけを黒くしたりなど、ノッチをいじくる、厳禁だと言われていたと思います。
いま考えると、中途半端に、ノッチを邪魔なものとしてネガティブに扱うのを避けるポリシーだったのではと思います。
Dynamic Islandによって、フロントカメラ回りを、ポジティブに活用できるようになって初めて、これが解禁されたのだと思います。

来年のiPhone 15ではノッチにもDynamic Islandのような動きが与えられるかもしれません（あるいは一気に全機種がDynamic Islandになってしまうのでしょうか）。
iPad Proの方はと言えば、ベゼルにカメラがうまく収められていますし、カジュアルな使い方のiPhoneよりも落ち着いて使う使い方が主体ですし、さらにマルチウィンドウもできるようになるので（Stage Managerがある）、Dynamic Islandのような派手な通知機能は採用されないだろうと思います。
さらに、M2/M3世代のMacBookではどうなるのでしょう（センターに通知が表示されても画面が広いので視認性が良くないですね）。

[2022-10-06] Dynamic Islandを備えたiPhone 14 Proは、第二世代のiPhone Xと言えますね。