Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remember / fallback for currentTemperatureSource #17

Open
Sammy1Am opened this issue Apr 2, 2024 · 4 comments
Open

Remember / fallback for currentTemperatureSource #17

Sammy1Am opened this issue Apr 2, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@Sammy1Am
Copy link

Sammy1Am commented Apr 2, 2024

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).
@Sammy1Am Sammy1Am added the enhancement New feature or request label Apr 2, 2024
@Sammy1Am
Copy link
Author

Sammy1Am commented Apr 2, 2024

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

@KazWolfe
Copy link
Collaborator

KazWolfe commented Apr 2, 2024

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."

@sle118
Copy link

sle118 commented Apr 6, 2024

@KazWolfe you have my vote on this one.

@Sammy1Am Sammy1Am transferred this issue from Sammy1Am/mitsubishi-uart May 12, 2024
@Sammy1Am Sammy1Am transferred this issue from another repository May 12, 2024
@sle118
Copy link

sle118 commented Nov 29, 2024

I would like to bump this one, as I think it has some importance.

What happens if we source the temperature from a home assistant sensor, and the home assistant instance is down for an extended period of time? In my case, I would want to fallback on the thermostat, but others may prefer the internal sensor.

When home assistant is back up, then the "preferred" sensors should be used.

So I guess I'm proposing a fallback/fail safe temperature sensor which could be internal, thermostat or perhaps a thermal sensor mounted on the esp directly

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants