Queue commands

Could you write a bit how the queue command works?

Queueing commands, so you can don’t have to wait anymore for the completion of a command before issueing the next command

For example if I send following commands to the Bluetooth device:

writeCharacteristic(A)
writeCharacteristic(B)
setNotify(XYZ)
writeCharacteristic(C)

then I assume all commands are queued executed on each success? Case A: invoke write A -> successful written A -> invoke write B -> successful written B -> set notfiy XYZ -> succesful notfied XYZ -> invoke write C -> successful written C

or are they only queued invoked but not wait for a successful completion? Case B: invoke write A -> invoke write B ->set notfiy XYZ -> invoke write C-> successful written B -> successful written A -> succesful notfied XYZ -> successful written C

For my program I need the case A but I think you implemented case B, am I right?

[weliem]

Ok, that looks ok. You can also very clearly see here that ‘Case A’ is implemented…

BLESSED doesn’t add any delay to commands. Once one command is completed, the next one is executed immediately without any delay. This should not be any problem in normal case. If there is a device that really needs a delay, then the delay is always needed and not sometimes. In other words, if your Yunmai scale is working fine and the other isn’t then it is very unlikely that adding delays would solve anything.

I see a number of potential causes for the issue that was logged for OpenScale:

• The scale is out of battery and hence behaving erratic. I have seen this happen many times. So replace batteries with new ones and see if the problems persist.
• The scale is a ‘bad state’. Factory resetting it or pulling the batteries briefly may solve the issue.
• The Bluetooth stack on the phone is messed up. Reboot your phone and try again.

There is one more possibility and that it is a threading issue. I recently pushed a commit to fix a potential threading issue that could block the queue. It will be included in the next release but I think it is very unlikely that this is causing the issue. I never saw the threading issue in practice and only noticed it when doing code reviews.

[weliem]

Ok, I see from the issue that there doesn’t seem to be queue issue anymore. So closing this issue…

I will think about how to extend the list of callbacks so that you can do more logging and get back to you…