Pinging Terminal Device

Questions
1

Hello There,
Can someone help me understand why I always get the status of the device as “Available”. I turned off the device to check if the status changes to Unavailable but it’s not changing. I am developing a custom POS. I need to ping the device before I send the Total amount to it.

Here is what I have used:

    # Set the request headers
    headers = {
        'Authorization': f'Bearer {SQUARE_ACCESS_TOKEN}',
        'Content-Type': 'application/json',
    }

    # Set the device status URL
    device_status_url = f'https://connect.squareup.com/v2/devices/device%3A{SQUARE_DEVICE_ID}'

    # Send a GET request to check the device status
    response = requests.get(device_status_url, headers=headers)
    print(response.text)
2

How long was the device unavailable. Was it just turned off? :slightly_smiling_face:

3

Yes, for about 5 min. Should it not report if the device has not internet or if it’s turned off?

4

It definitely should. I haven’t been able to replicate this with my device. Are you able to repeat this consistently? :slightly_smiling_face:

5

It shows be correct status only after a couple of hours. There ought to be a way to get the device status on a real time basis. Can you suggest me any other way?

thanks

6

Is this only happening with one device? If so what’s the device_id? :slightly_smiling_face:

7

device:326CS149B4000934

8

Are there more devices or is this the only one? :slightly_smiling_face:

9

There are other 4 as well.

10

All with the same behavior? If so what are there device_ids? :slightly_smiling_face:

11

Have not checked with other devices as they are located at different places.

12

Hello, I just wanted to drop my 2 cents here. I too have noticed that the device status does not update when using the new “device status” end point. I’ve tried multiple times, across multiple API versions and it never quite does what you expect. I just assumed that it’s not close to real time (I would consider sub 10 sec bare minimum for “real time”). We really need a way to know if the device is ready before we start sending requests, it would help smooth out dealing with the device.

I have resorted to keeping a heart beat going on the back end, and then having the front end request the current status of the heart beat. The heart beat is on ~30 sec intervals, which is still not fast enough. But I’ve found that any faster and I start to get false positives.

13

How are you using the ping? Are you doing it before every payment? Or are you periodically checking? :slightly_smiling_face:

14

Periodic check (aka “heartbeat”), every 30 seconds, assuming I’m understanding correctly.

15

I just double checked and forgot that I had to set the interval to 60 seconds. I forgot why I had to do that now.

I have a small backend (nodejs server) running locally on the machine. It handles keeping the heartbeat going, even when the client is not interacting with the API or the server. The server saves the last status it got from the ping as a bool. The client asks the back end for the latest status of the device throughout various operations (when the user connects, when the users wants to get payment, etc).

The backend sends out a terminal action for pinging the device, then about ~60 seconds later, it checks the status of the ping/action. If the backends detects a bad status from the device, it sends out a terminal action as usual, but the status of that same action is checked more frequently, about every 15 seconds, until that action times out. At which point it will send another action and this repeats until the we get a good status update.

I don’t really like my solution. I would rather just ask the API if the device is ready. But as I’ve pointed out before, it doesn’t behave as expected.

One test I conducted was asking the API for the device status (using the new endpoint for doing so) every like 10 seconds or so. And then I would turn the device off and watch the responses from the API. Minutes would go by before the status would change. Not sure if that was the intended behavior.

16

I’m reaching out to the team about this. I was able to replicate the delayed behavior. :slightly_smiling_face:

17

I’ve been writing in another post (WEIRD problem with my square terminal) about another problem I was having. Turns out doing the pinging strategy I describe above causes the device to take an unacceptable length of time before it would acknowledge the checkout request. Oddly, if I touched the screen while waiting, the device would immediately acknowledge the request.

I make mention of this here so people don’t go doing what I did. Our best bet is to wait for the devs to provide a solid endpoint for this kinda thing. Trying to do anything close to real time with the provided APIs seems to cause the device/service to behave oddly.