OBDelevenでLong Coding

VCDSではできない「Video in Motion」ができるということで納車より先に買っていたOBDeleven(とAndroidスマホ)，みなさんの奮闘を見ているうちに，VCDS並みにいじれそうなことが分かってきた(そんなにあれこれやるつもりもないのだけど)。

平日はクルマにつないでいじる時間もなく，週末に車庫にこもって，どこをどういじれるのかとあれこれ覗いてみた。練習のつもりだったので保存は一切してなかったのだが，

Long coding
　　Control unit: 09 Central Electrics
　　Old value:
　　　　03011A42424122FB49E44000000C07281800000000000000000000000000
　　New value:
　　　　03011A42424122FB49E44000000407281800000000000000000000000000
　　Mileage: 774 km
　　Date: 2017-07-22 23:46

というログが残っていた。この設定がどこなのかもよく分からず気持ち悪い……。

<追記>
(シンクレアさんから頂戴したコメントへのお返事)

左から数えて14bytes目(0byte→13bytes)が0C→04に変わってて，その1byteを2進で表すと00001100→00000100で，「右から数えて4bit目(0bit→3bit)はヘッドライトウォッシャーのON/OFF」なんですよ，と，そういう訳なんですね。「Cが4に変わった」のが何を表すのかさっぱり分からずモヤモヤしてましたが，意味が分かってスッキリしました。

で，なぜその時にはいじってないのにログに残ったか，という疑問が残りますが，ログの日時より前にOBDelevenのAppでヘッドライトウォッシャーをOFFにしています。それをLong Codingで見るとどういう感じになってるのか見てみよう，と件の場所を開きました。まさにご推察の通りです(恥ずかしながら言われて思い出しました)。Appで設定した時にはログに残らず，Long Codingで開くとそれ以前にAppで変更した設定がログに残る，という仕様なのかもしれませんね。

OBDelevenはVCDSの様なヘルパーがなく，その代わり結果に一直線で進むAppが売りな訳ですが，コーディングに奮闘中の諸兄の取り組みを参考にさせていただきながらLong Codingで設定を変えたほうが「OBDelevenのブラックボックス感」が薄れますね。ケチくさいですがクレジットも減りませんし。

(独り言)
30bytesの後半がフィラーで埋まってるっぽいのは拡張性のためなのか設計の都合上なのか。プログラマーなみなさんはどう見るのかな？