Inconsistent results for setEntry commands via SmartThings SDK

Developer Programs Support
1

We’ve been working on optimizing our app and our integration with SmartThings. We’ve been trying to troubleshoot why we seem to have inconsistent results when using the SDK to send setEntry and deleteEntry commands to our locations. We use OAuth with a clientID to connect these locations to SmartThings.

This is what we are seeing in our development environment which currently has 3 locations with locks and 4 locks total (two locations with one lock and one location with two locks). All 4 locks are triggered at the same time, so they are sending the following commands to 3 locations at approx the same time:

  1. Start with getCapabilityStatus to get the current lock slots & identify which is open for us to use
client.devices.getCapabilityStatus(stDeviceUuid, 'main', 'lockCodes')
  1. Then we wait (was 15 secs now 60 secs) to send the setEntry command
client.devices.executeCommand(stDeviceUuid, command)

{
  "component": "main",
  "capability": "lockCodes", 
  "command": "setCode",
  "arguments": [
    code_slot,
    "code", 
    "code_name"
  ]
}

We get a {"results":[{"id":"uuid","status":"ACCEPTED"}]} response from SmartThings with our setEntry command. However, the code only programs to the lock less than 50% of the time.

We also tried copying the same commands directly from our logs into Postman and sending manually this way, and we get a 100% success rate.

@nayelyz Is there something we can do to get more visibility into why these commands are not executing on the device after they are accepted by SmartThings? We’d like to optimize this to get closer to a 100% success rate through the SDK

2

Hi, @gregjanes
Just to clarify, you’re referring to the commands setCode and deleteCode in the lockCodes capability, right?

What I can think of is: Have you checked what happens if you subscribe to the “lockCodes” capability to get a device event when that capability is updated?
That should issue only one when the new value is saved in the attribute. I haven’t seen how they work for this specific case, but I can do some tests in the meantime.

3

Hi, @gregjanes
Just to clarify, you’re referring to the commands setCode and deleteCode in the lockCodes capability, right?

What I can think of is: Have you checked what happens if you subscribe to the “lockCodes” capability to get a device event when that capability is updated?
I haven’t seen how it works for this specific command but I can do some tests on my side as well.

We can also investigate if there’s an issue with the events from the SDK, to do so, we would need you:

  1. To replicate the issue and take note of the timestamps of when you sent the command to set/delete a code but failed
  2. Do another test from Postman to checl why that one is successful compared to the others.
4

Thanks for your reply @nayelyz - appreciate any assistance we can get in determining what may be happening. We have added extensive debugging logs on our end but don’t have any visibility once we send the commands to SmartThings.

Just to clarify, you’re referring to the commands setCode and deleteCode in the lockCodes capability, right?

Yes, we’re seeing more inconsistency with setCode than deleteCode, but still on both. And many times we are getting an Updated rather than Deleted result with the deleteCode command which we’re also trying to understand.

Have you checked what happens if you subscribe to the “lockCodes” capability to get a device event when that capability is updated?

Yes, we subscribe to the device to get the update – so we have logs when things are successful. For these particular tests we have found it most accurate to check 60 seconds after we send the setCode command with a get device status to check if the code exists.

  1. To replicate the issue and take note of the timestamps of when you sent the command to set/delete a code but failed

To be clear, you’d like timestamps for the specific events we are seeing where we send the command and get the Accepted return from SmartThings, but then the command does not process? Here is a spreadsheet with testing results from today. The Success outcome is obvious, the lock received the code. The Failed outcome is only recorded if we got an Accepted return when sending the command, then check after 60 seconds and the code is not present on the device.

  • 100 successes
  • 76 failures
  1. Do another test from Postman to checl why that one is successful compared to the others.

We have been trying all types of different tests to isolate the variables. Only differences we have come up with so far:

  1. Command Wrapper: Postman payloads are sent in a command wrapper, SDK commands are not. As we understand, the SDK does not need the command wrapper.
  2. Timing: Obviously I can’t send Postman commands manually as quickly as software can, but as I understand there shouldn’t be limits if we are sending to different locations

If you have any other ideas for tests we’re happy to try them out.

5

Yes.
Wwe also need access to the account(s) where those devices are installed, since the engineering team tried to look for the events in the timestamps you shared and couldn’t find them. Having access to the account can help us collect other information to narrow down the search.
To do so, we need:

  1. The email account used in the SmartThings account (you should send it over DM)
  2. Enable support access to your account:
  1. Go to the SmartThings Web (my.smartthings.com)
  2. Log in to your Samsung Account
  3. Select Menu (⋮) and choose Settings
  4. Toggle on Account Data Access
  5. Select the time period and confirm - In this step, please select “Until turned off”, once the team finishes, we’ll let you know so you can disable it again.

See more information about this access here: https://support.smartthings.com/hc/en-us/articles/36170233944852-Enabling-Account-Data-Access-for-Support

6

Hi, @gregjanes

After checking some of the devices you shared, this is the feedback from the team:

  1. We see that the command goes through all the correct services until the hub to be sent to the device.
  2. However, the team tried to collect the hub logs to see if there was an error shown there but it didn’t have the logs of the corresponding date.
  3. So, we suggest you monitor the execution of the commands through the Driver logs. They can be seen by setting up the CLI, and this command:
smartthings edge:drivers:logcat
  1. Since the commands are sometimes successful and sometimes fail, it could be due to something during the transmission of those messages. In this case, for your tests, we suggest you keep the devices closer to the Hub to see if it improves the result.
7

Hi @nayelyz -

I moved the devices to be closer to the hubs as well and made sure there was more space between the hubs themselves (since these are test locations, they were in a room close to one another). Those changes seem to have improved things, I’m seeing better results now.

I do have another question related to the lock codes – it appears that we are getting a significant number of “unset” webhook events when we send a deleteCode command – we are getting a webhook return of “deleted” but then that is followed up by a number of “unset” webhook events. Here is a spreadsheet with examples from one location.

Location uuid: dd50077b-c703-49a7-9c84-64f16edc0bd3
Device uuid: 49ddabfb-d2ae-4e19-97ff-1b09e08bfa9f

Is this expected and should those be ignored, or is there something wrong with how we are sending the commands?

8

Have you checked what happens in the driver logs of the device to see if those “unset” events are also shown there?

Also, if I understand correctly, you’re getting several “unset” events for the same device, right?
If so, please provide the following info to look at the Cloud logs as well:

  • InstalledAppId
  • It would also be helpful if you captured the eventId to look for them in the logs.
  • Having the device’s name and timestamp like in the spreedsheet is necessary as well.