Better Home Assistant support

[realthk]

In Home Assistant, an MQTT heating climate device has 3 modes: "off", "heat" and "auto", which is sent to the mode_command_topic if specified.

Without direct support in this fw, now I use a NodeRed action listening to this mode_command_topic and simply send "true" to "thermostatBeca/manualMode" if HA send "heat" and "false" to "thermostatBeca/manualMode" in case of "auto" mode. ("off" is handled by "power_command_topic" that is mapped to "thermostatBeca/deviceOn")

As I see, Bikemike handles this in his fw - something similar would be nice in this fw as well. (and if support for relay state gets into this fw, sending that state would be a nice feature)

[klausahrenberg]

Next version will support Mozilla iot sheme for thermostat: https://iot.mozilla.org/schemas/#Thermostat There is a ThermostatModeProperty, which is an enumeration of ["off", "heat", "cool", "auto"] The unit will only switch between "off" and "auto" and will also accept values via mqtt over the topic "mode". Maybe this will directly work with your Home-Assitant-Sheme.

[uls169]

Klaus, maybe you can use "off" (thermostat off), "heat (thermostat in manual mode - only one target temperature), "auto (thermostat in automatic mode - more possible temperatures based on schedule).

Anyone who use it with hass and who has good configuration? Even if I set auto mode (on thermostat) and update plan via mqtt with json (and it is in the thermostat), I don't see target temperature change in hass. My config

platform: mqtt
name: Obývák termostat
payload_on: "true"
payload_off: "false"
power_command_topic: "termostat/obyvak/deviceOn"
temperature_command_topic: "termostat/obyvak/desiredTemperature"
temperature_state_topic: "termostat/obyvak/state"
temperature_state_template: "{{state_attr('climate.obyvak_termostat','desiredTemperature')}}"
json_attributes_topic: "termostat/obyvak/state"
current_temperature_topic: "termostat/obyvak/state"
current_temperature_template: "{{state_attr('climate.obyvak_termostat','actualTemperature')}}"
mode_state_topic: "termostat/obyvak/state"
mode_state_template: >
  {% if state_attr('climate.obyvak_termostat','deviceOn') != true %}
  off
  {% elif state_attr('climate.obyvak_termostat','manualMode') == true %}
  heat
  {% else %}
  auto
  {% endif %}
modes: 
  - "heat"
  - "auto"
  - "off"
min_temp: 5
max_temp: 25
temp_step: 0.5
precision: 0.5
retain: true

Based on information in #25

Thanks.

[bikemike]

@uls169, the thermostat does not report the schedule temperature to the wifi module so that logic would have to be added to the firmware.

I have added it to my own custom firmware [here] [and here] which @klausahrenberg could copy if he likes.

This is the result:

[realthk]

Home Assistant is superiour as auto controller anyway, so I use that for two good reasons:

