Delay between calls

Using v2 API, FW v2.10.8 on Zermatt bridge, it seems I have to introduce a delay between the PUT for executing an Action and a GET for the State. I can make multiple GETs in a row with not problem. But if I do a PUT for execute Action and then turn right around on a good return code (204) and do a GET for the State, I get an “‘Connection aborted.’, BadStatusLine(”’’",)" in Python. This seems like the Bond is returning bad data to the GET.

Doesn’t take a big delay - 200 ms seems to do it. But is this normal and do you have an official recommendation on this? Seems like the developer of the mobile app may have experienced this problem too.

Thanks for your help.

Hey @kingwr, you should be able to make the follow up GET request immediately!

What would be useful is, doing a wireshark capture so we can see the exact request/response from the Bond. NOTE: you will want to set a capture filter on Bond’s IP or MAC to reduce the noise and avoid capturing sensitive data.

I can confirm, same problem, I have to add 200 ms delay between PUT and GET, otherwise it doesn’t work. At least when I toggle direction using Summer and Winter (SetDirection) action.

Okay, this sounds like a real problem that could affect any client. We’ll try to reproduce on our side.

Sorry mate - my bad. It was multithreading issue in my code - when polling for status interferes with other request from different thread. I added lock to the connection - now it works without delay.

Great! That’s a big relief

1 Like

Looks like there’s an issue, but slightly different.

After lots of testing by @CJMH - the suspicion is that the receive error happens when sending requests without delay (i.e. status request). With minimal delay (i.e. 50ms) the error is gone.

However, periodic polling for the Bond device state on a Bond Hub (not SBB) still gets occasional receive errors on my Raspberry Pi using Alex’s HomeSeer integration. Just tested this again. Still working on why …

My time delay is down to 70ms and haven’t seen the error come back up. But I haven’t tried it without the time delay since the initial posting. 70ms is not too bad in my integration, so I am fine with the delay, because the delay only effects the Bond integration for one user - not multiple integrations running on the same Pi or multiple users. If there were multiple integrations running in the process and/or for multiple users, then this would be a problem (delay would have to be asynch).

@jacob @merck I want to re-send the command in this case, but since I don’t know where the failure is - on sending or receiving side - so I don’t know if the Bridge received the command or not. Which is crucial in case of “toggle” command.

If you need to implement a retry mechanism in your integration, please contact the Bond Engineering Team via the Bond Forums

What’s your OS? And what language/framework?

RPi on Raspbian Buster running a python process using Requests library.

1 Like

Bingo! We have the same problem on the apps where the local HTTP connection drops when the app has a weak wifi connection.

The trick is, in ever request we embed a unique ID, and retries of that user intent should duplicate that ID.

I’ll DM you the details. We’re still working on a proper public way to document it. I will share publicly when we have it in a form which will not confuse others.

Can’t see why it’s difficult? Just add ‘id’ field to every request, and on the client side increment the id with every send. But I may be missing something?

I shared instructions that should solve the immediate issue you face. Note that simply incrementing is not good enough: if the client’s counter resets the Bond would stop responding to requests.

Thank you Chris, I’ll try it.

Just wondering, why you add the request ID to the HTTP header, no the REST payload?

Because it’s not part of the payload, but rather metadata. Like the token.

Token is fixed for all requests, but request id is tied to the payload.

By that argument, you could also say that the topic (URL) should be in the payload, because it changes…

I do know that adding HTTP headers (although an essential part of the standard) is sometimes difficult in some restrictive client platforms. It would be possible for us to add the option to provide the _uuid in the payload, like we did for _token, but crucially, this would not be in the earlier firmware so could cause some issues if users haven’t upgraded!

Would be great. And not a big issue - because request id is a “cherry on the top” feature, so if the user wants it - will have to upgrade FW.