cleanup storage, variables and more #515
Conversation
no need to stay compatible to old storage structure, remove reserved or freetouse rename a lot of vars deleted missed coldstart stuff set PID Mode based on pidPonmOn for regular and brew pid d
| .minValue = BREW_SETPOINT_MIN, | ||
| .maxValue = BREW_SETPOINT_MAX, | ||
| .ptr = (void*)&brewSetpoint}; | ||
| editableVars["TEMP"] = { |
There was a problem hiding this comment.
why are some blocks formatted like before (e.g. for PID_PONM_ON above) and some like this inline? Not sure if this still needs to be auto-formatted
There was a problem hiding this comment.
i have no clue why this happens, but this is already formated. maybe @simonspa has an idea for it
There was a problem hiding this comment.
I think if the entire thing fits into the total line length defined, it will not be broken up, and otherwise aligned.
There was a problem hiding this comment.
If so then the line length might be configured to be too long? 220 chars usually doesn't fit on screens ;)
There was a problem hiding this comment.
There was someone who wanted it so long, but it doesn't fit on my screen. (4k, only vsc with one side bar).
So I'm fine to break the line earlier.
Reading and editing the editiblevars isn't fun like that.
There was a problem hiding this comment.
Well, just "someone" shouldn't define the line lengths for the whole project ;) A more modern number might be 100 or 120, more traditional ones are 88.
There was a problem hiding this comment.
80, for traditionalists. (Not counting the no-longer-common line numbers, which could leave you with 72.)
There was a problem hiding this comment.
hmm 120 does destroy the layout quit a lot, but formats all editibleVars as we want.
200 is still fine for my screen, editibleVars are still fine, but produce still some mess on other parts
| @@ -66,97 +61,68 @@ typedef enum { | |||
|
|
|||
| // storage data structure | |||
| typedef struct __attribute__((packed)) { | |||
| // Any 'freeToUse' areas ensure the compatibility to origin EEPROM layout and can be used by new value. | |||
There was a problem hiding this comment.
Changing all this means that saved configurations will not work when updating firmware and Erase Flash needs to be used, correct?
There was a problem hiding this comment.
yes right.
i did talked about a 4.0 release with fiendie. There is the idea of postpone the new storage/config system to a 4.1 release.
If so, i would move this PR also to a 4.1 release, so there is only one point where all users have to do a flash erase and not two times.
maybe i should take all cleanup stuff into its own PR and wait with the storage.
no need to stay compatible to old storage structure anymore -> remove reserved or freetouse
rename a lot of vars to be consistent and follow camelcase
deleted unused coldstart stuff
set PID Mode based on pidPonmOn for regular and brew pid
remove HA Discovery defaults for sensor objects. sensor types are too different than any default type would make sense
to test this PR, esp has to be erased before flash