search

google / eddystone

Specification for Eddystone, an open beacon format from Google
Apache License 2.0
3.08k stars 762 forks source link

Nearby Notifications #190

Closed ashkumar579 closed 7 years ago

ashkumar579 commented 7 years ago

Suddenly stopped receiving nearby notifications a few days ago.. when will they be restarted in india ?

pranavparthtyagi commented 7 years ago

Yes I am also not receiving eddystone notifications on any Android phones

scottjenson commented 7 years ago

Nearby notifications have a temporary bug in Android and are unfortunately turned off for 6 weeks until the next release of Google Play Services which will happen in 6 weeks. In the meantime if you have Chrome installed, it will roll back to the old behavior of creating the notifications.

To repeat, this is a bug we hope to fix soon. I you want something a bit more direct, you can install a Nearby icon directly to your homescreen from the Nearby list itself.

pranavparthtyagi commented 7 years ago

Thanks for the clarification Scott ,does this bug also affect the physical web notifications behavior on Android. I am asking because new users with Bluetooth turned on are not getting "Physical web opt in notifications" or the "Physical webpage near by" notifications in the locations we have deployed Eddystone (Kontakt) beacons

adriancretu commented 7 years ago

I can confirm that there's no kind of notification created when using the latest GPS (updated to 9.8), with latest Chrome (and Chrome beta) installed, PW enabled in browser, Location and BT on. However both lists (the Nearby panel, and the Chrome's one) detect all the beacons. Its just that there's no notification created whatsoever when turning the screen on.

scottjenson commented 7 years ago

Sorry about that @adriancretu, it should be working.

If you have latest GPS and Chrome, you SHOULD be getting a notification. I'll check to see if this isn't rolled out to 100% and you're somehow just in the remaining few who doesn't have it. However, it SHOULD be working.

adriancretu commented 7 years ago

N6 @ Android 7.0 official Chrome 53.0.2785.124 Chrome Beta 55.0.2883.18 GPS 9.8.77

There's no updates available as of right now, I believe I should be getting Chrome 54 but its not 100% rolled out? This would explain why people were updated to the new Nearby but got left with old Chrome, hence PW would be broken.

scottjenson commented 7 years ago

You should be able to get Chrome 54. That is the version with the notifications turned on.

sk-falcon commented 7 years ago

@scottjenson - Facing the same issue here as well. Checked a couple of scenarios. Not receiving Physical Web notifications from Chrome on v53 (even with Physical Web turned on in Chrome). Only receiving notifications when Physical Web App is installed. Also, earlier I was getting the Chrome-based Phy Web notifications on the same v 53 without Phy Web App installed. Will this issue (i.e receiving Phy Web notifications without the App) be resolved with the Play Services update scheduled for Nov? Also, when can we expect v54 to launched in India?

adriancretu commented 7 years ago

The way I see it:

scottjenson commented 7 years ago

You are correct. This is certainly not a situation we wanted and, not surprisingly, we are extremely frustrated ourselves. We're just trying to do what we can until the next release of GPS (in ~5 weeks now) We're hoping the Chrome 54 release will at least soften the blow (when you get it of course)

ashkumar579 commented 7 years ago

Unfortunately we have deployed around 1500 eddystone beacons over the last few months.. this has slowed us down quite considerably..

@Scott how can we reach out to you directly for a brief discussion?

Thanks Ashish

adriancretu commented 7 years ago

Just received Chrome 54 finally today. But still, Physical Web notification is not created unless I actually reload Chrome. To be specific: a. Chrome closed, screen-on: no notification b. Chrome closed completely, screen-on, load Chrome: notification appears immediately. c. Chrome open, screen-on, bring Chrome to foreground: no notification

Should there be any kind of service running during this whole time? Because I'm not seeing anything running related to Chrome in the Developer Options. How is the scanning triggered?

scottjenson commented 7 years ago

The big restriction with Chrome is that it has to be launched once after boot in order for notifications to show up. Once that's done though, notifications should show up. This is one of the reasons we moved to Android OS as it got rid of this restriction.

