Makes absolute sense. I was originally thinking the driver would have an offset in the driver as a reading to get a more correct reading. At the same time like you mentioned, that wouldn't force the unit to continue operating when it thinks it already lower than 62.5.
Probably going to have to hack this. I'd try to put a piece of tape over the inbuilt sensor, but there is no opening. The sensor is probably inside the air intake stream. The manual also makes no mention of the sensor location.
Adding a wired thermostat to my unit made a big difference. It actually reads the room temp properly now. You can find model compatibility info here but once you figure out which thermostat model you need you can usually find them for cheaper on eBay.
Also, Midea makes a programmable version for all of their units. I ended up going with this type over the standard one because it defaults to “follow me” and looks much more attractive.
Question for @tomw about the driver and Rule Machine. I’m trying to use “off” as a condition in Rule Machine but I can’t figure out where to find it. Any idea how to best get the off state as a usable condition?
The way these lists in Rule Machine get overridden is with a custom attribute, but thermostatOperatingState doesn't seem to work (unless I'm guessing the name wrong).
@bravenel, can you help with a suggestion on how to override these options (if that is possible)?
When an Attribute has a defined set of values, RM uses those, and there is no way to change that list in Custom Attribute.
Another approach would be to use a different attribute entirely, and have the driver deal with how it is set and interpreted, with no defined list of values.
I took a virtual thermostat driver, and added this:
attribute "ownState", "ENUM"
Then in RM when I use Custom Attribute this comes up:
Thanks, I was aware of the built-in attribute lists from the developer documentation.
I thought that the lists could be overridden (e.g., as with "supportedThermostatModes"), but I suppose this only applies to command parameters and not attribute values?
Would you consider a feature request to allow overriding attribute values similarly for built-in attributes?
It's a bummer that the built-in attribute types use static lists instead of those values that are relevant to a given custom device implementation.
supportedThermostatModes and supportedThermostatFanModes were done because of the wide variety of those that exist in thermostats.
I don't really know what you're trying to do. Are you using a custom driver? If so, why won't a custom attribute work for you? Why does it have to be thermostatOperatingState?
But RM supports the attributes associated with capability "Thermostat", but the selectable values for triggers based on that attribute are the fixed list instead of a list that is relevant for this specific driver.
So, each user would try to use the built-in capability and find values that don't match those that are actually supported, and that seems confusing. And then they'd have to find their way to using the custom attribute, which seems clunky.
Make sense? It's a usability issue from my perspective, and to remedy that I'd like to be able to specify the possible attribute values the way I can specify the possible values for command parameters.
I don't think this has much likelihood of being done any time soon. We shy away from changes that impact every driver in order to support a single custom driver, when there is already a means available to you to get the information from the driver. You're basically proposing an attribute supportedThemostatOperatingStates be implemented, along with the associated command setSupportedThemostatOperatingStates. This is not a small undertaking, and there are many things of higher priority for us to address. It will go on the list of feature requests.
To be clear, I think the need is only for something like supportedThermostatOperatingStates. I don't see why the command would be required - I would just sendEvent() the list in configure() or some such thing. And I wouldn't want a command to be able to overwrite those values, because a user could corrupt them relative to what the driver actually knows how to support.
But you are correct in the general request to support using that attribute to populate the trigger comparison values in RM.
Edit: just noting that I'd assume the behavior would be to use the static list unless a custom list was specified. This would limit the blast radius to not include existing drivers.
What do you mean by "a means available to you to get the information..." ?
Your path forward is to use an attribute in your driver, and document it. That attribute would be accessible to Custom Attribute in RM, with or without a list of defined values.
Hey, @tomw and folks. Would it be possible to add Turbo as a feature? I would love to be able to rapidly cool the rooms down at night before bedtime. I've been doing it manually through the NetHome Plus app but would love to be able to schedule it in Hubitat!
I see this in the debug logs of my units: "turbo_mode:false"
I added Turbo Mode support in v0.9.5, available now via HPM.
Also, special thanks to GitHub user jcox10 (let me know if you have a handle here on the Hubitat forums). They have recently provided some updates, including in this version by adding units to the temperature-related attributes so that they appear on Hubitat dashboards.
I am experiencing some issues trying to style the tile in my Hubitat dashboard based on the thermostat mode. I believe this has to do with the fact that the tile reads " and 'on'" instead of cooling or heating.
Hey, @tomw and folks! It's topping 100º here in Oklahoma City today and I'm seeing a weird issue in the device. The outdoor temp on the unit is switching back and forth between 101.5 and -128.0.
Could there be something wrong with the Celsius to Fahrenheit conversion that's causing this?
I'll bet the data being returned from the API is overflowing its data size.
It could be that there's an error in the formula I used or that the AC company didn't plan for temperatures that high. Or both.
Does the outside temperature look correct before the temperatures get that high for the day? Can you enable debug logging and try to get a raw capture of the response when you're seeing this bad number in the attributes?
