Getting _requestId


#1

Hi,

This is somewhat related to my previous question
"Why getAttribute increments _requestId twice?"

As I’m hoping to compare my request and reported result,
I’d like to acquire the requestId when I issue get/setAttribute.

But considering that there are bunch of “setAttribute” adding
a pointer argument to all of these does not sound right.

Probably adding a new member function “getRequestId” to
iafLib and afLib would be more elegant.
I wonder if such member function could be added in the future version?

Although I’ve already added one to my local copy of afLib,
I don’t want to make my copy too different from the original one.

moto


#2

Hi Moto-san,

In all honesty we have a lot of support for requestID in the afLib code, but we don’t really do too much with it internally. If you have improvements that work better for you, we’re more than happy to make upgrades to core afLib to support your use case.

You just want a method to return the currently active requestid on demand, correct? Something like this?

uint8_t getRequestId() { return _requestId; }


#3

Dear Joe-san,

Yes, exactly!

Then I can get requestId of my set/getAttribute
and use it to confirm that particular request has been taken care of.

BTW, I noticed that although I could establish sequence like
(1) setAttribute and get requestId1
(2) find particular requestId1 from updateNotify and verify the data is correct
(3) To double confirm the data, call getAttribute and get requestId2
(4) the value returned for requestId2 also agrees the original data
Then I noticed that this sequence can take place
even without link/connection to the cloud.

So I suppose ASR(modulo) is returning ack and data
from its internal memory instead of downloaded/confirmed cloud data.
Am I correct?

Then would you teach me what is the recommended method
to confirm that my “setAttribute” request was really granted
by the cloud?

Best Regards,
29-Nov-2017
moto