• presence detection is much better base for controlling temperature than a simple time schedule (especially because we don't have a fixed schedule for every day). HA detects when we leave the house and when someone arrives back, so I don't have to adjust anything even on bank holidays when someone stays at home on a weekday.
• the auto mode of the thermostat is not convenient at all: you cannot adjust temperature manually, and if you switch to manual mode because of this, it won't revert back to auto at the next scheduled time. So it's either full manual or auto with fixed schedule. But in a real life you should be able to manually change temperature just temporarily if you feel a bit cold/hot without affecting auto mode. With Home Assistant, this is also not a problem: I leave the thermostat in manual mode, so it is possible to change it manually, but this does not affect my auto mode set in HA (like lower temp setting for the night, higher for the morning and lower if everyone has left the house, higher when someone arrives home)

[klausahrenberg]

I don't see target temperature change in hass.

Hmm, you are right - the target temperature is only the value for 'manual mode'... That makes no sense. I will change the behavior - so in next version the targetTemperature will report the correct value - depending if thermostat is in 'schedule mode' or 'manual mode'

[klausahrenberg]

Hi, Try version 0.97. Target value gives now the correct value. When in 'auto mode', it gives now the target value from schedules. Additionally, when you modify the 'targetTemperature', but Thermostat is in 'auto mode', it will switch now to 'manual mode'

[uls169]

@klausahrenberg thank you, now I am on some technical training abroad, will return 2 days before Christmas, I will make relay state hack and will flash the latest version then. Don't want to do it remotely, my home WAF is not high, so I rather don't disable floor heating in livingroom now in the winter. Thank you for your work. @realthk You know, I use hass for many years (how time went - rpi raspbian, virtual machines, containers - mainly virtenv, now I am back on rpi and hass.io because my old server died completely and I don't want to invest again. I trashed setups and started from beginning. I can't say hass is superior, it has many limits, specially in automation settings - it is not possible to program more difficult things directly. With this thermostat and this firmware I am collecting all data now, real temperature changes in the room, floor, outside, occupancy of room to set the automation well. You need to know the conditions when you should change the temperate well if don't want to return to cold house or you don't want to have 10 calls by your wife every week and listen "I have a cold nose" :-) I travel a lot, no rooms for errors. But so far so good, thanks all, mostly Klaus, for this FW, it seems these cheap things will replace my current system which is not compatible with hass (or any other reasonable HA).

[realthk]

@uls169 I think you should give AppDaemon a try: it is very easy to create automation even for the most difficult things with that.

Anyway, today, after upgrading to 0.97, I ran into the same problem as you (target temperature seems to be always the same as the current temperature on the HA thermostat), and after several hours of experimenting I can say that the "json_attributes_topic" causes the problem! Probably because of the same name ending, it somehow overwrites "targetTemperature" with "temperature"...

So the simple solution is to get rid of json_attributes_topic from the climate device config, and create all sensors manually from the MQTT messages you'd like to use. So create for example a switch.deviceOn, switch.manualMode instead of letting HA auto-create these from json. For temperature_state_template and current_temperature_template you can use "{{ value_json['targetTemperature'] | round(1) }}" and "{{ value_json['temperature'] | round(1) }}" (these are topic names from 0.97, not the same as in 0.95)

[iMike78]

So create for example a switch.deviceOn, switch.manualMode instead of letting HA auto-create these from json.

Could you explain this, or could you send a working HA config, please?

[realthk]

In the meantime, I found another problem with json array connection: HA updates the content of a climate control only if there was a change in a topic - and it doesn't detect changes correctly when data comes in json array (which you parse with templates).

So first you have to transform json array data from home/things/thermostat/properties into separate MQTT topics: one topic for each data. That can easily be done with a small NodeRed flow. Here is mine (check the second part):

The switch is just a condition if payload>"" (as to avoid warnings about empty data), and function nodes are simple JS functions, passing a singe parameter, eg. deviceOn:

"mode" function node creates mode name from the 3 possible state the thermostat is in:

As you can see, first part of the flow does the opposite of this: when "auto" or "heat" arrives into home/thermostatmode, it sends "auto" or "off" to home/things/thermostat/properties/schedulesMode, or false to home/things/thermostat/properties/deviceOn when "off" is received.

"Action" function node does the same for the relay state, and passes "heating", "idle" or "off" into an "action" topic:

Oh, and nearly forgot: all output MQTT topics set as "retain on" in NodeRed, to let HA always have data, even right after a restart (although I've put a mqtt_publish "" -> home/things/thermostat/properties into my HA startup automation to force a status update, but that takes place after climate and switches setup, so HA would not have data first if it wasn't retained in MQTT)

So now the climate.yaml can be the most simple as it does not need to have templates at all:

This way everything works fine, climate control updates at once.

I also have some other switches to control ecoMode and locked state, but that's not required:

("tétlen" is hungarian for "idle". That comes from the action topic based on the relay state)

Of course there are also several automations in HA like increasing temp if someone arrives home (based on mobile phone locations or movement detected in the house): (and several more, like lower temp for the night, higher for the morning, lower if nobody is at home - but you get the picture how to control the thermostat)

[iMike78]

@realthk I sent an e-mail to you! ;)

