I2C通信に触れてみた

最近仕事でI2C通信に触れる機会があり、触ったことが無かったため、体験する良い機会だと思い、自分で機材を買って動作確認を行った。

OSはUbuntu 22.04を使った。最近Ubuntuに嵌ってしまい、Windowsに戻りたくない病を患っている。Ubuntuを使ってつくづく思うのは、Windowsはとても恵まれた環境だということだ。使っている人数がUbuntuとは桁違いに多いため、企業が積極的にサポートしているおかげで、ドライバは必ず対応されている。それに比べてLinux環境は、最新のものを使おうとするとドライバが自動でインストールされないことがあるため、自分で探してきてインストールする必要があったり、ドライバのアクセス権を宣言しないとドライバ自体が使えなかったりと色々な知識やググりが必要になる。

今回I2C通信を体験するにあたり買った機材は、以下の２つ。

サンハヤト　USB・I2C（SMBus）変換モジュール MM-CP2112
https://www.sunhayato.co.jp/material2/ett09/item_1052
→USBポートからI2Cへ変換するCP2112というICが搭載されたもの。I2Cのマスター側として動作する。

I2C通信のスレーブ側として動作させるのが以下のモジュール。

Grove-I2C高精度温度および湿度センサー（SHT35）

https://jp.seeedstudio.com/Grove-I2C-High-Accuracy-Temp-Humi-Sensor-SHT35.html

I2C通信は、WriteとReadを同時に行うことはできない。Writeしたい場合は、I2Cアドレスに何バイトのデータを書き込むことを伝えて、ACKを受信後、書き込むデータをWriteする。Readしたい場合も同様に、I2Cアドレスに何バイトのデータを読み込むことを伝えて、ACKを受信後、読み込むデータをReadする。主導権は常にマスター側にある。この0x45(default)とox44(optional)の使い方がサンプルソースを読んでも理解できず、２〜３時間悩んだ。SHT35のサンプルソースは以下だが、Arduinoという評価ボードから実行するためのコードであるため、CP2112のAPIとは異なるArduino専用のAPIを使っている点が分かり辛さを増幅していた。

https://github.com/Seeed-Studio/Seeed_SHT35

SHT35のデータシート（以下を参照）には確かに「The ADDR pin must not be left floating. Please note that only the 7 MSBs of the I2C Read/Write header constitute the I2C Address.(I2C Read/Write ヘ ッ ダ の 7 MSB だ け が I2C Address を構成することに注意してください。)」と書いてあるし、
https://github.com/SeeedDocument/Grove-I2C_High_Accuracy_Temp-Humi_Sensor-SHT35/raw/master/res/Datasheet%20SHT3x-DIS.pdf

CP2112のAPI仕様にも「slaveAddress is the address of the slave device to write to. This value must be between 0x02 – 0xFE. The least significant bit is the read/write bit for the SMBus transaction and must be 0.（アドレスはデバイスのスレーブアドレス（0x02-0xFE）です。デバイスはこのアドレスのみを認識します。デフォルトは 0x02 です。最下位ビットはSMBusトランザクションのリード/ライト・ビットで、0でなければなりません。）」と何故か１バイトのうち、１ビット目だけ指定できないようになっている点に疑問を持たなかったのが敗因だが、よくよく考えてみれば不自然な範囲である。

上の図の８ビット目のところは、I2C通信プロトコル固有のビットでWirteなら０、Readなら１に使われる。CP2112のAPI仕様のI2Cアドレスは0x02〜0xFEまでしか指定できないのは、１ビット目が固有ビットになっているから空けておけという意味なのである。
上手く行かなくて悩んでいるとき、「空ける必要があるのであれば、0x45は空いてないから0x44にしないと行けないのかな？」と訳の分からない解釈をしてわざわざジャンパーを0x44に切り替えるために、カッターと半田作業をして余計なことをしていた。。。


以下に今回試したソースコードをアップしました。0x44 << 0x1としている点が味噌です。
https://github.com/zattu1/i2c

上記を動かすには、Qtフレームワークが必要なのと、CP2112のサンプルコードにあるSiliconLabs.rulesを/etc/udev/rules.d/に放り込むのと、CP2112のライブラリ群を/usr/local/lib/に放り込む必要がある。

以下はCP2112のSDK
https://jp.silabs.com/documents/public/software/USBXpressHostSDK-Linux.tar

新型コロナウィルスに罹りました

家族がもらってきた新型コロナウィルスが家族に蔓延して、４回のワクチン接種をしている私でさえも新型コロナウィルスに罹りました。

