1mckenna/esp32_iGrill

Temperature overflow

dev-strom opened this issue · 3 comments

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:

static void notifyCallback(BLERemoteCharacteristic* pBLERemoteCharacteristic, uint8_t* pData,  size_t length,  bool isNotify)
{
  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);
      publishProbeTemp(1,pData[0]);
    }
    [...]
}

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.

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

  1. Install the Weber iGrill App and pair the device to the phone via the app
  2. Install the nrfConnect Android App
  3. Once in the App Click on the Bonded Tab
  4. You should see your iGrill3 listed, click Connect
  5. It should then go through discovery of the services
  6. In the listed services if its like the iGrillv2 you should see an entry for "Battery Service"
  7. Validate you can see the device battery level and if you can please attach a screenshot or type out the UUIDs shown for the service and the Battery Level
  8. Dont forget to unpair the iGrill device from your phone so you dont run into connectivity issues with the ESP32

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:

Screenshot_20210419-094444

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).