Reset Configuration Settings After F/W Update

[Martinski4GitHub]

Modified code to properly reset some configuration settings after a F/W Update has been successfully completed, followed by a router reboot. This way, we have a "cleaner" starting point for the next F/W update.

[Martinski4GitHub]

@ExtremeFiretop,

This PR contains my proposed solution for resetting the specific config settings after the F/W Update is completed.
Essentially, I created separate routines to set up and later check the post-reboot F/W Update status so that it's no longer dependent on the user enabling email notifications. Then, at the appropriate time and conditions, the config settings are reset.

Note that the FW_New_Update_Notification_Date variable is not reset because I like having the time/date stamp of the last notification - it can be a useful piece of data.

Please review and test whenever you get a chance. I tested as much as I could on my test router, but I need your "2nd pair of eyes," and you have different models and use Gnuton F/W, so you can test the new code and put more mileage on it.

Thanks, bud. Talk to you tomorrow evening. I have an Engineering meeting tomorrow morning, so I'm going to bed early tonight.

[ExtremeFiretop]

@Martinski4GitHub

Sorry for the delay buddy. I reviewed the code while on my 1 hour of lunch today.

Everything so far looks logical, but I haven't actually tested anything yet. So my job of putting milage on it isn't complete.

I'll have more time tomorrow to check it out. Hope you had a good Easter buddy and a productive engineering meeting.

Chat more tomorrow!

[Martinski4GitHub]

@Martinski4GitHub

Sorry for the delay buddy. I reviewed the code while on my 1 hour of lunch today.

Everything so far looks logical, but I haven't actually tested anything yet. So my job of putting milage on it isn't complete.

Ah, no worries. Take your time to review and validate the solution. There's no rush to get this done, so don't sweat it.

I'll have more time tomorrow to check it out. Hope you had a good Easter buddy and a productive engineering meeting.

Chat more tomorrow!

Our Easter weekend was uneventful, calm, peaceful, and enjoyable - just as we like it.
Work continues as usual. Our 1st major release for the year is scheduled for this month, so we'll be busy.

Enjoy the rest of the week, bud. We'll talk more when we can.

[ExtremeFiretop]

@Martinski4GitHub

Tested this on both my primary router and my secondary node running Merlin, since there was some alpha builds available to flash.

So far everything appears to work exactly as expected. It reset the values and sent me my emails after flashing.
I will say I prefer this method of having the post F/W update setup be done in it's own function: Do_PostReboot_FWUpdate_Setup

Instead of relying on the email function: SendEMailNotification POST_REBOOT_FW_UPDATE_SETUP
As we previously did. It previously was not as intuitive and would confuse someone unless you knew what it was supposed to be doing.

Just looking over it as a quick glance you would think it's sending an email previously, when it really was never sending an email and was doing the setup instead.

So this just makes more logical sense to me. Approved, merged and tested!

[ExtremeFiretop]

Oh and I also forgot to mention I agreed with the choice to keep the notification date.

And also I agree with the choice to reset the expected run date, the firmware notification version, and the changelogs approval. 👍

[Martinski4GitHub]

@Martinski4GitHub

Tested this on both my primary router and my secondary node running Merlin, since there was some alpha builds available to flash.

Thank you for taking the time to validate and put more mileage on the solution.

So far everything appears to work exactly as expected. It reset the values and sent me my emails after flashing. I will say I prefer this method of having the post F/W update setup be done in it's own function: Do_PostReboot_FWUpdate_Setup

Instead of relying on the email function: SendEMailNotification POST_REBOOT_FW_UPDATE_SETUP As we previously did. It previously was not as intuitive and would confuse someone unless you knew what it was supposed to be doing.

Just looking over it as a quick glance you would think it's sending an email previously, when it really was never sending an email and was doing the setup instead.

So this just makes more logic sense to me. Approved, merged and tested!

Yeah, when I thought more carefully about the situation, I realized that creating separate functions would be the best solution to detach the email notification option from the actual post-reboot setup and check.

This reminds me of a saying we have in S/W Engineering: "Software is never done; it must keep evolving."

Speaking of that, I have another PR that I'll submit shortly about some messaging improvements.