questions for future release ?

[stef-ladefense]

Hi,

Thank you for your library, it is very good, and is much more flexible than my homemade solution. I was wondering things I have several ESP modules that do (again with my update code) automatic updates when I release a new version. There are identical modules, and variants, which may have slightly different hardware, in which case the bin is of course compiled accordingly. But they share the same source, it's just #define that changes the code. Is it possible to have a single json file that would contain multiple configs? instead of having a json/bin pair for each variant.

Steph

[mikalhart]

@stef-ladefense Thank you for your comment. Yes, I need to make it clearer in the README, but the library is indeed designed to support multiple Configurations in the same .json.

Let's say you had one device that ran using the "ESP32 Device Module" board profile. You might choose to create a Configuration block with

{
  "Configurations": [
    {
      "Board": "ESP32_DEV",
      ...
    }
  ]
}

If your other device is, say, ESP32 S3 Dev Module, you could make a second block with

{
  "Configurations": [
    {
      "Board": "ESP32S3_DEV",
      ...
    }
  ]
}

If you have two variants using the same Board, then perhaps that's when you'd define "Config" strings, e.g

      "Config": "16MB with PIR sensor",

or

      "Config": "4MB with no sensor",

The library simply uses the first Configuration block it comes to that fully matches.

Clear?

[mikalhart]

@stef-ladefense, May I ask... what tools do you use for your automated builds? I, too, would like to be able to make a small change to a sketch, then automatically recompile (and post?) the 10 different binaries for all the various devices it runs on.

Thanks!

M

[stef-ladefense]

hi @mikalhart

i tested 2 config in one json

{
  "Configurations": [
    {
      "Board": "LOLIN_S2_MINI",
      "Version": "1.0.1",
      "Config": "CO2_S8",
      "URL": "http://........free.fr/testweb.ino.lolin_s2_mini.bin"
    }
  ]
}

{
  "Configurations": [
    {
      "Board": "LOLIN_S2_MINI",
      "Version": "1.0.1",
      "Config": "CO2_S4",
      "URL": "http://.......free.fr/testweb.ino.lolin_s2_mini.bin"
    }
  ]
}

but only first work, second : CheckForOTAUpdate returned -2 (No profile matches)

[stef-ladefense]

@stef-ladefense, May I ask... what tools do you use for your automated builds? I, too, would like to be able to make a small change to a sketch, then automatically recompile (and post?) the 10 different binaries for all the various devices it runs on.

Thanks!

M

unfortunately it is not automatic. I use the preprocessor. for example, I have several CO2 detectors, the card is the same, an esp32s2, but the sensor is different, senseair S8, Sensirion SCD40 or 41, etc. so i have a party where i start a #define and I make blocks between #ifdef and #endif where it will be different.

it must be possible to automate, but I now only make a few modifications, it is often adaptation following an update of the core or a library of a routine that no longer works. the next will be the integration of your update routine.

[mikalhart]

@stef-ladefense Try this syntax:

{
  "Configurations": [
    {
      "Board": "LOLIN_S2_MINI",
      "Version": "1.0.1",
      "Config": "CO2_S8",
      "URL": "http://.......free.fr/testweb.ino.lolin_s2_mini.bin"
    },
    {
      "Board": "LOLIN_S2_MINI",
      "Version": "1.0.1",
      "Config": "CO2_S4",
      "URL": "http://.......free.fr/testweb.ino.lolin_s2_mini.bin"
    }
  ]
}

[stef-ladefense]

very good, work fine y a the best thank :)

[mikalhart]

Great!

[nseidle]

May I ask... what tools do you use for your automated builds? I, too, would like to be able to make a small change to a sketch, then automatically recompile (and post?) the 10 different binaries for all the various devices it runs on.

@mikalhart - Funny you should ask. We are using your lib inside our github action to compile our production firmware. While not exactly what you are looking for, we are compiling and posting different binaries (production vs beta release) to a binaries repo. To address the 4MB vs 16MB, we leverage a python based Firmware Uploader to ping the ESP32 for its flash size during prelim step, then use the appropriate partition binary when loading the new firmware. We don't do automatic build-on-push but it's trivial to implement that in the yml script.

Now, for those nuggets of (hopefully) helpful info, may I please request you do a new release so that I can stop maintaining a fork because GetVersion() is not in your release and is breaking our firmware builds? :)

[mikalhart]

Now, for those nuggets of (hopefully) helpful info, may I please request you do a new release so that I can stop maintaining a fork because GetVersion() is not in your release and is breaking our firmware builds? :)

@nseidle - Those nuggets were indeed golden: thank you very much! Re the release, would you be so kind as to check on your end if anything is amiss with what, from my end looks like a good release of ESP32-OTA-Pull? Yes, it's marked "pre-release" quality in Github, but the version that appears in the Arduino Library Manager as v 1.0.0 does have GetVersion().

[nseidle]

Never mind! I must be sleep deprived. It's working fine now.

[stef-ladefense]

hi @mikalhart ,

i test version for use with esp32 and esp8266. look this : https://github.com/stef-ladefense/ESP32-OTA-Pull/commit/de5912382b0bbcbc7e554a932e91edd729aaba19