結論から言うと、結構厄介なウィルスです。デルタ株が流行したときには、味覚・嗅覚機能が低下するという症状がありましたが、オミクロン株は後遺症がある点があります。

コロナは風邪だ、みたいなことを言っているのを聞いたり見かけたりしますが、それを言えるのは３０歳前後ぐらいまでの場合の症状だと思っていて、我が家の子供は熱が収まった後はピンピンしているのに比べて、４０代の私や妻は罹患後症状（いわゆる後遺症）に悩まされています。

日々その後遺症は減ってはいるのですが、風邪よりも圧倒的に傷跡を残そうとするウィルスという印象が強い。以下のページに新型コロナウィルスの後遺症に関する内容が書かれていて参考になるのですが、代表的な症状の１、２位の咳や倦怠感が長い間残ります。

後遺症　東京都福祉保健局

７～１０日前後の安静が必要という理由がよくわかります。倦怠感がとにかく厄介で、頭を使うクリエイティブな作業がとても苦痛になります。というかできません。やる気が起こりません。

私は感覚人間なので、やる気が無くなるとこれが一生続いてしまうのかと考えてしまい落ち込みますが、やれることは食べて寝るぐらいしかやれることがないのが辛い。これがいつまで続くのか考えるのが辛い。朝起きたときに倦怠感があると辛い。

ワクチン接種しているからこれでも症状が軽かったのかもしれません。新型コロナウィルスはヤバいけど、免疫を獲得できたのは嬉しい。

最後に、今年もお世話になりました。
今年は、会社員を辞めて新たな生活様式に移行していく人生の挑戦の始まりの年になりました。
今年こそは、チケットのBOTも全てEmperor AIOにまとめたいなぁ・・・と思っています。やれる時間があれば。

私にとってBOT開発とは何か？

最近、表題のことについて、考えることがあったので、文章に起こしてみた。

一番大事なこととして、自身の収入がある。

元はと言えば、どうしても治療したかった自身の悩みを克服するには、お金が必要だと思っていた。ほぼほぼ完治しした今となっては、お金ではなく自身の働き方から来る自己管理の問題だったわけだが、当時は訳が分からず、手当たり次第でやってみるしかなかったので、お金で解決するのが近道だと考えていた。

私は物欲がない。というのは嘘だが、趣味のバイクとパソコンがあれば、それ以外は興味がない。有り余るお金は必要ない。その為、当社のサロンで、うちのBOTを使ってくれているユーザには惜しみ無くお返ししているつもりだ。

ただ、将来のことは心配なので、蓄えというか株式投資はある程度は行っている。

自己防衛。

次に、プログラミングトレーニングとしての位置付けがある。

途切れなく仕事があるとも限らず、しばらく時間が空いた状態でプログラミングをすると、集中するのに時間が掛かってしまい、非効率な時間を消費してしまうことがあった。常にパソコンと向き合うことで、すぐに集中できるように日頃から準備しておく。その為の自社プロダクト。自分の考えがそのまま仕様となるのは、気持ち良い。しかし、相手はどこかの企業が作ったサーバシステムであり、仕様は分からない。常に手探りで作っており、一番適切な表現なのが、パズルを組み合わせている感覚である。

なので、上手く行ったときは無茶苦茶嬉しい。

開発する上で、仕様がなければ作ることは出来ないが、それを予測しながら作らなければならないので、あらゆることを想定して想像しながら作らなければならないのは、面白くもあり、難しい。

私は勝手に企業の情報システム部門に勝負を挑んでいる気持ちになって作っている。最近は、リアルタイムでアップデートしてくるので、その早さに驚くこともある、

来年からは、新規開発は控えて、今までとは違ったプロダクトを作っていこうと思っています。

TIGETユーザの皆様、お待たせしました。

TIGET自動購入がようやく完成しました。速度が遅くなる原因がようやく解決することができました。

開発当初から速度が安定しない問題はずっとあったにも関わらず、半永久ライセンスを購入頂いていた方には、申し訳ない気持ちでした。色々調査していましたが、ようやくreCAPTHCA v3突破方法が分かりました。

今まではアップデートした直後は速いのに、別のチケットにした途端に遅くなる現象がありましたが、今回のアップデートではそれがありません。

2022/06/30 追記
reCAPTCHA v3もv2と同じように認証のキツさのようなレベルが存在しているようで、Googleにログインしていないと遅くなる現象を確認しました。

TIGETの速度が安定しない

前回の投稿で、高速になったことをお伝えしましたが、特定の条件下じゃないと速くならないことが分かってきました。

