Add separate CONST_OVERLAY_NEXT_TIME_BLOCK to use CONST_OVERLAY_TADO_MODE for the actual TADO_MODE #71
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the const.py there is no overlay type/mode constant that is set to "TADO_MODE". However, this string is supported by the tado API, and if used as typeSkillBasedApp the overlay will remain until either the next time block is reached or the home state is changed.
At the moment the CONST_OVERLAY_TADO_MODE is set to "NEXT_TIME_BLOK". In contrast to the actual "TADO_MODE," this overlay remains until the time of the next time block arrives independently of the home state.
The two different types are reflected in the UI like this
TADO_MODE

NEXT_TIME_BLOCK

Therefore, I'd suggest that CONST_OVERLAY_TADO_MODE is now set to "TADO_MODE" and a new CONST_OVERLAY_NEXT_TIME_BLOCK is introduced. Since this is a breaking change for everyone using the previous definition of CONST_OVERLAY_TADO_MODE, it should be discussed how to proceed. However, using a const named this way might have caused unintended behavior in the past.