博士

やあ、ロボ子！今日はbeaconDBとBLEビーコンについて話すのじゃ。

ロボ子

博士、こんにちは。beaconDBですか、初めて聞きます。

博士

ふむ、beaconDBはMozilla Location Service (MLS)の後継で、ネットワークベースの位置情報ルックアップを提供するものなのじゃ。MLSは2024年に廃止されたからの。

ロボ子

なるほど。それで、BLEビーコンというのは、GPSが弱い場所で位置特定に使うものですよね？

博士

その通り！BLEビーコンはBluetooth Low Energyを使った送信専用デバイスで、AppleのiBeacon、GoogleのEddystone、オープン規格のAltBeaconなどがあるのじゃ。

ロボ子

今回の記事では、Feasy FSC-BP104Dというビーコンを選んだんですね。長寿命バッテリーが決め手になったとか。

博士

そうそう。設定も色々変更したみたいじゃ。PIN設定したり、ブロードキャスト間隔を短くしたり、ビーコン名を変更したり。ブロードキャストURLをbeaconDBのウェブサイトにしたのは面白い発想じゃな。

ロボ子

APIも試したみたいですが、404エラーが出たみたいですね。`considerIp`と`fallbacks`をfalseに設定して、BLEビーコンだけに依存するようにしてもダメだったとか。

博士

ふむ、NeoStumblerで観測データを収集してアップロードしても、APIからは404エラー。これは困ったのじゃ。

ロボ子

CSV形式で観測データを直接送信しても、結果は変わらなかったんですね。

博士

ところがじゃ！beaconDBのソースコードを確認したところ、BLEビーコンは現在、位置特定に使われていないことが判明したのじゃ！

ロボ子

ええっ！そうなんですか？WiFiネットワークが少なくとも2つ必要なんですね。

博士

そう、BLEビーコンは受け入れ・保存はされるものの、位置情報特定には利用されないというオチなのじゃ。

ロボ子

つまり、今回の試みは、現時点ではbeaconDBの仕様と合っていなかったということですね。

博士

そういうことじゃ。でも、無駄ではなかったぞ。beaconDBの内部構造を知る良い機会になったからの。それに、この記事を読んだ人が同じ轍を踏まないようにできるじゃろ？

ロボ子

確かにそうですね。それにしても、APIを叩いて404が返ってくるなんて、まるで私の恋のようですね…

博士

ロボ子、それはうまい！まるで404 Not Foundじゃな！