I know there have been a few a of these, but have not been able to create a working configuration for my mqtt thermostat. I have a Honeywell T9 that is connected via mqtt from my Smartthings hub, I have been able to get some of the information to flow, but several of the topics don’t report correctly. I am also confused about how to account for the coolingsetpoint topic and heatingsetpoint topic as the thermostat appears to require that command topic to change the setpoint, not just the thermostatSetpoint command.
I know I am in over my head on this, so any help is appreciated.
MQTT HVAC uses only one topic for publishing the target temperature.
temperature_command_topic:
However, you need two topics, one for the target heating set point and another for the target cooling set point.
Short of using a custom component that supports two topics for target temperature, I imagine you’ll need to use an automation to ‘split’ the one temperature_command_topic into two topics.
Basically, you would set temperature_command_topic to a new topic. For example:
temperature_command_topic: "T9/setpoint"
Create an automation that is triggered by state-changes to T9/setpoint (easy so far). The automation’s action needs to check the thermostat’s current mode (heat, cool, auto, off) and then publish the received payload to the appropriate topic.
For example, let’s say the received payload is 72
if current mode is heat then it publishes to smartthings/Thermostat T9/heatingSetpoint/cmd
if it’s cool then the payload goes to smartthings/Thermostat T9/coolingSetpoint/cmd
if it’s auto then things get a bit more complicated …
Thanks, that does make sense as I couldn’t figure out how to address the setpoint to a different topic based on the mode, but the automation would be a good idea.
Could the two setpoints (heating and cooling) be messing up the accurate reporting of the temperature state? If the thermostat is set to 67 but the room temp is 70, HA only shows 67 as both temperatures, it doesn’t seem to report the actual room temp reported by the thermostat.
I would use an MQTT client (such as MQTT Explorer) to subscribe to all sub-topics of smartthings/Thermostat T9/ and confirm the published values match my expectations.
I’m having some issues getting MQTT explorer to connect to the smarthings MQTT bridge instead of the HA MQTT bridge, however I did find this list on the mqtt smartapp from smartthings
temperature: 67 F
heatingSetpoint: 67 F
coolingSetpoint: 75 F
thermostatSetpoint: 67 F
thermostatMode: heat
thermostatFanMode: auto
thermostatOperatingState: idle
supportedThermostatFanModes:
[on, auto, circulate]
supportedThermostatModes:
[heat, off, cool, auto]
DeviceWatch-DeviceStatus: online
maxHeatingSetpoint: 90 F
minHeatingSetpoint: 50 F
maxCoolingSetpoint: 90 F
minCoolingSetpoint: 50 F
deviceTemperatureUnit: F
outdoorTemperature: 46 F
thermostatStatus: Right Now: Idle
It does seem to match what I am seeing in the MQTT detail in HA. It’s odd that it does not seem to be updating in HA correctly, unless I have it misconfigured which is certainly a possibility.
I think I am connected to the broker (it is listed as localhost in the config file so I am just connected to my HASSIO server address), but for some reason the events don’t seem to pass to the broker, they only show up in the Smartthings MQTT Bridge log, not in the MQTT broker log.
I did post on a Smartthings Bridge thread about that to see if others have used MQTT Explorer. The Smartthings MQTT Bridge lists 172.17.0.1 as the broker address which I believe is a docker bridge address, but again getting over my head here.
I found this thread while looking for ways to solve this issue. Here’s what I’m thinking:
No need to look at current mode for anything. Instead only focus on the scenario proposed below for auto, and apply that to any scenario.
Auto:
if payload >= T9/temperature
then publish to T9/heatingSetpoint/cmd
elif payload < T9/temperature
then publish to T9/coolingSetpoint/cmd
else
payload NaN, bail.
It seems like this should be python code inside the mqtt/climate.py source