You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two related enhancements (may only implement one at a time):
Currently flashing a new version of the software to the microcontroller will cause the currentTemperatureSource to be forgotten (because preferences are assumed invalid between versions to prevent conflicts). This could be fixed by checking to see if what we think is the old currentTemperatureSource preference is still a valid choice, and if so just rolling with it. More complicatedly, we could add a preferences version somewhere reliable and only invalidate preferences if this number changes, but this is a less ideal solution as it adds extra logic and would reset the currentTemperatureSource selection more often than the former solution. Prefer first solution unless lots of other preferences start cropping up.
Right now if the currentTemperatureSource doesn't report a value after 7min, we switch back to the internal source (but automatically revert to the currentTemperatureSource once it sends a value again. If a thermostat is connected, we may want to fall back to the thermostat instead of the internal source (as it's more likely to have a good room temperature), but then we need to handle what happens if we haven't heard from the thermostat in too long as well).
The text was updated successfully, but these errors were encountered:
Both of these can be resolved via Home Assistant automations that check for and set the selected temperature source, and only an issue when flashing new code, so probably low priority
A deceptively simple option: defaultTemperatureSource.
Perhaps even make it a list so it can be prioritized? Might be good for "try the room sensor for Room A, then Room B, then the thermostat, then internal."
Two related enhancements (may only implement one at a time):
currentTemperatureSource
to be forgotten (because preferences are assumed invalid between versions to prevent conflicts). This could be fixed by checking to see if what we think is the oldcurrentTemperatureSource
preference is still a valid choice, and if so just rolling with it. More complicatedly, we could add a preferences version somewhere reliable and only invalidate preferences if this number changes, but this is a less ideal solution as it adds extra logic and would reset the currentTemperatureSource selection more often than the former solution. Prefer first solution unless lots of other preferences start cropping up.The text was updated successfully, but these errors were encountered: