Provision commands, are they removed from the custom builds?

[chemmex]

Just found a time to test provisioning in its current state, but seems that all Provision commands are not recognized.

Have FEATURE_SETTINGS_ARCHIVE and DEFAULT_PROVISIONING_URL defined in the Config.h, no more visible related settings

Can retreive the settings from the GUI, though

[tonhuisman]

You can add #define FEATURE_CUSTOM_PROVISIONING 1 to your Custom.h file to have that enabled, it was removed from the Custom builds for bin-size reasons, AFAIR.

[chemmex]

Tried that, didn't help

I am on ESP32-C3 now

[tonhuisman]

The current Custom-sample.h mentions that also FEATURE_SETTINGS_ARCHIVE must be enabled (defined to be 1) for this to work, so adding #define FEATURE_SETTINGS_ARCHIVE 1 should fix that

[chemmex]

Yes, I have that enabled as per template

[tonhuisman]

Ah, it seems that you get LIMIT_BUILD_SIZE for free with a Custom build, but that turns off the Provisioning options.
You can add #define NO_LIMIT_BUILD_SIZE to get rid of that 😉

[TD-er]

Hmm sounds like we should add some proper checks in the define_plugin_sets.h file.
When someone explicitly defines to enable this provisioning feature, all dependencies should be enabled too.

N.B. there still should be a check that it can really only be included in a custom build (and thus not in a MAX build) or else we introduce a backdoor people may not be aware of.

[chemmex]

Thanks, will try this now

[chemmex]

Nope, still

83791: HTTP: ProvisionConfig
83792: Command unknown: ProvisionConfig

[chemmex]

Sorry, my bad, just realized that used the old syntax

118837: HTTP: provision,rules,1
119320: downloadFile: rules1.txt Success

[tonhuisman]

Ah, yes, the fall-back for the old syntax is only included in the MAX builds... 😊

[chemmex]

There is another confusion, though
Even if I have all file types checked in Allow Fetch by Command section, it downloads only those checked in the Files to Download section

[tonhuisman]

That's a security measure, to prevent accidental overwriting of your configuration

[tonhuisman]

Documentation on Provisioning

[chemmex]

Yes, just read it fully. Not completely intuitive, but should work as a security measure at least once :)

Actually, I am not going to use it on a production scale at least until encryption is ready

[chemmex]

And firmware downloading seems too sensitive either for network delays or loop load, I got timeout on 5 out of 6 attempts without ProvisionFirmware#Failed event

79675: EVENT: updatefirmware=20240117.bin
79726: ACT : Provision,firmware,20240117.bin
79734: CRC : ProvisioningSettings CRC ...OK
80130: HTTP : DownloadFile ota.xxx.yyy80 GETHTTP code: 200
80132: EVENT: http#ota.xxx.yyy=200
91743: Timeout: 20240117.bin

[tonhuisman]

Ah, I guess there's a little bit too much code there, it never gets to generating that event on a time-out... 🤔 (or a write-error, for the same reason)

[TD-er]

I have tested it on a few modules which were about 1000 km away, so definitely not "local".
Sometimes I got these timeouts, but also on local flashes via the browser.
Disabling some intensive tasks (not calling save) may help here

[chemmex]

Yes, I think it should be done in a more relaxed state

[chemmex]

Concluding this session, for custom builds:

#define NO_LIMIT_BUILD_SIZE is not required while

#define FEATURE_SETTINGS_ARCHIVE 1 and
#define FEATURE_CUSTOM_PROVISIONING 1 are necessary

[TD-er]

@chemmex Did you test the commit I linked?
It is now merged in the 'mega' branch.

[chemmex]

Yes, just have tested that
That's what the log looks like now:

unsuccsessful 404 FW update attempt

00:36:38.412 : (194140) Info   : EVENT: updatefirmware=20240118.bin
00:36:38.432 : (193964) Info   : ACT  : Provision,firmware,20240118.bin
00:36:38.452 : (193236) Info   : CRC  : ProvisioningSettings CRC   ...OK
00:36:38.563 : (189524) Error  : HTTP : DownloadFile ota.bb.cc:80 GETfailed HTTP code: 404
00:36:38.565 : (189988) Error  : HTTP code: 404 http://ota.bb.cc/files/20240118.bin
00:36:38.572 : (193260) Info   : EVENT: http#ota.bb.cc=404

unsuccessful due to timeout

00:01:01.264 : (200316) Info   : EVENT: updatefirmware=20240119.bin
00:01:01.288 : (200136) Info   : ACT  : Provision,firmware,20240119.bin
00:01:01.309 : (199588) Info   : CRC  : ProvisioningSettings CRC   ...OK
00:02:01.693 : (194764) Error  : HTTP : DownloadFile ota.bb.cc:80 GETfailed HTTP code: -11 read Timeout
00:02:01.696 : (194700) Error  : HTTP code: -11 http://ota.bb.cc/files/20240119.bin
00:02:01.705 : (195968) Info   : EVENT: http#ota.bb.cc=-11

successful

00:36:59.164 : (193972) Info   : EVENT: updatefirmware=20240119.bin
00:36:59.184 : (193312) Info   : ACT  : Provision,firmware,20240119.bin
00:36:59.197 : (193236) Info   : CRC  : ProvisioningSettings CRC   ...OK
00:36:59.310 : (184816) Info   : HTTP : DownloadFile ota.bb.cc:80 GETHTTP code: 200
00:36:59.314 : (180792) Info   : EVENT: http#ota.bb.cc=200
00:37:17.539 : (187868) Info   : downloadFile: 20240119.bin Success
00:37:17.668 : (192768) Info   : EVENT: ProvisionFirmware#success=20240119.bin
00:37:17.688 : (193296) Info   : ACT  : Reboot

It looks like only ProvisionFirmware#success event is generated, in all failure cases it goes silently.

By the way, there is minor inconsistency between text and example in the docs:
in the text:
ProvisionFirmware#Failed=<FirmwareBinary.bin> When something went wrong during download or install
and in the rules example:
On provisionfirmware#failure Do

[TD-er]

Ah good catch about the discrepancy between docs and actual failure event.
That needs to be fixed for sure (and not in the docs :) )

Are you testing this on ESP8266? I thought I had the logs showing the strings for those errors. (at least on ESP32)

[chemmex]

No, that's ESP32-C3