Closed vshymanskyy closed 6 years ago
I also discovered this issue in BLE mode on ESP32 and in fact, this is good behaviour: it is always caused by the fact that not enough parameters have been received. When working with BLE and ZeRGBa in merge mode, not all 3 parameters are always being received, sometimes only 2. In that case the param[2].asInt() will result in the usage of a NULL pointer, in which case the chip stops working. I solved it by doing following check:
BLYNK_WRITE(V0) { BlynkParam::iterator param0 = param[0]; BlynkParam::iterator param1 = param[1]; BlynkParam::iterator param2 = param[2];
if (!param0.isValid() || !param1.isValid() || !param2.isValid()) { return; }
int r = param0.asInt(); int g = param1.asInt(); int b = param2.asInt();
// ...
}
If the origin of the problem is in fact a) missing bytes in BLE data transfer b) bad parameter transmission from Android app is not clear to me: the byte describing the length of the data following always seems to be consistent with the data following. In other words, it seems that the app only transmitted 2 instead of 3 parameters. But I didn't test it really well to be sure about this. In fact, my opinion is that in the receiver software (ESP32) one should check if all parameters are being received correctly, as the Blynk protocol on BLE doesn't guarantee correct transmission.
So, following actions are possible, or a combination, a) change the blynk library so that param[N] with N>=nr of transmitted parameters doesn't result in a crash b) instruct (e.g. in the example files) to do parameter check in all BLYNK_WRITE functions c) change the blynk tranmission protocol in direct mode by adding sync and crc bytes ?d) make sure that always all parameters are included in Android app
So, I think the library doesn't crash in the [] operator, but in the functions asInt, asLong, asDouble & asFloat of the class BlynkParam because there is no NULL-pointer check before calling atoi, atol and atof.
should be fixed on master
when N > what server has sent...