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)
- <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.
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:
- I have already updated the
for-v3.3 branch with all the recent
changes from v3.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.
- After release of that, we
branch off master to a v3.2 branch, for
historical purposes (and if we need it
for anything).
- 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