GATTTool discover characteristics no longer parses properly with 3.2.0

[andrew-gillan]

I recently upgraded from 3.0.0 to 3.2.0 and I could not subscribe to a characteristic any longer.

I traced the problem down to the parsing of the gatttool output when doing a characteristic discovery. The parsing somehow behaves differently between 3.0.0 and 3.2.0. Not all the characteristics are successfully extracted from the output.

I've gone back to 3.0.0 for now until this issue can be resolved.

See the attached for example of successful and unsuccessful parsing of the characteristics.

incorrect-parse.txt
correct-parse.txt

EDIT: corrected the version numbering

[H3Gouchan]

I recently upgraded from 2.0.0 to 2.2.0 and I could not subscribe to a characteristic any longer.

Perhaps you are talking about v3.2.0, are not you?
I encountered the same problem in that version.

I think that it is necessary to specify an appropriate 'maxread' parameter in the argument of pexpect.spawn().

What do you think?

--- pygatt/backends/gatttool/gatttool.py.orig   2017-10-02 16:14:29.642966730 +0900
+++ pygatt/backends/gatttool/gatttool.py        2017-10-02 16:16:20.285820133 +0900
@@ -256,7 +256,7 @@ class GATTToolBackend(BLEBackend):
         gatttool_cmd = ' '.join([arg for arg in args if arg])
         log.debug('gatttool_cmd=%s', gatttool_cmd)
         self._con = pexpect.spawn(gatttool_cmd, logfile=self._gatttool_logfile,
-                                  searchwindowsize=self._search_window_size)
+                                  searchwindowsize=self._search_window_size, maxread=120)
 
         # Wait for the interactive prompt
         self._con.expect(r'\[LE\]>', timeout=initialization_timeout)

[iduhetonas]

@Hiro-AK47 I tried this for version v3.2.0, and it appears to work better, but it's still not quite reliable. For my specific (and very similar problem), I attached the output from using the gatttool -I directly, to be compared to the output from the debug logger, after running a search for the characteristics using pygatt.

Note that the incorrect output has two attempts, where some characteristics were missing each time.

correct_output.txt
incorrect_output.txt

[andrew-gillan]

@Hiro-AK47 yes, I did mean 3.2.0. Thanks for catching that! I'll edit the description with the proper version numbering.

[andrew-gillan]

@Hiro-AK47 I think you on to something with specifying the pexpect window size. The commit added a default max read size of 200.

b2777f3

Perhaps this change did not help us as intended. I will did more on this when I get a chance.

[joh06937]

This is happening to me as well. Updated from 3.1.1 to 3.2.0 and suddenly I can no longer find all of the characteristics I need to. Playing around with things, I noticed the list of characteristics would sometimes be longer, indicating (like mentioned above) something related to a timeout.

I did a quick-and-dirty diff between 3.1.1 and 3.2.0 and also saw the "search_window_size" change in there. Not sure if that's it though :-D

[IlyaSukhanov]

@andrew-gillan is referring to PR #123. I also encountered this issue added some details in the previously closed PR.

[IlyaSukhanov]

Setting maxread=200 helps but still fails (<5% rate). Obviously with default of 2000 pygatt can be in situation where it discards 90% of the data it intends to look at.

I don't think default value of searchwindowsize should be set, and if pygatt allows setting of it it should also let user set maxread tuning one without the other is bound to lead to problems.

[darkrift]

@IlyaSukhanov

I have a device which has quite alot of characteristics, and with 200 as maxread, it only discovered 2 of them. Setting searchwindowsize to None without trying all the changes for maxread did fix it for me.

pygatt.txt
gatttool.txt

Thank !

[FlurinArner]

Thanks @IlyaSukhanov for bringing this issue back to my attention. I had previously seen it, and had tried out some maxread settings, but wasn't initially been able to solve my problems.

I can confirm that for my observations in #161, setting search_window_size=None in 3.2.0 (like @darkrift proposed) solved it.

[Hodapp87]

Running into this too on 3.2.0. 3.1.1 solves it.

[HansBouwmeester]

Ran into this as well. 48 out of 52 characteristics were dropped.
Also for me, using v3.1.1 fixed it.

[peplin]

#156 landed in v4.0 and should fix this problem. Thanks for the report and the PR!