avi885 commented 7 years ago

@scottjenson My use case is also dependent on Nearby Notifications. Can the upgrade to Google Play Services with the fix be expected to be rolled out by November end? Launch of my product is dependent on this.

Armstrong30 commented 7 years ago

Does Google Play Services v10.0.84 fix the nearby notification bug?

adriancretu commented 7 years ago

To answer your question, yes and no. I manually upgraded from GPS 9.8 to 10.0.84, but notifications were served by Chrome v54. After reverting Chrome to v53, notifications were served by Nearby. So, it looks like the notifications are back, UNLESS you are using Chrome v54. IMHO this is bad, since Chrome is unreliable at creating the notifications (it basically needs to be reopened and not running in the background - not just started once after a reboot). I'm not sure what magic is going on, but Nearby should have top priority.

Armstrong30 commented 7 years ago

Thanks @adrian, i like to find out what the schedule may be for a true fix - such a key part of the no app required, reverting chrome is ok for development but does not scale in the market.

scottjenson commented 7 years ago

I'm very sorry we can't promise/confirm a release date. All I can say we're working very hard to get it out but there are numerous validation reasons it can't ship. We'll let you know as soon as we can.

Armstrong30 commented 7 years ago

NP, appreciate the hard work and the fact it's imminent.

Armstrong30 commented 7 years ago

Great to see that Nearby is live again! Having some challenges with my Samsung Galaxy Note 5: Problem: I'm not receiving nearby notifications until having received and viewed them in the nearby mobile application (icon on desktop). It appears that the nearby applications needs to be running (foreground or background) in order for the phone to receive the notification.

My Note 5 settings are:

Eager to learn more or have some links that can enlighten me,

Thanks!

Armstrong30 commented 7 years ago

Question about the beacon scanning.

What are the beacon advertising requirements in order to be detected by GPS ?

Here is what I found: The scanning is performed by Google Play Services, and only at "screen-on" events.

Questions: Is there a minimal number of advertisements, frequency, duration for advertisements. In other words could I just advertise 10 or 20 times every 100 ms with a phone in range?

If not what should it be in order to guarantee detection ? How many times in what time window?

scottjenson commented 7 years ago

