Correct Reqest Class memory allocation, Improve _sleep_time read-write to EEPROM

[Akubi]

Change « Request Class » memory allocation, issue #214

• Add buffer « char _value[MAX_PAYLOAD+1] » to keep request data
• Buffer size is to prevent buffer overrun

Improve _sleep_time read-write to EEPROM, issue #215

• _sleep_time is a long value and bust be split into bytes in order to be saved to EEPROM
• Use union structure to achieve this
• Only 3 bytes are saved to EEPROM

[user2684]

Thanks for the great contribution! I do wonder how we can handle a user migrating to this version since _loadConfig() is called at the beginning and if something is already in the EEPROM the calculated sleep time would be different. I think we have two options: 1) using a different EEPROM slot to save this setting so to avoid conflicts (and optionally migrating an old value if any) 2) adding a warning to the release notes about the lack of compatibility.
I'd go for this latter option, what's your thought?

[Akubi]

My opinion, for the moment:

• You can commit this modification, but is not correcting the PERSIST functionality
• Add a warning to the release note to inform that PERSIST is under construction

In any case, I’m not sure someone use it.

I just correct the 2 methods _loadConfig and _saveConfig.
Of course no more compatible.

The PERSIST behaviors must be modified in the future.

• _sleep_time is a long (4bytes) and only 3 byte are saved
• Service function [3] [4] [5][29] use getValueInt(), can be dangerous
• After startup _loadConfig() call, _status is not updated (still AWAKE)
• If service function [3] [4] [5][29] try to set _sleep_time to 0, nothing is send to EEPROM
• EEPROM_SLEEP_SAVED is never reset to 0

So the _loadConfig and _saveConfig are correctly codes to store 3 bytes, but I believe the PERSIST function must be revised

[Akubi]

Hi,
Do you prefer I change the PR and remove the issue #215 part ?
That can be part of a different PR.

[user2684]

Sorry for the huge delay. I'd split the two if you don't mind so I can start merging this one straight away.
I've also created this issue #222 so we will not forget to re-think PERSIST entirely.
Thanks again!

[Akubi]

Hi, no problem for the "delay". We all have a lot of activities.
Yes, of course, you can splitt.
Thank

[user2684]

Great. If you don't mind applying the changes directly in your branch I think will be quicker, otherwise I have to submit a PR against your repository, you have to merge and I have to merge back into this one :) Thanks!

[Akubi]

PR closed and replaced by PR #225