Thank you @tomw for the reply.
I will continue with double commanding. It works well enough.
So I guess the only way to add thermostatOperatingState : off would be to get RM to add it to the Thermostat definitions.
Yes, I am using Thermostat capability.
Thanks for the clarification.
Either that, or an attribute could be declared like supportedThermostatOperatingStates that RM could consume (which would allow a driver writer to override the default options in RM).
Why not just use thermostatMode
thermostatMode- ENUM ["auto", "off", "heat", "emergency heat", "cool"]
or thermostatOperatingMode == "idle"
2 Likes
I support both mode and state. And I override the values for mode, which is supported, unlike with state. So using mode would be a potential workaround @WardS .
Thank you @thebearmay
I am very new at this. I didn’t notice those attributes.
I will look for them.
Thank you @tomw.
I will look for those attributes.
1 Like
Lot of good information here:
1 Like
I decided to just make Variables to track On/Off conditions.
Even though thermostatOperatingState cannot be set to On, it does contain on/off so just setting a Variable to thermostatOperatingState sets the Variable to off/on depending on the current state.
Seems to be working fine as a state checking variable.
Thanks again for all the help!!
1 Like
Has anyone experienced this error? Any recommendations on solutions?
apply(): socket access failed. another session is already in progress.
Those errors have to do with my driver logic that prevents sending an update to the A/C while one is already sent but still waiting for its response from the A/C. This was meant to protect against unexpected behavior by sending commands too quickly to the A/C unit.
It looks like there are several commands being sent in quick succession (a few requests in less than a second).
Can you tell me more about what app or actions are sending commands to the device in the time period of the failure from the logs?
Now that I'm home and watching the logs, I can't seem to replicate it. I have a rule that is utilizing the "set thermostat" action to set the unit heat/cool mode, the fan mode and the setpoint. I'm guessing that's why I hear several beeps (when the LED/sound is enabled) when the app runs an action.
Cool, well keep me posted if you can find a way to reproduce it reliably.
1 Like
Tom -
an echo again of thanks for the work on this driver!
I recently purchased a Midea maw12v1qwt
(12,000 BTU U-shaped Air Conditioner)
I was able to run the python script on my Mac and use the results to get the driver to connect.
The buttons on the device page for fan speed though are propagated with weird values.
In Current States on the device page it shows:
* supportedThermostatFanModes : **["auto","full","high","medium","low","silent"]**
The dropdown for Set Thermostat Fan Mode only allows "on", "circulate", "auto". This makes sense because its using capability.thermostat.setThermostatFanMode Driver Capability List | Hubitat Documentation
In the MSmartHome app itself, it allows numeric fan speeds from 1 to 100.
As a stopgap, I added capability "FanControl" in the definition section of the driver, and then further down defined setSpeed:
def setSpeed(fanSpeed)
{
if(["auto", "full", "high", "medium", "low", "silent"].contains(fanSpeed))
{
def params = updateSettingParams([fan_speed: translateFanMode(fanSpeed, "string")])
if(params)
{
apply(params)
}
}
else
{
log.warn("setSpeed(): unsupported mode ${fanSpeed}")
}
}
I'm able to set fan speed from the Device page now, yay! Anything I'm forgetting? (I'm sure there's something I'm forgetting.)
1 Like
I could override the options dropdown on the device page, but it would require declaring a custom command (which is no big deal, but I believe the supportedThermostatFanModes setting does override the options in Rule Machine, so it would be useful if Hubitat also did it on the device page).
Cool! Send me a PR on Github and I'll incorporate that change, as well as adding the custom command that I described above.
1 Like
Pull request in. Caveat that I don't have any way to test any devices but my own, but mine likes the change.
1 Like
Thanks for the submission! Change is in now.
v0.9.3 is posted, with FanControl support as well as improvements to command dropdowns on the device page
Request to anyone with a device that supports a heat mode -- please spot check the updated command dropdown behaviors and let me know if anything seems broken.
2 Likes
@tomw, would it be possible to add an offset to the temperature?
Issue: temperature displayed on the unit (and in its Hubitat “thermostat”) is nowhere close to the sensors I have in the room. Setting a thermostat scheduler can’t do its job properly. There is no offset in the driver.
Temp set to 68, but unit thinks it’s already colder than its minimum operating limit (62.5?) and turns off when the room is barely 70-72. 
when it’s not running, the temperature reads closer to other sensor temp. This is another case of a badly placed or useless internal sensor, like in a smart vent.
I could add an offset, but I want to make sure it will serve the desired purpose.
The offset could be on the temperature measurement, which would be useful for the app to get a more correct reading so that it could send different setpoints.
But there isn't anything I can do if the unit is setting a minimum operating limit despite the setpoint you send. For example, if it is set to 68, and it "thinks" it is already lower than 62.5 (which is a limit that it enforces internally?), and you decide you need to set the temp to something lower based on the offset but the unit still won't try to get there...then an offset won't actually help.
Not sure if that made sense, but please let me know if you think you need an offset on the reading, or the command, or both.