There is no real advantage to broadcast faster than 700ms (our recommended rate) We offer a verification service: verify.physical-web.org which will test if your URL will be returned by our scanner. This is often where most people have issues. The BLE beacon is fine, the local Physical Web scanning is fine, the URL just fails our security requirements (or can't be found) Have you tested your URL against this yet?

scottjenson commented 7 years ago

On Wed, Dec 14, 2016 at 5:16 PM, Armstrong30 notifications@github.com wrote:

For testing the end to end experience we use a populat url like google.com. our issue has been the mobile side. Notifications have not shown up till they have been seen in the nearby app. This may be since we only advertise for a few seconds after we detect the phone. Our use case is:

  1. Beacon is off - deep sleep. Not advertising.
  2. Detect phone
  3. Advertise for 5 seconds at 100ms interval
  4. Beacon back to deep sleep

I'm a bit confused by step 2: Detect Phone. How exactly are you doing that? That implies that you are detecting the scan which we have tried to guard against by only requiring only single length non-scan response packets. Beacons should never know the phone is nearby.

The issue is that depending on how you are doing this, you may have missed the scanning window of the phone. Given our recent tests, we're geeting 5 years of battery life from an nRF52 category beacon with a 1000mah battery. I clearly don't understand your hardware/product but it's worth considering just broadcasting continually. It may not be as power hungry as you think.

jfarfel commented 7 years ago

For testing the end to end experience we use a populat url like google.com . Note that http://google.com won't work, only https://google.com will. (But you're probably already using https, because you say you do see it when you open the Nearby app.)

One thing you can do is check if the expected Nearby Notifications service is running. In version 10.0.x of GMS Core, the nearby.discovery.service.ScreenOnListenerService should be running at all times. (Be aware that this is very likely to change in future GMS Core versions; we're refactoring things.)

If you run dumpsys for the ScreenOnListenerService, it may not print any other information, but it should print "Client:". If it prints "No services match" instead, that means it's not running. (We've seen that bug before, and rebooting should fix it. Again, things will work differently in the next version of GMS Core, as the ScreenOnListenerService will no longer be used.)

In GMS Core version 10.0.x, this service dump should display

"Client:" (indicating the service is running). You shouldn't get "No services match".

(But note that starting with version 10.2.x next year, this service

may be gone.) adb shell dumpsys activity service com.google.android.gms/.nearby.discovery.service.ScreenOnListenerService

On Wed, Dec 14, 2016 at 7:26 PM, Scott Jenson notifications@github.com wrote:

On Wed, Dec 14, 2016 at 5:16 PM, Armstrong30 notifications@github.com wrote:

For testing the end to end experience we use a populat url like google.com. our issue has been the mobile side. Notifications have not shown up till they have been seen in the nearby app. This may be since we only advertise for a few seconds after we detect the phone. Our use case is:

  1. Beacon is off - deep sleep. Not advertising.
  2. Detect phone
  3. Advertise for 5 seconds at 100ms interval
  4. Beacon back to deep sleep

I'm a bit confused by step 2: Detect Phone. How exactly are you doing that? That implies that you are detecting the scan which we have tried to guard against by only requiring only single length non-scan response packets. Beacons should never know the phone is nearby.

The issue is that depending on how you are doing this, you may have missed the scanning window of the phone. Given our recent tests, we're geeting 5 years of battery life from an nRF52 category beacon with a 1000mah battery. I clearly don't understand your hardware/product but it's worth considering just broadcasting continually. It may not be as power hungry as you think.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/google/eddystone/issues/190#issuecomment-267228987, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwHPtalh_gbQpt4xRtLD6m7mlshv0Szks5rILNtgaJpZM4Kdxzb .

frankviljoen commented 7 years ago

Just to add as I have been getting increasingly frustrated today. I have Nexus 6, running Chrome v55.0.2883.91 and no beacons detected using PW. I checked this on my iOS device, chrome widget and also nothing. Using the Beacon Scanner app, the beacons were detected no problem. I did not realise that there were so many issues on this, thank goodness I have not been relying on Eddystone for much. the UX is abominable!

scottjenson commented 7 years ago

@frankviljoen given that you aren't seeing anything on android or iOS the odds are very high that your beacon isn't setup correctly. That isn't a UX issue but a developer one. We've posted this advice many times but I'll repeat it here:

ashkumar579 commented 7 years ago

@scottjenson There seems to be an issue or a change with nearby notifications .. we are seeing a 80-90% drop in nearby notifications at most locations since last week. The other evironmental factors such as human traffic and connectivity and URLs remain unchanged. Have verified the URLs as well .

scottjenson commented 7 years ago

Obviously, this is a big issue. We've been running tests over the last few days and aren't seeing any issues on our side. Anything that you can tell us to help reproduce the problem would be appreciated.

scottjenson commented 7 years ago

Sorry if it wasn't clear. We're treating this as a potential bug on our side and are still looking into it. We'd just like any additional info you may have.

scottjenson commented 7 years ago

If you wouldn't mind sharing your URL, we can look in our logs on confirm what you're seeing. That might help pin point the problem.

ashkumar579 commented 7 years ago

Thanks Scott

We have been noticing this since the last week to 10 days.

We are seeing outages of about 15 minutes to an hour on our test phones (Samsung, xiaomi, Motorola, lenovo) wherein notifications don't show up from any beacon on the pull down screen or in google settings -> nearby

In other instances the notifications do not show in the pull down screen until you search/refresh for them in google settings -> nearby - this is even if you are standing walking next to the beacon for over 2 minutes.

Is there a way to privately send you the URLs?

Thanks Ashish

On 17 Dec 2016 5:12 am, "Scott Jenson" notifications@github.com wrote:

If you wouldn't mind sharing your URL, we can look in our logs on confirm what you're seeing. That might help pin point the problem.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/eddystone/issues/190#issuecomment-267722820, or mute the thread https://github.com/notifications/unsubscribe-auth/AV7aKvue6bi3kmuPa_UmuHQznyIfKDmvks5rIyHNgaJpZM4Kdxzb .

scottjenson commented 7 years ago

Sure, just send me an email to scottj@google.com

Armstrong30 commented 7 years ago

We are experiencing a similar issue as @ashkumar579 except that we never get the notification in the pull down screen until you search/refresh for them in google settings -> nearby. After search refresh notifications do show up in the pull down screen.

I have changed the beacons to continuously advertise to avoid any issues with the periodic advertising.

Armstrong30 commented 7 years ago

@jfarfel

Our environment is: Phone: Samsung Note 5 Google play services: 10.0.84 Location services: on Bluetooth: on Google nearby: nearby links available is on Chrome Physical web: on

Will check next week on: nearby.discovery.service.ScreenOnListenerService

It feels like it may not be running since the refresh of nearby makes it appear in the pull screen, never before.

This will be an awesome product once the kinks are worked out!

Armstrong30 commented 7 years ago

In researching further I found another references to the same issue:

Link: https://groups.google.com/forum/#!topic/physical-web-discuss/0OW5mJ0aDas

-- Since the latest Nearby release we've noticed the following two major Physical Web notification changes, which in our view downgraded the complete user experience and ability for simple discovery of Physical Web by the end users. Physical Web notification are not displayed on the lock screen any more. See the following GIF animation of prior functionality: https://www.fizicnisplet.si/res/img/OPT-Notification-lockscreen.gif. Nearby icon is not displayed in the notification bar when in proximity to Physical Web beacon. See the following GIF animation of prior functionality: https://www.fizicnisplet.si/res/img/OPT-Notification-homescreen.gif We believe both of these were really essential for Physical Web discovery and were surprised to see it removed, although it was not mentioned anywhere in your comments.

Can you please comment on this. Is our assumption correct that above mentioned functionalities were removed? If so, what was the reason and do you plan to restore the functionality?

Thank you and regards, Vojko @ Bikn.io.

Armstrong30 commented 7 years ago

@jfarfel @scottjenson

I'm not familiar with the technical details, here is what one of my guys could find. Let me know if there is anything else we can do.

roberts-mbp:~ robertchrzanowski$ adb shell dumpsys | grep ScreenOnListenerService -A 10

Armstrong30 commented 7 years ago

@jfarfel @scottjenson

Sorry for my many entries here, let me know if I need to take this direct via email (let me know what email)

Did some more testing:

During our test on a Nexus 6:

  1. While phone was on with screen unlocked, the beacon was started.
  2. After 20 seconds without any log output from the service, we turned the screen off and back on.
  3. after a couple seconds, we unlocked the screen.

We were saving logs based on the pid of the service: .nearby.discovery.service.ScreenOnListenerService

12-19 11:28:11.232: E/ctxmgr(1851): [ProducerActiveIntervalImpl]closeActiveInterval: Error: ongoing, trying to close 12-19 11:28:11.294: I/PlaceInferenceEngine(1851): [anon] Setup for configuration 105:[] 12-19 11:28:11.294: I/PlaceInferenceEngine(1851): [anon] Active modules after start(): 0 12-19 11:28:11.387: E/DataBuffer(1851): Internal data leak within a DataBuffer object detected! Be sure to explicitly call release() on all DataBuffer extending objects when you are done with them. (internal object: com.google.android.gms.common.data.DataHolder@5ed56ff) 12-19 11:28:11.387: E/DataBuffer(1851): Internal data leak within a DataBuffer object detected! Be sure to explicitly call release() on all DataBuffer extending objects when you are done with them. (internal object: com.google.android.gms.common.data.DataHolder@ec9eccc) 12-19 11:28:11.388: E/DataBuffer(1851): Internal data leak within a DataBuffer object detected! Be sure to explicitly call release() on all DataBuffer extending objects when you are done with them. (internal object: com.google.android.gms.common.data.DataHolder@3e82b15) 12-19 11:28:11.525: I/BeaconBle(1851): Client requested scan, settings=BleSettings [scanMode=ZERO_POWER, callbackType=ALL_MATCHES, reportDelayMillis=0, 3 filters, 1 clients, callingClientName=Nearby], listener=gyy@4c4cd24 12-19 11:28:11.528: I/BeaconBle(1851): ZERO_POWER is disabled. 12-19 11:28:11.529: I/BeaconBle(1851): 'L' hardware scan: scan stopped, no powered clients 12-19 11:28:12.782: I/BeaconBle(1851): Client requested scan, settings=BleSettings [scanMode=LOW_LATENCY, callbackType=ALL_MATCHES, reportDelayMillis=0, 6 filters, 1 clients, callingClientName=Nearby], listener=gyy@4c4cd24 12-19 11:28:12.789: I/BeaconBle(1851): 'L' hardware scan: 7 filters, scanMode=2, reportdelay=0, callback type=1, #clients=2 12-19 11:28:12.790: D/BluetoothAdapter(1851): STATE_ON 12-19 11:28:12.792: D/BluetoothLeScanner(1851): onClientRegistered() - status=0 clientIf=5 mClientIf=0 12-19 11:28:12.796: I/BeaconBle(1851): Client requested scan, settings=BleSettings [scanMode=LOW_LATENCY, callbackType=ALL_MATCHES, reportDelayMillis=0, 6 filters, 1 clients, callingClientName=Nearby], listener=gyy@4c4cd24 12-19 11:28:12.798: D/BluetoothAdapter(1851): STATE_ON 12-19 11:28:12.802: I/BeaconBle(1851): 'L' hardware scan: 7 filters, scanMode=2, reportdelay=0, callback type=1, #clients=2 12-19 11:28:12.802: D/BluetoothAdapter(1851): STATE_ON 12-19 11:28:12.804: D/BluetoothLeScanner(1851): onClientRegistered() - status=0 clientIf=5 mClientIf=0 12-19 11:28:12.826: E/ctxmgr(1851): [ProducerActiveIntervalImpl]addNewAppInterval: already contained:appKey=bww@bb9b632b,appInterval=bwu@9e0a632,record=key=(com.google.android.googlequicksearchbox, 10036, account#-311300731#, com.google.android.apps.gsa.extradex.kato.GmsContextManagerClientHelper, b943e3b0-13b3-443c-99a6-7a80b2e0dcc0), t=1482158376509, name=1, lifetime=(2), production=null, retention=null, dispatch=(1), consumer=(byr@c2dc1f40-159474974) 12-19 11:28:18.798: I/BeaconBle(1851): Client requested scan, settings=BleSettings [scanMode=ZERO_POWER, callbackType=ALL_MATCHES, reportDelayMillis=0, 6 filters, 1 clients, callingClientName=Nearby], listener=gyy@4c4cd24 12-19 11:28:18.801: D/BluetoothAdapter(1851): STATE_ON 12-19 11:28:18.807: I/BeaconBle(1851): ZERO_POWER is disabled. 12-19 11:28:18.807: I/BeaconBle(1851): 'L' hardware scan: scan stopped, no powered clients 12-19 11:28:18.824: I/BeaconBle(1851): Client requested scan, settings=BleSettings [scanMode=ZERO_POWER, callbackType=ALL_MATCHES, reportDelayMillis=0, 3 filters, 1 clients, callingClientName=Nearby], listener=gyy@4c4cd24 12-19 11:28:18.827: I/BeaconBle(1851): ZERO_POWER is disabled. 12-19 11:28:18.827: I/BeaconBle(1851): 'L' hardware scan: scan stopped, no powered clients 12-19 11:28:24.385: I/Coffee-PlaceTrustlet(1851): User Present broadcast receiver action: android.intent.action.USER_PRESENT 12-19 11:28:24.385: I/Coffee-PlaceLure(1851): User present 12-19 11:28:24.385: I/Coffee-PlaceLure(1851): Check whether to show notification 12-19 11:28:24.387: I/Coffee-PlaceLure(1851): today (local timezone) is: 19/12/2016 12-19 11:28:24.422: I/Coffee-HomeAddressChangeTracker(1851): User Present. Maybe fetch home. 12-19 11:28:24.423: I/Coffee-HomeAddressChangeTracker(1851): fetch for account outsitetester@gmail.com 12-19 11:28:24.423: I/Coffee-HomeFetcher(1851): return existing home address! 12-19 11:28:24.423: I/Coffee-HomeAddressChangeTracker(1851): home address is not changed. 12-19 11:28:24.651: W/ctxmgr(1851): [AclManager]No 3 for (accnt=account#-517948760#, com.google.android.googlequicksearchbox(10036):com.google.android.googlequicksearchbox, vrsn=0, 1, 3pPkg = null , 3pMdlId = null). Was: 3 for 6, account#-517948760# 12-19 11:28:24.675: I/PlaceInferenceEngine(1851): [anon] Setup for configuration 105:[] 12-19 11:28:24.675: I/PlaceInferenceEngine(1851): [anon] Active modules after start(): 0 12-19 11:28:24.780: I/Places(1851): ?: PlacesBleScanner start() with priority 2 12-19 11:28:24.780: I/PlaceInferenceEngine(1851): [anon] Setup for configuration 102:[BeaconScoring, CategoryScoring, DistanceScoring, GeoJournalScoring, HomeWorkScoring, HulkPersonaScoring, PopularityScoring, SpotterScoring, TimeBasedScoring, WifiScoring] 12-19 11:28:24.780: I/PlaceInferenceEngine(1851): [anon] Active modules after start(): 10 12-19 11:28:24.878: I/PlaceInferenceEngine(1851): No beacon scan available - ignoring candidates. 12-19 11:28:24.906: E/ctxmgr(1851): [PlaceFenceHelper]NearbyBuffer is null! 12-19 11:28:24.915: W/ctxmgr(1851): [AclManager]No 2 for (accnt=account#-517948760#, com.google.android.gms(10015):PlacesProducer, vrsn=10084000, 0, 3pPkg = null , 3pMdlId = null). Was: 3 for 18, account#-517948760# 12-19 11:28:34.704: E/DataBuffer(1851): Internal data leak within a DataBuffer object detected! Be sure to explicitly call release() on all DataBuffer extending objects when you are done with them. (internal object: com.google.android.gms.common.data.DataHolder@dc15a2a) 12-19 11:28:34.704: E/DataBuffer(1851): Internal data leak within a DataBuffer object detected! Be sure to explicitly call release() on all DataBuffer extending objects when you are done with them. (internal object: com.google.android.gms.common.data.DataHolder@b48601b) 12-19 11:28:34.704: E/DataBuffer(1851): Internal data leak within a DataBuffer object detected! Be sure to explicitly call release() on all DataBuffer extending objects when you are done with them. (internal object: com.google.android.gms.common.data.DataHolder@afb55b8) 12-19 11:29:34.656: I/GCoreUlr(1851): Starting BLE scan: mode: 2 12-19 11:29:34.659: I/BeaconBle(1851): Client requested scan, settings=BleSettings [scanMode=LOW_LATENCY, callbackType=ALL_MATCHES, reportDelayMillis=0, 3 filters, 0 clients, callingClientName=ULR], listener=gyy@c1f70a8 12-19 11:29:34.678: I/BeaconBle(1851): 'L' hardware scan: 4 filters, scanMode=2, reportdelay=0, callback type=1, #clients=2 12-19 11:29:34.679: D/BluetoothAdapter(1851): STATE_ON 12-19 11:29:34.684: D/BluetoothLeScanner(1851): onClientRegistered() - status=0 clientIf=5 mClientIf=0 12-19 11:29:36.696: I/GCoreUlr(1851): Starting BLE scan: mode: 3 12-19 11:29:36.697: I/BeaconBle(1851): Client requested scan, settings=BleSettings [scanMode=ZERO_POWER, callbackType=ALL_MATCHES, reportDelayMillis=0, 3 filters, 0 clients, callingClientName=ULR], listener=gyy@c1f70a8 12-19 11:29:36.705: I/GCoreUlr(1851): BLE: collected 30 results 12-19 11:29:36.725: D/BluetoothAdapter(1851): STATE_ON 12-19 11:29:36.730: I/BeaconBle(1851): ZERO_POWER is disabled. 12-19 11:29:36.730: I/BeaconBle(1851): 'L' hardware scan: scan stopped, no powered clients

Armstrong30 commented 7 years ago

wondering if it is working on wake up only and not screen on

jfarfel commented 7 years ago

@Armstrong30 Thanks for the test and logs.

Note that it's expected that nothing happens if you enable a beacon while leaving the screen on. Currently, BLE scanning occurs only for a few seconds at each screen-on event -- so it's expected that nothing was logged until you turned the screen off/on.

Whether the screen is unlocked or not shouldn't matter (the scan triggers at screen-on, unlock is ignored).

Could you turn the screen on/off with the nearby beacon enabled, then take a bug report, and attach it the file here? To take a bug report:

adb bugreport > some_file_name.txt
Armstrong30 commented 7 years ago

@jfarfel, will do.

Question: does this mean no notifications unless there is a screen turning off or turning on? In other words if a user walks up to a beacon object with the screen on, he will not receive a notification?

jfarfel commented 7 years ago

Unfortunately, yes. We're looking into scanning more often in the future (while trying to be careful about the trade-off between fresh results and battery use).

On Mon, Dec 19, 2016 at 4:03 PM, Armstrong30 notifications@github.com wrote:

@jfarfel https://github.com/jfarfel, will do.

Question: does this mean no notifications unless there is a screen turning off or turning on? In other words if a user walks up to a beacon object with the screen on, he will not receive a notification?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/eddystone/issues/190#issuecomment-268114969, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwHPgZxHGAWZtOFcb759l-BiKIXOhy2ks5rJxtngaJpZM4Kdxzb .

Armstrong30 commented 7 years ago

@jfarfel just to make sure, did I get this user experience evolution right ? 1) Prior UX: settings based nearby low priority beacon notifications (the user does not have to know that there are beacons nearby) 2) New UX: settings based, cycle screen to on (for scan) receive minimal priority level beacon notifications (the user must know there are beacons)

