Closed dev-strom closed 3 years ago
Sorry for the long delay on the reply.
Can you change that code snippet to the following and see what the values returned are? I see in some of the other iGrill code on github that they are adding pData[0] and pData[1]. I really only use my iGrill for smoking meat so havent had to read any temps > 255 so that might be why I never noticed the issue.
if(PROBE1_TEMPERATURE.equals(pBLERemoteCharacteristic->getUUID()))
{
if(pData[1] ==248) //This is the value set when probe is unplugged
{
IGRILLLOGGER(" ! Probe 1 Disconnected!", 2);
publishProbeTemp(1,-100); //We use -100 as the lowest supported temp via the probes is -58
}
else
{
IGRILLLOGGER(" * Probe 1 Temp: "+ String(pData[0]),2);
IGRILLLOGGER(" * pData[0]: "+ String(pData[0]),1);
IGRILLLOGGER(" * pData[1]: "+ String(pData[1]),1);
IGRILLLOGGER(" * Combined: "+ String(pData[0]+pData[1]),1);
publishProbeTemp(1,pData[0]);
}
For the battery value not reporting that sounds like the iGrill3 must be using a different BLE characteristic for the battery value than is used for the iGrill2.
Since I don't have an iGrill3 device I'll need to see if you can determine what characteristic is used for battery on the v3 devices. The easiest way to do that will be to
Once i have the correct UUIDs for the v3 device it should be a simple fix to get it to read and publish those values.
Hi, I think I fixed the temperature problem and others. I'll put a pull request later...
For the battery problem I took this screenshot as requested:
Looks good to me! The value 100% appeared after I pushed the download button.
I think the problem is, that it is at 100% and will only be published by the iGrillv3 if it changes. That wasn't the case during all my testings. The esp32 should initially read it during setup routine. Currently it only registers for notifications.
Thank you for contributing! I just finished testing and merged your PR!! (also listed you in the Contributions section in the README).
Yesterday I wonder why the temperatur stops growing at 254 °C and steps back at 2 °C. It's obviously a problem at the maximum of a byte at 255 or 0xFF.
So I found this in the code:
Here at
publishProbeTemp(1,pData[0]);
the range of pData[0] is only uint8_t or a byte. I'm not sure, what byte order is used by BLE, but I think pData[1] should be included in this value by some kind of bit shifting and the&
operator.btw: I'm using an iGrill v3 and did not see any battery level message over one hour of using it. Because @christiaaneggink had the same problem, I think there is another bug on v3 devises.