ChastiKey API

Thank you for mentioning the typo. I'll try and correct that today. I'm surprised the user id is case sensitive as I don't thibk the database table is but I'll have a look and will update the documentation accordingly.

Are you saying you want the API to show when the lock is due to finish? That is doable but only applicable for fixed locks where the timer isn't hidden. Would you not run into issues or wouldn't it be flawed it relied on this timestamp only, especially if the keyholders hides the timer during the lock, so when created it was due to end in 4 days, after 2 days the keyholder hides the time and adds 10 days. If your lockbox relies on that timestamp wouldn't it unlock after 4 days, even though 10 days was added just because the time to unlock timestamp is hidden in the API data

Thanks for the reply.

I would like to know that the status of the key is ready to be unlocked. Not the actual time length.  Though knowing the time length might be nice as well for timed locks.

My thoughts is add a few status
so you have UnlockedFake, UnlockedReal, sucess  already.  My thoughts would be add something like "KeyAvailable" when the timer or keyholder has unlocked it but the lockee has not yet tried the key.  (LockedReady or LockedKeyAvailable ... any words to that effect would work just as well)
You can't see at this point if if a real or fake key since the user does not know.  If the keyholder adds time before the lock is tried it would update back to the Locked status.

Any remote app would just send a once every minute or so query to your server so it does not need to predict when it will be unlocked. If it notices the status that the key is available it could then remotely unlock its lock. If the key turns out to be fake the lockee might still not be able to enter a lock box but that is not the fault of the api.

If you want to populate the time in the future for timestampUnlocked of when it would be unlocked but not update the status that would be OK for timed locks but that isn't what I was after.  That would be nice in that a remote API could use that data to update a color light or something though perhaps that is better handled by a different field that would also give a prediction of the number of cards in the case of non-timed lock but that is a different request.

There's now a version 0.3 of the API available. I've created a new version because of a new status code addition: ReadyToUnlock

I've also added a flag to show if the lock is frozen or not

https://www.chastikey.com/api/doku.php?id=v0.3

Please let me know if you find any problems or want other things added to it.

very good. I'll give it a go and let you know if I see an issue. You were rather quick about it!
Documentation page doesn't show the new status

Hmm, https://api.chastikey.com/v0.3/listlocks.php?userID=my-user-id-tag gives a 500 Server error.  The v0.2 entry still works.

EDIT: It appears as if the v0.2 entry has been updated so it includes the "frozen" attribute.

Also the documentation is still listing combination as a number, when it's really a string.

with 0.3 the listlocks tosses a 500 error regardless of input.
The checklock for a variable lock is not showing readyUnlock

thanks again

The 0.3 not loading issue has now been fixed. I'll have to have another look at the ReadyToUnlock flag. It looks like the app isn't always updating the database correctly when it's on your device ready to unlock.

And yes frozen was added to 0.2 as it was an extra variable so unlikely to break things for people already using it. Adding the new ReadyToUnlock flag in an existing variable might have caused issues so created a new version.

I've fixed the documentation so that combination shows as strings. Thanks.

Here's another users lock with the ReadyToUnlock flag showing



{"response":[{"status":200,"message":"Success","timestampGenerated":1549961097}],"locks":[{"lockID":XXXX,"lockedBy":"XXXX","lockFrozen":0,"timestampLocked":1525568430,"timestampUnlocked":0,"status":"ReadyToUnlock","combination":""}]}



It works, just not all of the time, but that's an app issue that would need to be looked into and fixed.

I've fixed the documentation so that combination shows as strings. Thanks.

Almost :-)  The JSON now looks right, but the description still has "Will return 0 if not yet unlocked" in both places.

Thank you @sweh I've fixed that error now in both versions.

It appears that that the readyToUnlock only shows up after the application has run in the forground and has a chance to evaluate the lock.  That makes sense now that you mention it as the logic is in the app and not on the server.  It does change some things as it makes it not possible to do remote unlocking without touching the phone (at least in Android) as the app will be sleeping.

Sorry if this is a double-post but I think the previous one was eaten...

Anyway, just found this app, and am having fun with it.  Well written and nicely done...

I have an esp32-based lockbox that I've made, which currently is just time based, that I'm adapting to use with this api.  Once the username and lockid have been entered on the esp32's web interface, the esp32 can go pull the lock status from the api, and unlock once 'UnlockedReal' is seen for the lockid.  That part is good.

The part that is not so good is that I haven't figured out a way to make using it easy.  Each time it's locked, I need to get the shared lock, start it, and then enter the new lockid into the lockbox web page. 

It would be nice if a shared lock could be made 'persistent', so that the same lockid could be reset either by the hw or the user, as if it was being re-loaded, but keeping the same lockid.   

If I can get it working a little smoother, I'd be happy to share the construction, esp32 code, etc.

At the moment you can't restart a lock once it has unlocked, but that will likely change in a future version

I don't think a lockbox should be stuck to work with the one lock though because that means you can't create new and longer ones when you're trying to set personal goals/records

I don't think a lockbox should be stuck to work with the one lock though because that means you can't create new and longer ones when you're trying to set personal goals/records

I agree here... When the box is unlocked it's possible to choose any keys.  I haven't used chastikey that much yet, but based on the previous incarnation of the box which uses time, my wife almost always uses the same settings to start, and then adjusts it once its running. 

Making it really quick and easy to re-run a shared session is really the goal.  Maybe even just save a list of previously loaded shared locks?  I could just have the box find the first locked key managed by a specific user...

BTW, The discussion with my kh is that one mode she'd like to have a variable lock available that starts frozen.  She could then unfreeze as she saw fit to give me chances...

CHT:  You could use just the user ID and not the individual lock.  So if any lock is running for that user it stays lock?