Danfoss Ally thermostat: firmware archive [v1.28, v1.20, v1.18, v1.08] & specifications [zha] [deconz] [zigbee2mqtt]

Hi there,

I already have some Danfoss Ally thermostats over here, which work nicely with ZHA as climate components.

Recently I contacted the Danfoss support for their plans about making firmware update public available including changelogs etc.
Response was pretty fast and nicely including a link to v1.08, the statement that updates can be done by each and every software / bridge, which is capable of doing them, and they attached the specs for the new v1.08 software.


archived content

  • Does anyone know how we could improve the ā€œout-of-the-boxā€ experience of these devices by making additional properties or commands available? i.e. see a selection of interesting attributes below.

  • Would it be possible to combine multiple thermostats in one room to act as a group ? / as one? (using automations or node-red to apply same settings is fine, but question is related to make more use of the zigbee features)

  • What steps do I have to do to manually update the thermostats firmware?

  • Update 2021-12-16: added v1.18 spec and firmware archives to
    GitHub - SimpleUserHA/DanfosseTRV

= Cluster = 0x0204 Thermostat UI Configuration =

  * Attribute ID = 0x4000 Viewing Direction
     Range: 0 to 1
     0x00 = viewing direction 1
     0x01 = viewing direction 2
     Default is 0, but overwritten to value from production configuration at Init

= Cluster = 0x0201 Thermostat =

  * Attribute ID = 0x4000 eTRV Open Window Detection
     0x00: Quarantine
     0x01: Windows are closed
     0x02: Hold ,Windows are maybe about to open
     0x03: Open window detected
     0x04: In window open state from external, but detected closed locally

  * Attribute ID = 0x4003 External Open Window Detected
     0x00: Windows are closed
     0x01: Windows are opened

  * Attribute ID = 0x4014 eTRV Orientation
     0x00: Horizontal (Default)
     0x01: Vertical
     Default is 0, but overwritten to value from production configuration at Init.

  * Attribute ID = 0x4015 External Measured Room Sensor
     Recommended to be received from Gateway at least
     every 3 hours but not more often than every 30 minutes
     @ every 0,1K change

  * Attribute ID = 0x4020 Control algorithm scale factor
     Range 1-10 (lower 4 bit allocated to scale factor)
     Scale factor of setpoint filter timeconstant
     ("aggressiveness" of control algorithm) 1=5min(Quick) ...
     5=30min(Moderate) ... 10=80min(Slow).
     Bit4=Quick open feature disable. 1=disable. 0=enable

  * Attribute ID = 0x4051 Window Open Feature ON/OFF
     0x00: window open feature OFF.
     0x01: window open feature ON.
Ā“Ā“Ā“
2 Likes

Are you able to turn off the thermostat from lovelace / services? No matter if I try setting the hvac mode og using the climate.turn_off I have no success.

Regarding the OTA update i guess it should be enough to put the unpacked 1246-0100-01080108.0002_(DF4ECCE1).ota inside the otau_directory (see https://www.home-assistant.io/integrations/zha/)

edit: got the update to run by placing the ota file inside the otau_directory. I placed a copy of the file with both 1246-0100-01080108.0002_(DF4ECCE1).ota and 1246-0100-01080108.0002.ota as names and now it is updating (very slowly :))

2 Likes

Great work, very cool they shared the firmware!

Also very interested in grouping valves and making them adhere to an external thermometer.

Nice, thanks for the hint using the otau_directory. Firmware updates running fine here.

Now anyone knows, how I can assign the cluster and attribute ID to an entity in HA to easily modify the viewing direction or set the external open window detection ?

For now I set the temperature to 6 deg C when the window opens and back to 22 C when closing it. Seems to work OK but it would be nicer to turn of completely or trigger window open condition. It does not seem that the thermostat can be bound to a doorswitch directly

Doing the same here, but when you are running schedules with different temps during day or situations, then the reset temperature is different. Previous temp could be written as well to a variable and read afterward. However itā€™s more about doing it right and improving the device support.

I am having some success updating the open window attribute using the gui see : How to set cluster attribute. Works from gui not from service
However I am having difficulty converting it to a valid service call

Edit: Figured it out :slight_smile:

1 Like

Full code for the script

alias: bad_term_open_window
sequence:
  - service: zha.set_zigbee_cluster_attribute
    data:
      ieee: '84:2e:14:ff:aa:56:eb:c0'
      endpoint_id: 1
      cluster_id: 513
      attribute: 16387
      cluster_type: in
      value: 1
      manufacturer: '4678'
mode: single

Same for close window where value should be 0

In order to get the history of what the thermostat is doing the following can be added to configuration.yaml:

sensor:
  - platform: sql
    db_url: sqlite:////config/zigbee.db
    scan_interval: 10
    queries:
      - name: Open Window Detection
        query: "SELECT value FROM attributes where ieee = '84:2e:14:ff:aa:56:eb:c0' and cluster = 513 and attrid = 16384"
        column: "value" 
      - name: External Open Window Detection
        query: "SELECT value FROM attributes where ieee = '84:2e:14:ff:aa:56:eb:c0' and cluster = 513 and attrid = 16387"
        column: "value" 
  - platform: template
    sensors:
      bad_set_temp:
        friendly_name: "Bad st set point"
        unit_of_measurement: 'Ā°C'
        value_template: "{{ state_attr('climate.bad_term_c0eb56fe_thermostat','temperature') }}"
      bad_cur_temp:
        friendly_name: "Bad st temp"
        unit_of_measurement: 'Ā°C'
        value_template: "{{ state_attr('climate.bad_term_c0eb56fe_thermostat','current_temperature') }}"
      bad_pi_heating_demand:
        friendly_name: "Bad st heat demand"
        unit_of_measurement: '%'
        value_template: "{{ state_attr('climate.bad_term_c0eb56fe_thermostat','pi_heating_demand') }}"
2 Likes

Now we just need to figure out how to make it adhere to an external thermometer. :slight_smile:

Iā€™m using deconz with conbee but having the same need about external thermometer. I found out that the internal sensor of those eTRV are nearly 2Ā°C above the room temperature when the radiator is hot (but identical when off) in my case. This make the valve to close a bit early or too much when you set the eTRV to the exact temperature you want.

For those wanted to turn the device on or off, you cannot do such thing. You can only set the temperature and the internal PID algorithm will do the math.

For window detection there are different possible values, but only readable (giving current state)

0x0201 0x4000 eTRV Open Window Detection
  0x00: Quarantine
  0x01: Windows are closed
  0x02: Hold ,Windows are maybe about to open
  0x03: Open window detected
  0x04: In window open state from external, but detected closed locally

it seems you have to use this one which is writable

0x0201 0x4003 External Open Window Detected
  0x00: Windows are closed
  0x01: Windows are opened
1 Like

Regarding the external thermometer, Iā€™ve opened a PR for this, for ZHA:

Iā€™ve been using it for a week or so now, and I see that the TRV will try to hit the setpoint as an AVG between the TRV measured temperature and the external temperature. This works great for me, where the TRV is behind a closet (so the TRV measured temperature is always high), but Iā€™ve placed an external temp sensor on the office desk to report the actual room temperature.

An homeassistant automation will set the TRV external temp whenever the external temp sensor state changes.

2 Likes

Fantastic work Thor!

Iā€™ll look forward to see how you implement this, when the release is public!

The fact you can do this is marvelous! I wonder if itā€™s possible because it uses zigbee, which means some kind of gateway that you can hijack? Iā€™m asking because I have Danfoss Eco 2 with the same temperature issue that I canā€™t find way to resolveā€¦So maybe thereā€™s some hope? Or at the worst Iā€™d have to change my TRVā€™s to Ally? :stuck_out_tongue:

It is because Danfoss (and other brands) is going on ZigBee I guess. Like Blu-Ray versus HD-DVD, the war is over between ZigBee & Z-Wave. Bluetooth was a Switzerland choice until then. So by doing more dev on the ZigBee version and also because ZigBee allows more vendor specific properties / attributes than Z-Wave from what I have understood, the Danfoss Ally have more feature than the Z-Wave or Bluetooth versions. Maybe they will update the older one, but I wont bet a cent on it.

It is also convenient for the brand when its own bridge will come out (2021 fall?), they will be able to market & sell more devices as a all package.

So youā€™re basically suggesting that I shouldnā€™t believe in Eco 2 getting reading external temperature any time soon? :stuck_out_tongue:

I can buy Ally to replace the one thatā€™s making me trouble but because itā€™s quite more expensive Iā€™d like to make sure I understand this correctly. With the ZHA integration and @nslrā€™s handler I could use Ally with one of the supported Zigbee adapters to feed Ally with external temperature sensor, which will make Ally take it into account when checking if set temperature is already achieved, right?

Iā€™m using a standard USB Zigbee stick (canā€™t remember the exact model, but one that can be flashed with custom Zigbee 3 firmware), and with the latest (no-yet released) version of ZHA/zigbee-device-handlers, this is what my Danfoss Ally + external temp device integration looks like:

office-heating

in the top graph, green is the temp reading fromt he Ally TRV, red is from the external temp sensor, blue is the set-point for the TRV. Works nicely, I reckon.

That is beautiful! Did the commit find itā€™s way into release yet? And how would you go about it to implement it?

I have a bathroom with both the Ally and an external sensor, ready to be combined! :slight_smile:

The change is released in the latest zigbee-device-handlers release, but itā€™s not made it to homeassistant just yet. Iā€™ve modified the zigbee-device-handlers source locally on my homeassistant installation, but I donā€™t recommend doing that unless you really canā€™t wait :smiley:

Haha, I think I will wait. But I will bother you on how to set up the change by then! :slight_smile:

Latest Homeassistant release dropped today apparently, so no need to wait for too long!

1 Like