速くなるときの条件を上げると、フレームワークを更新したときに、速くなることが分かっています。
Googleのログインをしていないときでも高速だったため、トークン自体の品質があるのではないかと考えていましたが、トークンの品質は考慮しなくて良さそうだということが分かってきました。
reCAPTCHAを使った通信手順は、Client（WebブラウザやBOTなど）がトークンをサーバに送ると、サーバがGoogleサーバにトークンの合否を確認して、その結果によりサーバが様々な応答を返す仕組みです。今まではGoogleからトークンの品質結果によりTIGETサーバの応答速度を変えていると思っていましたが、それが当てはまらないことが分かったため、TIGETサーバ独自の判断が入っているように思えてきました。

一番速い場合は、１秒で購入完了します。次が６～７秒、次が１０ or １３秒付近ということがこれまでの結果から分かっています。この判断が恐らくはTIGETサーバ独自でやっていると考えると、フレームワークを更新後に動作させたときに、何かのフラグが立てられてしまい、速度規制させられているように感じています。

まだまだ調査が必要だと感じています。

TIGET自動購入が納得行くものができました

これまでの最速は６～７秒でした。これはスマホやブラウザ操作よりも遅いという指摘を頂いていました。

改良を重ねた結果、ようやく手動よりも速いものができました。
ログを見る限り、２秒以内で購入が完了しています。

古いのをアンインストール後、販売サイトのダウンロードリンクより最新をダウンロードおよびインストールしてください。

会社員辞めます

今の会社に入ったのが２０１８年なんですが、大手企業からの仕事を長きにわたって開発してきました。

一度のめりこむと、突き進むタイプなので、あまり周りの意見を聞かないところがあるのは性格なので自分でも諦めています。

開発も終盤に差し掛かってくると、テスト内容もえげつないことをするので、バグもかなり難解のものが出てくるため改修するのも大変で、それでいてリリース期間はどんどん狭まっていくので、バグが出たら直ぐに対応しないといけないのですが、気づいたら自分しか対応していない状況になっていました。理由はメンバーの対応速度が遅すぎることに不満を持ち、自分がメンバー分も担当する訳ですが、結果として自分の首をどんどん絞めることになっていきます。。。

そのプロジェクトが突然ポシャりました。理由は、現行バージョンの同システムが市場に出てから一定期間経ったところで全然エンドユーザに使われてないことが判明したためだそう。

これまでのモチベーションは、大手企業の仕事をやらせてもらっているという１点しかなく、自分しか開発していない体制にめちゃくちゃ不満はあったのですが、１日でも早く終わらせたいという思いを抱いて必死に耐えていました。なので、この結果は残念という気持ちよりも、キツイ状況から解放される気持ちしかほぼ無い感じでした。

今後何をやるかはまったく白紙の状態ですが、次も同じメンバーでやるとなったときに自分がどういう気持ちになるかを考えた場合、２度とやりたくないと思い、会社を辞めることを考えるようになりました。

幸いなことに、Emperorメンバーも増えて、会社員を辞めてもzatturightの運営で生活できそうだと思えるようになったことも大きいです。

ユーザを大切にしたいし、使い勝手の良さを追求していきたいし、やりたいことがたくさん出てきたので、良いタイミングかなと思っています。

まだ上司には辞めることを伝えていません。良くしてもらっていたので心苦しいので、来週伝えることにします。。。

P.S.
ユーザを大切にしたいのは当然のことですが、不快感しかないような対応をしたときは、とにかく忙しくて疲れて、人の気持ちなど考えてられない状況のときであり、そういうタイミングは今後も必ずあるだろうし、人との出会いは運だと思って諦めて前に進みます。

今年もお世話になりましたm(_ _)m

今年は、コロナ禍になってからやく１年経過したところから始まったわけですが、会社に通勤する時間が無くなり、今まで以上に使える時間が増えたところからある程度慣れてきた時期に２０２１年が始まりました。

通勤の時間が無くなるというのは非常に大きくて、会社についてすぐに休憩する必要があるぐらいの長旅をする時間が無くなったことで、仕事ができる時間が増えた訳ですが、それによる弊害として座っている時間が増えたことで体の凝りに悩まさられた１年でもありました。

これまでの人生で一番マッサージ店に通った１年でした。本来であれば、ジムで体を定期的に動かして体の凝りを作らないようにすべきだと思うのですが、仕事が忙しくなると体を動かす事自体が億劫になってしまい、結果として体の凝りを増やしてしまうという悪循環に陥っていました。

