Provision commands, are they removed from the custom builds?
chemmex opened this issue · 23 comments
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
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.
Tried that, didn't help
I am on ESP32-C3 now
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
Yes, I have that enabled as per template
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 😉
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.
Thanks, will try this now
Nope, still
83791: HTTP: ProvisionConfig
83792: Command unknown: ProvisionConfig
Sorry, my bad, just realized that used the old syntax
118837: HTTP: provision,rules,1
119320: downloadFile: rules1.txt Success
Ah, yes, the fall-back for the old syntax is only included in the MAX builds... 😊
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
That's a security measure, to prevent accidental overwriting of your configuration
Documentation on Provisioning
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
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
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)
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
Yes, I think it should be done in a more relaxed state
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
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
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)
No, that's ESP32-C3