Hello, i´m working on an App which should show me a state of an Smart lock in (close) to realtime
What i have done so far:
What have i done wrong?
I don’t quite understand why you’re polling the lock Api’s status every 5 seconds (that might be a good way to get yourself rate limited), but I can see why you might do that in a testing context. (Obviously, you would probably not want to do that in production.)
I assume that perhaps you are trying to conveniently assess whether you can detect the lock being operated by some other means, correct?
At any rate, what you may have to do here, to force your group to re-evaluate the conditions on that text element is to send reset data to the group after Step 2 (set status/retrieve from api):
Here’s what may be happening with the API call: I’m not sure if this is 100% correct, but some have observed that, if an API call is made sequentially with the same exact parameters it can sort of act like the results of the call are cached.
(That is, Group API Call’s Status is not actually being reset as the value being returned is either (a) exactly the same as API Call’s state state and hence there is no need for bubble to actually update the value or (b) the parameters you are sending to Nuki - API Call are identical to the last call and so it is assumed that the results of the call would be the same and, again, the resulting return value is not updated [that is, the call truly is "cached].)
My own observations, from writing my own API endpoints and pinging them via Bubble, is that sequential repeated API calls are in fact made. However, if the values coming back are identical there’s no point in Bubble actually doing the data write as no value has changed, right? (So what I’m saying is that I believe what happens is “case (a)” not “case (b)”.)
At any rate, sending reset to the group as I suggest will likely result in the behavior you are expecting.
But another way to do it would be to go back into your API call and reconfigure it such that the call always results in different values coming back. One way to do this, for example, is to reinitialize your call and capture response HEADERS. One of those headers will be something like the response time when the result came back. This value will of course be unique and always changing. (Select that value as a parameter to return, don’t ignore it.)
Here’s an example: Note “headers date”:
You may have to further retrieve that value in your page. For example, don’t just set Group API Call’s Status, but also set something like Group API Call’s headers date.
Anyway, that’s a rather long-winded explanation for what you may be observing.
Just curious, does the API you’re working with offer a webhook for when the lock status changes? I just did a quick Google search and it does seem like a “thing” with some smart lock systems that offer APIs (for example: https://api.lockitron.com/ - see their webhook section).
That would be most ideal because then you can update your database with the status based on a real-time event and not have to poll it a crazy number of times (like @keith mentioned) .
Just a thought!
Gaby at Coaching No Code Apps (formerly Coaching Bubble)
Courses & Products, Tutorials, Private Coaching, and High-level Development
This is true for “action” calls, but not for “data” calls: Bubble retrieves the result from cache instead of making the call again.
Almost got it … reconfigure such that the outgoing call always has something different - url, headers or parameters.
I totally agree, webhooks are superior to polling.
Sadly enough it doesnt, software seems to be teyr main Problem. Thats the whole reason why i even start to work on an app to highjack the lock. While the Hardware is really nice, the Managing Software (Adding and Deleting User on regular bases ) is a bit troubblesome.
In the finish app, i intend to open a Popup, in there the User will see the Lock with Name, Status, and his Options. Therefore i need the Actual Status of the Lock, and an updatet one after a few Seconds until the Operation (Lockin, Opening…) is finish.
The Status you get back from the Lock are: Locked/Unlocking/Unlocked/Locking/Opening/Open/Motor Blocked.
I find it important for the App to show them in “Realtime” So it will update rather often, but only for a short Period of time, as long as the Popup is Open.
But thanks to all of you for your feedback, it will help for shure.
Hmm, i could ask every second time for a nonexisting lock… but thats just…BAD work. Do you have an Idea how to make the Call allways different. Sending an Extra Parameter nobody needs- does this work stable?
@technical-solutions my favourite approach is to create a header and set it to current time milliseconds, most APIs ignore any header they don’t recognise.
Thanks, will send an update as soon as ife got Time to Test it.
@misha, what you are saying about caching MAY be true for GET methods, but it IS NOT true for POST method data, action and file calls. They are always executed.
I know, because I’ve written my own API endpoints and they are always hit. (I always write POST calls. GET calls are for sissies. 
)
Considering that it seems to be a caching issue, @technical-solutions likely has GET calls then.