Feels like there is a fundamental philosophical issue in play between notify purely based on settings or inquire based on knowing there is a beacon (screen cycle). Put in another way, does the object inform the user or does the user inquire about the object.

Anticipating this very UX issue, we made our beacons so that the user must activate an objects specific beacon. This also deals with places that have many beacons (notifications) and users only want a specific objects engagement.

I'm curious what other scan events are being considered. Could screen pull down be considered as a scan trigger action ? the user would be looking for notifications.

jfarfel commented 7 years ago

The description of UX changes is not quite correct:

You're right that there are difficult philosophical issues here. We're trying to err on the side of "no spam" (i.e. we don't want to annoy users by vibrating the phone or pushing notifications that they're not interested in). I don't think I'm at liberty to talk about any new scanning strategies (don't want to commit to anything and then have to change it), but I like the idea of pulling down the notification shade as a trigger.

scottjenson commented 7 years ago

Sorry, @Armstrong30 didn't mean to close this prematurely. Did you get your question answered?

aureliencapi commented 7 years ago

hello @scottjenson, i still have the same issue here, i've set up all parameters possibles and i don't receive any notifications.

Armstrong30 commented 7 years ago

Not working well on Samsung note 5. Taking a wait and see how Eddystone evolves with what seams like an oxymoron of unsolicited URL discovery and delivery without disturbing the user.