[rengaboy]

Hello, friends. Can you help me with syntax for this config. I update firmware ro 1.00 and have stucked with my config. I changed it, but still no success.

platform: mqtt
name: Bath Thermostat
payload_on: "true"
payload_off: "false"
power_command_topic: "homeassistant/beca/bath/things/thermostat/properties/deviceOn"
temperature_command_topic: "homeassistant/beca/bath/things/thermostat/properties/targetTemperature"
temperature_state_topic: "homeassistant/beca/bath/targetTemperature"
current_temperature_topic: "homeassistant/beca/bath/temperature"
mode_state_topic: "homeassistant/beca/bath/things/thermostat/properties/state"
mode_state_template: >
  {% if state_attr('climate.bath_thermostat','deviceOn') != true %}
  off
  {% elif state_attr('climate.bath_thermostat','schedulesMode') == true %}
  auto
  {% else %}
  heat
  {% endif %}
modes: 
  - "heat"
  - "auto"
  - "off"
min_temp: 15
max_temp: 36
temp_step: 0.5
precision: 0.5
retain: true

[realthk]

@rengaboy there are no separate topics (like "targetTemperature", "temperature") in the 1.0 firmware, so you can create these with NodeRed, from the json array received in the "properties" topic. Also, there are no attributes of climate.bath_thermostat unless you allow HA to auto-create these with json_attributes_topic - but that I cannot reccommend, it is better to use NodeRed to report state in another topic. See everything above. Then HA config can be very simple, w/o any templates.

[rengaboy]

@realthk I think, this is not homeassistant problem, because with 0.95 firmware all was good. @klausahrenberg Maybe it is firmware issue?

[klausahrenberg]

Please note, that topic have changed between 0.95 and 1.00 - see Readme. For example, your topic "homeassistant/beca/bath/temperature" to "homeassistant/beca/bath/things/thermostat/properties/temperature". If you rewrite your config in this way, it will be work again maybe.

[realthk]

@rengaboy Yes, in 1.0 there is no topic like "homeassistant/beca/bath/temperature" or "targetTemperature" it doesn't work like that.

There is only a "homeassistant/beca/bath/things/thermostat/properties" topic with a json array content from which you have to parse things like temperature and targetTemperature. You either do it with a

json_attributes_topic: homeassistant/beca/bath/things/thermostat/properties

which is not in your config above, so state_attr() calls won't work, or use expression like

current_temperature_topic: "homeassistant/beca/bath/things/thermostat/properties"
current_temperature_template: "{{ value_json['temperature'] }}"

but then HA doesn't notice updates at once, so it is better to use NodeRed to create standalone topics from this json array.

[realthk]

@klausahrenberg I don't think that would work: "things/thermostat/properties/targetTemperature" can be used as command topic to set a new target - but not for receiving the currently set value. For that, json array from "things/thermostat/properties" can be parsed.

[rengaboy]

@klausahrenberg @realthk So, after some changes this was last config.

- platform: mqtt
  name: Bath Thermostat
  payload_on: "true"
  payload_off: "false"
  json_attributes_topic: "homeassistant/beca/bath/things/thermostat/properties"
  temperature_command_topic: "homeassistant/beca/bath/things/thermostat/properties/targetTemperature"
  temperature_state_topic: "homeassistant/beca/bath/things/thermostat/properties"
  temperature_state_template: "{{ value_json['targetTemperature'] }}"
  current_temperature_topic: "homeassistant/beca/bath/things/thermostat/properties"
  current_temperature_template: "{{ value_json['floorTemperature'] }}"
  mode_state_topic: "homeassistant/beca/bath/things/thermostat/properties"
  mode_state_template: >
    {% if value_json.deviceOn != true %}
    off
    {% elif value_json.schedulesMode == on %}
    auto
    {% else %}
    heat
    {% endif %}
  modes: 
    - "off"
    - "auto"
    - "heat"
  min_temp: 15
  max_temp: 36
  temp_step: 0.5
  precision: 0.5
  send_if_off: false
  retain: true

