2024年5月24日金曜日

NFCタグに実際にタッチしないと表示されない Webサイトを作る

以前に書いた NTAG424 DNA の記事が意外に好評でよくアクセスいただいているのですが、結局さー、何に使うん? みたいな内容が無かったのでこちらに記載したいと思います。

NFCタグの使い方として一番多いのは、URLを書き込んでおいてスマホでタッチするとブラウザが起動してそのURLにアクセスできる所謂スマートポスター的な使い方だと思います。

ただそれだけですと QR と変わらないのですが、NTAG424 の機能を使うと実際にタグにタッチした時しかアクセスできない Webサイトを作ることができます。(ちなみに同様な機能を持つタグは他にもあります)

NTAG424 は NTAG213 などでも実装されている、UIDミラーとカウンターという機能があります。これはタグに書き込んだURLのパラメータ部分に、自身の UID と タッチされた回数 を自動で埋め込んでくれるというすばらしい機能です。

例)
書き込まれたURL
https://www.hayato.info/tag?uid=00000000000000&ctr=000000
スマホで読み取ったときのURL
https://www.hayato.info/tag?uid=04C767F2066180&ctr=000010

NTAG424 では、さらにこのパラメータ部分を AES暗号化してくれます。

スマホで読み取ったときのURL
https://www.hayato.info/tag?id=sja0tVH8IK3Y2NnpJlPDhq0HDKQcwxMucecXCvFYYb4=

こんな感じ

カウンタも含めて暗号化するというのがミソで、そのおかげでタッチする度に毎回異なるコードが生成されます。

ここからはサーバ側の処理になります。送られてきたパラメータ部分を復号し、UIDとカウンタの値を取得します。サーバ側ではアクセスしてきたUIDとカウンタをセットで記録するようにしておきます。

で、記録してあるカウンタと今送られて来たカウンタの値を比較して、記録してある値と同じか低い値であれば、今タグにタッチしてアクセスしてきたのではなく、過去にタッチされたときのURLでアクセスしてきたことがわかります。

上記を実際にAWSで実装した場合が以下になります。AWSで実装したらこうなるという話で、AWSじゃないと実現できないということではありません。


S3: ここに最終的に表示させたいコンテンツを格納します。CloudFrontのOACを利用して、CloudFront経由でのみアクセスできるように設定しておきます。

CloudFront: スマホからのアクセスはここで受けるようにします。Lambda@Edgeを使って、アクセス時にLambda関数を走らせます。

Lambda: 上記の復号とチェックを行います。古いURLとわかれば、それ用のHTMLを返すようにします。

DynamoDB: UIDとカウンタの値を保存します。

これでタッチしないと表示されないWebサイトの完成です。もちろんタッチしてURLにアクセスせず、そのURLを他の場所に送ってそちらでアクセスするという抜け道もありますが、その場合でも実際にタッチしていることに変わりはありません。

2024年5月21日火曜日

新しいチャレンジ、そしてICタグとの出会い

こんにちは。4月に入社しました新入社員です。

社員が気軽に発信できるBLOGがあるなんて、いいですよね!

早速ですが、入社してICタグの可能性を目の当たりにしたとき、真っ先に浮かんだこと、ICタグの魅力についてお話ししたいと思います。

私はこれまで、ずっとWEB関連の仕事をしてきました。

その中で携わった、ERPシステム開発時の出来事が真っ先に思い浮かんだのです。


クライアントの多くが月末の棚卸に頭を悩ませていました。

業務を数日間停止して棚卸を行うことも珍しくないということでした。

このような状況は、会計処理にも大きな影響を及ぼし、月末で締めた会計システムを遡って変更する際の課題も多く、会議が長引くこともよくありました。

ICタグを使えば、物品の管理が格段に楽になります。

例えば、棚卸の際に手作業で一つ一つ確認する必要がなく、一瞬で在庫状況を把握できます。

ICタグは無線通信を利用して、タグが付けられた物品の情報を瞬時に読み取り、システムに自動的に反映されるため、広い倉庫内でも短時間で正確な在庫確認ができます。