今年は、仕事量が増大した年でもあり、それも結構キツかったです。
本業の作業量が増大してしまい、副業であるBOT開発時間が減ったこと、また、BOT開発に使用しているフレームワークがメジャーアップデートするタイミングになり、それに合わせた対応に迫られたことも、BOT開発時間が減った要因になりました。
最新フレームワークにしなければならない理由として、ブラウザを常に最新化させることが必要だという考えに基づいており、Googleの更新頻度に極力合わせて行く必要があるという思いがあります。
しかし、Googleは一般開発者がフレームワークから開発したブラウザのGoogleログインを無効にする処置を今年実施しました。これによって影響を受けるのがGoogle reCAPTCHAが使われているサイトの攻略です。このために最新化させることを頑張ってきたのですが、私の最近の考えではログインが必要なのか疑問に思うようになりました。これについても検証をしていきたかったのですが、時間が思うように取れませんでした。

本業を辞めて副業を本業にすることを何度も考えてはいるのですが、本業の方の開発も面白いので、なかなか区切りをつけることが出来ないというのが本音です。
今開発しているものは、守秘義務により詳細を話すことは出来ませんが、２０２３年に登場する車の一部を開発しており、自分もその車を購入して自分が開発したものを利用したいという思いがあり、頑張って開発しています。

来年は、ALERTS JPから離れたサービスに戻ります。
詳しくは後日改めて報告します。

今年もお世話になりました。来年もよろしくお願いいたします。
それでは良いお年を。

当社が使うWeb Engineが遅い原因が分かりました

よく当社のブラウザ読み込みが遅いという意見を耳にすることがあり、自分自身も感じていたのですが、Web Engine（Chromium）のバージョンが古いことに起因することだと考えていました。しかしそれが間違っていることが最近分かりました。

遅いのがChromiumのバージョンの古さに起因していると考えていたため、常により新しいブラウザバージョンを使用するのが良いのだろうと思っていたのですが、いつもと違う場所（環境）で作業したいと思いノートPCで開発をしていたところ、自宅デスクトップPCでは糞遅くなる症状が全く現れないことに気づき、これはWi-Fi環境などの回線やIPアドレスに起因する問題ではなく、PC単体の問題であることが決定的になりました。

インターネットで同様の事例について調べたところ、その中で一番多い解決策が、複数あるLANアダプタがある場合、必要なLANアダプタ以外はDisableにすることで速くなったというコメントがありました。

LANアダプタが複数ある事例としては、VPNだったりVirtual BOXなどの仮想環境のLANアダプタだったりします。

自分のデスクトップPCとノートPCでこのLANアダプタの構成を比較すると、異なる点は、Virtual BOXの仮想LANアダプタの有無の違いしかありませんでした。ちなみに、デスクトップPCにインストールされているVirtual BOXの仮想LANアダプタをDisableしてみましたが、症状は変わりませんでした。なので、Virtual BOX自体をアンインストールしてみたらどうなるのかなどを引き続き調査していこうと思います。

このブラウザ動作が遅いことを問題視したために、新しいWebブラウザを使うなどの方針転換をしてきたのですが、遅い問題が解消すれば、ブラウザを変える必要が無くなるため、自分の中の問題点・懸念点が無くなるのがとても大きいです。

TIGETなど、Googleのセキュリティコンテンツを使ったサイトが増えてきている中で、ブラウザを省いたHTTP通信のみの自動化が厳しくなってきており、ブラウザ操作とHTTP通信を組み合わせることで、より速い自動操作をできるようにしていくことが必要だと感じています。

販売しているBOTの中でもTIGETについてはなかなか期待した結果が出ていないため、近日中にブラウザ自動操作を増やしたバージョンにアップデートしていく予定です。

2021/12/06追記
ticketbookのリセール商品のリストック監視＆自動購入を作成しました。
欲しい方はメールください。
ブラウザ自動操作の遅い場合と早い場合の違いを以下の動画で確認いただけます。

早いバージョン　ノートPC（インテル® Core™ i7-6500U）

遅いバージョン　デスクトップPC（インテル® Core™ i7-8700K）

最新フレームワークに対応していきます

当社が使っているフレームワークのメジャーバージョンが９年ぶりに更新したため、それに対応するために調整していましたが、遂に対応させることができたため、第１段としてチケットぴあ自動購入をリリースしました。

チケットぴあ自動購入は、ぴあサイト、チケット大相撲、piaspサイトの３つのサイトに対応していますが、そのなかでぴあサイトだけは自動購入中にブラウザ画面遷移を挟みます。そのブラウザ画面遷移の動作が旧フレームワーク版と同じパソコンもあれば、遅くなるパソコンもあり、その理由が分かっていません。

旧フレームワーク版と新フレームワーク版は混在でも動作するように設計しているので、新フレームワーク版をインストールして頂き、動作状況を報告してください。
ご協力のほど、よろしくおねがいします。