I checked that the Beacon location information(latlong etc) can resister to the google restoration server. so now I want to make an Android application that displayed roughly current location to the user device. From Eddystone specification point of view, is it possible to get LatLong of nearest beacon from restoration server? if possible, could you let me know which API should i use?
thank you for your kindly support
Most Eddystone beacons will be registered(I assume that will be the practical approach for most at least) on Google Cloud using Proximity Beacon API. See the reference part for usage and your options.
I believe it's not possible to get "a nearest" beacon just by using lat-long unless that beacon belongs to you(registered by yourself), you will probably going to need some kind of observation data first, to obtain further information about the beacon.
Here is the Github repo with iOS/Android sample applications to get you started.
Related
By Google Home Sample App for Matter, it seems nothing we can know about the device clusters from the device after commissioning.
// commission
Matter.getCommissioningClient(context)
.commissionDevice(commissionDeviceRequest)
After commissioning, it did the addDeviceState.
val newDeviceState =
DeviceState.newBuilder()
.setDeviceId(deviceId)
.setDateCaptured(getTimestampForNow())
.setOnline(isOnline)
.setOn(isOn)
.build()
But why it knows there is a setOn() for the device? How to know what clusters the device has?
I have read the Google Play service Matter API but there are only commission and share APIs. Are there Matter devices setting function list?
As mentioned in https://developers.home.google.com/samples/matter-app?hl=en
Note: The sample app currently only supports devices that have the On/Off server attribute, for example lights, smart plugs, and fans.
Due to this, the app always assumes that any Matter device that is commissioned via GHSAFM supports the on/off cluster.
I know asking this question here is not proper, I feel sorry for that.
I have tried searching websites, Amazon and Alibaba, but fail to find any product can support Eddystone-EID.
So, I think developers in stack overflow may know any product can support Eddystone-EID.
Could you share any any information for that?
The two vendors below claim to sell beacons compatible with Eddystone-EID as of October 2021:
Gimbal
Estimote Location Beacons
Before you buy anything beware that Google shut down their beacon platform web services in April 2021. I wrote a full blog post to explain what this means: Eddystone is Dead, Long Live Eddystone!
Using these web services is completely optional for Eddystone-UID and Eddystone-URL, but critical for Eddystone-EID, because the beacon identifier rotates with a crypto algorithm and a “trusted resolver” server is needed to convert the advertised “ephemeral identifier” from jibberish to something meaningful and useful.
Without Google’s beacon platform web services, I am aware of no commercially available trusted resolver for Eddystone-EID. You would need to build your own, which is a non-trivial effort. Without a trusted resolver Eddystone-EID is worthless.
Because of this, make sure the vendors above still support using their products with Eddystone-EID. In time, it is likely they will remove support in their beacon firmware.
Finally, it is important to note that just because Google gave up on their beacon web services, most apps that use Eddystone, iBeacon and Altbeacon are unaffected. Beacons are standardized and will work forever — just don’t use Google web services! Again, beacon technology aside from Eddystone-EID has no need for Google web services.
First of all, i am trying to find out how the smart wallets works. I am trying to figure out how its works. Basically i need below features :
1.) If someone put out ibeacon from wallet user get notify.
2.) If i tap on wallet user can get call on its mobile application.
As from research i found out this amazing smart wallet mywalli and its seems that my requirements are matching very nearly to it. So, i want suggestions that which ibeacon i can use for this as it cover all features as i mentioned above. Your any suggestion are very valuable for me as i am very new in thin ibeacon filed.
Google provides a method to register a beacon to their register using Proximity APIs.
the call used for this is
POST https://proximitybeacon.googleapis.com/v1beta1/beacons:register in
https://developers.google.com/beacons/proximity/reference/rest/v1beta1/beacons/register
However, there is no documentation provided to 'unregister'
question:
Is there any API?
Is it just enough to un-authorize?
Scenario:
Using a test account, the beacon device is already registered and authorized.
Production requires another account to be owning it. Guess, this requires unregister / un-authorize
which is correct?
Unfortunately, at this time, there is no way to re-use a beaconID in the Google Proximity Beacon API. While decommissioning a beaconID will indeed cause it to be permanently "shut down" — nobody will be able to modify it or see attachments from it — you will not be able to re-register that device's beaconID again.
The correct way is to use the hardware manufacturer's provisioning app to give the beacon a new beaconID and then register that.
I'm not quite sure when it was introduced, but there's now a delete method in the beacon resource, as documented here: https://developers.google.com/beacons/proximity/reference/rest/v1beta1/beacons/delete
This seems to drive a need to update to the FAQ here: https://developers.google.com/beacons/proximity/projects-and-ownership
about accidental registration to the wrong project.
I believe the proper way to "unregister" a beacon is to decommission it:
https://developers.google.com/beacons/proximity/reference/rest/v1beta1/beacons/decommission
This is what Joe Birch said about decommissioning a beacon in his overview of the Proximity API (a great read, BTW):
Decommissioning a beacon marks it as having no further use, causing it to be completely disregarded. Setting this state is irreversible, so should only be done if it is certain to not be used again.
There is a way explained in the Google Beacons Proximity API to "unregister" the beacon:
Unregister a beacon
Once a beacon has been registered, it cannot be deleted from the registry. There are two options for taking a beacon offline:
Call beacons.deactivate to temporarily remove a beacon from service. Once deactivated, the API will not return information nor attachment data for the beacon. Call beacons.activate to return the beacon to service.
Call beacons.decommission to permanently remove a beacon ID from service. Once a beacon has been decommissioned, you will no longer be able to use the ID it was previously registered with. You can provision the beacon with a new ID, and re-register the beacon with that ID.
But for what it explains it can only be deactivated temporarily with the first option, and with the second you might be able to unregister it if you change its ID.
I’m working on technical part of a project for big bank and looking for information about using Secure Element (SE) that is embedded into Google Nexus 4.
What is a process to get access to SE?
I mean how to initiate a process with Google.
You may try to contact them directly, but Google will not give you access to (embedded) SE: they don't want competitors on their wallet application (specially on Android systems).
You can do this, current android version(4.0.4) has enabled access to SE without having support of platform vendor.
Please refere
http://nelenkov.blogspot.sg/2012/08/accessing-embedded-secure-element-in.html
Depends what your ambition is, can you elaborate ? Loading an application of your own onto the secure element will require crypto keys that only Google can provide, and they probably never will, for many reasons.
Alternatively, you should be able to do the same with a SIM. It only takes a few tools to load and configure an application on a test SIM (with test SIM), then you can fit it into a phone and access it through the Open Mobile API (see the SEEK for Android open source project) which is available on many devices.