毎月のように棚卸にかけていた労力を考えると、呆然としてしまう事実です。

さらに、リアルタイムで物品がどこにあるのか、いつ移動したのかを把握することもできます。

防犯対策としても有効ですね。

これまで、図書館やユニクロなどでICタグを使ったことはありましたが、実際に具体例を見てみないと業務にどのように活用できるかは、ピンとこないものですね。

しかし、何でも開発してしまう技術者って本当にすごいと思います!

こんな便利なツールを目の当たりにすると、効率を求めてシステム化されているはずの社会が、急にアナログの手作業で運用されているように感じてしまいます。

まだまだ世の中は変わっていくのだろうと、改めてICタグの可能性に感動した、RFID猛勉強中の私でした。


これからも、初心者目線で気づいたこと、ICタグの最新情報や活用事例など、ブログを通じて発信していきますので、どうぞよろしくお願いします! 

2024年5月2日木曜日

iOS用のSDKを.NET MAUIで使えるようにしてみる

 RFIDを使ったシステム開発ではスマートフォンでリーダを制御することが多いですが、iOSで使いたいという要望がとても多いです。iOSに対応しているリーダも少ないながらありますのでそのリーダのSDKを使って開発するわけですが、iOSでの開発というものは何と言うか、こう、いろいろ大変ですよね。

ちょこっとしたアプリなら問題無いですが、業務用のアプリになると画面数多いしそれはそれは大変なわけです。そこで少しでも開発を楽にしたいということでXamarinを使うという手があります。

XamarinならC#で書けますので開発は楽です。しかしXamarinのサポートが終わり、.NET MAUIに移行という流れになっています。

そのような事で MAUI で開発していこうと思うのですが、ここで先ほどの SDK が問題になってきます。そう、SDK はネイティブな Framework になっていることが多いのでそのままではMAUIで使用できません。バインディングというものを作成する必要があります。

チュートリアル: iOS Swift ライブラリをバインドする

この資料に沿って作業します。この資料のポイントは、SDKをそのままバインディングするのではなく、必要なメソッドだけラッパー的なライブラリを作ってSDKを後ろに隠し、バインディングはラッパーの部分だけにすることでバインディングに関するややこしい作業を省こうというところです。資料は Xamarin用ですが、まぁ、何とかなるかなと思ってやってみます。

ちなみに MAUI だと Mac がなくても iOS の開発ができるみたいな感じですが、さすがにバインディングのプロジェクトはビルドできなかったのでライブラリを作るところまでは Mac で作業します。

早速問題があって手元にある Mac mini が古くて OS が Catalina までしか上げられないので必然的に Xcode が Version 12.4 までしか入りません。

上記資料に沿って作業を行い、何とか「ネイティブライブラリをビルドする」の章まで完了しました。

次の章「メタデータを準備する」でコケます。Objective Sharpieというツールを使って、バインディングライブラリに必要な ApiDefinition.cs と StructsAndEnums.cs を作成する必要があるんですが、OSが古いせいか sharpie がエラーで起動すらしてくれません。困った。どうしよう。ただどちらのファイルもライブラリの定義情報を記載してるだけのようなので手作業で作ることにします。手作業と言っても、作成するのはラッパーの部分だけなので楽勝です。

次、「バインドライブラリをビルドする」の章、資料では Visual Studio for Mac で作業してます。Visual Studio 使うんなら Windows でもよくね?と思って試しに Windows の Visual Studio 2022 でやってみます。

ネイティブ参照などはうまくいって何かうまくいきそうな気配がする。画面見る限り何の文句も言ってこないしこれはこのまま行けるのか!? が、ビルドでエラー、ApiDefinition.cs に記載している NSObject を知らないと言う。え?何で?基本型じゃん。(※追記 ちなみに Visual Studio を Mac に接続してると、この部分は Mac 側で処理するようで、ビルドアクションの objBindingApiDefinition がそうさせている様子。しかし結局 Xcodeが古いからダメ的なのが出てきて諦めた)

