Mark, why not introduce this for v3.2 as well? If a v3.3 user accidentally installs a v3.2 build, that would not heal automatically but stick until manually fixed. I think it makes sense to have all builds automatically try to update to the best build available for the hardware in use. Am I missing somehing? Regards, Michael Am 19.11.21 um 02:44 schrieb Mark Webb-Johnson:
Regarding the 3.2.018, I will handle it this afternoon (my time).
Regarding OTA and support for rev3 ESP32, at the moment, the OTA URL is composed of:
* <server> (default api.openvehicles.com/firmware/ota <http://api.openvehicles.com/firmware/ota>) * <base> (either /v3.0/ or /v3.1/ depending on CONFIG_OVMS_HW_BASE_3_0 or CONFIG_OVMS_HW_BASE_3_1 * <tag> (default ‘main’) * /ovms3.ver
My suggestion is to add the hardware platform (as detected by the code that provides metric m.hardware) in there. Perhaps replace <base> with something that detects /v3.0/, /v3.1/, or /v3.3/ based on a combination of CONFIG_OVMS_HW_BASE and m.hardware ESP32 revision? We should probably just implement that in the v3.3 code, so v3.2 and before keep using CONFIG_OVMS_HW_BASE.
Regards, Mark.
On 19 Nov 2021, at 5:24 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Signed PGP part Sounds OK for me.
Regarding using the platform revision instead of CONFIG_OVMS_HW_BASE_3_x config: so in case someone accidentally installs the wrong firmware, the system would heal itself by a simple OTA update? Sounds good and should be a simple change.
Regards, Michael
Am 18.11.21 um 08:06 schrieb Mark Webb-Johnson:
We need to get the v3.3 release ready for release now, as the new v3.3 hardware is about to enter production and the factory needs the firmware.
Accordingly, I suggest:
1. I have already updated the for-v3.3 branch with all the recent changes from v3.2.
2. We now (today/tomorrow) release the current v3.2 branch as tag 3.2.018, OTA release. This would be the (hopefully) last v3.2 release.
3. After release of that, we branch off master to a v3.2 branch, for historical purposes (and if we need it for anything).
4. We then merge back for-v3.3 into the master branch and start working through the usual daily builds for that to get it ready for production. I think there is still some work to do on pouring the plugins, but the core code (and in particular new modem support) should be ok now.
I think we will need to investigate an approach for dual builds for v3.3-or-later and pre-v3.3 hardware, to take advantage of the new ESP32 rev3 chips. I think those will require a different sdkconfig. We can do that automatically in the OTA system, by building the URL based on the ESP32 platform revision. Should we do that with the v3.3 release (even if the builds are for the moment the same), or at a later date?
Regards, Mark.
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26