search

HestiaPi / hestia-touch-one-ui

ONE UI files shown on the touch LCD
GNU General Public License v3.0
5 stars 7 forks source link

Does Auto need to be available to the user for Fan? #9

Closed gulliverrr closed 4 years ago

gulliverrr commented 4 years ago

Is there a reason you can even select "Auto" then? Auto should be forced by heating and cooling as needed. The user should only need to select between "On" and "Off".

Originally posted by @jaythomas in https://github.com/HestiaPi/hestia-touch-one-ui/pull/8

gulliverrr commented 4 years ago

What would be selected as active on OH UI while in Auto?

jaythomas commented 4 years ago

I don't think the fan's "Auto" necessarily needs to be removed from the OpenHAB UI if it is removed from the touch UI. The two UI's are independent. Although we're out of the scope of the OpenHAB UI's repo let's entertain some ideas and maybe move the issue to the correct repo if we derive some work to do from this discussion .

Having the fan's "Auto" selectable is useless but that's a side effect of how the OH UI is laid out. I'm not familiar enough with how customizable OH's UI is to allow for a better user experience, but something more clear to the user would be to combine all the buttons from each of the 3 modes into one array so you visually see only one thing can happen at a time:

[ Heat ] [ Cool ] [ Fan ] [ Off ]

versus the way it is now, you have the illusion that multiple things can be happening at once:

Screenshot from 2019-10-31 10-00-34

Surely you can't have heating and cooling running at the same time? And you shouldn't be able to turn off the fan while cooling is running or you freeze up your system.

Having the 4 buttons takes up less screen real estate too. For handling boost could have another row underneath that looks like: Boost [ Enabled ] [ Disabled ]

And make it invisible or grayed out if the active mode isn't heating or cooling.

gulliverrr commented 4 years ago

What would be selected as active on OH UI while in Auto?

That was my mental note for when I will deal with it.

versus the way it is now, you have the illusion that multiple things can be happening at once:

They can and it will be even more obvious with an update requested to have 2 separate setpoints shown for heating and cooling (below x start heating and above y start cooling) making sure that always y>x. So I believe we should not merge all in one array. I am also okay if you want to only change the Touch UI and leave an issue open on the OH UI repo.

gulliverrr commented 4 years ago

Fixed by #8 OH UI Issue created: https://github.com/HestiaPi/hestia-touch-openhab/issues/9