エラーをよくよく見るとMacが無いとビルドできないというメッセージも出ている。ダメか。結局Macか。ということで大人しく Visual Studio for Mac で作業することにする。が、Visual Studio for Mac をインストールしているとおまえの Xcode が古いから使えない機能があるかも的なメッセージが出る。無視して進む。

ビルドまでできるようになったが .NET 7.0 でビルドされている様子。ターゲットを.NET 8.0にしようとするが、インストールされていないと出てくる。別途 .NET 8.0 SDK をインストールするが、相変わらず.NET 8.0はインスールされていないと出る。仕方ないので .NET 7.0 のものをそのまま使うことにする。

ビルドしてできた DLL 等を Windows に持ってくる。これが使えるのかが問題だ。まず MAUI のプロジェクトを作り、例のDLLを参照してみる。参照できた!ビルドも通った。あとは実機で動くかどうかだ。早速 iPhone を繋いで実行しようとすると iTunes が必要と言われるのでインストールする。

すると実機で動いた!上記以外に他にも細かいトラブルはたくさんありましたが、何とか動作するところまでたどり着きました。あー長かった。

2024年4月26日金曜日

AWSで管理しているLoRA WANデバイスの情報を取得する AWS IoT Wireless

  AWSのIoT Coreでは、LoRA WAN通信のデバイスを登録してデバイスの状態をクラウドから取得することができます。デバイスの登録はコンソール画面から行うのですが、いろいろと面倒なところがあり、これをAPIっぽくカスタムのサイト上で行えるようにしたくなりました。ところが参考となる資料がなかなかないため、ここで紹介します。

必要なパッケージ

using Amazon.IoTWireless.Model;
using Amazon.IoTWireless;
using Amazon.Runtime;

登録しているデバイスの取得

var credentials = new BasicAWSCredentials("YOUR_KEY", "SECRET_KEY");

AmazonIoTWirelessClient client = new AmazonIoTWirelessClient(credentials, Amazon.RegionEndpoint.APNortheast1);

ListWirelessDevicesRequest request = new ListWirelessDevicesRequest(); request.WirelessDeviceType = WirelessDeviceType.LoRaWAN; request.MaxResults = 100;

ListWirelessDevicesResponse response = client.ListWirelessDevices(request);

デバイスの登録

var credentials = new BasicAWSCredentials("YOUR_KEY", "SECRET_KEY");

AmazonIoTWirelessClient client = new AmazonIoTWirelessClient(credentials, Amazon.RegionEndpoint.APNortheast1);

OtaaV1_0_x otaa = new OtaaV1_0_x() {

    AppKey = appkey,     AppEui = appeui };

LoRaWANDevice lora = new LoRaWANDevice {     OtaaV1_0_x = otaa,     DevEui = deveui,     DeviceProfileId = deviceprofileid,     ServiceProfileId = serviceprofileid };

CreateWirelessDeviceRequest request = new CreateWirelessDeviceRequest {     Name = devname,     LoRaWAN = lora,     DestinationName = destination,     Type = WirelessDeviceType.LoRaWAN };

名前はオプションですが、これで最低限のデバイスの登録が行えます。ほかにもデバイスの説明や位置情報なども追加できます。

2024年4月24日水曜日

LoRaWAN のローミングを試す

 LoRaWANはゲートウェイを中心としたスター型の通信になっていますので、基本的には1台のゲートウェイと通信をするんですが、ローミングの機能もあってゲートウェイが変わっても継続して通信することができます。LoRaWANでは通信開始時にJOINという手続きが必要なんですが、ここでの継続して通信というのはこのJOINをゲートウェイが変わってもやり直さなくてよいということになります。

今回はこれを実際に試してみようと思います。ちなみにLoRaWANサーバはAWSのIoT Coreを使用しています。

まず事務所に設置してる1台のゲートウェイから離れた場所に移動して、一時的にゲートウェイを動かしてそちらでJOINを行います。


JOINできたのを確認して、一応データ送信してみます。

うまく飛んでます。ここでゲートウェイは電源を落として、PCは電源落とさないように注意して事務所まで移動します。


窓にゲートウェイ貼っつけてあります。

ここで先程のPCで続けてデータ送信してみます。

あっさり飛びました。すぐに応答があったので、JOIN等の手続きをしているようには見えません。これで一度JOINすれば、通信するゲートウェイが変わっても問題なく通信できることがわかりました。




2024年2月28日水曜日

頭に近づけるとリーダーの読み取り距離は伸びるのか実験

車のロックを遠隔で解除する、鍵についているリモコンキーがありますね。以前このリモコンキーについて面白い記事を見かけました。
どうやら鍵を頭に近づけてボタンを押すと、車のロックをより遠くの距離から解除できるそうです。前から裏技としてこのテクニックは知られていたようで、シミュレーションで検証する記事もありました。

さらに気になるのはこのリモコンキーが扱う周波数です。
二つの記事をざっと見た感じだとだいたい300MHzあたりのようで、超短波(VHF)寄りの極超短波(UHF)になるのでしょうか?

もしかしたらこのリモコンキーのテクニックはRFIDリーダーにも応用できるかもしれません。
そういうわけで、実際にUHF帯のリーダーを頭やペットボトルに近づけたりして距離が変わるのか試してみました。

広い空間で検証する必要があったので、今回はDENSOさんのハンディリーダーSP1を使用します。
SP1の周波数はだいたい916~920MHzになります。リモコンキーの周波数とは結構差があると思いますが、試してみます。



屋外なのでカバンのなかにタグをいれ、これを読み取れる距離をはかります。


結構簡単な検証だと思っていましたが、屋外だと風があるせいか、標準になる限界の距離がどこなのかなかなかつかめませんでした。

これでだいたい5mくらいでした。
ここからリモコンキーの記事にあったように、リーダーを頭やあごあたりに近づけつつ後ずさりしてみました。

頭に近づけた結果としては、確かに距離が伸びたように感じる瞬間があった、程度でした。
リーダーを頭に近づけたり離したりを繰り返すと、読み取りもそれに応じて、頭に近づけるたびに反応があるということが起きました。しかし結構偶然に近いような感じで、あまり再現できませんでした。

今度は天然水のペットボトルを使います。


頭に近づける必要があるのは、頭にアンテナのように電波を延長させてくれる水分があるためなので、これをリーダーに近づければもっと効果があるかもしれません。


結果としては、頭に近づけるときと同様にイマイチでした。


やはりICタグと水分の相性は悪いと考えたほうがよいのでしょうか。
もっと電波について勉強したいと思える実験でした。

2024年2月27日火曜日

LoRaWANの電波強度を測定してみる

 おかげさまで最近よく沖縄のニュースなどで取り上げていただいている「ミマモライド」ですが、こちら通信に LoRaWAN を使用しております。エンドデバイスは自動販売機などに設置していて地面に近いところにあります。なのでゲートウェイはなるべく高いところに設置をしています。

使用しているゲートウェイは DRAGINO の DLOS8 です。

ところが、設置後に通信のテストしていると、あれ?何か届かなくね?みたいのが発生したりします。よくよく調べると、アンテナのコネクタがきちんと刺さってなかったのか、そのあたりをイジってるときちんと電波飛ぶようになるときがあります。

設置場所は気軽に入れない場所がほとんどで、後から何か電波弱いね―みたいになると非常に面倒です。なのでアンテナが付いているときと付いてないときで電波強度にどのくらいの差が出るのかを事前に測定したいと思いました。

アンテナをきちんと接続した状態と、アンテナを外した状態でそれぞれ10m、20m、30m離れたところから2回ずつ電波を出して、ゲートウェイでどのくらいのRSSIで受信できたのかを測定しました。


結果がこちら。SFはすべて10でした。いちおう各測定ごとにJOINから開始しています。これを見るとやはり結構な差が出ています。これをもとにゲートウェイ設置後、近くで送信してみてRSSIが-50くらいであれば大丈夫というような認識でOKのようです。