Lockitron API command times out and alerts all users the lock is offline


So I’m attempting to write my own SMS control for fun, but I’m having issues with the simple lock/unlock commands. It seems that if the API commands time out, anyone (or maybe just admins) who has the Android app installed is alerted that the lock is offline.

Is this by design?

Also, will the API commands be queued (like the app commands), until the lock wakes up?


Hey there. I don’t work for Lockitron, so always check with them for official answers.

In the meanwhile,

I believe it’s Admins, but I don’t think it should send a notification out to everyone… Make sure you’re using your own individual access token etc, and that your SMS access is set up as an individual app on the API page.
At any rate, there’s no notes as to whether or not this is by design.

Yes. In “Locking and Unlocking”, it states:

This method will lock or unlock the user’s door. It blocks until locking/unlocking is finished. If the Lockitron is asleep, it can take several minutes. Failures return standard errors.

This is followed up by the “Pending Action” section:

This method allows you to cancel a pending activity on a Lock. Pending acitivities are those activities on WiFi Lockitrons which have yet to be carried out because the Lockitron has not yet reconnected to WiFi since the command was sent.


I gotta say, I too was having this error message the other night when I was fiddling with the API for the first time in probably a month. I just brushed it off, but perhaps it’s something with the new firmware? Prior, I never once had an issue with the API.


@fly @roastedbagel is this under the v1 or v2 API? Have you tried the noblock param? This is partially due to a difference in how we architected old vs. new Lockitrons; for compatibility we allow you to still carry out a blocking command to wait for confirmation, but this is a really bad idea if it will block for 30 minutes (the server will time you out first) which is why we recommend setting up a webhook instead.


I’m using the documentation outlined here

I don’t see anything about noblock and a quick search gave me nothing relevant.


@fly ok, we need to document that - we’re likely going to migrate to it as default behavior, however, you can do it now with by adding ?noblock=true to your PUT request. You will get a response with the pending activity (although this may be a bit buggy in the activity returned).

Lockitron-PHP to respond to Webhooks (used for auto door lock)

Awesome. Thanks!

(20 characters)


@cameron How do I know if the state of the lock changed when I send a PUT request with the noblock=true parameter?

The response I get has a state attribute that makes me think the lock changed state (state = lock). But if I do a GET request on the lock I see that the state really hasn’t changed (it’s still state = unlock).

    "button_type" = slider;
    id = "xxxxx";
    "last_heard_from" = "2015-03-06T16:40:00Z";
    "last_offline" = "<null>";
    "last_online" = "2015-03-06T19:18:56Z";
    name = "Hanlon's Lockitron";
    "next_wake" = "2015-03-07T16:40:11Z";
    "pending_activity" =     {
        "created_at" = "2015-03-06T19:18:56Z";
        id = "xxxxxxx";
        kind = "lock-updated-locked";
        "request_status" = 0;
        status = notice;
        "updated_value" = "<null>";
    state = lock;


@Hanlon yes, this is super frustrating behavior that we keep around because one of the clients still expects it. The idea is that your lock request successfully went through, not the actual state change.

We would like to change this - in the meantime the only way to confirm the state change is to wait for the webhook.


If you’re concerned about the result, shouldn’t you just omit ‘noblock’?


@fly the server will essentially always timeout without noblock, so we recommend it for any lock/unlock actions with v2 Lockitrons.


Yeah. I like the noblock because I get a response immediately (no timeouts) and I don’t fill the log with “Lock Offline” activities that could confuse the end user. Plus it’ll be the default behavior eventually so I might as well learn to work with it.

For now I’ll just run a GET request for the lock status after each PUT request to confirm the lock’s true status and then wait for the webhook to let me know when the status finally does change.



@Hanlon hmm I don’t think doing a GET right after the PUT would help since the system will still indicate the desired state rather than the actual state.