I have no idea what you are referring to as the link is not working. The need to define the type and the name of the data being read is necessary, so if it's not here it will be somewhere else, that we can't escape. Exporting that to different files won't serve a purpose and will only increase complexity as when debugging you will need to reference a separate file. For the defs it made sense as they are used multiple places, but what a message contains is a single use place, so storing it separately is meaningless as it won't have any use outside of this single function.
Should there be any constraints to setting these request flags to TRUE? What if drain request is still in progress for example? Shouldn't drain finish before fill starts? This wouldn't be an issue if we combined the 3 state machines.
Facing build errors. Please check if DD staging builds with your branch. Also, please add these to the sheet MSG_ID_DD_TREATMENT_PARAMS_OVERRIDE_REQUEST MSG_ID_DD_UF_DATA_PUBLISH_OVERRIDE_REQUEST
Yes, they are aliases that are used for example in Dialin's temperature sensor module to decide which msg id to use for the override. Updating an alias's value when adding new entries to the enum is easier then changing the last or first sensor type across Dialin modules, which could be forgotten or missed.
This state machine running continuously. fill request is initiated for every 1 minutes of balancing chamber exec (since right now level sensor is not working )
//Increment counter for dry bicarb chamber fill bicarbChamberPeriodicFillCounter += 1; // Fill bicarb chamber once every 60secs. if ( bicarbChamberPeriodicFillCounter >= BICARB_CHAMBER_PERIODIC_FILL_TIME )
