Ha ha that’s fair enough. I can see that useing remote sensors for temperature is featured in a couple of forums, so fingers crossed it will be trivial soon. I will try to fool around with it for a bit, and see if I can get your script at automation working.
Just a little update.
So, I have spent some time checking all options. YAML is pretty annoying for a newbie like me, with the indentation. Anyways I now have most of the setup working. That is automation runs script correctly, and the script updates the “external_measured_room_sensor” on the Danfoss. Yet still no luck getting the Danfoss to do anything with this external temperature. Sigh…
However, it did get me thinking, what is the response time? I have fairly quickly warmed/cooled my external sensor to test it, but should I expect e.g. 15 min before the Danfoss react?
Just as a sidenote, there seems to be a ton of options for the Danfoss you can (perhaps) use. In this attempt with the external temperature, it is
“DanfossThermostatCluster (Endpoint id: 1, Id: 0x0201, Type: in)”
“external_measured_room_sensor (id: 0x4015)”
Converted from hexadecimal to binary we get:
1 = 1
0x0201 = 513
0x4015 = 16405
which is evident in nslrThor Jacobsen’s script. So makes good sense, despite it still teasing me.
One other example is “external_open_windows_detected (id: 0x4003)” which may be of interest to you bjorn.sivertsen, perhaps take a look here:
To check if it’s actually working, you can read the value off of the TRV in the cluster. My server is crashed right now and I’m not at home, so I can’t explain the exact steps, but you need to find the TRV under entities and fiddle around there.
It does take a while for the motor to react, so you can’t test it quickly. You need to trust that if the value is set (you can read it in the cluster), it’s working.
Thanks, I did indeed fiddle around reading the cluster values, and yes it does read the external sensor temperature. I will then assume it works, but still see if I can come up with a more efficient test setup that last longer - just to be sure.
Success!
I created a small cold box and put the external sensor in there. I was pretty disappointed when nothing happened for 2 hours. But then I got a suspicion, and sure enough the Danfoss uses a mean of its own temperature and the external. Duuuh! Actually double duh, as you nslrThor Jacobsen specifically mention it here.
So, as you can see in the attached images it works as intended. And nice feature that it is not on/off but actually gradually opening/closing.
Anyway, it works now, and it is usually within few minutes, so acceptable. That it actually uses an average is fine I guess – I might strive to position external sensors in the opposite site of the room. Otherwise, I might be able to figure something out in an equation to make the avarage temperature equal to the external sensor.
A big thanks for nslrThor Jacobsen and bjorn.sivertsen, and whoever else has have to put up with my walls of text.
Just adding to previous sidenote, I added to open/close window for fun, at it works perfectly, i.e., closes off the Danfoss. All credits go to wormie_dkDavid Alberg Peters who mentioned it here
ally1_open:
alias: 'Danfoss Ally 1: open window'
sequence:
- service: zha.set_zigbee_cluster_attribute
data:
ieee: [IEEE of your Danfoss Ally TRV]
endpoint_id: 1
cluster_id: 513
attribute: 16387
cluster_type: in
value: 1
manufacturer: '4678'
mode: single
ally1_close:
alias: 'Danfoss Ally 1: close window'
sequence:
- service: zha.set_zigbee_cluster_attribute
data:
ieee: [IEEE of your Danfoss Ally TRV]
endpoint_id: 1
cluster_id: 513
attribute: 16387
cluster_type: in
value: 0
manufacturer: '4678'
mode: single
1 Like
@nslr Hey man,
I have been shown this post by someone on z2m asking if I can make this attribute accessible.
Looking at the specification:
https://assets.danfoss.com/documents/176987/AM375549618098en-000101.pdf
The description states the following:
Recommended to be received from Gateway at least
every 3 hours but not more often than every 30 minutes @
every 0,1K change
After 3 hours the function is disabled and goes back to
standard mode
So that range is meant to be in degress Kelvin rather than Celsius? Your template seems to not do this conversion.
Can you confirm the behaviour at your end?
I wonder if this is referring to 100 value e.g. 0.1K, and nothing to do with temperature
Thanks,
Rob
Hi Rob,
No, I did not add any conversions of any kind. I’ve never noticed the docs referring to temp changes in degress Kelvin - but AFAIR a change of 1 degree Kelvin is equal to 1 degree Celcius. They just have different definitions of zero.
Also, I haven’t updated my hardware to the latest firmware, so not sure if that’ll break something for me.
Hi Thor,
Thanks for your reply. Yes you are correct, 1 degree will always be 1 degree. The value though will mean something else. The spec is obviously not clear enough whether it means 0.1k degrees or 0.1k as in 0.1 x 1000 = 100 points of value.
Can you please confirm, the value you are sending? For example 22.5C you would send 2250?
Thanks again
Ah, now I get it. Yes, the value needs to be 2250 for 22.5C - so the “k” is probably “1000s”, not “kelvin” 
1 Like
Thanks a lot. I got a PR to support this on zigbee2mqtt Add support for external temp sensor by robertalexa · Pull Request #2890 · Koenkk/zigbee-herdsman-converters · GitHub
I am hopeful that the value means 1000s and no conversion is needed, otherwise the internal mechanism will definitely not behave as expected. But given that every other attribute of the device is specified in C, i doubt they would have done something silly for this one.
Thanks a lot for your input!
I assume 1.12 replaces the 1.08 firmware? Does anyone have a link to it? Can only find the 1.08 one.
Same here. I sent them a support request. I’ll write back if I get it, but I hope they just update the available download and make it available for everyone.
1 Like
Sounds great, let us know what they reply!
Hej @bjorn.sivertsen, I’m a newbie with Home Assistant. Your thermostat card looks great and better suited than the default one for what we’re doing here. I guess you wrote it yourself? Would you mind sharing the code? Thanks!
Being a beginner, I am a bit confused about TRV firmware versions. How does one check What Danfoss TRV version they have?
For example I see when I go to Home Assistant Configuration / Devices / Danfoss eTRV0100- “Firmware: 0x0000010c”. Is that Danfoss firmware version?
Yes, and it translates to 1.12, which is functionally the same as 1.08.
So you can use automations and scripts just the same as us others.
Check one of the last replies in this thread for details:
Thanks!
Now I am testing the scripts with my Danfoss TRV (firmware 1.12) but it does not seem to be working. I put my external temp sensor outdoors to simulate low temp so that it would trigger TRV to start heating, but nothing happens and the radiator remains cold. Could you please have a look at the details below, perhaps you could spot any mistakes I made?
I set my TRV to maintain 20 degrees. I know that this setting works, as it immediately starts heating if TRV internal sensors measures temperature below 20 degrees. During testing below TRV internal temp sensor was measuing ~21 degrees.
I put external temp sensor outdoors to simulate low temperature and at the time it was measuring 18.30 degrees.
Automation triggered script ran, but heating did not start. According to trace information it seems that 18.3 temperature was sent to the TRV:
Script:
alias: trv_external_temp_read
sequence:
- service: zha.set_zigbee_cluster_attribute
data:
ieee: 80:4b:50:ff:fe:3c:20:68
endpoint_id: 1
cluster_id: 513
attribute: 16405
cluster_type: in
value: >-
{{ (states("sensor.lumi_lumi_weather_47fcf006_temperature") | float *
100) | round(0)}}
mode: single
Automation:
alias: trigger_trv_temp_update
description: ''
trigger:
- platform: state
entity_id: sensor.lumi_lumi_weather_47fcf006_temperature
condition: []
action:
- service: script.trv_external_temp_read
data: {}
mode: single
I have a separate script.yaml file, but my code looks like this. The script looks a bit different with the value part
bathroom_temp_follow:
alias: Bathroom Temp Follow
sequence:
- service: zha.set_zigbee_cluster_attribute
data:
ieee: 84:2e:14:ff:fe:5e:41:dc
endpoint_id: 1
cluster_id: 513
attribute: 16405
cluster_type: in
value: '{{ (states("sensor.bathroom_air_temperature") | float * 100) | round(0)}}'
mode: single
- id: '1612470219876'
alias: TEM01 - Update External Temp - Bathroom
description: ''
trigger:
- platform: state
entity_id: sensor.bathroom_air_temperature
condition: []
action:
- service: script.bathroom_temp_follow
data: {}
mode: queued
max: 10
I changed the automation to queued, as it sometime failed because it was already running.
Also, bear in mind that the script takes the average between the onboard sensor and the external one. So try sticking the external one in the fridge.
Have you tested when external temp sensor is measuring higher temperature than internal?
Based on my tests (firmware 1.12), it just seems to follow internal sensor value, ignoring external completely.
1 Like