Feature request.. a way to disable thermostat command(s) that yours doesnt support in device panel

📢 Feedback Feature Requests
1

I cannot find a way to limit the commands that show up when you enable capability thermostat in a driver..

For instance, many do not have or support emergency heat but a command always still comes out and therefore you should then code somthing that says in the logs: not supported when someone pushes it innevitably.

Thanks

1 Like
2

The entire point of a capability is that apps can expect to use all of the commands and attributes that come along with it. If it doesn't make sense to support them all, then either:

  1. You should either not implement the capability; or
  2. You should do exactly as you suggest and log something about how that command is not supported (with this second option being reserved for rare cases where the first makes less sense).

Therefore:

This is an intentional part of the hub design.

1 Like
3

Don't agree . In m opinion stupid to require and have a command on the screen that probably 80% of those devices don't support. Look at most gas or oil furnaces . They dont have it.

And it doesnt appear on any.therm manuf. Apps or.therms when your system doesnt support it

4

Probably because these manufacturer- and device-specific mobile apps do not attempt to generalize device functionality to support a possibly-wide variety of real-word devices like the capability model on the hub does (which abstracts specific device details into standard commands and attributes that any app can expect to use). For example, can they work with other manufacturers' devices?

I'm not sure with what; my statement above was not an opinion but rather factual representation of how this model works. If you want it to work differently, that is unlikely to happen for the above reasons (what would a capability mean if apps have to expect required commands to not be there?). However, either of the two solutions above can provide an outcome that will not result in unhandled exceptions in Logs. The second is not unheard of, even in built-in drivers, even if it is uncommon in general.

You know, something like this. :slight_smile:

log.warn "Greetings, user! Your device does not support this, and I have no idea why you are trying."

5

I wouldn't have a problem with the capability broken up like the capabilities for button devices are into pushable, holdable and other button commands. The Thermostat capability commands could be broken up in a similar way, IMO... I'm not that invested personally, even though I have developed a thermostat driver myself.... but could see some benefit in clarity for what a driver / device offers. If the HE platform was able to them leverage this by not providing these options in the "real" front-end, being Apps / dashboards, then users who are not familiar with the setup of the HE hub and it's devices could get more appropriate feedback about what is possible, rather than needing to read through potential logs that may be generated.

The only ground I would concede is that some "platforms", like Mitsubishi, utilise the one interface / API for all their systems, so, unless you develop a separate driver for each possible combination of capabilities available, where some modes may be options for the same system, it could become difficult....

So I guess I'll need to get comfortable on this fence.... :wink:

6

You can hide the option from appearing on your dashboard using CSS. I currently do that with my own setup.

Ex. code:

#tile-xx .shadow-md:nth-of-type(4) {display:none}

Note - you can also use the div> class, but I've found that .shadow-md is common to at least thermostat and fan device popups.

7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.