我使用的是iBKS 105 BLE信标来自口音系统。我正在接收Eddystone数据包,如他们的github上的示例代码中所概述的那样。信标在我的项目的谷歌接近灯塔仪表板上注册。
我关注的主要数据字段是:
- TimestampNanos
- Advertised ID (EID)
- EncryptedTLMData, Salt, IntegrityCheck广告中的数据是加密的,所以为了获取信标附件数据,我使用Google的"beaconinfo.getforobserved“HTTP请求。
十八日三月二十一日,我从信标收到以下资料:
"timestampNanos" : 201887331447701,
"advertisedEID" : "326846421e0df00d",
"telemetry" : {
"encryptedDataTLM" : "39769a4b12d45bee0457e83a",
"salt" : "37fa",
"integrityCheck" : "01e6"
}将其转换为端点所需的"base64“编码:
{
"observations": [{
"advertisedId": {
"type": "EDDYSTONE_EID",
"id": "MmhGQh4N8A0="
},
"telemetry": "IAE5dppLEtRb7gRX6Do3+gHm",
"timestampMs": "8367-07-23T03:47:27.701000000Z"
}],
"namespacedTypes": ["*"]
}在那一天,当我立即查询“get遗忘”请求时,它正确地返回了保存在仪表板中的信标附件。但是当我今天(3月24日)使用相同的参数进行查询时,没有返回任何数据。我没有更改任何附件,信标在仪表板中仍然被标记为“活动”。
任何帮助或指示都将不胜感激。
发布于 2018-03-24 21:29:51
听起来,您使用的是Eddystone-EID格式,该格式广播加密标识符,并要求您使用可信的解析器将标识符转换为您提到的有意义的值。
整个系统依赖于信标中的精确时钟,因此信标的加密标识符与解析器端的时钟(基本上是Google的服务器)同步。如果信标上的时钟漂得太远,分辨率就会停止工作。,这很可能是你所看到的。您可以通过重新注册信标来确认这一点,以查看分辨率是否重新开始工作。如果这确实是问题所在,您将需要向信标制造商查询时钟的稳定性,以及在注册后需要多长时间才能妥善解决。我希望它能在一天内做到这一点!也许你有个糟糕的小组?
虽然可以构建一个独立于Google系统的解析器(我自己在Edystone-EID的预发布阶段为测试构建了一个解析器),但我不知道有什么可供通用的替代方案。从理论上讲,您可以在您的单文件应用程序中构建一个程序,但同样,我不知道有任何可公开使用的库可以这样做。
底线:你需要使用谷歌的基于服务器的解决方案,或者构建自己的解决方案。
发布于 2018-03-28 09:09:08
如果您正在使用Google服务器注册Eddystone-EID数据包,则需要考虑到它具有严格的定时,信标和服务器使用相同的时钟值,并且需要在同一时间更改它(允许延迟几秒钟或分钟,但不允许更多)。为了正确地使用Google服务器解析EID,需要使用EID (用实际时钟计算)和internet连接的最近值。如果您使用三天前的EID值,Google服务器将无法正确解析EID。这并不意味着Google不允许延迟开斋节中的天数,但是重新同步化可以持续几个小时或几天。这个问题与信标时钟的漂移无关。
https://stackoverflow.com/questions/49464454
复制相似问题