It was better than nothing, showing modes and current temperature, but in target temperature it was showing current temperature, and if i have been changing target temperature, it changed, but then was returning visually (actually didn't) back to current_temperature value. There is one more problem with locked and ecoMode options. There is no state_template option in mqtt.switch and no locked and ecoMode option in mqtt.climate integrations. So i made some tricks with hold mode and away mode and finally made this config.

- platform: mqtt
  name: Bath Thermostat
  payload_on: "true"
  payload_off: "false"
  json_attributes_topic: "homeassistant/beca/bath/things/thermostat/properties"
  temperature_command_topic: "homeassistant/beca/bath/things/thermostat/properties/targetTemperature"
  temperature_state_topic: "homeassistant/beca/bath/things/thermostat/properties"
  temperature_state_template: "{{ value_json['targetTemperature'] }}"
  current_temperature_topic: "homeassistant/beca/bath/things/thermostat/properties"
  current_temperature_template: "{{ value_json['floorTemperature'] }}"
  mode_state_topic: "homeassistant/beca/bath/things/thermostat/properties"
  mode_state_template: >
    {% if value_json.deviceOn != true %}
    off
    {% elif value_json.schedulesMode == on %}
    auto
    {% else %}
    heat
    {% endif %}
  modes: 
    - "off"
    - "auto"
    - "heat"
  hold_command_topic: "homeassistant/beca/bath/things/thermostat/properties/locked"
  hold_state_topic: "homeassistant/beca/bath/things/thermostat/properties"
  hold_state_template: >
    {% if value_json.locked == true %}
    locked
    {% else %}
    unlocked
    {% endif %}
  hold_modes: 
    - "locked"
    - "unlocked"
  away_mode_command_topic: "homeassistant/beca/bath/things/thermostat/properties/ecoMode"
  away_mode_state_topic: "homeassistant/beca/bath/things/thermostat/properties"
  away_mode_state_template: "{{ value_json['ecoMode'] }}"
  min_temp: 15
  max_temp: 36
  temp_step: 0.5
  precision: 0.5
  send_if_off: false
  retain: true

Locked/Unlocked state is under hold mode and ecoMode is "away" mode. Not perfect, but it's almost satisfies my requirements. So the one last problem is mixed target and current temperature values.

[realthk]

So the one last problem is mixed target and current temperature values.

Check above, 2 weeks ago I wrote about the same problem. It's probably a bug in HA json parser (that is switched on by json_attributes_topic) that somehow mixes temperature and targetTemperature probably because of the same name ending.

Feel free to try NodeRed flow (I inserted a link of its backup, in which you only need to change IP address of the MQTT broker) that handles this and everthing else.

This firmware needs an external solution (like NodeRed or anything else) that can parse json array and create standalone topics from different attributes for Home Assistant, otherwise HA doesn't recognise changes correctly, in time.

[rengaboy]

@realthk I'm stuck again. There is no "state" payload in mqtt, so my thermostat shows "Off(Heating)" in lovelace card. i don't uderstand, what should this code return:

var payload=msg.payload;
if (typeof payload.state !== 'undefined') {
    msg.payload = payload.state;
    return msg;
} else {
    return null;
}

[realthk]

@rengaboy Yes, for the state you have to make a hw modification.

[multijohn]

Please, about the current temp issue check my code below at temperature_state_template , current_temperature_template and 2 json_attributes_topics . Works for me :

`climate:

• platform: mqtt name: 2nd Floor Thermostat payload_on: "true" payload_off: "false" json_attributes_topic: "2nd_floor_thermostat/things/thermostat/properties" power_command_topic: "2nd_floor_thermostat/things/thermostat/properties/deviceOn" temperature_command_topic: "2nd_floor_thermostat/things/thermostat/properties/targetTemperature" temperature_state_topic: "2nd_floor_thermostat/things/thermostat/properties" temperature_state_template: "{{ value_json.targetTemperature }}" json_attributes_topic: "2nd_floor_thermostat/things/thermostat/properties/temperature" current_temperature_topic: "2nd_floor_thermostat/things/thermostat/properties" current_temperature_template: "{{ value_json.temperature }}" mode_state_topic: "2nd_floor_thermostat/things/thermostat/properties" mode_state_template: > {% if value_json.deviceOn != true %} off {% else %} heat {% endif %} modes:
  • "heat"
  • "off" min_temp: 5 max_temp: 35 temp_step: 0.5 precision: 0.5 send_if_off: false retain: true `

[uls169]

@klausahrenberg don't you want to consider full hass support including mqtt autodiscovery? @realthk thank you very much for nodeRED json, it helped me much in my config Guys thanks a lot, very good firmware, I have problems with displayed time (NTP and MQTT is OK) still but maybe I have bad/faulty hardware? The integration into hass with nodeRED is sufficient but it seems I touched the limits of my hassOS installation on RPi 3. So far so good, everything is working now, I am staring to think about reasonable automation. Again, thank you!

[Hedgehog57]

I have looked at NodeRed configuraion by @realthk. Thanks a lot to sharing it.

Then I have created the same logic but on AppDaemon. Because I have AppDaemon and doesn't have NodeRed. Is there someone who need it?

ATM it do the same as @realthk NR configuration. I try to read scheduling from MQTT and save it in bunch of input_datetime and input_number in HA. But it's look ugly. too many variables in configuration.yaml and ui-interface.yaml...

[Hedgehog57]

About TZ and NTP.

I have UPS (with NTP server) on RPi and router. But thermostat is not connected to it. So there is a situation when core system at home is online but we don't have internet access. If thermostat start at this time it can get time but cannot get TZ. Is there any hope we can configure TZ in Firmware not by URL but just entering in format like (GMT+3) or similar?

[multijohn]

Hello, Is there any method in hass for availability function with this fw; Is it possible to use idx value from properties as available payload, and how; I'm thinking idx apearens as available payload and null for not available payload but i can't find a way to achieve in hass!

Thank u!

[austwhite]

Wondering myself if you can add the HASS Auto Discovery for MQTT to your script. Documentation is at https://www.home-assistant.io/docs/mqtt/discovery/

This would simplify the install for Home Assistant as this would make it automatically discovered. Also, a per another issue logged, we need the update interval to be faster. Changing the thermostat manually takes 5 minutes to update status in Home Assistant. This also means temperautre updates only happen every 5 minutes also.

[austwhite]

Is there any method in hass for availability function with this fw;

The way it is currently written it does not have a LWT topic, but this could easily be added if needed.

[ghost]

Below my HA config for the BHT-6000. This seems to work fine as far as I can see. There are probably still a few things in there that could be skipped.

climate:
  - platform: mqtt
    name: Living Thermostat
    temperature_command_topic: "living/thermostat/things/thermostat/properties/targetTemperature"
    temperature_state_topic: "living/thermostat/things/thermostat/properties"
    temperature_state_template: "{{ value_json['targetTemperature'] | round(1) }}"
    current_temperature_topic: "living/thermostat/things/thermostat/properties"
    current_temperature_template: "{{states('sensor.thermostat_current_temperature')}}"
    mode_command_topic: "living/thermostat/things/thermostat/properties"
    mode_state_topic: "living/thermostat/things/thermostat/properties"
    mode_state_template: >
      {% if value_json.deviceOn != true %}
      off
      {% elif value_json.schedulesMode == 'auto' %}
      auto
      {% else %}
      heat
      {% endif %}
    modes:
      - "heat"
      - "auto"
      - "off"
    min_temp: 5
    max_temp: 35
    temp_step: 0.5
    precision: 0.5
    retain: true

sensor:
  - platform: mqtt
    name: "thermostat_current_temperature"
    state_topic: "living/thermostat/things/thermostat/properties"
    value_template: "{{ value_json['temperature'] | round(1) }}"
  - platform: mqtt
    name: "thermostat_target_temperature"
    state_topic: "living/thermostat/things/thermostat/properties"
    value_template: "{{ value_json['targetTemperature'] | round(1) }}"

  - platform: template
    sensors:
      living_thermostat_delta:
        value_template: "{{ ((states('sensor.thermostat_target_temperature')|float) - (states('sensor.thermostat_current_temperature')|float)) | round(2) }}"

automation:
  trigger:
    platform: state
    entity_id: climate.living_thermostat
  action:
    service: mqtt.publish
    data:
      topic: "living/thermostat/things/thermostat/properties"
      payload_template: >
        {% if states('climate.living_thermostat') == 'heat' %}
        {"schedulesMode": "off", "deviceOn": true}
        {% elif states('climate.living_thermostat') == 'auto' %}
        {"schedulesMode": "auto", "deviceOn": true}
        {% else %}
        {"schedulesMode": "off", "deviceOn": false}
        {% endif %}

[SolarNeron]

Below my HA config for the BHT-6000. This seems to work fine as far as I can see. There are probably still a few things in there that could be skipped.

climate:
  - platform: mqtt
    name: Living Thermostat
    temperature_command_topic: "living/thermostat/things/thermostat/properties/targetTemperature"
    temperature_state_topic: "living/thermostat/things/thermostat/properties"
    temperature_state_template: "{{ value_json['targetTemperature'] | round(1) }}"
    current_temperature_topic: "living/thermostat/things/thermostat/properties"
    current_temperature_template: "{{states('sensor.thermostat_current_temperature')}}"
    mode_command_topic: "living/thermostat/things/thermostat/properties"
    mode_state_topic: "living/thermostat/things/thermostat/properties"
    mode_state_template: >
      {% if value_json.deviceOn != true %}
      off
      {% elif value_json.schedulesMode == 'auto' %}
      auto
      {% else %}
      heat
      {% endif %}
    modes:
      - "heat"
      - "auto"
      - "off"
    min_temp: 5
    max_temp: 35
    temp_step: 0.5
    precision: 0.5
    retain: true

sensor:
  - platform: mqtt
    name: "thermostat_current_temperature"
    state_topic: "living/thermostat/things/thermostat/properties"
    value_template: "{{ value_json['temperature'] | round(1) }}"
  - platform: mqtt
    name: "thermostat_target_temperature"
    state_topic: "living/thermostat/things/thermostat/properties"
    value_template: "{{ value_json['targetTemperature'] | round(1) }}"

  - platform: template
    sensors:
      living_thermostat_delta:
        value_template: "{{ ((states('sensor.thermostat_target_temperature')|float) - (states('sensor.thermostat_current_temperature')|float)) | round(2) }}"

automation:
  trigger:
    platform: state
    entity_id: climate.living_thermostat
  action:
    service: mqtt.publish
    data:
      topic: "living/thermostat/things/thermostat/properties"
      payload_template: >
        {% if states('climate.living_thermostat') == 'heat' %}
        {"schedulesMode": "off", "deviceOn": true}
        {% elif states('climate.living_thermostat') == 'auto' %}
        {"schedulesMode": "auto", "deviceOn": true}
        {% else %}
        {"schedulesMode": "off", "deviceOn": false}
        {% endif %}

I use a similar configuration of my thermostat in HA, but when i restart HA y have a diferents errors, you too? 2020-01-16 23:48:12 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'value_json' is undefined (value: , template: {% if value_json.state == "heating" %} heating {% else %} idle {% endif %} ) 2020-01-16 23:48:12 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'value_json' is undefined (value: , template: {{ value_json['temperature'] | round(1) }}) 2020-01-16 23:48:12 ERROR (MainThread) [homeassistant.components.mqtt.climate] Could not parse temperature from 2020-01-16 23:48:12 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'value_json' is undefined (value: , template: {{ value_json['targetTemperature'] | round(1) }}) 2020-01-16 23:48:12 ERROR (MainThread) [homeassistant.components.mqtt.climate] Could not parse temperature from 2020-01-16 23:48:12 ERROR (MainThread) [homeassistant.helpers.template] Error parsing value: 'value_json' is undefined (value: , template: {% if value_json.deviceOn != true %} off {% elif value_json.schedulesMode == "off" %} heat {% else %} auto {% endif %} ) 2020-01-16 23:48:12 ERROR (MainThread) [homeassistant.components.mqtt.climate] Invalid modes mode:

Then the thermostat works fine, but i don`t understand what is the problem

[realthk]

Error parsing value: 'value_json' is undefined Then the thermostat works fine, but i don`t understand what is the problem

That is quite straightforward, I wrote about it above: if data comes from non-retained topic (like this firmware provides) then there is no data during HA startup. That is also a reason why use NodeRed to create standalone topics from the single properties one this firmware reports into.

[austwhite]

For HA users : If the Command and State topics are the same topic, this can cause issues with MQTT freezing and not responding or other undesired behaviour. There is a current pull request under #81 that separates the topics into separate command and state topics. This solves the MQTT conflicts caused by the single topic. I don't use WebThings so unsure if it makes a difference there, but for HA users, it solves all the MQTT issues.

[klausahrenberg]

Hi, I would like to close this thread because several topics are mixed here. A description for HA configuration (a README.md) is welcome, I would integrate this in the repository.

I picked hopefully most of the described problems here and realized some solutions in new version 1.02. More in detail:

So first you have to transform json array data from home/things/thermostat/properties into separate MQTT topics: one topic for each data.

In version 1.02 you can now configure the thermostat now in this way: Choose, if for every property should send a separate MQTT command or complete JSON with all properties. Hope that will make the integration of thermostat in HA easier now

Oh, and nearly forgot: all output MQTT topics set as "retain on" in NodeRed, to let HA always have data

In version 1.02 now the thermostat sends all properties as "retain on" too.

I don't think that would work: "things/thermostat/properties/targetTemperature" can be used as command topic to set a new target - but not for receiving the currently set value. For that, json array from "things/thermostat/properties" can be parsed.

For HA users : If the Command and State topics are the same topic, this can cause issues with MQTT freezing and not responding or other undesired behaviour.

I gave up to keep same topics for getting and setting values :-) You can now configure your own 'state' and 'set' topic for MQTT in web configuration. The default 'state' topic is 'properties', for setting values is 'set' used - but you can change as you like. Moreover, don't use same topics for both from now on. For state reports the device sends now for example: <your_mqtt_topic>/thermostat/properties. To set all values, send json structure to: <your_mqtt_topic>/thermostat/set. If you like to modify a specific parameter, send the value as payload to e.g. <your_mqtt_topic>/thermostat/set/deviceOn

Is there any hope we can configure TZ in Firmware not by URL but just entering in format like (GMT+3) or similar?

Realized in version 1.02. You can give a fixed offset in minutes, for GMT+3 specify 180 minutes in configuration. The solution will be improved in further versions to reflect DST also.

Is it possible to use idx value from properties as available payload, and how;

idx parameter is realized since version 1.00. Set an individual idx in web configuration of device

[grafalex82]

Does anybody have a blueprint for this?

[olehdutko]

Hello, and thanks for the interesting solution! But looks like it is not working with HA anymore(