Real-time data with makeWebRequest (-101, -2 errors)

I've made an app that streams heartrate in real time, however I'm running into the -101 and -2 errors as have many in the past.

My App only ever has 1 webRequest outstanding, if the request comes back with anything other than a 200 it starts backing off, however this doesn't help.

I have a vivoactive 3, and sometimes it works for hours, sometimes minutes. I have a friend with a Forerunner 245 Music and it's much more reliable though sometimes does a similar thing.

I'm looked to all the previous forum posts and I think I've done everything recommended, but the issue persists, at least for me.

Any suggestions or is this a limitation of the hardware/ API?

function initialize() {
        Sensor.setEnabledSensors([Sensor.SENSOR_HEARTRATE]);
        Sensor.enableSensorEvents(method(:onSensor));
        View.initialize();
    }
    
    function onSensor(sensorInfo) {
    	if (!pending) {
	    	hr = sensorInfo.heartRate;
    		if (!backoff) {

		    	var url = "https://real.ssl.site/page";
		    	var params = {
		    		"hr" => hr
		    	};
		    	var opts = {
		    		:method => Communications.HTTP_REQUEST_METHOD_POST,
		    		:headers => {
		    			"Content-Type" => Communications.REQUEST_CONTENT_TYPE_URL_ENCODED},
		    		:responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_JSON
		    	};
		    	Communications.makeWebRequest(url, params, opts, method(:onResponse));
		    	if (hr == null) {
		    		hr = "";
		    	}
		    } else {
		    	backoff--;
		    }
	    	WatchUi.requestUpdate();
    	}
    }
    
    function onResponse(responseCode, responseData)
    {
    	if (responseCode == 200) {
    		backoff = 0;
    		prev_backoff = 0;
    	} else {
    		prev_backoff++;
    		backoff = prev_backoff;
    	}
    	pending = false; //Implement backoff for 101 errors?
    }

  • The BLE_HOST_TIMEOUT (-2) can happen based on the connection to the phone, or the phone's data connection.  For example I'll see it if the makeWebRequest was made but I'll walk out of BT range before there's a response.  The range can vary based on watch, phone, obstructions, etc.

    With the BLE_QUEUE_FULL (-101)  - not sure how your backoff is actually used, but with pending, it looks like you are trying to limit things to one active request at a time,  While you check if(!pending) before making the request, I think your missing

    pending=true;

    after you make the request to stop further requests until you get a response from the active one.  Pending is always false in this code.

  • Oh damn, I can't believe I missed that, will implement and check again, thanks!

  • I just have the -2 error code now, I'm getting notifications from the phone, and live heart rate appears in GMC. Is there anything I can do about that one?

  • -2 error is old classic. I don't think you can still recover within the app when this happens without forcing users to manually restart bluetooth or app or leave from the BT range between watch and smartphone and go back. Shame this wasn't handled after all these years, as lots of app use-cases are simply not possible to do because of that. 

  • When I see -2, it seems to be when I'm borderline on the BT range for the device, and it recovers when I'm within a good range.  If my phone is on the desk, a makeWebRequest occurs while I'm walking to the other side of the house.  When I'm back in the office, the next makeWebRequest goes fine. (I've never had to reset the app or the phone)

    I've been doing some testing with some apps that use CIQ BLE to a Raspberry Pi, and the BT range does vary between devices.  In one case I have to be in the same room as the Pi, and another, I can be a good ways away.

  • We are of course talking about getting into this issue without leaving BT range... 

  • And it could also be that the phone's data connection is borderline, the server is running slow, etc.

    I've not tested it specifically, but I'm thinking a -2 could occur with my phone in my pocket but I'm in a tunnel or something where cell coverage isn't that great.  

  • There is no issue with getting "first" -2 error. The main issue is that when this happen, app will get -2 for any future requests regardless the connectivity should be already working again. I remember that in the past, BT had to be restarted when this occurred (either via watch or phone) to make it work again. With my current tests it seems simple CIQ app restart is sufficient. Higher the transmitted data, higher change to run into this. When pushing watch sensors data during sleep to servers, you can't alert user to fiddle with the devices..

  • There was a bug that was fixed years ago where the FW was using a 32 bit sequence count while BLE was using a 16 bit counter.  So the first 65535 (up to 0xffff) requests worked fine, but starting with the 65536th (starting with 0x10000 in 32 bits) request, everything would get a -2.

    That's been fixed though.

  • I did tests every night past week to try to find a way whether I can continuously output raw accelerometer (no compression) data from CIQ app to HTTP API. I used Vivoactive3 as it showed as most prone to stuck on -2 error. 
    It "survived" during whole night only in case app was sending only 1Hz of accelerometer data and it didn't depend if http request was done every second or for example every 5s with merged data. 
    On all other cases (>4Hz sample rate) ciq app was in the morning found stucked on -2 error and actual time of first error varied depends on number of data continuously transmitted.. 

    Conclusion: even such basic use-case can't be implemented reliably, therefore it is not possible to do - and I just dissapointed another client eager to have their health-care solution using Garmin devices long time after commiting to work on the project (because who would know..). Rolling eyes