#john-terminal-m2
1 messages · Page 1 of 1 (latest)
this is what's happening
we have a full app for this already built, and we sent customers the new terminals but usually out of the box they are having trouble initially connecting to the app. Is this a battery issue or something else?
john-terminal-m2
Hey @visual gale ! It could be a battery issue per https://support.stripe.com/questions/a-bluetooth-reader-is-encountering-issues-connecting-to-my-point-of-sale-application
So I think you might want to advise your users to first fully charge the reader before usage
So what would happen if they are at like 20% the very first time? In theory, it SHOULD connect but tell them they need to update
but it's just simply not connecting
do the terminals not allow connection if it needs an update?
if it needs an update it needs 50% battery before it connects
and then if it's under 50%, it's possible we're getting an issue where it "connects" and then doesn't have enough juice to update and fails. So in the case where it NEEDS an update, and is between 10-50% battery is a weird place. We should find a way to handle that cleanly
is there a way we can get whether it needs an update BEFORE they connect?
so we can tell them "Must charge to 50%" before they try and connect?
I don't think so
So really you need to instruct them that they have to have the battery high enough for the first connection
is there any part of the SDK that allows us to determine a software update avail?
or how/when does it determine the device needs an update?
can we intercept that message?
@vapid python ?
No I don't think you can
We're still looking at this, but I agree there's a gap if you can't know this before connecting.
it "connects" and then doesn't have enough juice to update and fails
Do you get a relevant error code here when it fails? Does the connection fail or does it connect then disconnect?
did you see the video I shared?
I can dig into the logs and share what I'm getting in a few haha my device is charged now...so gotta try and replicate
Might need to come back later on this, will the thread close out?
Is there a way to simulate lower battery?
We'll close it later, yea, but you can always refer to it and link back to it
eg: hey, more info debugging the issue discussed here: https://discord.com/channels/841573134531821608/1116071900767076423
I don't think so, unfortunately
great tahnks!
Yea, I watched but this doesn't really reveal what's going on with the underlying SDK calls and errors
yeah we'll get the Android logs soon
(as expected, your UI should hide those details from your users)
One more questions
are we able to get the battery level BEFORE connecting?
according to this https://github.com/stripe/stripe-terminal-android/issues/63, we can't get battery level until connected to a reader. Unless they've added that functionality. The issue is from 2019
but I feel like this is a thing now
where can we find "m2 docs" in the Android SDK about this?
I don't think that's exposed currently anywhere you can access it -- I can see why this is a challenge and trying to make sure I understand for shaping feedback to improve this
yeah ideally we can get the battery percentage in the same paylaod that helps us render the list initially. Like theoretically, the M2 readers should only NEED to be connected to provide "internet/network" required information since that's kind of the whole point of the M2 readers...which makes sense why it needs a connection for the updates to check if there is one available/needed. However, battery is a device specific (non-network) level piece of data that should be easily fetchable without a connection in that bluetooth scanned payload. Then, there should ideally be some specific code/message "requires_update_battery_limited" or something that is returned on the CONNECTING action if it needs an update but doesn't have the juice to do so. Right now, I believe it returns some kind of "requires_update" message if it has the juice and needs an update
pretty sure iOS handles this
FYI @scenic flint here are some of the logs we get in that payload on discovered readers for a BRAND NEW terminal
Doing some research over here, and one possible option for detecting this:
when the SDK anncounes didStartInstallingUpdate you should be able to check the reader batteryLevel
so this is a terminal that has never before been connected (kind of the core 'cause' of the issue)
If its under 50% you should be able to cancel the install & disconnect and surfance appropriate UI to a user
what about the instance where it simply doesn't have the appropriate battery level (5%) or something, is there a message it returns about battery level?
To connect in the first place? What are you seeing now when that happens?
still waiting on battery to get lower, I would imaging there is some kind of message
also, should we restrict any use of the terminal if it can't be updated?
like if the battery isn't high enough to update, but high enough to connect - can we stay connected and just ask about battery charging
Yes, because required update must be installed before the reader can be used
got it
we'll try that out
only thing that would be extra helpful is the battery level in payload BEFORE connecting, but I think we can use what you gave us to solve the issue for now
@formal belfry Also, do you happen to know if that battery level is static? Like is it just the value we get once we connect to a reader and it doesn't update itself after that? If that's the case, the user would have to refresh the list of readers again to get their updated battery level
Hello, apologies I missed that question for a bit. How are you retrieving the battery levels currently? Can you show me your code where you do this? I'm reading through the rest of the thread but if you can paste it here that may be faster