Summer is finally here and I needed to get this working so after a lot of messing around, this is what I have come up with as a work around until the Domoticz MQTT-AD is fixed. (I wouldn't hold my breath on that as I opened an issue on this but the response was "Domoticz has no issues". Even though it clearly does.)
With the Current HASS Device JSON from z-wave-js-ui Domoticz will only create a Temperature device, a Heating Setpoint, and a Selector switch that controls the thermostat mode (this is also not correct as this should be a mode device not a selector switch). The HASS Device JSON from z-wave-js-ui is missing the second setpoint and Fan mode but Domoticz is still not creating the Operating status device (a Domoticz issue). Even if the HASS Device JSON is updated with the Fan Mode Domoticz still will not add the Fan Mode device (clearly another issue with Domoticz). I did verify that the config topics in MQTT were updated and Domoticz still was not creating the devices. Domoticz log shows that it is getting the updated MQTT config topics but just isn't creating any device or giving any errors.
Work around.
The HA autodiscover specification doesn't seems to support multiple setpoints so we need to create a new config for the cooling setpoint.
Since Domotizc currently won't create a fan mode device given "fan_mode_state_topic" and "fan_mode_command_topic" and since we are creating a new config for the cooling setpoint anyway we can trick Domoticz into creating a second mode device that is for the Fan mode using the "mode_state_topic" and "mode_command_topic". The second config needs to have a "unique_id" so Domoticz will create new devices instead of just applying the new setting to the current setpoint and mode devices. Thus the 2 at the end of the unique_id (and that matches the config topic name I used as well).
Code: Select all
"unique_id": "zwavejs2mqtt_0xe23caefc_Node35_climate2"
The work around to get Cooling setpoint and Fan Mode devices (I added the following config topic using MQTT Explorer with the retain checked):
Code: Select all
domoticz/climate/Test-ThermostatTest2/climate2/config
Code: Select all
{
"modes": [
"Off",
"Low"
],
"mode_state_template": "{{ {0: \"Off\", 1: \"Low\"}[value_json.value] | default('Off') }}",
"temperature_state_topic": "zwave/Test/ThermostatTest2/67/0/setpoint/2",
"temperature_state_template": "{{ value_json.value }}",
"temperature_command_topic": "zwave/Test/ThermostatTest2/67/0/setpoint/2/set",
"mode_state_topic": "zwave/Test/ThermostatTest2/68/0/mode",
"mode_command_topic": "zwave/Test/ThermostatTest2/68/0/mode/set",
"temperature_unit": "F",
"device": {
"identifiers": [
"zwavejs2mqtt_0xe23caefc_node35"
],
"manufacturer": "Remotec",
"model": "ZTS-110 Z Wave Thermostat (ZTS-110)",
"name": "Test-ThermostatTest2",
"sw_version": "3.14"
},
"name": "Test-ThermostatTest2_climate2",
"unique_id": "zwavejs2mqtt_0xe23caefc_Node35_climate2"
}
I was able to add a binary_sensor to get the Fan state.
Fan Mode state device using binary_sensor:
Code: Select all
domoticz/binary_sensor/Test-ThermostatTest2/fan_status/config
Code: Select all
{
"payload_on": 1,
"payload_off": 0,
"value_template": "{{ value_json.value }}",
"state_topic": "zwave/Test/ThermostatTest2/69/0/state",
"device": {
"identifiers": [
"zwavejs2mqtt_0xe23caefc_node35"
],
"manufacturer": "Remotec",
"model": "ZTS-110 Z Wave Thermostat (ZTS-110)",
"name": "Test-ThermostatTest2",
"sw_version": "3.14"
},
"name": "Test-ThermostatTest2_Fan_State",
"unique_id": "zwavejs2mqtt_0xe23caefc_Node35_climate3"
}
Operating State as selector. The selector config below works as a device for Operating State. Even though this is just a read only value Domoticz requires a command_topic otherwise you get:
Code: Select all
Error: MQTT Broker: Missing command_topic!
So we can add a command_topic and just not use it. Turn On protection for the device in Domoitcz so it is read only. Looks like it doesn't cause any issues if you do try to set the command_topic value. Z-wave-js-ui just logs value not writable or something like that.
Code: Select all
domoticz/select/Test-ThermostatTest3/operating_state/config
Code: Select all
{
"command_topic": "zwave/Test/ThermostatTest3/66/0/state/set",
"value_template": "{{ {0: \"Idle\", 1: \"Heating\", 2: \"Cooling\", 3: \"Fan\"}[value_json.value] | default('Idle') }}",
"state_topic": "zwave/Test/ThermostatTest3/66/0/state",
"options": [
"Idle",
"Heating",
"Cooling",
"Fan"
],
"device": {
"identifiers": [
"zwavejs2mqtt_0xe23caefc_node37"
],
"manufacturer": "Remotec",
"model": "ZTS-110 Z Wave Thermostat (ZTS-110)",
"name": "Test-ThermostatTest3",
"sw_version": "3.14"
},
"name": "Test-ThermostatTest3_Operating_State",
"unique_id": "zwavejs2mqtt_0xe23caefc_Node37_operating_state"
}
Part of the problem is not knowing what Domoticz is actually doing under the hood. It would be nice if you could see all the MQTT-AD configurations inside Domoticz.
****Update: So apparently there is more going on here than initially meets the eye. Looks like z-wave-js-ui is changing the config topic for the thermostat any time the mode of the thermostat is changed. This is causing the setpoint to be mapped between the cooling and heating setpoints.
This implementation would allow you to control the heating setpoint when the mode is heating and the cooling setpoint when the mode is cooling but in Auto it only controls the heating setpoint (since there is only one setpoint device).